[Libosinfo] [PATCH osinfo-db 5/9] device: Add chipset q35

[Cole Robinson]

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