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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list