Re: [PATCH osinfo-db 0/5 v2] Add q35 devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
Libosinfo mailing list
Libosinfo@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libosinfo




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Fedora Users]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux