Re: [libvirt] [PATCH 4/7] qemu: Add monitor APIs to fetch CPUID data from QEMU

On Tue, Jul 23, 2013 at 07:32:46PM +0200, Jiri Denemark wrote: > On Tue, Jul 23, 2013 at 19:28:38 +0200, Jiri Denemark wrote: > > On Tue, Jul 23, 2013 at 17:32:42 +0100, Daniel Berrange wrote: > > > On Tue, Jul 23, 2013 at 06:11:33PM +0200, Jiri Denemark wrote: > > > > --- > > > > src/qemu/qemu_monitor.c | 21 +++ > > > > src/qemu/qemu_monitor.h | 3 + > > > > src/qemu/qemu_monitor_json.c | 162 +++++++++++++++++++++ > > > > src/qemu/qemu_monitor_json.h | 6 + > > > > tests/Makefile.am | 1 + > > > > .../qemumonitorjson-getcpu-empty.data | 2 + > > > > .../qemumonitorjson-getcpu-empty.json | 46 ++++++ > > > > .../qemumonitorjson-getcpu-filtered.data | 4 + > > > > .../qemumonitorjson-getcpu-filtered.json | 46 ++++++ > > > > .../qemumonitorjson-getcpu-full.data | 4 + > > > > .../qemumonitorjson-getcpu-full.json | 46 ++++++ > > > > .../qemumonitorjson-getcpu-host.data | 5 + > > > > .../qemumonitorjson-getcpu-host.json | 45 ++++++ > > > > tests/qemumonitorjsontest.c | 74 ++++++++++ > > > > 14 files changed, 465 insertions(+) > > > > create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-getcpu-empty.data > > > > create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-getcpu-empty.json > > > > create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-getcpu-filtered.data > > > > create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-getcpu-filtered.json > > > > create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-getcpu-full.data > > > > create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-getcpu-full.json > > > > create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-getcpu-host.data > > > > create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-getcpu-host.json > > > > > > ACK, though I believe the design of this monitor API is flawed > > > because it requires you to re-launch QEMU with different accel > > > args > > > > Not really, this can be used in tcg too. It's just when we want to get > > the data for "host" CPU, we need to enable kvm as tcg knows nothing > > about that CPU. Which makes sense as kvm (the kernel module) influences > > how the "host" CPU will look like. > > However, you need to have a CPU to be able to ask for his properties > (which kinda makes sense too) and for that you also need a machine with > type != none. Which makes sense too, as the CPU may differ depending on > machine type (which, however, does not happen for "host" CPU). In addition to the "-cpu host" KVM initialization problem, this is an additional problem with the current interfaces provided by QEMU: 1) libvirt needs to query data that depend on chosen machine-type and CPU model 2) Some machine-type behavior is code and not introspectable data * Luckily most of the data we need in this case should/will be encoded in the compat_props tables. * In either case, we don't have an API to query for machine-type compat_props information yet. 3) CPU model behavior will be modelled as CPU class behavior. Like on the machine-type case, some of the CPU-model-specific behavior may be modelled as code, and not introspectable data. * However, e may be able to eventually encode most or all of CPU-model-specific behavior simply as different per-CPU-class property defaults. * In either case, we don't have an API for QOM class introspection, yet. But there's something important in this case: the resulting CPUID data for a specific machine-type + CPU-model combination must be always the same, forever. This means libvirt may even use a static table, or cache this information indefinitely. (Note that I am not talking about "-cpu host", here, but about all the other CPU models)