[libvirt] [RFC] Support for CPUID masking
Hugh O. Brock
hbrock at redhat.com
Mon Oct 12 12:56:08 UTC 2009
On Sun, Oct 11, 2009 at 11:44:04AM +0200, Dor Laor wrote:
> On 10/09/2009 12:58 PM, Mukesh G wrote:
>> Speaking from an x86 angle,providing an ability to enable or disable
>> high level constructs like SSE instead of low level constructs, will
>> make it easy to understand.
>
> ain't SSE a low level construct too?
>
> What about another approach for the cpuid issue:
> I think that dealing with specific flags is pretty error prone on all
> levels - virt-mgr, libvirt, qemu, migration, and even the guest.
> We can't just 'invent' new cpu modules that will be a combination of
> flags we have on the host. It might work for some kernels/apps but it
> might break others. In addition to cpuid we have the stepping and more
> MSRs that needed to be hidden/exposed.
>
> The offer:
> Libvirt, virt-mgr, qemu will not deal with lowlevel bits of the cpuid.
> We'll use predefined cpu modules to be emulated.
> These predefined modules will represent a real module that was once
> shipped by Intel/AMD.
>
> We'll write an additional tool, not under libvirt, that will be able to
> calculate all the virtual cpus that can run over the physical cpu. This
> tool will be the one messing with /proc/cpuinfo, etc.
>
> Example (theoretical): Physical cpu is "Intel(R) Core(TM)2 Duo CPU T9600
> @ 2.80GHz" the output of the tool will be:
> shell>computeVirtCpuCapabilities
> core2duo
> core solo
> 486
> pentium3
> ..
>
> Libvirt will only expose the real physical cpu and all of the outputs
> above. Higher level mgmt will compute the best -cpu to pick for the VM,
> and it will take account the user needs for performance or for migration
> flexibility.
>
>
> The cons:
> - Simple for all levels
> - Fast implementation
> - Accurate representative of real cpus
>
> The pros:
> - none - we should write the tool anyway
> - Maybe we hide some of the possibilities, but as said above, it is
> safer and friendlier.
> I also recommend of adding a field to be added next to the cpu for
> flexibility and possible future changes + dealing with problematic
> bios with NX bit disabled.
>
> Regards,
> Dor
Dan was discussing something quite like this early on, IIRC...
--Hugh
>
>>
>> Thanks
>>
>> Mukesh
>>
>> On Thu, Sep 3, 2009 at 3:09 PM, Daniel P. Berrange<berrange at redhat.com> wrote:
>>> 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 at redhat.com
>>> https://www.redhat.com/mailman/listinfo/libvir-list
>>>
>
> --
> Libvir-list mailing list
> Libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
More information about the libvir-list
mailing list