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

Re: [Xen-devel] [PATCH 1/2] x86/xen: set regions above the end of RAM as 1:1



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@xxxxxxxxxx>
> > 
> > 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@xxxxxxxxxx>
> 
> 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@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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


 


Rackspace

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