On Wed, Jul 24, 2013 at 11:03:03AM +0100, Daniel P. Berrange wrote:
On Tue, Jul 23, 2013 at 07:28:38PM +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.
Is there no ioctl() for the KVM module we can just invoke directly to
discover what CPU flag filtering it will perform. Presumably QEMU is
using some ioctl to discover this, so libvirt ought to be able to
too.
Yes, there is: GET_SUPPORTED_CPUID. But availability of some features
may depend on QEMU capabilities as well. On those cases libvirt may need
to combine the GET_SUPPORTED_CPUID results with what it knows about QEMU
capabilities. But this should work as long as we report and document
QEMU capabilities/options that affect CPU features very clearly.
That may be an appropriate way to go to, if you don't mind having
low-level KVM ioctl() code inside libvirt, that duplicates some QEMU
logic.
(But we still have the problem of querying/reporting CPU feature details
that depend on machine-type+CPU-model [that is not addressed by this
series yet]. See my previous message about it)
--
Eduardo