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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux