Re: [libvirt] [RFC] Support for CPUID masking
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.
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
--
|: 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 :|