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

[Daniel Henrique Barboza]

On 3/23/20 9:34 PM, David Gibson wrote:
> On Mon, Mar 23, 2020 at 06:28:34PM +0100, Andrea Bolognani wrote:
>> On Thu, 2020-03-19 at 18:44 -0300, Daniel Henrique Barboza wrote:
>>> The Perfomance Monitoring Unit (PMU) feature is not available for
>>> the Power architecture. The "<pmu/>" feature will always have a value
>>> 'on' or 'off' after saving the domain XML, and both will be rejected
>>> by QEMU when launching. This is the error message for
>>> "<pmu state='on'/>":

[...]

>> So it seems to me that, if anything, the PMU feature should be
>> treated like the <panic/> device, that is, automatically added to
>> pSeries guests if it's not present already.
>>
>> David, what's your opinion on the matter?
> 
> You're correct.  The difference originates at the hardware level.  On
> x86 the host always "owns" the PMU, and it requires explicit work in
> KVM to make it available to the guest.  On POWER, the guest owns the
> PMU.  I'm not sure if it's possible to disable guest access to the PMU
> at all.  Even if it is, it must be some obscure bit in the HFCR or
> somewhere which I don't believe we've wired up at all.
> 
> So for now, certainly, pmu is effectively always on.
> 

Thanks for the info.

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'/>

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 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.



Thanks,


DHB