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