On 08/30/2018 11:04 AM, Daniel P. Berrangé wrote:
On Wed, Aug 29, 2018 at 05:54:43PM -0400, Cole Robinson wrote:
Signed-off-by: Cole Robinson <crobinso@xxxxxxxxxx>
---
Is class 'chipset' fine for q35? The actual PCI ID is for
' 82G33/G31/P35/P31 Express DRAM Controller'
I've been looking into this more and am increasingly convinced we should not
be keying off the host-bridge PCI ID at all.
For a start a machine type is actually multiple devices, of which host-bridge
is just one small part. So we already have multiple PCI IDs for a single
machine type.
Then on aarch64 and risv the PCI root is just a generic QEMU invented chipset.
Meanwhile PPC64 is even more insane as it has no PCI host-bridge AFAICT.
The pseries machine type just has a VGA controller immediately as device 0
Then there's all the machines which don't have PCI at all. eg most arm7
machines, where it would be desirable to indicate wihch are supported
by Fedora.
If we look at VMWare they emulate an i440bx chipset, but it is not like
any realworld i440bx chipset because it supports PCI Express, whose
invention post-dates the invention of i440bx by 6 years. So it is really
a custom vmware chipset at this point.
Thus, my gut feeling is that we need to express the chipset / machine
type in some more generic manner.
We could invent a custom URI format for the machine types
eg
qemu.org/chipset/i686-i440x
qemu.org/chipset/i686-q35
qemu.org/chipset/x86_64-i440fx
qemu.org/chipset/x86_64-q35
qemu.org/chipset/aarch64/virt
qemu.org/chipset/riscv/virt
vmware.com/chipset/version12
vmware.com/chipset/version13
vmware.com/chipset/version14
microsoft.com/chipset/gen1
microsoft.com/chipset/gen2
I'm also wondering if we should not use the <device> models at all,
and instead invent a new XML element
<chipset id="qemu.org/chipset/i686-i440x">
<vendor>qemu</vendor>
<arch>i686</arch>
<name>i440fx</name>
</chipset>
<chipset id="qemu.org/chipset/x86_64-i440x">
<vendor>qemu</vendor>
<arch>x86_64</arch>
<name>i440fx</name>
</chipset>
<chipset id="qemu.org/chipset/aarch64/virt">
<vendor>qemu</vendor>
<arch>i686</arch>
<arch>x86_64</arch>
<name>i440fx</name>
</chipset>
...etc...
And reference those chipset definitions in guest OS:
<chipset id="qemu.org/chipset/aarch64/virt"/>
I think that all makes sense. I'm not excited to add the new libosinfo
APIs to handle it but i'll do it :)
Though while we are considering extending the API I figure I'll mention
the other metadata bits that I think should end up in libosinfo, but
it's not clear yet if/how to expose them. Maybe it will shake out some
other ideas
Already tracked virt-manager:
* clock localtime vs utc
* don't combine x2apic with solaris10/11:
https://bugs.launchpad.net/qemu/+bug/1395217
* UEFI + hyperv clock can't be combined with certain windows OS:
https://bugs.launchpad.net/qemu/+bug/1593605
https://bugzilla.redhat.com/show_bug.cgi?id=1185253
Kinda tracked in virt-manager:
* Enabling hyper-v enlightenments for windows guests. Right now we just
turn them on if in the OS is windows family, but I believe it could be
more fine grained than that. Like maybe osinfo should advertise which
enlightenment features each windows version supports. Part of the
weirdness here is that linux infact supports these enlightenments as
well, for better behavior when linux runs on top of hyper-v, but we
don't want to enable them for linux+kvm. Not sure if/how that would be
represented.
Not presently tracked in virt-manager:
* Some windows versions limit the max number of CPU sockets:
https://bugzilla.redhat.com/show_bug.cgi?id=1335977
Thanks,
Cole
_______________________________________________
Libosinfo mailing list
Libosinfo@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libosinfo
