[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: xen: memory initialization/balloon fixes (#3)
> Er. We don't really but I think this if needs to be: > > /* > * Page align regions. > * > * Reduce RAM regions and expand other (reserved) regions. > */ > if (type == E820_RAM || type == E820_UNUSABLE) { > start = PAGE_ALIGN(start); > end &= ~((u64)PAGE_SIZE - 1); > } else { > start &= ~((u64)PAGE_SIZE - 1); > end = PAGE_ALIGN(start); > } > > So reserved regions also become page aligned (which is part of the fix > for the dmidecode bug). I am not sure actually that is required for the e820_* calls. As those are used by 'ioremap' and memory buddy system and they only care about the RAM regions. Everybody else assumes that the "gaps" and "anything-but -RAM-regions" are OK - as long as they don't touch the RAM regions. It certainly is required for the set_phys_to_identity(..) call. I am trying here to be sure we don't mess it up - and I don't know what the right answer is for e820_* calls. Well, I do know what the right answer if for RAM regions - they must be page-aligned. But for reserved/non-RAM/ACPI/ACPI-NVS... ? BIOS-e820: 00000000dfe8ac00 - 00000000dfe8cc00 (ACPI NVS) BIOS-e820: 00000000dfe8cc00 - 00000000dfe8ec00 (ACPI data) .. snip.. reserve RAM buffer: 00000000dfe8ac00 - 00000000dfffffff or say: BIOS-e820: 00000000bff66f00 - 00000000bff76300 (ACPI data) .. [ 1.026860] reserve RAM buffer: 00000000bff66f00 - 00000000bfffffff They all seem to work OK without being page-aligned. I think we can drop the page-alignment on non-RAM regions when we give it to e820_*. We want to diverge as little as possible from what baremetal does. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |