[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Thu, Jan 19, 2017 at 01:29:15AM -0700, Jan Beulich wrote:
> >>> On 18.01.17 at 20:56, <elena.ufimtseva@xxxxxxxxxx> wrote:
> > I am looking at rmrr_identity_mapping where the RMRR paddr get converted
> > to pfn and then mapped with iommu.
> > If ( rmrr->end_address & ~PAGE_SHIFT_MASK_4K ) == 0, the while loop
> >     while ( base_pfn < end_pfn )
> >  will not map that inclusive end_address of rmrr.
> > Does it seem wrong?
> 
> I don't think so, no. end_pfn is being calculated using
> PAGE_ALIGN_4K(), i.e. rounding up.

I mean to say, if the end address is already aligned, then the page wont
be mapped.
For example, if end paddr is 0x00000000000ed000, end_pfn will be
0x00000000000ed and wont be mapped in the loop
while ( base_pfn < end_pfn ).
And we will have mapped RMRR end address saved in arch.mapped_rmrrs
as 0x00000000000ed000.
Looks like parsed ACPI RMRR end addresses are extended to end of the
page though. Not sure if there is somewhere same boundary alignment in
code similar to what you proposed below.

> 
> >> > +        rmrr->segment = seg;
> >> > +        rmrr->base_address = pfn_to_paddr(user_rmrrs[i].base_pfn);
> >> > +        rmrr->end_address = pfn_to_paddr(user_rmrrs[i].end_pfn + 1);
> >> 
> >> "And this seems wrong too, unless I'm mistaken with the inclusive-ness."
> >> 
> > This one is the avoidance of the while loop mapping in
> > rmrr_identity_mapping.
> 
> Well, that's the purpose you describe, but the comment was about
> the calculation itself, which I think is lacking a "- 1", but even better
> would be - for avoiding boundary issues -
> 
>         rmrr->end_address = pfn_to_paddr(user_rmrrs[i].end_pfn) | ~PAGE_MASK;

Yes, this will eliminate this problem. This will need to be accounted
for in overlapping condition as well.

> 
> or some such.
> 
> Jan
> 

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.