Re: [libvirt] [RFC] Support for CPUID masking

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 :| -- Libvir-list mailing list Libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list