[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |