[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.