Messages in this thread | | | Date | Fri, 8 Jan 2021 14:09:32 +0000 | From | Will Deacon <> | Subject | Re: [PATCH 2/5] iommu/vt-d: Fix unaligned addresses for intel_flush_svm_range_dev() |
| |
Hi Lu,
On Fri, Jan 08, 2021 at 07:52:47AM +0800, Lu Baolu wrote: > On 2021/1/6 9:09, Lu Baolu wrote: > > On 2021/1/6 3:03, Will Deacon wrote: > > > On Thu, Dec 31, 2020 at 08:53:20AM +0800, Lu Baolu wrote: > > > > @@ -170,6 +172,22 @@ static void intel_flush_svm_range_dev > > > > (struct intel_svm *svm, struct intel_svm_d > > > > } > > > > } > > > > +static void intel_flush_svm_range_dev(struct intel_svm *svm, > > > > + struct intel_svm_dev *sdev, > > > > + unsigned long address, > > > > + unsigned long pages, int ih) > > > > +{ > > > > + unsigned long shift = ilog2(__roundup_pow_of_two(pages)); > > > > + unsigned long align = (1ULL << (VTD_PAGE_SHIFT + shift)); > > > > + unsigned long start = ALIGN_DOWN(address, align); > > > > + unsigned long end = ALIGN(address + (pages << > > > > VTD_PAGE_SHIFT), align); > > > > + > > > > + while (start < end) { > > > > + __flush_svm_range_dev(svm, sdev, start, align >> > > > > VTD_PAGE_SHIFT, ih); > > > > + start += align; > > > > + } > > > > +} > > > > > > Given that this only seems to be called from > > > intel_invalidate_range(), which > > > has to compute 'pages' only to have it pulled apart again here, > > > perhaps it > > > would be cleaner for intel_flush_svm_range() to take something like an > > > 'order' argument instead? > > > > > > What do you think? > > > > We need to clean up here. It's duplicate with the qi_flush_piotlb() > > helper. I have a patch under testing for this. I will post it for review > > later. > > I'm sorry, above reply is a little vague. > > I meant to say, let's take 'pages' as the argument. We are going to use > qi_flush_piotlb() here to avoid duplicate QI interactions. The > qi_flush_piotlb() helper also takes 'pages', so keep 'pages' here will > make things easier. > > My cleanup patch is for v5.12. Can you please take this for v5.11?
Ah sorry, I didn't realise that was your plan. Please just include this patch in a series of 2 when you post a fixed version of the trace event removal and then I'll queue them up next week, as I've already prepared the pull for today.
Apologies,
Will
| |