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

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?

> > 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 :-)

> 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.

> 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.

> 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.