|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [PATCH v2 06/14] x86/PVH: lift E820 alignment requirement
Before reordering things (to move in particular pvh_steal_ram()
invocations ahead of the pvh_populate_p2m() one) drop an undue (and as it
turns out unnecessary) assumption: find_memory() doesn't really depend on
E820 regions to end on page boundaries. (Note that the check of "start"
was pointless, as just before "start" was aligned to a page boundary.)
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
---
Really the assumption towards the start of regions doesn't look to be
relevant either, yet I thought I'd limit the change to the minimum needed.
---
v2: Drop leftover (pointless) assertion altogether. Further shrink
comment.
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -365,6 +365,9 @@ static __init void pvh_setup_e820(struct
* that's the minimum granularity of the 2nd stage translation. Since
* the p2m code uses PAGE_ORDER_4K internally, also use it here in
* order to prevent this code from getting out of sync.
+ *
+ * Note that this is only for pvh_populate_p2m(). Subsequent uses of
+ * pvh_steal_ram() will break the length part.
*/
start = ROUNDUP(entry->addr, PAGE_SIZE << PAGE_ORDER_4K);
end = (entry->addr + entry->size) &
@@ -505,10 +508,7 @@ static paddr_t __init find_memory(
PAGE_SIZE);
unsigned int i;
- /*
- * The memory map is sorted and all RAM regions starts and sizes are
- * aligned to page boundaries.
- */
+ /* The memory map is sorted. */
for ( i = 0; i < d->arch.nr_e820; i++ )
{
paddr_t start, end = d->arch.e820[i].addr + d->arch.e820[i].size;
@@ -519,8 +519,6 @@ static paddr_t __init find_memory(
start = MAX(ROUNDUP(d->arch.e820[i].addr, PAGE_SIZE), MB(1));
- ASSERT(IS_ALIGNED(start, PAGE_SIZE) && IS_ALIGNED(end, PAGE_SIZE));
-
/*
* NB: Even better would be to use rangesets to determine a suitable
* range, in particular in case a kernel requests multiple heavily
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |