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