From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
David Vrabel <david.vrabel@citrix.com>,
xen-devel@lists.xen.org
Subject: Re: [PATCH 1/2] x86/xen: set regions above the end of RAM as 1:1
Date: Fri, 3 Jan 2014 13:34:20 -0500 [thread overview]
Message-ID: <20140103183420.GB28915@phenom.dumpdata.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1401031805160.8667@kaball.uk.xensource.com>
On Fri, Jan 03, 2014 at 06:12:26PM +0000, Stefano Stabellini wrote:
> On Fri, 3 Jan 2014, David Vrabel wrote:
> > From: David Vrabel <david.vrabel@citrix.com>
> >
> > PCI devices may have BARs located above the end of RAM so mark such
> > frames as identity frames in the p2m (instead of the default of
> > missing).
> >
> > PFNs outside the p2m (above MAX_P2M_PFN) are also considered to be
> > identity frames for the same reason.
> >
> > Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>
> Shouldn't this be the case only for dom0?
You can have PV guests with PCI passthrough that depend on identity
MFNs.
Which is interesting - because if we do not have the E820 setup
to reflect the memory correct (and especially the MMIO regions), we
are screwed. Unless the user boots this PV guest with memory right
up to the MMIO BAR.
The 'e820_hole=1' parameter helps in fabricating an E820 for PV
guests that looks like the hosts - with the nice mix of E820_RSV
and MMIO bars.
>
>
> > arch/x86/xen/p2m.c | 2 +-
> > arch/x86/xen/setup.c | 10 ++++++++++
> > 2 files changed, 11 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> > index 2ae8699..a905355 100644
> > --- a/arch/x86/xen/p2m.c
> > +++ b/arch/x86/xen/p2m.c
> > @@ -481,7 +481,7 @@ unsigned long get_phys_to_machine(unsigned long pfn)
> > unsigned topidx, mididx, idx;
> >
> > if (unlikely(pfn >= MAX_P2M_PFN))
> > - return INVALID_P2M_ENTRY;
> > + return IDENTITY_FRAME(pfn);
> >
> > topidx = p2m_top_index(pfn);
> > mididx = p2m_mid_index(pfn);
> > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> > index 68c054f..6d7798f 100644
> > --- a/arch/x86/xen/setup.c
> > +++ b/arch/x86/xen/setup.c
> > @@ -412,6 +412,16 @@ char * __init xen_memory_setup(void)
> > max_pfn = min(MAX_DOMAIN_PAGES, last_pfn);
> > mem_end = PFN_PHYS(max_pfn);
> > }
> > +
> > + /*
> > + * Set the rest as identity mapped, in case PCI BARs are
> > + * located here.
> > + *
> > + * PFNs above MAX_P2M_PFN are considered identity mapped as
> > + * well.
> > + */
> > + set_phys_range_identity(max_pfn + 1, ~0ul);
> > +
>
> Wouldn't this increase the size of the P2M considerably?
Yes. The P2M[4->500] parts will end up being allocated (if you
boot with a 4GB guest/dom0). One thought I had was to have a
p2m_top_missing to be a 'P2M' 'identity' type so you don't waste
that much memory. Similary to how the checks are done against
'p2m_missing' right now.
The neat thing with this patch is that regions _after_ the P2M
(so past the 500GB) are solved with this patch.
(which is what the original bug was about).
>
>
> > * Clamp the amount of extra memory to a EXTRA_MEM_RATIO
> > * factor the base size. On non-highmem systems, the base
> > --
> > 1.7.2.5
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2014-01-03 18:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-03 16:45 [PATCH RFC 0/2] Linux: possible ixes for mapping high MMIO regions David Vrabel
2014-01-03 16:45 ` [PATCH 1/2] x86/xen: set regions above the end of RAM as 1:1 David Vrabel
2014-01-03 18:12 ` Stefano Stabellini
2014-01-03 18:34 ` Konrad Rzeszutek Wilk [this message]
2014-01-06 11:20 ` David Vrabel
2014-01-03 16:45 ` [PATCH 2/2] x86/xen: make mfn_to_pfn() work with MFNs that are 1:1 in the p2m David Vrabel
2014-01-03 18:13 ` Stefano Stabellini
2014-01-03 18:27 ` Konrad Rzeszutek Wilk
2014-01-03 18:35 ` [PATCH RFC 0/2] Linux: possible ixes for mapping high MMIO regions Konrad Rzeszutek Wilk
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=20140103183420.GB28915@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=stefano.stabellini@eu.citrix.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.