From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Feng Wu <feng.wu@intel.com>,
venu.busireddy@oracle.com, xen-devel@lists.xen.org
Subject: Re: [PATCH v13 3/3] iommu: add rmrr Xen command line option for extra rmrrs
Date: Thu, 19 Jan 2017 09:44:43 -0800 [thread overview]
Message-ID: <20170119174443.GA2043@localhost.localdomain> (raw)
In-Reply-To: <588086EB0200007800131AF7@prv-mh.provo.novell.com>
On Thu, Jan 19, 2017 at 01:29:15AM -0700, Jan Beulich wrote:
> >>> On 18.01.17 at 20:56, <elena.ufimtseva@oracle.com> 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@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-01-19 17:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-10 22:57 [PATCH v13 0/3] iommu: add rmrr Xen command line option Venu Busireddy
2017-01-10 22:57 ` [PATCH v13 1/3] iommu VT-d: separate rmrr addition function Venu Busireddy
2017-01-11 12:39 ` Jan Beulich
2017-01-10 22:57 ` [PATCH v13 2/3] pci: add wrapper for parse_pci Venu Busireddy
2017-01-10 22:57 ` [PATCH v13 3/3] iommu: add rmrr Xen command line option for extra rmrrs Venu Busireddy
2017-01-12 11:44 ` Jan Beulich
2017-01-18 19:56 ` Elena Ufimtseva
2017-01-19 8:29 ` Jan Beulich
2017-01-19 17:44 ` Elena Ufimtseva [this message]
2017-01-20 8:30 ` Jan Beulich
2017-01-11 5:55 ` [PATCH v13 0/3] iommu: add rmrr Xen command line option Tian, Kevin
2017-01-11 15:53 ` Venu Busireddy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170119174443.GA2043@localhost.localdomain \
--to=elena.ufimtseva@oracle.com \
--cc=JBeulich@suse.com \
--cc=feng.wu@intel.com \
--cc=kevin.tian@intel.com \
--cc=konrad.wilk@oracle.com \
--cc=venu.busireddy@oracle.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).