[Libosinfo] [osinfo-db PATCH] RFC: schema: Add support to Guest Features

[Daniel P. Berrangé]

On Tue, Nov 20, 2018 at 03:53:54PM +0100, Fabiano Fidêncio wrote:
> On Tue, Nov 20, 2018 at 12:11 PM Daniel P. Berrangé <berrange at redhat.com> wrote:
> >
> > On Thu, Nov 15, 2018 at 12:04:33PM +0100, Fabiano Fidêncio wrote:
> > > One of the requests that came from KubeVirt is that would be really nice
> > > if we could expose Guest supported features.
> > >
> > > In order to do so, I came up with this *prototype* and I'd like to ask
> > > for some review of the schema before I actually start implementing
> > > something on libosinfo side.
> > >
> > > One example of how it'll look like is:
> > > <os>
> > >   <features>
> > >     <feature removed="true">device-hotplug</feature>
> > >     <feature>cpu-hotplug</feature>
> > >     <feature>NUMA</feature>
> > >   </features>
> > > </os>
> >
> > In general our documentation for the osinfo schema is poor to
> > non-existant.  If we start adding features like this, however,
> > I think it is important that we explicitly document what each
> > one means as clearly as possible.
> >
> > eg 'device-hotplug' presumably refers to PCI device hotplug,
> > but we should be clear it just means the OS is capable of
> > supporting it. It doesn't mean its actually guaranteed to
> > work. eg if either QEMU or kernel is booted with "noapci"
> > it won't work.
> >
> > I'd be ok with the documentation simply comprising XML comments
> > in the RNG schema
> 
> There's one thing (from Martin's series*) that makes me wonder whether
> we should also have something else than just a <feature>foo</feature>
> attribute.
> His example is:
> +  <features>
> +    <hugepages size="1" unit="G"/>
> +    <nic>passthrough</nic>
> +    <io>native</io>
> +    <disk cache="none"/>
> +  </features>
> 
> At this point In wonder two things:
> - What he's trying to achieve could also take advantage of my proposal?
> - Shall we follow his suggested syntax?
> 
> I totally can see my proposal having, for instance:
> <features>
>   <feature>hugepages</feature>

There are separate concepts here. Martin was expressing whether QEMU
should use hugepages for guest RAM. This has no dependency on the
guest OS as its invisible to the guest. Then there is whethe the guest
OS configures hugepages, which is a decision it can make on its own,
regardless of whether QEMU use hugepages for guest RAM.

IOW, this is not a feature we care about for guest OS

>   <feature>nic-passthrough</feature>

In Martin's example this is saying that we should use a PCI passthrough
device instead of emulated NIC for better performance. This is something
that doesn't matter to the guest OS - it just sees a PCI device in both
cases. What matters to the guest is whether it supports the device driver
which is something we can already represent.

IOW, this is also not a feature we care about.

> <features>
> 
> But then, specifying the size of hugepage, for instance, is not
> something that I was planning to contemplate with my series. Neither
> I'm convinced that I should.
> 
> So, the main question here is ... shall I go-ahead with my approach
> and later on we can come up with a better naming for Martin's proposal
> or shall we have an agreement about this (and maybe expanding my
> proposal) right now?

I think Martin's feature stuff is largely tangential to OS level
feature stuff.

> *: https://www.redhat.com/archives/libosinfo/2018-November/msg00202.html
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 :|