src/qemu/qemu_capabilities.c | 362 ++++++++++++++++++++++++++++++++++++++++++- src/qemu/qemu_capabilities.h | 9 ++ src/qemu/qemu_driver.c | 29 ++++ src/qemu/qemu_monitor_json.c | 34 ++-- 4 files changed, 414 insertions(+), 20 deletions(-)
Some architectures (S390) depend on QEMU to compute baseline CPU model. Interacting with QEMU requires starting the QEMU process and completing one or more query-cpu-model-baseline QMP exchanges with QEMU. This patch set depends on qemuMonitorGetCPUModelBaseline function exposed by "query-cpu-model-baseline QMP Command" patch set discussed previously on libvir-list. See "s390x CPU models: exposing features" patch set on Qemu-devel for discussion of QEMU aspects. This is part of resolution of: https://bugzilla.redhat.com/show_bug.cgi?id=1511999 Signed-off-by: Chris Venteicher <cventeic@redhat.com> Chris Venteicher (7): qemu_monitor_json: Properties optional in QMP JSON for CPUModelInfo qemu_capabilities: CPUModelInfo: XML/QMP format conversion qemu_capabilities: Start and connect to QEMU qemu_capabilities: Baseline CPUModel via QEMU qemu_capabilities: Find QEMU binary for S390 arch qemu_capabilities: qmperr pointer tracked in QMPCommand qemu_driver: Baseline CPU model using QEMU src/qemu/qemu_capabilities.c | 362 ++++++++++++++++++++++++++++++++++++++++++- src/qemu/qemu_capabilities.h | 9 ++ src/qemu/qemu_driver.c | 29 ++++ src/qemu/qemu_monitor_json.c | 34 ++-- 4 files changed, 414 insertions(+), 20 deletions(-) -- 2.14.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Sat, May 05, 2018 at 12:48:42 -0500, Chris Venteicher wrote: > Some architectures (S390) depend on QEMU to compute baseline CPU model. > > Interacting with QEMU requires starting the QEMU process and completing one or > more query-cpu-model-baseline QMP exchanges with QEMU. > > > This patch set depends on qemuMonitorGetCPUModelBaseline function exposed by > "query-cpu-model-baseline QMP Command" patch set discussed previously on > libvir-list. Since patch 1/7 changes some code introduced in the series implementing query-cpu-model-baseline support, please send patches for both series at once next time and (as already suggested by Collin) squash the changes to the patches which introduced the code you're fixing here in 1/7. Overall, I think the approach of making the monitor API work on CPUModelInfo is better than the one using CPUDef because the monitor code in general does not have all data it could potentially need to perform the translation. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 05/17/2018 04:15 PM, Jiri Denemark wrote: > On Sat, May 05, 2018 at 12:48:42 -0500, Chris Venteicher wrote: >> Some architectures (S390) depend on QEMU to compute baseline CPU model. >> >> Interacting with QEMU requires starting the QEMU process and completing one or >> more query-cpu-model-baseline QMP exchanges with QEMU. >> >> >> This patch set depends on qemuMonitorGetCPUModelBaseline function exposed by >> "query-cpu-model-baseline QMP Command" patch set discussed previously on >> libvir-list. > > Since patch 1/7 changes some code introduced in the series implementing > query-cpu-model-baseline support, please send patches for both series at > once next time and (as already suggested by Collin) squash the changes > to the patches which introduced the code you're fixing here in 1/7. > > Overall, I think the approach of making the monitor API work on > CPUModelInfo is better than the one using CPUDef because the monitor > code in general does not have all data it could potentially need to > perform the translation. > > Jirka I can agree with this. qemuMonitorCPUModelInfo is simpler and has everything qmp needs. I also concur with your response to 2/7. Translating ModelInfo -> CPUDef and using the existing CPUDef -> XML functions is the way to go. Since we're getting a closer to an agreement on how this API should work, I could respin my comparison patches with what we've learned thus far to see how they look. Otherwise, I have no problem waiting until we come up with something more definitive -- I have plenty to keep me busy in the meantime :) > > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list > -- Respectfully, - Collin Walling -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Quoting Collin Walling (2018-05-17 16:07:14) > On 05/17/2018 04:15 PM, Jiri Denemark wrote: > > On Sat, May 05, 2018 at 12:48:42 -0500, Chris Venteicher wrote: > >> Some architectures (S390) depend on QEMU to compute baseline CPU model. > >> > >> Interacting with QEMU requires starting the QEMU process and completing one or > >> more query-cpu-model-baseline QMP exchanges with QEMU. > >> > >> > >> This patch set depends on qemuMonitorGetCPUModelBaseline function exposed by > >> "query-cpu-model-baseline QMP Command" patch set discussed previously on > >> libvir-list. > > > > Since patch 1/7 changes some code introduced in the series implementing > > query-cpu-model-baseline support, please send patches for both series at > > once next time and (as already suggested by Collin) squash the changes > > to the patches which introduced the code you're fixing here in 1/7. > > > > Overall, I think the approach of making the monitor API work on > > CPUModelInfo is better than the one using CPUDef because the monitor > > code in general does not have all data it could potentially need to > > perform the translation. > > > > Jirka > > I can agree with this. qemuMonitorCPUModelInfo is simpler and has everything > qmp needs. > > I also concur with your response to 2/7. Translating ModelInfo -> CPUDef > and using the existing CPUDef -> XML functions is the way to go. > > Since we're getting a closer to an agreement on how this API should work, > I could respin my comparison patches with what we've learned thus far to > see how they look. Otherwise, I have no problem waiting until we come up > with something more definitive -- I have plenty to keep me busy in the > meantime :) > Thanks for the feedback. Most of the comments make immediate sense. The rest I will need a few days in the code to dig deeper to understand. Jirka, - Looks like S390 support for baseline / compare still needs to be added to your "new cpu related apis". (Exchanging QMP messages so QEMU can do the baseline / compare operation.) The baseline patches I am working on should add S390 support to your new cpu related apis. - Looks like S390 support should still be added to virsh cpu-baseline (and cpu-compare) but there are dependencies on the changes made in the "new cpu related apis" patch set. Collin, This is my main task right now but the code is new to me so it might take a week or two to get to a new patch set for baseline. Thanks, Chris > > > > -- > > libvir-list mailing list > > libvir-list@redhat.com > > https://www.redhat.com/mailman/listinfo/libvir-list > > > > > -- > Respectfully, > - Collin Walling > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Sat, May 19, 2018 at 08:31:50 -0500, Chris Venteicher wrote: > Most of the comments make immediate sense. > The rest I will need a few days in the code to dig deeper to understand. > > Jirka, > - Looks like S390 support for baseline / compare still needs to be added to your > "new cpu related apis". (Exchanging QMP messages so QEMU can do the baseline > / compare operation.) > The baseline patches I am working on should add S390 support to your new cpu > related apis. Yes, the s390 code would just fit in a new "else if (ARCH_IS_S390(arch))" branch in qemuConnectCompareHypervisorCPU. > - Looks like S390 support should still be added to virsh cpu-baseline (and > cpu-compare) but there are dependencies on the changes made in the "new cpu > related apis" patch set. No, the old APIs won't get any support for s390. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2024 Red Hat, Inc.