[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/5] xen: use maximum reservation to limit amount of usable RAM
> > I ran this on three setups: > > > > 1) PV (domU) > > 2) PV+PCI (dom0) > > 3) PV+PCI+e820_hole=1 (domU) > > > > and then the same without this patch. > > > > Both the 2) and 3) worked correctly - the E820 had the same non-RAM regions > > and > > gaps - and the last RAM E820 entry was properly truncated. However, when it > > came to pure PV it was truncated more than it should: > > > > domU: domU: > > 0000000000000000 - 00000000000a0000 (usable) > > 0000000000000000 - 00000000000a0000 (usable) > > 00000000000a0000 - 0000000000100000 (reserved) 00000000000a0000 - > > 0000000000100000 (reserved) > > 0000000000100000 - 0000000040800000 (usable) | > > 0000000000100000 - 0000000040100000 (usable) > > > > (left has the old PV - without your patch). Which makes me think that there > > is something > > amiss in the toolstack? I used 'xl' (latest xen-unstable from today). > > What were you expecting? It looks like xl is either: specifying a memory > map that is larger than it should be or b) setting the maximum > reservation as too low. And if you asked for 1 GiB neither looks right. 'xm' is even worst. It ends up truncating it to 40000000 exactly. Anyhow, I chatted with Ian about it and also the thread "difference between xen hypervisor and common kernel on handling BIOS's e820 map" nails the coffin to this - there is no need anymore for that 8MB of extra space. So - off to look at your next set of patches :-) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |