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

[Eduardo Habkost]

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)

-- 
Eduardo