[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/2] x86/xen: do not identity map UNUSABLE regions in the machine E820
On Fri, Aug 16, 2013 at 03:42:55PM +0100, David Vrabel wrote: > From: David Vrabel <david.vrabel@xxxxxxxxxx> > > If there are UNUSABLE regions in the machine memory map, dom0 will > attempt to map them 1:1 which is not permitted by Xen and the kernel > will crash. > > There isn't anything interesting in the UNUSABLE region that the dom0 > kernel needs access to so we can avoid making the 1:1 mapping and > treat it as RAM. > > We only do this for dom0, as we do not expect any domU to ever have a > UNUSABLE region in their pseudo-physical map. Hm, you are going to be disappointed that this is in libxl: /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948 "xen/setup: Inhibit resource API from using System RAM E820 gaps as PCI mem gaps" for full explanation. */ if (end > ram_end) src[i].type = E820_UNUSABLE; } > > This fixes a boot failure on hosts with tboot. > > tboot marks a region in the e820 map as unusable and the dom0 kernel > would attempt to map this region and Xen does not permit unusable > regions to be mapped by guests. > > (XEN) 0000000000000000 - 0000000000060000 (usable) > (XEN) 0000000000060000 - 0000000000068000 (reserved) > (XEN) 0000000000068000 - 000000000009e000 (usable) > (XEN) 0000000000100000 - 0000000000800000 (usable) > (XEN) 0000000000800000 - 0000000000972000 (unusable) > > tboot marked this region as unusable. > > (XEN) 0000000000972000 - 00000000cf200000 (usable) > (XEN) 00000000cf200000 - 00000000cf38f000 (reserved) > (XEN) 00000000cf38f000 - 00000000cf3ce000 (ACPI data) > (XEN) 00000000cf3ce000 - 00000000d0000000 (reserved) > (XEN) 00000000e0000000 - 00000000f0000000 (reserved) > (XEN) 00000000fe000000 - 0000000100000000 (reserved) > (XEN) 0000000100000000 - 0000000630000000 (usable) > > Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx> > --- > arch/x86/xen/setup.c | 21 +++++++++++++++++++++ > 1 files changed, 21 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index 056d11f..5a093b7 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -313,6 +313,17 @@ static void xen_align_and_add_e820_region(u64 start, u64 > size, int type) > e820_add_region(start, end - start, type); > } > > +void xen_ignore_unusable(struct e820entry *list, size_t map_size) > +{ > + struct e820entry *entry; > + unsigned int i; > + > + for (i = 0, entry = list; i < map_size; i++, entry++) { > + if (entry->type == E820_UNUSABLE) > + entry->type = E820_RAM; > + } > +} > + > /** > * machine_specific_memory_setup - Hook for machine specific memory setup. > **/ > @@ -353,6 +364,16 @@ char * __init xen_memory_setup(void) > } > BUG_ON(rc); > > + /* > + * Xen won't allow a 1:1 mapping to be created to UNUSABLE > + * regions, so if we're using the machine memory map leave the > + * region as RAM as it is in the pseudo-physical map. > + * > + * UNUSABLE regions are not expected in domUs. > + */ > + if (xen_initial_domain()) > + xen_ignore_unusable(map, memmap.nr_entries); > + > /* Make sure the Xen-supplied memory map is well-ordered. */ > sanitize_e820_map(map, memmap.nr_entries, &memmap.nr_entries); > > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |