Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/11/2012 07:41 AM, Gleb Natapov wrote:
> On Sat, Mar 10, 2012 at 12:58:43PM -0300, Eduardo Habkost wrote:
>> On Sat, Mar 10, 2012 at 12:42:46PM +0000, Daniel P. Berrange wrote:
>>>>
>>>> I could have sworn we had this discussion a year ago or so, and had decided
>>>> that the default CPU models would be in something like /usr/share/qemu/cpu-x86_64.conf
>>>> and loaded regardless of the -nodefconfig setting. /etc/qemu/target-x86_64.conf
>>>> would be solely for end user configuration changes, not for QEMU builtin
>>>> defaults.
>>>>
>>>> But looking at the code in QEMU, it doesn't seem we ever implemented this ?
>>>
>>> Arrrgggh. It seems this was implemented as a patch in RHEL-6 qemu RPMs but,
>>> contrary to our normal RHEL development practice, it was not based on
>>> a cherry-pick of an upstream patch :-(
>>>
>>> For sake of reference, I'm attaching the two patches from the RHEL6 source
>>> RPM that do what I'm describing
>>>
>>> NB, I'm not neccessarily advocating these patches for upstream. I still
>>> maintain that libvirt should write out a config file containing the
>>> exact CPU model description it desires and specify that with -readconfig.
>>> The end result would be identical from QEMU's POV and it would avoid
>>> playing games with QEMU's config loading code.
>>
>> I agree that libvirt should just write the config somewhere. The problem
>> here is to define: 1) what information should be mandatory on that
>> config data; 2) who should be responsible to test and maintain sane
>> defaults (and where should they be maintained).
>>
>> The current cpudef definitions are simply too low-level to require it to
>> be written from scratch. Lots of testing have to be done to make sure we
>> have working combinations of CPUID bits defined, so they can be used as
>> defaults or templates. Not facilitating reuse of those tested
>> defauls/templates by libvirt is duplication of efforts.
>>
>> Really, if we expect libvirt to define all the CPU bits from scratch on
>> a config file, we could as well just expect libvirt to open /dev/kvm
>> itself and call the all CPUID setup ioctl()s itself. That's how
>> low-level some of the cpudef bits are.
>>
> s/some/all
>
> If libvirt assumes anything about what kvm actually supports it is
> working only by sheer luck.

Well the simple answer for libvirt is don't use -nodefconfig and then it can 
reuse the CPU definitions (including any that the user adds).

Really, what's the point of having a layer of management if we're saying that 
doing policy management is too complicated for that layer?  What does that layer 
exist to provide then?

>> (Also, there are additional low-level bits that really have to be
>> maintained somewhere, just to have sane defaults. Currently many CPUID
>> leafs are exposed to the guest without letting the user control them,
>> and worse: without keeping stability of guest-visible bits when
>> upgrading Qemu or the host kernel. And that's what machine-types are
>> for: to have sane defaults to be used as base.)
>>
>> Let me give you a practical example: I had a bug report about improper
>> CPU topology information[1]. After investigating it, I have found out
>> that the "level" cpudef field is too low; CPU core topology information
>> is provided on CPUID leaf 4, and most of the Intel CPU models on Qemu
>> have level=2 today (I don't know why). So, Qemu is responsible for
>> exposing CPU topology information set using '-smp' to the guest OS, but
>> libvirt would have to be responsible for choosing a proper "level" value
>> that makes that information visible to the guest. We can _allow_ libvirt
>> to fiddle with these low-level bits, of course, but requiring every
>> management layer to build this low-level information from scratch is
>> just a recipe to waste developer time.
> And QEMU become even less usable from a command line. One more point to
> kvm-tool I guess.

I'm not sure what your point is.  We're talking about an option that humans 
don't use.  How is this a discussion about QEMU usability?

Regards,

Anthony Liguori