On Fri, Sep 28, 2018 at 06:55:37PM -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. Grouping q35 and ich9 together is definitely fine IMHO, since ich9 is a chip in the q35 chipset. Grouping e1000e together is probably not right, but it is not harmful - worst case it means we're not reporting e1000e support in some cases where we should be. We can easily fix that as needed later. > * 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. I already commented on this in v3 so won't repeat. > 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. Yes, this rationale is fine with me. > 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. I think it might actually be sufficient to just use 'chipset'. The fact that it is a virtual impl is already expressed by the fact that you put the device ID under the qemu.org namespace. If we need to track a real Q35 chipset separately later we can have a different device ID URI. > 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 > > 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? I would not expect <class> to change unless we screwed up the initial DB entry, as devices don't suddenly grow new features. For applications my thought is that they should be using the device ID URI as the preferred identifier. I view 'name' as something targetted towards humans who can't remember that http://pcisig.com/pci/8086/293e means ich9 audio. > 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. Note that I suggested we just use 'x86' for q35 since qemu shares code for both x86_64 and i686 for q35, and I'd expect guest OS to support both arches equally too. My gut feeling would be for qemu-x86_64-q35 because especially with the "virt" chipset you have two radically different things that have essentially nothing in common between riscv and aarch64. > 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> > > > 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. > 2) There aren't any other examples yet of non-unique <name> so maybe > it causes other issues. > > 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. Apps should definitely prefer device ID, but I think we should stil try to keep name unique too. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
