Re: [PATCH v1 3/4] qemu_domain.c: do not launch ppc64 guests with 'pmu' setting
On Tue, 2020-03-24 at 09:27 -0300, Daniel Henrique Barboza wrote:
Andrea, I see that the behavior of the 'panic' device in the
ppc64 XML is to
always add a:
<panic model='pseries'/>
Even if I remove it Libvirt will automatically added it back again. How do you
suggest we handle this PMU?
We can copy what 'panic' is doing, adding a
<pmu model='peries'/>
This is definitely not the right approach - we should use the
existing interface rather than try to come up with a new one.
In the XML just like 'panic' does. Or we can add the
'pmu' feature:
<feature>
<pmu/>
</feature>
PMU can't be left without a state ATM, thus this would translate to:
<feature>
<pmu state='on'/>
</feature>
This is what we should do.
This would require to add the whole <feature> element if none
is present as well. Both
requires some code tweaking here and there. I am not sure which one is better, although
the first option would require us to handle the <pmu> XML feature anyway since we
can't
have both, so there's that.
For the sake of completeness, I'll also mention that we can simply allow <pmu/>
to be
declared in the XML, handling the <pmu state='on'/> inside the QEMU driver
to not add the
bogus '.pmu' parameter for QEMU ppc64, forbid <pmu state='off'/> to
be declared, and
nothing else. No auto-generation of XML indicating that the guest will support a PMU.
Looking again at how other architectures, specifically x86 and ARM,
handle this, the PMU is generally enabled by default without this
fact being reflected in the domain XML; the user can then go ahead
and specifically ask for it to be turned on or off, at which point
libvirt will add the relevant bits to the QEMU command line.
This is basically the second behavior you're describing above, and
I think it would be perfectly fine if that's the one we would adopt
for ppc64.
--
Andrea Bolognani / Red Hat / Virtualization