Re: [PATCH 3/4] qemu: validate machine virt ras feature

On a Thursday in 2024, Michal Prívozník wrote: > On 4/24/24 16:59, Kristina Hanicova wrote: > > case VIR_DOMAIN_FEATURE_RAS: > > + if (def->features[i] == VIR_TRISTATE_SWITCH_ON && > > + !qemuDomainIsARMVirt(def)) { > > + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", > > + _("ras feature is only supported with ARM Virt machines")); > > + return -1; > > + } > > + if (def->features[i] == VIR_TRISTATE_SWITCH_ON && > > + !virQEMUCapsGet(qemuCaps, QEMU_CAPS_MACHINE_VIRT_RAS)) { > > Just realized, this checks for the capability only when: > > <features> > <ras state='on'/> > </features> > > But the next patch adds 'ras=' onto cmd line even for the following case: > > <ras state='off'/> > > But unfortunately, I don't think we have a good way out. How I see our > options: > > 1) check for != VIR_TRISTATE_SWITCH_ABSENT here, just like we're doing > in the next patch. Problem is, when user specifies <ras state='off'/> > and we're talking to an older QEMU (say 4.2.0), which doesn't support > (toggling) the feature, well then users are would be unable to start > such guest. Even though the feature might already be off by default. I prefer this one. Don't see any point in toggling a feature that: 1) was not even present in the QEMU they're using 2) is currently off by default and possibly will be for some time.