[libvirt] [RFC] Support for CPUID masking

[Daniel P. Berrange]

On Thu, Sep 03, 2009 at 11:19:47AM +0300, Dor Laor wrote:
> On 09/02/2009 07:09 PM, Daniel P. Berrange wrote:
> >On Wed, Sep 02, 2009 at 11:59:39AM -0400, Jim Paris wrote:
> >>Jiri Denemark wrote:
> >>>Hi,
> >>>
> >>>We need to provide support for CPU ID masking. Xen and VMware ESX are 
> >>>examples
> >>>of current hypervisors which support such masking.
> >>>
> >>>My proposal is to define new 'cpuid' feature advertised in guest
> >>>capabilities:
> >>...
> >>><domain type='xen' id='42'>
> >>>     ...
> >>>     <features>
> >>>         <pae/>
> >>>         <acpi/>
> >>>         <apic/>
> >>>         <cpuid>
> >>>             <mask level='1' register='ebx'>
> >>>                 xxxx:xxxx:0000:1010:xxxx:xxxx:xxxx:xxxx
> >>>             </mask>
> >>...
> >>>What are your opinions about this?
> >>
> >>I think it's too low-level, and the structure is x86-specific.  QEMU
> >>and KVM compute their CPUID response based on arguments to the -cpu
> >>argument, e.g.:
> >>
> >>    -cpu core2duo,model=23,+ssse3,+lahf_lm
> >>
> >>I think a similar structure makes more sense for libvirt, where the
> >>configuration generally avoids big blocks of binary data, and the
> >>XML format should suit other architectures as well.
> >
> >I'm going back&  forth on this too. We essentially have 3 options
> >
> >  - Named CPU + flags/features
> >  - CPUID masks
> >  - Allow either
> >
> >
> >If we do either of the first two, we have to translate between the
> >two formats for one or more of the hypervisors. For the last one we
> >are just punting the problem off to applications.
> >
> >
> >If we choose CPUID, and made QEMU driver convert to named CPU + flags
> >we'd be stuck for non-x86 as you say.
> 
> Why is that? cpu model + flags may apply for other arch too.

If we have CPUID in the XML, there is no meaningful CPUID register
representation for sparc/ppc/arm/etc. It is an x86 concept, which
is almost certainly why QEMU uses named CPU models + named flags
instead of CPUID as is public facing config.

Xen/VMWare of course don't have this limitation since they only
really care about x86.

So really QEMU's  CPU model + flags approach is more generic albeit
being much more verbose to achieve the same level of expressivity.

> >If we chose named CPU + flags,  and made VMWare/Xen convert to raw
> >CPUID we'd potentially loose information if user had defined a config
> >with a raw CPUID mask outside context of libvirt.
> >
> >The other thing to remember is that CPUID also encodes sockets/cores/
> >threads  topology data, and it'd be very desirable to expose that in
> >a sensible fashion (ie not a bitmask).
> >
> >On balance i'm currently leaning to named CPU + flags + expliciti
> >topology data because although its harder to implement for Xen/VMWare
> >I think its much nicer to applications&  users. We might loose a tiny
> >bit of data in the CPU ->  named/flags conversion for Xen/VMWare but
> >I reckon we can get it good enough that most people won't really care
> >about that.
> >
> >Daniel
> 
> There are 2 more issues to consider:
> 1. The VMW approach with all the cpuid bits might be ok, the problem is
>    to map it into qemu model, will libvirt to that?

THe problem is that CPUID is not viable for non-x86 archs so can't
really be used as our master representation

> 2. If we use the qemu approach, the host information (cpuids) need to
>    travel to higher mgmt level in order to allow computation of
>    greatest common denominator.

Yes, whatever we decide for exposing guest CPU model/flags/etc should
be equally applied to the libvirt capabilities XML so that apps can
query physical host data

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|