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