[Libvir] [PATCH] pae/nonpae capabilities for paravirt xen guests
I noticed that the guest capabilities on a xen dom0 always contain both the pae and nonpae feature - AFAIK, you can't mix pae/nonpae guests and hosts, and only one of the features should be there. The attached patch contains the obvious fix. David
On Fri, 2007-03-23 at 12:24 -0700, David Lutterkort wrote:
I noticed that the guest capabilities on a xen dom0 always contain both the pae and nonpae feature - AFAIK, you can't mix pae/nonpae guests and hosts, and only one of the features should be there.
The attached patch contains the obvious fix.
Jim Meyering pointed out that the newline after '<nonpae/>' was missing. The attached patch contains that. David
David Lutterkort wrote:
I noticed that the guest capabilities on a xen dom0 always contain both the pae and nonpae feature - AFAIK, you can't mix pae/nonpae guests and hosts, and only one of the features should be there.
The attached patch contains the obvious fix.
Actually, <pae/><nonpae/> was intentional, to indicate that both modes of operation could be used. (Perhaps the error, then, is that if PAE is not supported, <features><nonpae/></features> should be used?). Anyway, I don't really understand the specifics of selecting PAE and non-PAE for Xen guests, so I'll punt on this to Dan. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)
On Sun, Mar 25, 2007 at 03:48:41PM +0100, Richard W.M. Jones wrote:
David Lutterkort wrote:
I noticed that the guest capabilities on a xen dom0 always contain both the pae and nonpae feature - AFAIK, you can't mix pae/nonpae guests and hosts, and only one of the features should be there.
The attached patch contains the obvious fix.
Actually, <pae/><nonpae/> was intentional, to indicate that both modes of operation could be used. (Perhaps the error, then, is that if PAE is not supported, <features><nonpae/></features> should be used?). Anyway, I don't really understand the specifics of selecting PAE and non-PAE for Xen guests, so I'll punt on this to Dan.
Yes, as Rich says its perfectly valid to have both flags listed under the same architecture. We're actually dealing with a tri-state here rather than a boolean. Xen can support - PAE only (Xen i686 paravirt) - non-PAE only (Xen i686 paravirt) - PAE & non-PAE (Xen i686/x86_64 fullyvirt) That said, I'm not sure we've got the translation of Xen capabilities into XML quite right - I'm going to do some verification of a couple of other dev boxes with varying levels of Xen support / archicture mixes. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Fri, Mar 23, 2007 at 12:24:57PM -0700, David Lutterkort wrote:
I noticed that the guest capabilities on a xen dom0 always contain both the pae and nonpae feature - AFAIK, you can't mix pae/nonpae guests and hosts, and only one of the features should be there.
So it turned out to be a bit more complicated. The <guest> blocks are supposed to be keyed off (machine,os-type) tuples eg (i686,xen) or (x86_64,hvm), etc. The impl was in fact though doing a linear conversion from Xen's /sys/hypervisor/properties/capabilities which is keyed off a (machine,os-type,flags) tuple (where flags==pae). So we needed to collapse one level of cardinaility from the Xen data - hence the <pae/> & <nonpae/> flags can both be used at once. Anyway the collapsing was not correct, so I'm attaching a patch to address that. This does a couple of other things too - Re-factors xenGetCapabilities so that it merely opens the /proc & /sysfs files and then passes the handle down to xenMakeCapabilitiesXML method. - Adds a huge test suite which has a library of various cpuinfo & capabilities files from various archs and calls xenMakeCapabilitiesXML with all of them - Removes the <emulator> element from paravirt <guest> block since it is only relevant to HVM. - Adds PowerPC support Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Mon, Mar 26, 2007 at 08:39:16PM +0100, Daniel P. Berrange wrote:
On Fri, Mar 23, 2007 at 12:24:57PM -0700, David Lutterkort wrote:
I noticed that the guest capabilities on a xen dom0 always contain both the pae and nonpae feature - AFAIK, you can't mix pae/nonpae guests and hosts, and only one of the features should be there.
So it turned out to be a bit more complicated. The <guest> blocks are supposed to be keyed off (machine,os-type) tuples eg (i686,xen) or (x86_64,hvm), etc. The impl was in fact though doing a linear conversion from Xen's /sys/hypervisor/properties/capabilities which is keyed off a (machine,os-type,flags) tuple (where flags==pae). So we needed to collapse one level of cardinaility from the Xen data - hence the <pae/> & <nonpae/> flags can both be used at once.
Anyway the collapsing was not correct, so I'm attaching a patch to address that. This does a couple of other things too
Patch looks fine,
- Re-factors xenGetCapabilities so that it merely opens the /proc & /sysfs files and then passes the handle down to xenMakeCapabilitiesXML method. - Adds a huge test suite which has a library of various cpuinfo & capabilities files from various archs and calls xenMakeCapabilitiesXML with all of them
That is great !
- Removes the <emulator> element from paravirt <guest> block since it is only relevant to HVM.
I remember wondering a bit about the empty element a couple of weeks ago, good :-)
- Adds PowerPC support
Just one nitpick, what about raising an error at the unknown case in the switch: /* XXX surely no other Xen archs exist */ thanks a lot, being able to regression test more code is really cool ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
David Lutterkort -
Richard W.M. Jones