Re: [Xen-devel] [PATCH v2 02/13] iommu: introduce the concept of BFN...

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.07.18 at 16:08, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: dunlapg@xxxxxxxxx [mailto:dunlapg@xxxxxxxxx] On Behalf Of
>> George Dunlap
>> Sent: 10 July 2018 14:47
>> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
>> Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>; Kevin Tian
>> <kevin.tian@xxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>;
>> Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>; Julien Grall
>> <julien.grall@xxxxxxx>; Jan Beulich <jbeulich@xxxxxxxx>
>> Subject: Re: [Xen-devel] [PATCH v2 02/13] iommu: introduce the concept of
>> BFN...
>> 
>> On Sat, Jul 7, 2018 at 12:05 PM, Paul Durrant <paul.durrant@xxxxxxxxxx>
>> wrote:
>> 
>> > @@ -651,34 +651,34 @@ int amd_iommu_map_page(struct domain *d,
>> unsigned long gfn, unsigned long mfn,
>> >      if ( rc )
>> >      {
>> >          spin_unlock(&hd->arch.mapping_lock);
>> > -        AMD_IOMMU_DEBUG("Root table alloc failed, gfn = %lx\n", gfn);
>> > +        AMD_IOMMU_DEBUG("Root table alloc failed, bfn = %lx\n", bfn);
>> >          domain_crash(d);
>> >          return rc;
>> >      }
>> >
>> >      /* Since HVM domain is initialized with 2 level IO page table,
>> > -     * we might need a deeper page table for lager gfn now */
>> > +     * we might need a deeper page table for wider bfn now */
>> 
>> Oh, come on, no lager gfns? ;-)
>> 
>> > @@ -2737,10 +2737,12 @@ static void
>> arm_smmu_iommu_domain_teardown(struct domain *d)
>> >         xfree(xen_domain);
>> >  }
>> >
>> > -static int __must_check arm_smmu_map_page(struct domain *d,
>> unsigned long gfn,
>> > +static int __must_check arm_smmu_map_page(struct domain *d,
>> unsigned long bfn,
>> >                         unsigned long mfn, unsigned int flags)
>> >  {
>> >         p2m_type_t t;
>> > +       unsigned long frame = bfn;
>> > +       unsigned long gfn;
>> 
>> I don't understand what the poind of these temporary variables are.
>> They don't seem to really add any information at this point.
> 
> I added these at Jan's request. I can defer introducing them to the later 
> patch introducing typesafe bfns and gfns if that's preferable. The eventual 
> code will be the same.

Hmm, I've just gone back to my replies on v1, and I can't find any
request like that. Is this perhaps a transformation of me having said
"I'd prefer if such could at least be accompanied by a comment
clarifying why this mix of address spaces is correct in the specific
case"?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel