Hi, This work was intended to fix a bug with APIC-EOI setting only (patch 1). I decided to take a closer look and ended up handling more cases. I consider the first 3 patches to be straightforward: those are conditions that QEMU will complain about and I'm simply refusing to launch while giving a better error message than the one QEMU provides. Patch 4 is more debatable. <hyperv><hyperv/> declaration in the XML is benign, but any of the 14 features being declared will cause QEMU errors. Instead of putting more code (i.e. a switch with 14 features in the middle of the code) to prevent any of those features to be enabled, I made a call to simply refuse to launch with any <hyperv> setting in the XML. This is not because I have a beef with Windows or MS or anything. This is about making an educated guess that it's highly unlikable that anyone is running ppc64 guests with <hyperv> declared in the XML, and it's not worth all the code to support it. But I'm all ears to hear otherwise. After this series, these are the features that aren't supported by ppc64 but can be declared in a ppc64 guest without resulting in a failed launch: <features> <acpi/> <apic/> (without 'eoi' setting) <pae/> <hap state='on|off'/> <viridian/> </features> Daniel Henrique Barboza (4): qemu_domain.c: do not launch ppc64 guests with APIC-EOI setting qemu_domain.c: do not launch ppc64 guests with 'pvspinlock' setting qemu_domain.c: do not launch ppc64 guests with 'pmu' setting qemu_domain.c: do not launch ppc64 guests with Hyperv settings src/qemu/qemu_domain.c | 49 ++++++++++++++++++++++++++++++++++++++---- 1 file changed, 45 insertions(+), 4 deletions(-) -- 2.25.1
