[libvirt PATCH 5/5] qemu: wire up support for maximum CPU model
Pavel Hrdina
phrdina at redhat.com
Tue Feb 9 16:37:17 UTC 2021
On Tue, Feb 09, 2021 at 05:33:28PM +0100, Pavel Hrdina wrote:
> On Tue, Feb 09, 2021 at 01:59:01PM +0000, Daniel P. Berrangé wrote:
> > The "max" model can be treated the same way as "host" model in general.
> >
> > Signed-off-by: Daniel P. Berrangé <berrange at redhat.com>
> > ---
> > 94 files changed, 431 insertions(+), 73 deletions(-)
> >
> > diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> > index ecfb313d0a..58e28c3bd1 100644
> > --- a/src/qemu/qemu_capabilities.c
> > +++ b/src/qemu/qemu_capabilities.c
> > @@ -2336,6 +2336,8 @@ virQEMUCapsIsCPUModeSupported(virQEMUCapsPtr qemuCaps,
> > return cpus && cpus->ncpus > 0;
> >
> > case VIR_CPU_MODE_MAXIMUM:
> > + return virQEMUCapsGet(qemuCaps, QEMU_CAPS_CPU_MAX);
> > +
> > case VIR_CPU_MODE_LAST:
> > break;
> > }
> > @@ -2985,7 +2987,7 @@ virQEMUCapsProbeQMPCPUDefinitions(virQEMUCapsPtr qemuCaps,
> > virQEMUCapsAccelPtr accel,
> > qemuMonitorPtr mon)
> > {
> > - qemuMonitorCPUDefsPtr defs = accel->cpuModels;
> > + qemuMonitorCPUDefsPtr defs;
> > size_t i;
> >
> > if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_DEFINITIONS))
> > @@ -2994,6 +2996,7 @@ virQEMUCapsProbeQMPCPUDefinitions(virQEMUCapsPtr qemuCaps,
> > if (virQEMUCapsFetchCPUDefinitions(mon, qemuCaps->arch, &accel->cpuModels) < 0)
> > return -1;
> >
> > + defs = accel->cpuModels;
>
> And there is the fix for the crash from previous patch, so please do it
> directly there.
>
> > for (i = 0; i < defs->ncpus; i++) {
> > if (STREQ_NULLABLE(defs->cpus[i].name, "max")) {
> > virQEMUCapsSet(qemuCaps, QEMU_CAPS_CPU_MAX);
> > @@ -5977,6 +5980,18 @@ virQEMUCapsFillDomainCPUCaps(virQEMUCapsPtr qemuCaps,
> > VIR_TRISTATE_SWITCH_OFF);
> > }
> >
> > + if (virQEMUCapsIsCPUModeSupported(qemuCaps, hostarch, domCaps->virttype,
> > + VIR_CPU_MODE_MAXIMUM,
> > + domCaps->machine)) {
> > + domCaps->cpu.maximum = true;
> > +
> > + domCaps->cpu.maximumMigratable.report = true;
> > + VIR_DOMAIN_CAPS_ENUM_SET(domCaps->cpu.maximumMigratable,
> > + VIR_TRISTATE_SWITCH_ON);
> > + VIR_DOMAIN_CAPS_ENUM_SET(domCaps->cpu.maximumMigratable,
> > + VIR_TRISTATE_SWITCH_OFF);
> > + }
> > +
> > if (virQEMUCapsIsCPUModeSupported(qemuCaps, hostarch, domCaps->virttype,
> > VIR_CPU_MODE_HOST_MODEL,
> > domCaps->machine)) {
>
> [...]
>
> > diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
> > index bf4ac19104..62a915e946 100644
> > --- a/src/qemu/qemu_validate.c
> > +++ b/src/qemu/qemu_validate.c
> > @@ -255,10 +255,11 @@ qemuValidateDomainDefFeatures(const virDomainDef *def,
> >
> > case VIR_DOMAIN_FEATURE_KVM:
> > if (def->kvm_features[VIR_DOMAIN_KVM_DEDICATED] == VIR_TRISTATE_SWITCH_ON &&
> > - (!def->cpu || def->cpu->mode != VIR_CPU_MODE_HOST_PASSTHROUGH)) {
> > + (!def->cpu || (def->cpu->mode != VIR_CPU_MODE_HOST_PASSTHROUGH &&
> > + def->cpu->mode != VIR_CPU_MODE_MAXIMUM))) {
> > virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> > _("kvm-hint-dedicated=on is only applicable "
> > - "for cpu host-passthrough"));
> > + "for cpu host-passthrough / maximum"));
> > return -1;
> > }
> > break;
> > @@ -396,7 +397,15 @@ qemuValidateDomainDefCpu(virQEMUDriverPtr driver,
> > * CUSTOM.
> > */
> > break;
> > +
> > case VIR_CPU_MODE_MAXIMUM:
> > + if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_CPU_MAX)) {
> > + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> > + _("maximum CPU is not supported by QEMU binary"));
>
> s/by QEMU/by this QEMU/
>
> > + return -1;
> > + }
> > + break;
> > +
> > case VIR_CPU_MODE_CUSTOM:
> > case VIR_CPU_MODE_LAST:
> > break;
>
> Otherwise looks good but it would need some changes if we do not trust
> QEMU to behave the same way for kvm and tcg.
>
> Pavel
No chages needed for the kvm vs tcg question so with the issues fixed
Reviewed-by: Pavel Hrdina <phrdina at redhat.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20210209/0d1830aa/attachment-0001.sig>
More information about the libvir-list
mailing list