[Libosinfo] [PATCH osinfo-db 5/9] device: Add chipset q35
Cole Robinson
crobinso at redhat.com
Tue Sep 4 18:42:47 UTC 2018
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 at redhat.com>
>> ---
>> 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
More information about the Libosinfo
mailing list