Re: [Xen-devel] [PATCH v14 3/3] iommu: add rmrr Xen command line option for extra rmrrs

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.01.17 at 16:35, <venu.busireddy@xxxxxxxxxx> wrote:
> On Tue, Jan 24, 2017 at 01:46:44AM -0700, Jan Beulich wrote:
>> >>> On 23.01.17 at 19:20, <venu.busireddy@xxxxxxxxxx> wrote:
>> > +        overlap = false;
>> > +        list_for_each_entry(rmrru, &acpi_rmrr_units, list)
>> > +        {
>> > +            if ( pfn_to_paddr(base) <= rmrru->end_address &&
>> > +                 rmrru->base_address <= pfn_to_paddr(end) )
>> 
>> So this now looks correct as long as rmrru->base_address is
>> page aligned (as required by the spec), which should be good
>> enough for now (considering that we make this assumption
>> elsewhere). Nevertheless it would have been nice if you had,
>> following the subsequent discussion with Elena, accounted for
>> spec violations here.
>> 
>> > +        rmrr->segment = seg;
>> > +        rmrr->base_address = pfn_to_paddr(user_rmrrs[i].base_pfn);
>> > +        /* Align the end_address to the end of the page */
>> > +        rmrr->end_address = pfn_to_paddr(user_rmrrs[i].end_pfn) | 
> ~PAGE_MASK_4K;
>> 
>> Hmm, Ive just checked - in my reply to Elena I had intentionally used
>> PAGE_MASK here (and I recall correcting it from PAGE_MASK_4K).
>> What has led you to use PAGE_MASK_4K here, when pfn_to_paddr()
>> uses PAGE_SHIFT?
> 
> Elena suggested to use PAGE_MASK_4K because the functions in
> drivers/passthrough/vtd/iommu.c (including rmrr_identity_mapping())
> use the _4K. With the current assumptions, both will work.

Granted this is somewhat of a mess, but I'd prefer if at least within
a single statement things would be consistent in which page size is
being meant.

> If you would like me to change this to PAGE_MASK, I will do so before
> committing. Please let me know.

As said, I don't see a need for you to re-submit, unless there are
other issues in need of taking care of.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel