[PATCH v1 3/4] qemu_domain.c: do not launch ppc64 guests with 'pmu' setting

Andrea Bolognani abologna at redhat.com
Tue Mar 24 14:00:04 UTC 2020


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




More information about the libvir-list mailing list