[libvirt] [Qemu-devel] Qemu, libvirt, and CPU models

[Eduardo Habkost]

On Thu, Mar 08, 2012 at 02:41:54PM +0100, Jiri Denemark wrote:
> On Wed, Mar 07, 2012 at 19:26:25 -0300, Eduardo Habkost wrote:
> > Awesome. So, if Qemu and libvirt disagrees, libvirt will know that and
> > add the necessary flags? That was my main worry. If disagreement between
> > Qemu and libvirt is not a problem, it would make things much easier.
> > 
> > ...but:
> > 
> > Is that really implemented? I simply don't see libvirt doing that. I see
> > code that calls "-cpu ?" to list the available CPU models, but no code
> > calling "-cpu ?dump", or parsing the Qemu CPU definition config file. I
> > even removed some random flags from the Nehalem model on my machine
> > (running Fedora 16), and no additional flags were added.
> 
> Right, currently we only detect if Qemu knows requested CPU model and use
> another one if not. We should really start using something like -cpu ?dump.
> However, since qemu may decide to change parts of the model according to,
> e.g., machine type, we would need something more dynamic. Something like, "hey
> Qemu, this is the machine type and CPU model we want to use, these are the
> features we want in this model, and we also want few additional features,
> please, tell us what the resulting CPU configuration is (if it is even
> possible to deliver such CPU on current host)". And the result would be
> complete CPU model, which may of course be different from what the qemu's
> configuration file says. We could then use the result to update domain XML (in
> a way similar to how we handle machine types) so that we can guarantee the
> guest will always see the same CPU. Once CPU is updated, we could just check
> with Qemu if it can provide such CPU and start (or refuse to start) the
> domain. Does it seem reasonable?

Absolutely.

I would even advise libvirt to refrain from using "-cpu ?dump", as its
semantics are likely to change.

> > > We could go one step further and just write
> > > out a cpu.conf file that we load in QEMU with -loadconfig.
> > 
> > Sounds good. Anyway, I want to make everything configurable on the
> > cpudef config file configurable on the command-line too, so both options
> > (command-line or config file) would work.
> 
> I'd be afraid of hitting the command line length limit if we specified all CPU
> details in it :-)

True. I am already afraid of hitting the command-line length limit with
Qemu as-is right now.  ;-)


> > So, it looks like either I am missing something on my tests or libvirt
> > is _not_ probing the Qemu CPU model definitions to make sure libvirt
> > gets all the features it expects.
> > 
> > Also, I would like to ask if you have suggestions to implement
> > the equivalent of "-cpu ?dump" in a more friendly and extensible way.
> > Would a QMP command be a good alternative? Would a command-line option
> > with json output be good enough?
> 
> I quite like the possible solution Anthony (or perhaps someone else) suggested
> some time ago (it may however be biased by my memory): qemu could provide a
> command line option that would take QMP command(s) and the result would be QMP
> response on stdout. We could use this interface for all kinds of probes with
> easily parsed output.

This is another case where command-line limits could be hit, isn't it?
Reading QMP commands from a normal chardev (a socket, or even stdio) is
already available, we just need to make sure the "query QMP without ever
initializing a machine" use-case is working and really supported by
Qemu.

> > So, about the above: the cases where libvirt thinks a feature is
> > available but Qemu knows it is not available are sort-of OK today,
> > because Qemu would simply refuse to start and an error message would be
> > returned to the user.
> 
> Really? In my experience qemu just ignored the feature it didn't know about
> without any error message and started the domain happily. It might be because
> libvirt doesn't use anything like -cpu ...,check or whatever is needed to make
> it fail. However, I think we should fix it.

Correct, I was assuming that 'enforce' was being used. I forgot that
libvirt doesn't use it today.

I really think libvirt should be using 'enforce', the only problem is
that there may be cases where an existing VM was working (but with a
result unpredictable by by libvirt), and with 'enforce' it would stop
working. This is very likely to happen when using the defualt "qemu64"
CPU model, that has some AMD-only CPUID:8000_0000h bits set, but
everybody probably expects it to work on Intel CPU hosts too.

> 
> > But what about the features that are not available on the host CPU,
> > libvirt will think it can't be enabled, but that _can_ be enabled?
> > x2apic seems to be the only case today, but we may have others in the
> > future.
> 
> I think qemu could tell us about those features during the probe phase (my
> first paragraph) and we would either use them with policy='force' or something
> similar.

Yes, that's the conclusion I was trying to reach: we really need better
CPU feature probing.

-- 
Eduardo