On Tue, 2020-03-24 at 11:05 -0300, Daniel Henrique Barboza wrote: > On 3/24/20 11:00 AM, Andrea Bolognani wrote: > > On Tue, 2020-03-24 at 09:27 -0300, Daniel Henrique Barboza wrote: > > > 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. > > I guess I'll roll with this one then. I will allow <pmu state='on'/> to be > declared in the XML without breaking QEMU. For <pmu state='off'/> I'll > throw an CONFIG_UNSUPPORTED error mentioning that PMU can't be turned off > for ppc64. Sounds good. -- Andrea Bolognani / Red Hat / Virtualization
