[Libosinfo] [PATCH osinfo-db 0/5 v2] Add q35 devices
Fabiano Fidêncio
fidencio at redhat.com
Thu Oct 4 07:26:17 UTC 2018
On Fri, 2018-09-28 at 18:55 -0400, Cole Robinson wrote:
> The main goal of this series is to advertise q35 chipset and device
> support for suitable OS. Some details about the individual decisions
>
> * We group q35+ich9+e1000e together. This likely isn't completely
> accurate but in the virt case I think it only makes sense to
> specify the latter two devices when pcie (q35) is present, so
> I went with it.
>
> * We only advertise q35 when virtio1.0 devices are available, on
> linux.
> This definitely isn't accurate, q35 predates virtio1.0 by 8 years
> or
> so, but there's issues combining q35 with legacy virtio, and that's
> the only combo I'll be exploring for virt-manager so other
> scenarios
> my go untested.
>
> * The actual OS+q35 combos are largely untested by me.
>
> v1 posting:
> https://www.redhat.com/archives/libosinfo/2018-August/msg00006.html
>
> v2 changes:
> * Rebased, drop committed patches
> * Rework the chipset device ID and dir structure
>
>
> In the original posting danpb suggested introducing a new <chipset>
> concept to cover this case, roughly outlined here:
>
> https://www.redhat.com/archives/libosinfo/2018-September/msg00014.html
>
> This posting doesn't add that and instead uses <device> like before,
> but with some changes:
>
> $ cat data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in
> <libosinfo version="0.0.1">
> <!-- Licensed under the GNU General Public License version 2 or
> later.
> See http://www.gnu.org/licenses/ for a copy of the license text
> -->
> <device id="http://qemu.org/chipset/x86_64/q35">
> <name>q35</name>
> <class>chipset.virtual</class>
> </device>
> </libosinfo>
>
>
> My justifications for not going the full <chipset> route:
>
> * It's much more work to add new APIs, test them, document them, etc.
> I'm lazy, but it's also a lot more code to maintain forever.
>
> * Will be harder in the short term for clients as well. virt-manager
> will need to use the new APIs and correctly check that they exist,
> vs just using the existing device APIs.
>
> * I think we should bite the bullet and make the <device> concept
> more fuzzy, since we may want that anyways to model things like
> hyperv features which aren't all strictly devices.
>
> * Eventually we will need to extend the XML schema with some way to
> mark <devices> unsupported if a new version of an OS drops support.
> This is already the case with newer windows which doesn't support
> ac97 out of the box, though libosinfo still reports support. If
> we have a separate <chipset> concept, we will need to duplicate
> that schema and likely libosinfo support to handle that case as
> well. So more work going forward.
>
>
> Now some questions: A quick one: is class=chipset.virtual okay? I
> used .virtual as some day we may want to track actual chipset PCI
> devices for example, like the PCI ID for q35.
Considering we're going for the approach you suggested, yes, it does
make sense.
>
> Bigger question: What is the expected way that API users should
> determine if libosinfo supports a particular device? Take USB tablet
> support for example. The qemu usb tablet has this device xml:
>
> <device id="http://usb.org/usb/80ee/0021">
> <name>tablet</name>
> <class>input</class>
> </device>
>
> Ways you can presently search for that device with the API:
>
> - Search for the device ID which is expected to be unique
> - Search for name=tablet which presently is unique. However that's a
> super generic name, and nothing seems to enforce <name> uniqueness
> for devices, so I don't know if we can/should count on that.
> - Search for class=input name=tablet which narrows it a bit
Boxes takes the second apprach.
It basically gets the list of all supported devices and then does, for
instance:
`find_device_by_prop(supported_devices, DEVICE_PROP_NAME, "virtio-
net")`
>
> virt-manager for example does the last step. I don't know if that's
> a good idea though, given how generic name is. Do we aim to give
> any guarantees about <name> uniqueness, or that it will never change?
> Is <class> never expected to change?
With the current codebase, I'd say that although we don' enforce, apps
are already assuming the <name> uniqueness. So, in case it fits your
design choices, we could go for that.
>
> With that context, let's consider querying chipset. I want to make
> sure this syntax isn't going to make future virt chipset additions
> difficult. Dan's list in the email lays out some other examples:
>
> qemu.org/chipset/i686-q35
> qemu.org/chipset/x86_64-q35
> qemu.org/chipset/aarch64/virt
> qemu.org/chipset/riscv/virt
>
> If <name> is expected to be globally unique, we probably don't want
> to use name=q35 incase it clashes with a future pcisig.com <device>,
> another virt stack's chipset, or even qemu q35 for i686. So that
> could
> mean name=x86_64-q35, or even name=qemu-x86_64-q35. That gets ugly
> and
> redundant fast though.
And here I see that it may not fit your design choices :-)
Anyways, can't we enforce the arch/platform for this?
So, for instance ...
<device id="foo">
<name>q35</name>
<class>chipset.virtual</class>
<arch>x86_64</arch>
<platform id="http://qemu.org/qemu/1.5.3"/>
</device>
Btw, I don't have a proper understanding on how we use the platform so
far and if someone is in the mood to give a nice explanation, that
would be really welcome! :-)
In any case, we'd have to expand the "device" schema and have new APIs
for that in order to guarantee we're not matching the wrong device.
>
> So IMO the sensible thing would be to enforce uniqueness in two ways:
> 1) the device ID, 2) the set of all device properties. So that would
> lead
> to these 4 configs
>
> <device id="http://qemu.org/chipset/x86_64/q35">
> <name>q35</name>
> <arch>x86_64</arch>
> <class>chipset.virtual</class>
> </device>
> <device id="http://qemu.org/chipset/i686/q35">
> <name>q35</name>
> <arch>i686</arch>
> <class>chipset.virtual</class>
> </device>
> <device id="http://qemu.org/chipset/aarch64/virt">
> <name>virt</name>
> <arch>aarch64</arch>
> <class>chipset.virtual</class>
> </device>
> <device id="http://qemu.org/chipset/riscv/virt">
> <name>virt</name>
> <arch>riscv</arch>
> <class>chipset.virtual</class>
> </device>
Aha. I should have read the whole e-mail before start answering it. :-/
>
>
> The downsides of that: 1) if an app naively searchs for name=q35 they
> may get the wrong result, because it ignored <arch>. Easy to misuse.
>
That's something that should be documented how the apps are expected to
use and that's it, IMHO.
> 2) There aren't any other examples yet of non-unique <name> so maybe
> it causes other issues.
True.
>
> All of that makes me think that the only safe recommendation for apps
> is to search by device id. <name> should be treated largely as
> metadata.
>
> We don't necessarily need to implement all this now, since the q35
> case
> is fairly straightforward, but we should at least make sure we aren't
> going down the wrong path.
Please, take my answers with a grain of salt as I do believe that
Daniel should/will want to have his opinion on this series as well.
>
>
> Cole Robinson (5):
> device: Add network e1000e
> device: Add sound ich9
> device: Add chipset q35
> os: Add q35/e1000e/ich9 for win2k8r2+ and win7+
> os: linux: Add q35/ich9/e1000e alongside virtio1.0 <device>
>
> data/device/pcisig.com/pci-8086-10d3.d/class.xml.in | 8 ++++++++
> data/device/pcisig.com/pci-8086-293e.d/class.xml.in | 8 ++++++++
> data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in | 8 ++++++++
> data/os/debian.org/debian-9.xml.in | 3 +++
> data/os/fedoraproject.org/fedora-23.xml.in | 5 ++++-
> data/os/microsoft.com/win-2k8r2.xml.in | 6 ++++++
> data/os/microsoft.com/win-7.xml.in | 3 +++
> data/os/opensuse.org/opensuse-42.2.xml.in | 3 +++
> data/os/redhat.com/rhel-7.2.xml.in | 3 +++
> data/os/suse.com/sled-12.2.xml.in | 3 +++
> data/os/suse.com/sles-12.2.xml.in | 3 +++
> data/os/ubuntu.com/ubuntu-17.04.xml.in | 3 +++
> data/schema/osinfo.rng.in | 1 +
> 13 files changed, 56 insertions(+), 1 deletion(-)
> create mode 100644 data/device/pcisig.com/pci-8086-
> 10d3.d/class.xml.in
> create mode 100644 data/device/pcisig.com/pci-8086-
> 293e.d/class.xml.in
> create mode 100644 data/device/qemu.org/chipset-x86_64-
> q35.d/class.xml.in
>
Best Regards,
--
Fabiano Fidêncio
More information about the Libosinfo
mailing list