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