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
