On Fri, Mar 09, 2012 at 03:15:26PM -0600, Anthony Liguori wrote:
On 03/09/2012 03:04 PM, Daniel P. Berrange wrote:
>On Fri, Mar 09, 2012 at 05:56:52PM -0300, Eduardo Habkost wrote:
>>Resurrecting an old thread:
>>
>>I didn't see any clear conclusion in this thread (this is why I am
>>resurrecting it), except that many were arguing that libvirt should
>>simply copy and/or generate the CPU model definitions from Qemu. I
>>really don't think it's reasonable to expect that.
>>
>>On Thu, Dec 15, 2011 at 03:54:15PM +0100, Jiri Denemark wrote:
>>>Hi,
>>>
>>>Recently I realized that all modern CPU models defined in
>>>/etc/qemu/target-x86_64.conf are useless when qemu is used through libvirt.
>>>That's because we start qemu with -nodefconfig which results in qemu
ignoring
>>>that file with CPU model definitions. We have a very good reason for using
>>>-nodefconfig because we need to control the ABI presented to a guest OS and
we
>>>don't want any configuration file that can contain lots of things
including
>>>device definitions to be read by qemu. However, we would really like the new
>>>CPU models to be understood by qemu even if used through libvirt. What would
>>>be the best way to solve this?
>>>
>>>I suspect this could have been already discussed in the past but obviously a
>>>workable solution was either not found or just not implemented.
>>
>>So, our problem today is basically:
>>
>>A) libvirt uses -nodefconfig;
>>B) -nodefconfig makes Qemu not load the config file containing the CPU
>> model definitions; and
>>C) libvirt expects the full CPU model list from Qemu to be available.
>
>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 ?
I don't remember that discussion and really don't think I agree with the
conclusion.
If libvirt wants to define CPU models on their own, they can. If
It can't
without knowing qemu/host cpu/host kernel capabilities and
knowing the logic that qemu uses to combine them.
libvirt wants to use the user's definitions, don't use
-nodefconfig.
CPU models aren't a QEMU concept. The reason it's in the
I do not know
what do you mean by that, but CPU capabilities (and CPU
model is only a name for a group of them) are KVM/TCG concept and,
by inclusion, are QEMU concept. If QEMU will not have built in support
for CPU models (as a name for a group of CPU capabilities) then how do
you start a guest without specifying full set of CPU capabilities on a
command line?
configuration file is to allow a user to add their own as they see
fit. There is no right model names. It's strictly a policy.
So you think it should be user's responsibility to check what his
qemu/host cpu/host kernel combo can support?
--
Gleb.