On Thu, Apr 25, 2024 at 02:09:47PM GMT, Ján Tomko wrote:
> 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.
I agree with Jano. If you want the ability to explicitly control the
status of RAS support, then use a version of QEMU that implements the
necessary toggle.
--
Andrea Bolognani / Red Hat / Virtualization
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
