On Fri, Mar 01, 2013 at 02:12:38PM +0100, Jiri Denemark wrote: Also: more important than fixing the CPU definitions from libvirt, is to ask QEMU for host capabilities and CPU model definitions. The whole point of this is to solve the CPU model data duplication/synchronization problems between libvirt and QEMU. Once you are able to query CPU model definitions on runtime, you don't even need to make cpu_map.xml agree with QEMU. You can simply ask QEMU how each model looks like, and remove/add features from the command-line as necessary, so the resulting VM matches what the user asked for. If you query for the "-cpu host" capabilities first and ensure all features from a CPU model is available, enforce is supposed to not fail. I understand that a machine-friendly error reporting for "enforce" would be very useful, but note that if "enforce" fails, it is probably already too late for libvirt, and that means that what libvirt thinks about host capabilities and CPU models is already incorrect. The main problem preventing us from making a machine-friendly interface is that "enforce" makes QEMU abort immediately, making us lose the main machine-friendly communication mechanism, that is QMP. (But I had an idea to solve that, look for "removed-features" below for a description). Actually I don't know much about the QMP command syntax and didn't test it a lot. But that's basically how I think it will look like. Except that instead of "X86CPU", the type name is "x86_64-cpu" (on qemu-system-x86_64) and "i386-cpu" (on qemu-system-i386). Maybe it is easier to simply use: implements: "cpu", abstract: false }. We may also end up with different CPU model classes for KVM and TCG, this is still under discussion. Another caveat: the CPU model class names will be longer than the names used on the "-cpu" command-line: something like "<model>-<arch>-cpu" or "<model>-kvm-<arch>-cpu". The class data don't depend on machine-types. But the resulting CPU objects may look different depending on machine type. In other words: you don't need -M to list CPU models, but you need -M if you want to know which features are going to be available on each model, exactly. Maybe "complete machine" isn't the right expression, here. What I mean is: AFAIK, it is not possible to get a QMP monitor without actually having a machine being created by QEMU (even if it is a machine that will never run). But answering your question: to query the CPU model list you don't need the right machine type or anything fancy. "qemu -nodefaults" should work. But to query the exact CPU definition (the item below), you need to specify the right machine-type. query-cpu-definitions returns only the CPU model names, and a proposal to include more detailed CPUID information was rejected, IIRC. I believe we should deprecate query-cpu-definitions it in favor of the QOM commands. I just noticed another problem here, but this gave me an idea that would help solve the "enforce" error reporting problem: Problem: "qemu -machine <M> -cpu <model>" will create CPU objects where the CPU features are _already_ filtered based on host capabilities. * Using "enforce" wouldn't solve it, because then QEMU would abort, and QMP would be unavailable. Solution: we could have a CPU object property like "removed-features" that would have the list of features that were disabled because they are not supported by the host (and would make "enforce" fail). * This would solve the problem above and also be a machine-friendly way to check for possible "enforce" errors. * In other words: instead of "enforce", libvirt could use "check" instead of "enforce", and before unpausing the VM (or even starting migration), it should first check if the "removed-features" property is empty. Would that work for you? It is up to you, it depends on what the libvirt API promises. But I always assumed that the same libvirt XML config would always create an equivalent machine (with not guest-visible differences), it didn't matter on which host it is running. Otherwise you would have problems like: * A VM being migratable to another host and suddenly it stops being migratable just because it was restarted. * A VM being migratable from A to B when started on host A, but not migratable from B to A if exactly the same VM XML is started on host B. I am not familiar with the libvirt code, but maybe the only cases where you need to do the probing are: * virConnectCompareCPU() * virConnectBaselineCPU() (I don't understand completely what it does) * Before starting a VM, when using match={minimu,exact,strict}. * When "host-model"/VIR_DOMAIN_XML_UPDATE_CPU is used * When checking if a given VM is migratable to a specific host (before actually starting migration). How is that implemented today? But I worry that at some point you may need to list detailed information about every CPU model, and this would require running QEMU once for each CPU model. Would that be a huge problem, or something we can work with? I quickly tested how quick QEMU can answer QMP queries: $ time sh -c '(echo "{\"execute\":\"qmp_capabilities\"}";echo "{\"execute\":\"qom-list-types\", \"arguments\": {}}";echo "{\"execute\":\"quit\"}"; ) | qemu-system-x86_64 -S -nodefaults -cpu SandyBridge,check -qmp stdio -nographic' [...] real 0m0.038s user 0m0.024s sys 0m0.012s Maybe this is reasonable enough? You probably just need to do that before starting a VM you never started before (for the cases where you want to choose the CPU model that would generate the shorter command-line). Also, note that the resulting CPU features for a given machine-type + CPU pair is supposed to never ever change on any future QEMU version, so libvirt should be able to safely cache those values even if the QEMU binary changes. True. PS: I will be out of office for 3 weeks, starting tomorrow, so I will probably not be able to continue this discussion after today, until I'm back on 25/March. -- Eduardo

On Fri, Mar 01, 2013 at 11:56:00PM +0100, Jiri Denemark wrote: [...] To make the libvirt logic simpler, we could do this: have a "force" mode (in addition to check/enforce), that wouldn't filter any CPU feature based on host capabilities. This way libvirt wouldn't need any non-trivial logic to combine the "f-*" flags and "removed-features" to find out the CPU model details. Then libvirt would need to look only at "f-*" to find out the CPU model details at probing time (as long as "force" is used at probing time), and just make sure "removed-features" is empty before starting the VM (optionally parsing its value or checking the "f-*" property values, to find out which features are missing exactly). -- Eduardo

On Fri, Mar 01, 2013 at 07:31:46PM +0100, Andreas Färber wrote: Yep, Jiri is wrong here actually. -cpu parsing is what we used to do. With latest libvirt + QEMU we do use query-cpu-definitions and have no "help parsing" code used at all. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

On Fri, Mar 01, 2013 at 07:31:46PM +0100, Andreas Färber wrote: I have the same questions you have. :-) But my main complaint about query-cpu-definitions is not about the implementation: it's that the interface was introduced without taking into account the requirements of libvirt regarding CPU features. It was found to be not appropriate for what libvirt needs[1], but somehow it got applied anyway. [1] http://article.gmane.org/gmane.comp.emulators.qemu/164772 -- Eduardo

On Thu, Feb 21, 2013 at 11:58:18 -0300, Eduardo Habkost wrote: Actually, one more thing. Can any of these requirements change while a host is up and QEMU is not upgraded? I believe, host CPU capabilities can only change when the host starts. Kernel capabilities are a bit less clear since I guess they could possibly change when kvm module is unloaded and loaded back with a different options. QEMU capabilities should only change when different version is installed. And the specific configuration options are the most unclear to me. The reason I'm asking is whether libvirt could run-time cache CPU definitions (including all model details) in the same way we currently cache QEMU capabilities, such as availability of specific QMP commands. Jirka