Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Thu, Nov 15, 2018 at 12:21:55PM +0100, Cornelia Huck wrote:
> On Wed, 14 Nov 2018 21:38:31 -0200
> Eduardo Habkost wrote:
>
> > diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
> > index 813082b0d7..1d2a11504f 100644
> > --- a/hw/virtio/virtio-pci.h
> > +++ b/hw/virtio/virtio-pci.h
>
> (...)
>
> > +/**
> > + * VirtioPCIDeviceTypeInfo:
> > + *
> > + * Template for virtio PCI device types. See virtio_pci_types_register()
> > + * for details.
> > + */
> > +typedef struct VirtioPCIDeviceTypeInfo {
> > +/* Prefix for the class names */
> > +const char *name_prefix;
>
> Maybe call this the vpci_name instead? It's not really a
> prefix in the way I would usually use the term, but rather a type name
> with a possible suffix tacked onto it.
I'm considering getting rid of all magic type name generation,
and make the struct explicit list all the type names to be
registered. This way people won't be confused when grepping the
code for the type names.
>
> > +/* Parent type. If NULL, TYPE_VIRTIO_PCI is used */
> > +const char *parent;
> > +/* If modern_only is true, only type will be registered
> > */
> > +bool modern_only;
> > +
> > +/* Same as TypeInfo fields: */
> > +size_t instance_size;
> > +void (*instance_init)(Object *obj);
> > +void (*class_init)(ObjectClass *klass, void *data);
> > +} VirtioPCIDeviceTypeInfo;
> > +
> > +/*
> > + * Register virtio-pci types. Each virtio-pci device type will be
> > available
> > + * in 3 flavors:
> > + * - -transitional: modern device supporting legacy drivers
> > + * - Supports Conventional PCI buses only
> > + * - -non-transitional: modern-only
> > + * - Supports Conventional PCI and PCI Express buses
> > + * - : virtio version configurable, legacy driver support
> > + * automatically selected when device is plugged
> > + * _ This was the only flavor supported until QEMU 3.1
>
> s/_/-/
> s/until/up to/ ?
Done. Thanks!
>
> > + * - Supports Conventional PCI and PCI Express buses
> > + *
> > + * All the types above will inherit from "-base", so generic
> > + * code can use "-base" on type casts.
> > + *
> > + * We need a separate "-base" type instead of making all types
> > inherit
> > + * from for two reasons:
> > + * 1) will implement INTERFACE_PCIE_DEVICE, but
> > + *-transitional won't.
> > + * 2) will have the "disable-legacy" and "disable-modern"
> > properties,
> > + *-transitional and -non-transitional won't.
>
> I'd formulate this rather as "x implements/has something, y
> and z do not", as the code actually does that (and does not just intend
> to do so :)
Done. Thanks!
>
> > + */
> > +void virtio_pci_types_register(const VirtioPCIDeviceTypeInfo *t);
> > +
> > #endif
>
> (...)
>
> > diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> > index a954799267..0fa248d68c 100644
> > --- a/hw/virtio/virtio-pci.c
> > +++ b/hw/virtio/virtio-pci.c
>
> (...)
>
> > +static void virtio_pci_1_0_instance_init(Object *obj)
>
> Ditch the _0? I don't expect this to change the name when virtio 1.1
> arrives.
I was going to rename this to
virtio_pci_non_transitional_instance_init() for consistency, but
I forgot. Thanks for noting.
>
> > +{
> > +VirtIOPCIProxy *proxy = VIRTIO_PCI(obj);
> > +
> > +proxy->disable_legacy = ON_OFF_AUTO_ON;
> > +proxy->disable_modern = false;
> > +}
>
> (...)
>
> After a quick look, this seems fine; have not actually tried to run it
> yet.
--
Eduardo
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Tue, 2018-11-20 at 14:14 -0500, Michael S. Tsirkin wrote: > On Tue, Nov 20, 2018 at 01:27:05PM +0100, Andrea Bolognani wrote: > > On Mon, 2018-11-19 at 14:14 -0500, Michael S. Tsirkin wrote: > > > Well it works now - connect it to a bus and it figures out whether it > > > should do transitional or not. You can force transitional in PCIe anyway > > > but then you are limited to about 15 devices - probably sufficient for > > > most people ... > > > > That's not how it works, though: current virtio-*-pci devices will > > be transitional (and thus support older guest OS) or not based on > > the kind of slot you plug them into. > > > > From the management point of view that's problematic, because libvirt > > (which takes care of the virtual hardware, including assigning PCI > > addresses to devices) has no knowledge of the guest OS running on > > said hardware, and management apps (which know about the guest OS and > > can figure out its capabilities using libosinfo) don't want to be in > > the business of assigning PCI addresses themselves. > > > > Having separate transitional and non-transitional variants solves the > > issue because now management apps can query libosinfo to figure out > > whether the guest OS supports non-transitional virtio devices, and > > based on that they can ask libvirt to use either the transitional or > > non-transitional variant; from that, libvirt will be able to choose > > the correct slot for the device. > > > > None of the above quite works if we have a single variant that > > morphs based on the slot, as we have today. > > So can we get an ack on the patchset then? Sure thing - whatever it might be worth :) Acked-by: Andrea Bolognani -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Tue, Nov 20, 2018 at 01:27:05PM +0100, Andrea Bolognani wrote: > On Mon, 2018-11-19 at 14:14 -0500, Michael S. Tsirkin wrote: > > On Mon, Nov 19, 2018 at 07:56:38PM +0100, Cornelia Huck wrote: > > > On Mon, 19 Nov 2018 13:42:58 -0500 "Michael S. Tsirkin" > > > wrote: > > > > We have this assumption that if we force a choice then people will > > > > choose the right thing but in practice they will do what we all do, play > > > > with it until it kind of works and leave well alone afterwards. > > > > That's at best - at worst give up and use an easier tool. > > > > > > That implies that we (the developers) need to care and make sure that > > > "model=virtio" gets them the best possible transport (i.e. on s390x, > > > that would be ccw unless the user explicitly requests pci; I'm not sure > > > what the situation with mmio is -- probably "use pci whenever > > > possible"?) I think that's what libvirt already gives us today (I hope.) > > The interface at the libvirt level is exactly "model=virtio", with > that ultimately translating to virtio-*-pci or virtio-*-ccw or > virtio-*-device or whatever else based on the architecture, machine > type and other information about the guest. > > > > What makes it messy on the pci side is that the "best option" actually > > > depends on what kind of guest the user wants to run (if the guest is > > > too old, you're stuck with transitional; if you want to reap the > > > benefits of PCIe, you need non-transitional...) > > > > Well it works now - connect it to a bus and it figures out whether it > > should do transitional or not. You can force transitional in PCIe anyway > > but then you are limited to about 15 devices - probably sufficient for > > most people ... > > That's not how it works, though: current virtio-*-pci devices will > be transitional (and thus support older guest OS) or not based on > the kind of slot you plug them into. > > >From the management point of view that's problematic, because libvirt > (which takes care of the virtual hardware, including assigning PCI > addresses to devices) has no knowledge of the guest OS running on > said hardware, and management apps (which know about the guest OS and > can figure out its capabilities using libosinfo) don't want to be in > the business of assigning PCI addresses themselves. > > Having separate transitional and non-transitional variants solves the > issue because now management apps can query libosinfo to figure out > whether the guest OS supports non-transitional virtio devices, and > based on that they can ask libvirt to use either the transitional or > non-transitional variant; from that, libvirt will be able to choose > the correct slot for the device. > > None of the above quite works if we have a single variant that > morphs based on the slot, as we have today. So can we get an ack on the patchset then? > -- > Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Mon, 2018-11-19 at 14:14 -0500, Michael S. Tsirkin wrote: > On Mon, Nov 19, 2018 at 07:56:38PM +0100, Cornelia Huck wrote: > > On Mon, 19 Nov 2018 13:42:58 -0500 "Michael S. Tsirkin" > > wrote: > > > We have this assumption that if we force a choice then people will > > > choose the right thing but in practice they will do what we all do, play > > > with it until it kind of works and leave well alone afterwards. > > > That's at best - at worst give up and use an easier tool. > > > > That implies that we (the developers) need to care and make sure that > > "model=virtio" gets them the best possible transport (i.e. on s390x, > > that would be ccw unless the user explicitly requests pci; I'm not sure > > what the situation with mmio is -- probably "use pci whenever > > possible"?) I think that's what libvirt already gives us today (I hope.) The interface at the libvirt level is exactly "model=virtio", with that ultimately translating to virtio-*-pci or virtio-*-ccw or virtio-*-device or whatever else based on the architecture, machine type and other information about the guest. > > What makes it messy on the pci side is that the "best option" actually > > depends on what kind of guest the user wants to run (if the guest is > > too old, you're stuck with transitional; if you want to reap the > > benefits of PCIe, you need non-transitional...) > > Well it works now - connect it to a bus and it figures out whether it > should do transitional or not. You can force transitional in PCIe anyway > but then you are limited to about 15 devices - probably sufficient for > most people ... That's not how it works, though: current virtio-*-pci devices will be transitional (and thus support older guest OS) or not based on the kind of slot you plug them into. >From the management point of view that's problematic, because libvirt (which takes care of the virtual hardware, including assigning PCI addresses to devices) has no knowledge of the guest OS running on said hardware, and management apps (which know about the guest OS and can figure out its capabilities using libosinfo) don't want to be in the business of assigning PCI addresses themselves. Having separate transitional and non-transitional variants solves the issue because now management apps can query libosinfo to figure out whether the guest OS supports non-transitional virtio devices, and based on that they can ask libvirt to use either the transitional or non-transitional variant; from that, libvirt will be able to choose the correct slot for the device. None of the above quite works if we have a single variant that morphs based on the slot, as we have today. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Tue, Nov 20, 2018 at 11:52:27AM +0100, Cornelia Huck wrote: > On Mon, 19 Nov 2018 22:44:54 -0200 > Eduardo Habkost wrote: > > > On Thu, Nov 15, 2018 at 11:50:56AM +0100, Cornelia Huck wrote: > > > On Thu, 15 Nov 2018 10:05:59 + > > > Daniel P. Berrangé wrote: > > > > > If libvirt did this compatibility approach, can you > > > > confirm this would be live migration state compatible. > > > > > > > > ie can live migrate virtio-*-pci -> virtio-*-pci-transitional, > > > > provided only PCI bus was used. > > > > > > It also needs to make sure that neither disable-legacy nor > > > disable-modern is set. Then this would have a compatible state AFAICS. > > > > > > > > > > > > - virtio-*-pci-non-transitional: modern-only > > > > > - Supports both Conventional PCI and PCI Express buses > > > > > > > > IIUC, libvirt can again provide compatibility with old > > > > QEMU by simply using the existing device type and setting > > > > disable-legacy ? Can you confirm this would be live > > > > migration compatible > > > > > > > > virtio-*-pci + disable-legacy -> virtio-*pci-non-transitional > > > > > > I think yes. > > > > This is exactly how it is implemented internally, but I'm not > > promising that this will be kept compatible forever. And I > > wouldn't like to make that promise unless there's an important > > use case for that. > > Shouldn't we be able to ensure compatibility by normal virtio feature > bit handling, as we have already done in the past? Ensuring compatibility is possible, and even likely. I just want to avoid spending effort keeping such a promise unless it's really necessary. > > > > > We could easily ensure it will be compatible in pc-4.0 and older, > > though. Would that be enough for the use case we have in mind? > > > -- Eduardo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Mon, 19 Nov 2018 22:44:54 -0200 Eduardo Habkost wrote: > On Thu, Nov 15, 2018 at 11:50:56AM +0100, Cornelia Huck wrote: > > On Thu, 15 Nov 2018 10:05:59 + > > Daniel P. Berrangé wrote: > > > If libvirt did this compatibility approach, can you > > > confirm this would be live migration state compatible. > > > > > > ie can live migrate virtio-*-pci -> virtio-*-pci-transitional, > > > provided only PCI bus was used. > > > > It also needs to make sure that neither disable-legacy nor > > disable-modern is set. Then this would have a compatible state AFAICS. > > > > > > > > > - virtio-*-pci-non-transitional: modern-only > > > > - Supports both Conventional PCI and PCI Express buses > > > > > > IIUC, libvirt can again provide compatibility with old > > > QEMU by simply using the existing device type and setting > > > disable-legacy ? Can you confirm this would be live > > > migration compatible > > > > > > virtio-*-pci + disable-legacy -> virtio-*pci-non-transitional > > > > I think yes. > > This is exactly how it is implemented internally, but I'm not > promising that this will be kept compatible forever. And I > wouldn't like to make that promise unless there's an important > use case for that. Shouldn't we be able to ensure compatibility by normal virtio feature bit handling, as we have already done in the past? > > We could easily ensure it will be compatible in pc-4.0 and older, > though. Would that be enough for the use case we have in mind? > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Mon, Nov 19, 2018 at 10:44:54PM -0200, Eduardo Habkost wrote:
> On Thu, Nov 15, 2018 at 11:50:56AM +0100, Cornelia Huck wrote:
> > On Thu, 15 Nov 2018 10:05:59 +
> > Daniel P. Berrangé wrote:
> >
> > > On Wed, Nov 14, 2018 at 09:38:31PM -0200, Eduardo Habkost wrote:
> > > > Many of the current virtio-*-pci device types actually represent
> > > > 3 different types of devices:
> > > > * virtio 1.0 non-transitional devices
> > > > * virtio 1.0 transitional devices
> > > > * virtio 0.9 ("legacy device" in virtio 1.0 terminology)
> > > >
> > > > That would be just an annoyance if it didn't break our device/bus
> > > > compatibility QMP interfaces. With this multi-purpose device
> > > > type, there's no way to tell management software that
> > > > transitional devices and legacy devices require a Conventional
> > > > PCI bus.
> > > >
> > > > The multi-purpose device types would also prevent us from telling
> > > > management software what's the PCI vendor/device ID for them,
> > > > because their PCI IDs change at runtime depending on the bus
> > > > where they were plugged.
> > > >
> > > > This patch adds separate device types for each of those virtio
> > > > device flavors:
> > > >
> > > > - virtio-*-pci: the existing multi-purpose device types
> > > > - Configurable using `disable-legacy` and `disable-modern`
> > > > properties
> > > > - Legacy driver support is automatically enabled/disabled
> > > > depending on the bus where it is plugged
> > > > - Supports Conventional PCI and PCI Express buses
> > > > (but Conventional PCI is incompatible with
> > > > disable-legacy=off)
> > > > - Changes PCI vendor/device IDs at runtime
> > > > - virtio-*-pci-transitional: virtio-1.0 device supporting legacy drivers
> >
> > It's a virtio-1 (not 1.0) device. Otherwise, I like this terminology
> > better.
> >
> > > > - Supports Conventional PCI buses only, because
> > > > it has a PIO BAR
> > >
> > > Am I right in thinking that this is basically identical
> > > to virtio-*-pci, aside from only being valid for PCI
> > > buses ?
> > >
> > > IOW, libvirt can expose this device even if QEMU does
> > > not support it, by simply using the existing device
> > > type and only ever placing it in a PCI bus ?
> > >
> > > If libvirt did this compatibility approach, can you
> > > confirm this would be live migration state compatible.
> > >
> > > ie can live migrate virtio-*-pci -> virtio-*-pci-transitional,
> > > provided only PCI bus was used.
> >
> > It also needs to make sure that neither disable-legacy nor
> > disable-modern is set. Then this would have a compatible state AFAICS.
> >
> > >
> > > > - virtio-*-pci-non-transitional: modern-only
> > > > - Supports both Conventional PCI and PCI Express buses
> > >
> > > IIUC, libvirt can again provide compatibility with old
> > > QEMU by simply using the existing device type and setting
> > > disable-legacy ? Can you confirm this would be live
> > > migration compatible
> > >
> > > virtio-*-pci + disable-legacy -> virtio-*pci-non-transitional
> >
> > I think yes.
>
> This is exactly how it is implemented internally, but I'm not
> promising that this will be kept compatible forever. And I
> wouldn't like to make that promise unless there's an important
> use case for that.
>
> We could easily ensure it will be compatible in pc-4.0 and older,
> though. Would that be enough for the use case we have in mind?
I guess that as long as it is compat in all existing machine types,
it doesn't matter what new machine types do.
Libvirt would only use the back compat stuff with QEMU < 4.0, in
which case you can guarantee a machine type < pc-4.0. If libvirt
saw a QEMU >= 4.0, it would never use the back compat approach,
so it wouldn't matter if >= pc-4.0 were not compatible. ie for
live migration it would be a case of
QEMU-3.1 + pc-3.1 -> QEMU_4.0 + pc-3.1
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 :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Mon, 19 Nov 2018 19:32:32 -0200 Eduardo Habkost wrote: > However, I wish this kind of usability magic didn't automatically > imposed us the burden of keeping guest ABI compatibility too. > Keeping ABI compatibility on the machine-friendly device types and > interfaces is already hard enough. Hm, what are you thinking about here? We can fence off new features in the hw compat section (and we already do so today), so the remaining compat woe is what you are addressing with this patch set, isn't it? > > We already have aliases that automatically select a virtio device > type at qdev-monitor.c:qdev_alias_table[], and I don't know if > they are supposed to keep a stable guest ABI. As the comment there states, it was a bad idea... when you are using the alias, you can't pass any properties that are unique to the transport anyway. Hopefully the compat code dealt with the disable-modern for old machine types correctly in this case; but I don't think that helps for the bus dilemma. I'm not sure we want to worry about the aliases too much; it might even be a good idea to deprecate them. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Mon, Nov 19, 2018 at 10:08:42PM -0500, Michael S. Tsirkin wrote: > On Mon, Nov 19, 2018 at 07:47:40PM -0200, Eduardo Habkost wrote: > > On Mon, Nov 19, 2018 at 01:07:59PM -0500, Michael S. Tsirkin wrote: > > n > > > On Mon, Nov 19, 2018 at 11:41:05AM +0100, Cornelia Huck wrote: > > > > On Fri, 16 Nov 2018 01:45:51 -0200 > > > > Eduardo Habkost wrote: > > > > > > > > > On Thu, Nov 15, 2018 at 05:29:24PM +0100, Andrea Bolognani wrote: > > > > > > > > > > One thing that I'm very much not convinced about is the naming, > > > > > > specifically leaving the virtio revision out: I get it that we > > > > > > Should Never Need™ another major version of the spec, but I'm > > > > > > afraid discounting the possibility outright might prove to be > > > > > > shortsighted and come back to bite us later, so I'd much rather > > > > > > keep it. > > > > > > That's not the claim. In fact the reverse is true - a major revision can > > > come at any point. The claim is that virtio compatibility is not based > > > on version numbers. And another claim is that you can trust the > > > virtio TC not to overload terminology that it put in the spec. So use > > > that and you should be fine. Come up with your own and end up writing > > > another spec just to document it. > > > > > > > > > > > > > > > And once that's done, "non-transitional" (while matching the > > > > > > language of the spec) starts to look a bit unnecessary when you > > > > > > could simply have > > > > > > > > > > > > virtio-*-pci > > > > > > virtio-*-pci-1 > > > > > > virtio-*-pci-1-transitional > > > > > > > > > > > > instead. But I don't feel as strongly about this as I do about > > > > > > keeping the virtio revision in the device name :) > > > > > > > > > > I like that suggestion. Makes the device names more explicit > > > > > _and_ shorter. I'll do that in v3. > > > > > > > > OTOH, that would mean we'd need to introduce new device types if we > > > > ever start to support a virtio 2.x standard. My understanding was that > > > > we'll want separate device types for transitional and non-transitional > > > > for two reasons: the bus which a device can be plugged into, and > > > > changing ids. Do we really expect huge changes in a possible 2.x > > > > standard that affect virtio-pci only, and not other virtio transports > > > > as well? > > > > > > Yes I think adding a version there is a mistake. > > > transitional/legacy/non-transitional are spec terms so > > > they are unlikely to change abruptly. OTOH virtio TC can > > > just decide next version is 2.0 on a drop of a hat. > > > > > > And I strongly believe command line users really really do not want all > > > this mess. Even adding "pci" is the name confuses people (what are the > > > other options?). For command line model=virtio is pretty much perfect. > > > So all these names are there primarily for libvirt's benefit. > > > And the only input from libvirt devs so far > > > has been that it's unclear how does cross version > > > migration work. That needs to be addressed in some way. > > > > What still needs to be addressed? > > I don't belive you answered Daniel's question. > > > Just keep the existing device > > types on migration. We could make additional promises about > > compatibility with the disable-modern and disable-legacy > > properties, but I don't see why we need to do it unless we start > > deprecating the old device types. > > Then the answer seems to be in the negative? If the question is about the current state, it's "yes". If it's about promises about the future, then we need to understand what kind of promise is expected. > > > > > > So can we maybe start with a libvirt domain xml patch, with an > > > implementation for existing QEMU, get that acked, and then just map it > > > back to qemu command line as directly as possible? > > > > I don't know what you mean here by "libvirt domain XML patch". > > > > Do you mean solving the problems only on the libvirt side, > > keeping the existing device types? Why would we do that? It > > would be a hack making the situation even messier. > > > > If libvirt needs us to provide better interfaces, let's cooperate > > with them. I'd like us to avoid having yet another "the problem > > must be solved in the other layer first" deadlock here. > > I mean IIUC libvirt is the solve user that will benefit from this patch. > Let's at least get an ack confirming it does make their lives easier. I understand this as an ACK; https://www.mail-archive.com/qemu-devel@nongnu.org/msg567161.html Quoted below: | I don't have a objection from libvirt side. | | Last time, I suggested/discussed this I was not convinced that the benefit | was compelling enough to justify the work across all levels in the stack. | | Apps using the new device model names would either make themselves | incompatible with older libvirt/QEMU, or they would increase their | code complexity & testing matrix by having to support both old & new
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Mon, Nov 19, 2018 at 07:47:40PM -0200, Eduardo Habkost wrote: > On Mon, Nov 19, 2018 at 01:07:59PM -0500, Michael S. Tsirkin wrote: > n > > On Mon, Nov 19, 2018 at 11:41:05AM +0100, Cornelia Huck wrote: > > > On Fri, 16 Nov 2018 01:45:51 -0200 > > > Eduardo Habkost wrote: > > > > > > > On Thu, Nov 15, 2018 at 05:29:24PM +0100, Andrea Bolognani wrote: > > > > > > > > One thing that I'm very much not convinced about is the naming, > > > > > specifically leaving the virtio revision out: I get it that we > > > > > Should Never Need™ another major version of the spec, but I'm > > > > > afraid discounting the possibility outright might prove to be > > > > > shortsighted and come back to bite us later, so I'd much rather > > > > > keep it. > > > > That's not the claim. In fact the reverse is true - a major revision can > > come at any point. The claim is that virtio compatibility is not based > > on version numbers. And another claim is that you can trust the > > virtio TC not to overload terminology that it put in the spec. So use > > that and you should be fine. Come up with your own and end up writing > > another spec just to document it. > > > > > > > > > > > > And once that's done, "non-transitional" (while matching the > > > > > language of the spec) starts to look a bit unnecessary when you > > > > > could simply have > > > > > > > > > > virtio-*-pci > > > > > virtio-*-pci-1 > > > > > virtio-*-pci-1-transitional > > > > > > > > > > instead. But I don't feel as strongly about this as I do about > > > > > keeping the virtio revision in the device name :) > > > > > > > > I like that suggestion. Makes the device names more explicit > > > > _and_ shorter. I'll do that in v3. > > > > > > OTOH, that would mean we'd need to introduce new device types if we > > > ever start to support a virtio 2.x standard. My understanding was that > > > we'll want separate device types for transitional and non-transitional > > > for two reasons: the bus which a device can be plugged into, and > > > changing ids. Do we really expect huge changes in a possible 2.x > > > standard that affect virtio-pci only, and not other virtio transports > > > as well? > > > > Yes I think adding a version there is a mistake. > > transitional/legacy/non-transitional are spec terms so > > they are unlikely to change abruptly. OTOH virtio TC can > > just decide next version is 2.0 on a drop of a hat. > > > > And I strongly believe command line users really really do not want all > > this mess. Even adding "pci" is the name confuses people (what are the > > other options?). For command line model=virtio is pretty much perfect. > > So all these names are there primarily for libvirt's benefit. > > And the only input from libvirt devs so far > > has been that it's unclear how does cross version > > migration work. That needs to be addressed in some way. > > What still needs to be addressed? I don't belive you answered Daniel's question. > Just keep the existing device > types on migration. We could make additional promises about > compatibility with the disable-modern and disable-legacy > properties, but I don't see why we need to do it unless we start > deprecating the old device types. Then the answer seems to be in the negative? > > > > > So can we maybe start with a libvirt domain xml patch, with an > > implementation for existing QEMU, get that acked, and then just map it > > back to qemu command line as directly as possible? > > I don't know what you mean here by "libvirt domain XML patch". > > Do you mean solving the problems only on the libvirt side, > keeping the existing device types? Why would we do that? It > would be a hack making the situation even messier. > > If libvirt needs us to provide better interfaces, let's cooperate > with them. I'd like us to avoid having yet another "the problem > must be solved in the other layer first" deadlock here. I mean IIUC libvirt is the solve user that will benefit from this patch. Let's at least get an ack confirming it does make their lives easier. > -- > Eduardo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Thu, Nov 15, 2018 at 11:50:56AM +0100, Cornelia Huck wrote:
> On Thu, 15 Nov 2018 10:05:59 +
> Daniel P. Berrangé wrote:
>
> > On Wed, Nov 14, 2018 at 09:38:31PM -0200, Eduardo Habkost wrote:
> > > Many of the current virtio-*-pci device types actually represent
> > > 3 different types of devices:
> > > * virtio 1.0 non-transitional devices
> > > * virtio 1.0 transitional devices
> > > * virtio 0.9 ("legacy device" in virtio 1.0 terminology)
> > >
> > > That would be just an annoyance if it didn't break our device/bus
> > > compatibility QMP interfaces. With this multi-purpose device
> > > type, there's no way to tell management software that
> > > transitional devices and legacy devices require a Conventional
> > > PCI bus.
> > >
> > > The multi-purpose device types would also prevent us from telling
> > > management software what's the PCI vendor/device ID for them,
> > > because their PCI IDs change at runtime depending on the bus
> > > where they were plugged.
> > >
> > > This patch adds separate device types for each of those virtio
> > > device flavors:
> > >
> > > - virtio-*-pci: the existing multi-purpose device types
> > > - Configurable using `disable-legacy` and `disable-modern`
> > > properties
> > > - Legacy driver support is automatically enabled/disabled
> > > depending on the bus where it is plugged
> > > - Supports Conventional PCI and PCI Express buses
> > > (but Conventional PCI is incompatible with
> > > disable-legacy=off)
> > > - Changes PCI vendor/device IDs at runtime
> > > - virtio-*-pci-transitional: virtio-1.0 device supporting legacy drivers
>
> It's a virtio-1 (not 1.0) device. Otherwise, I like this terminology
> better.
>
> > > - Supports Conventional PCI buses only, because
> > > it has a PIO BAR
> >
> > Am I right in thinking that this is basically identical
> > to virtio-*-pci, aside from only being valid for PCI
> > buses ?
> >
> > IOW, libvirt can expose this device even if QEMU does
> > not support it, by simply using the existing device
> > type and only ever placing it in a PCI bus ?
> >
> > If libvirt did this compatibility approach, can you
> > confirm this would be live migration state compatible.
> >
> > ie can live migrate virtio-*-pci -> virtio-*-pci-transitional,
> > provided only PCI bus was used.
>
> It also needs to make sure that neither disable-legacy nor
> disable-modern is set. Then this would have a compatible state AFAICS.
>
> >
> > > - virtio-*-pci-non-transitional: modern-only
> > > - Supports both Conventional PCI and PCI Express buses
> >
> > IIUC, libvirt can again provide compatibility with old
> > QEMU by simply using the existing device type and setting
> > disable-legacy ? Can you confirm this would be live
> > migration compatible
> >
> > virtio-*-pci + disable-legacy -> virtio-*pci-non-transitional
>
> I think yes.
This is exactly how it is implemented internally, but I'm not
promising that this will be kept compatible forever. And I
wouldn't like to make that promise unless there's an important
use case for that.
We could easily ensure it will be compatible in pc-4.0 and older,
though. Would that be enough for the use case we have in mind?
--
Eduardo
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Mon, Nov 19, 2018 at 01:07:59PM -0500, Michael S. Tsirkin wrote: n > On Mon, Nov 19, 2018 at 11:41:05AM +0100, Cornelia Huck wrote: > > On Fri, 16 Nov 2018 01:45:51 -0200 > > Eduardo Habkost wrote: > > > > > On Thu, Nov 15, 2018 at 05:29:24PM +0100, Andrea Bolognani wrote: > > > > > > One thing that I'm very much not convinced about is the naming, > > > > specifically leaving the virtio revision out: I get it that we > > > > Should Never Need™ another major version of the spec, but I'm > > > > afraid discounting the possibility outright might prove to be > > > > shortsighted and come back to bite us later, so I'd much rather > > > > keep it. > > That's not the claim. In fact the reverse is true - a major revision can > come at any point. The claim is that virtio compatibility is not based > on version numbers. And another claim is that you can trust the > virtio TC not to overload terminology that it put in the spec. So use > that and you should be fine. Come up with your own and end up writing > another spec just to document it. > > > > > > > > > And once that's done, "non-transitional" (while matching the > > > > language of the spec) starts to look a bit unnecessary when you > > > > could simply have > > > > > > > > virtio-*-pci > > > > virtio-*-pci-1 > > > > virtio-*-pci-1-transitional > > > > > > > > instead. But I don't feel as strongly about this as I do about > > > > keeping the virtio revision in the device name :) > > > > > > I like that suggestion. Makes the device names more explicit > > > _and_ shorter. I'll do that in v3. > > > > OTOH, that would mean we'd need to introduce new device types if we > > ever start to support a virtio 2.x standard. My understanding was that > > we'll want separate device types for transitional and non-transitional > > for two reasons: the bus which a device can be plugged into, and > > changing ids. Do we really expect huge changes in a possible 2.x > > standard that affect virtio-pci only, and not other virtio transports > > as well? > > Yes I think adding a version there is a mistake. > transitional/legacy/non-transitional are spec terms so > they are unlikely to change abruptly. OTOH virtio TC can > just decide next version is 2.0 on a drop of a hat. > > And I strongly believe command line users really really do not want all > this mess. Even adding "pci" is the name confuses people (what are the > other options?). For command line model=virtio is pretty much perfect. > So all these names are there primarily for libvirt's benefit. > And the only input from libvirt devs so far > has been that it's unclear how does cross version > migration work. That needs to be addressed in some way. What still needs to be addressed? Just keep the existing device types on migration. We could make additional promises about compatibility with the disable-modern and disable-legacy properties, but I don't see why we need to do it unless we start deprecating the old device types. > > So can we maybe start with a libvirt domain xml patch, with an > implementation for existing QEMU, get that acked, and then just map it > back to qemu command line as directly as possible? I don't know what you mean here by "libvirt domain XML patch". Do you mean solving the problems only on the libvirt side, keeping the existing device types? Why would we do that? It would be a hack making the situation even messier. If libvirt needs us to provide better interfaces, let's cooperate with them. I'd like us to avoid having yet another "the problem must be solved in the other layer first" deadlock here. -- Eduardo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Mon, Nov 19, 2018 at 07:56:38PM +0100, Cornelia Huck wrote: > On Mon, 19 Nov 2018 13:42:58 -0500 > "Michael S. Tsirkin" wrote: > > > On Mon, Nov 19, 2018 at 07:32:38PM +0100, Cornelia Huck wrote: > > > On Mon, 19 Nov 2018 13:07:59 -0500 > > > "Michael S. Tsirkin" wrote: > > > > > And I strongly believe command line users really really do not want all > > > > this mess. Even adding "pci" is the name confuses people (what are the > > > > other options?). For command line model=virtio is pretty much perfect. > > > > > > I'd argue that it's problematic on platforms where you have different > > > options for virtio transports. What does "model=virtio" mean? Always > > > virtio-pci, if available? Or rather virtio-, with > > > being the best option for the machine? > > > > Most people don't care, for them it's "whatever works". > > > > We have this assumption that if we force a choice then people will > > choose the right thing but in practice they will do what we all do, play > > with it until it kind of works and leave well alone afterwards. > > That's at best - at worst give up and use an easier tool. > > That implies that we (the developers) need to care and make sure that > "model=virtio" gets them the best possible transport (i.e. on s390x, > that would be ccw unless the user explicitly requests pci; I'm not sure > what the situation with mmio is -- probably "use pci whenever > possible"?) I think that's what libvirt already gives us today (I hope.) > > What makes it messy on the pci side is that the "best option" actually > depends on what kind of guest the user wants to run (if the guest is > too old, you're stuck with transitional; if you want to reap the > benefits of PCIe, you need non-transitional...) Yeah, sometimes we can't make everything work out of the box on the default case. But I think in this case we can make the QEMU command-line a bit more usable if we just cover more recent OSes. However, I wish this kind of usability magic didn't automatically imposed us the burden of keeping guest ABI compatibility too. Keeping ABI compatibility on the machine-friendly device types and interfaces is already hard enough. We already have aliases that automatically select a virtio device type at qdev-monitor.c:qdev_alias_table[], and I don't know if they are supposed to keep a stable guest ABI. -- Eduardo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Mon, Nov 19, 2018 at 07:56:38PM +0100, Cornelia Huck wrote: > On Mon, 19 Nov 2018 13:42:58 -0500 > "Michael S. Tsirkin" wrote: > > > On Mon, Nov 19, 2018 at 07:32:38PM +0100, Cornelia Huck wrote: > > > On Mon, 19 Nov 2018 13:07:59 -0500 > > > "Michael S. Tsirkin" wrote: > > > > > And I strongly believe command line users really really do not want all > > > > this mess. Even adding "pci" is the name confuses people (what are the > > > > other options?). For command line model=virtio is pretty much perfect. > > > > > > I'd argue that it's problematic on platforms where you have different > > > options for virtio transports. What does "model=virtio" mean? Always > > > virtio-pci, if available? Or rather virtio-, with > > > being the best option for the machine? > > > > Most people don't care, for them it's "whatever works". > > > > We have this assumption that if we force a choice then people will > > choose the right thing but in practice they will do what we all do, play > > with it until it kind of works and leave well alone afterwards. > > That's at best - at worst give up and use an easier tool. > > That implies that we (the developers) need to care and make sure that > "model=virtio" gets them the best possible transport (i.e. on s390x, > that would be ccw unless the user explicitly requests pci; I'm not sure > what the situation with mmio is -- probably "use pci whenever > possible"?) I think that's what libvirt already gives us today (I hope.) > > What makes it messy on the pci side is that the "best option" actually > depends on what kind of guest the user wants to run (if the guest is > too old, you're stuck with transitional; if you want to reap the > benefits of PCIe, you need non-transitional...) Well it works now - connect it to a bus and it figures out whether it should do transitional or not. You can force transitional in PCIe anyway but then you are limited to about 15 devices - probably sufficient for most people ... -- MST -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Mon, 19 Nov 2018 13:42:58 -0500 "Michael S. Tsirkin" wrote: > On Mon, Nov 19, 2018 at 07:32:38PM +0100, Cornelia Huck wrote: > > On Mon, 19 Nov 2018 13:07:59 -0500 > > "Michael S. Tsirkin" wrote: > > > And I strongly believe command line users really really do not want all > > > this mess. Even adding "pci" is the name confuses people (what are the > > > other options?). For command line model=virtio is pretty much perfect. > > > > I'd argue that it's problematic on platforms where you have different > > options for virtio transports. What does "model=virtio" mean? Always > > virtio-pci, if available? Or rather virtio-, with > > being the best option for the machine? > > Most people don't care, for them it's "whatever works". > > We have this assumption that if we force a choice then people will > choose the right thing but in practice they will do what we all do, play > with it until it kind of works and leave well alone afterwards. > That's at best - at worst give up and use an easier tool. That implies that we (the developers) need to care and make sure that "model=virtio" gets them the best possible transport (i.e. on s390x, that would be ccw unless the user explicitly requests pci; I'm not sure what the situation with mmio is -- probably "use pci whenever possible"?) I think that's what libvirt already gives us today (I hope.) What makes it messy on the pci side is that the "best option" actually depends on what kind of guest the user wants to run (if the guest is too old, you're stuck with transitional; if you want to reap the benefits of PCIe, you need non-transitional...) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Mon, Nov 19, 2018 at 07:32:38PM +0100, Cornelia Huck wrote: > On Mon, 19 Nov 2018 13:07:59 -0500 > "Michael S. Tsirkin" wrote: > > > On Mon, Nov 19, 2018 at 11:41:05AM +0100, Cornelia Huck wrote: > > > On Fri, 16 Nov 2018 01:45:51 -0200 > > > Eduardo Habkost wrote: > > > > > > > On Thu, Nov 15, 2018 at 05:29:24PM +0100, Andrea Bolognani wrote: > > > > > > And once that's done, "non-transitional" (while matching the > > > > > language of the spec) starts to look a bit unnecessary when you > > > > > could simply have > > > > > > > > > > virtio-*-pci > > > > > virtio-*-pci-1 > > > > > virtio-*-pci-1-transitional > > > > > > > > > > instead. But I don't feel as strongly about this as I do about > > > > > keeping the virtio revision in the device name :) > > > > > > > > I like that suggestion. Makes the device names more explicit > > > > _and_ shorter. I'll do that in v3. > > > > > > OTOH, that would mean we'd need to introduce new device types if we > > > ever start to support a virtio 2.x standard. My understanding was that > > > we'll want separate device types for transitional and non-transitional > > > for two reasons: the bus which a device can be plugged into, and > > > changing ids. Do we really expect huge changes in a possible 2.x > > > standard that affect virtio-pci only, and not other virtio transports > > > as well? > > > > Yes I think adding a version there is a mistake. > > transitional/legacy/non-transitional are spec terms so > > they are unlikely to change abruptly. OTOH virtio TC can > > just decide next version is 2.0 on a drop of a hat. > > I don't really expect that to happen on a drop of a hat, though :) It's > probably more likely when we either have some really major change (and > we messed up if we can't handle that via the virtio compatibility > mechanism), or we go up from 1.x because x is getting too large (won't > happen in the near future.) > > But yes, we should be able to handle further updates without any change > like the ones complicating things now for virtio-pci, as that was > mostly the transition to a proper standard while flushing out some > design problems that you only become aware of later. > > > > > And I strongly believe command line users really really do not want all > > this mess. Even adding "pci" is the name confuses people (what are the > > other options?). For command line model=virtio is pretty much perfect. > > I'd argue that it's problematic on platforms where you have different > options for virtio transports. What does "model=virtio" mean? Always > virtio-pci, if available? Or rather virtio-, with > being the best option for the machine? Most people don't care, for them it's "whatever works". We have this assumption that if we force a choice then people will choose the right thing but in practice they will do what we all do, play with it until it kind of works and leave well alone afterwards. That's at best - at worst give up and use an easier tool. > > So all these names are there primarily for libvirt's benefit. > > And the only input from libvirt devs so far > > has been that it's unclear how does cross version > > migration work. That needs to be addressed in some way. > > > > So can we maybe start with a libvirt domain xml patch, with an > > implementation for existing QEMU, get that acked, and then just map it > > back to qemu command line as directly as possible? > > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Mon, 19 Nov 2018 13:07:59 -0500 "Michael S. Tsirkin" wrote: > On Mon, Nov 19, 2018 at 11:41:05AM +0100, Cornelia Huck wrote: > > On Fri, 16 Nov 2018 01:45:51 -0200 > > Eduardo Habkost wrote: > > > > > On Thu, Nov 15, 2018 at 05:29:24PM +0100, Andrea Bolognani wrote: > > > > And once that's done, "non-transitional" (while matching the > > > > language of the spec) starts to look a bit unnecessary when you > > > > could simply have > > > > > > > > virtio-*-pci > > > > virtio-*-pci-1 > > > > virtio-*-pci-1-transitional > > > > > > > > instead. But I don't feel as strongly about this as I do about > > > > keeping the virtio revision in the device name :) > > > > > > I like that suggestion. Makes the device names more explicit > > > _and_ shorter. I'll do that in v3. > > > > OTOH, that would mean we'd need to introduce new device types if we > > ever start to support a virtio 2.x standard. My understanding was that > > we'll want separate device types for transitional and non-transitional > > for two reasons: the bus which a device can be plugged into, and > > changing ids. Do we really expect huge changes in a possible 2.x > > standard that affect virtio-pci only, and not other virtio transports > > as well? > > Yes I think adding a version there is a mistake. > transitional/legacy/non-transitional are spec terms so > they are unlikely to change abruptly. OTOH virtio TC can > just decide next version is 2.0 on a drop of a hat. I don't really expect that to happen on a drop of a hat, though :) It's probably more likely when we either have some really major change (and we messed up if we can't handle that via the virtio compatibility mechanism), or we go up from 1.x because x is getting too large (won't happen in the near future.) But yes, we should be able to handle further updates without any change like the ones complicating things now for virtio-pci, as that was mostly the transition to a proper standard while flushing out some design problems that you only become aware of later. > > And I strongly believe command line users really really do not want all > this mess. Even adding "pci" is the name confuses people (what are the > other options?). For command line model=virtio is pretty much perfect. I'd argue that it's problematic on platforms where you have different options for virtio transports. What does "model=virtio" mean? Always virtio-pci, if available? Or rather virtio-, with being the best option for the machine? > So all these names are there primarily for libvirt's benefit. > And the only input from libvirt devs so far > has been that it's unclear how does cross version > migration work. That needs to be addressed in some way. > > So can we maybe start with a libvirt domain xml patch, with an > implementation for existing QEMU, get that acked, and then just map it > back to qemu command line as directly as possible? > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Mon, Nov 19, 2018 at 11:41:05AM +0100, Cornelia Huck wrote: > On Fri, 16 Nov 2018 01:45:51 -0200 > Eduardo Habkost wrote: > > > On Thu, Nov 15, 2018 at 05:29:24PM +0100, Andrea Bolognani wrote: > > > > One thing that I'm very much not convinced about is the naming, > > > specifically leaving the virtio revision out: I get it that we > > > Should Never Need™ another major version of the spec, but I'm > > > afraid discounting the possibility outright might prove to be > > > shortsighted and come back to bite us later, so I'd much rather > > > keep it. That's not the claim. In fact the reverse is true - a major revision can come at any point. The claim is that virtio compatibility is not based on version numbers. And another claim is that you can trust the virtio TC not to overload terminology that it put in the spec. So use that and you should be fine. Come up with your own and end up writing another spec just to document it. > > > > > > And once that's done, "non-transitional" (while matching the > > > language of the spec) starts to look a bit unnecessary when you > > > could simply have > > > > > > virtio-*-pci > > > virtio-*-pci-1 > > > virtio-*-pci-1-transitional > > > > > > instead. But I don't feel as strongly about this as I do about > > > keeping the virtio revision in the device name :) > > > > I like that suggestion. Makes the device names more explicit > > _and_ shorter. I'll do that in v3. > > OTOH, that would mean we'd need to introduce new device types if we > ever start to support a virtio 2.x standard. My understanding was that > we'll want separate device types for transitional and non-transitional > for two reasons: the bus which a device can be plugged into, and > changing ids. Do we really expect huge changes in a possible 2.x > standard that affect virtio-pci only, and not other virtio transports > as well? Yes I think adding a version there is a mistake. transitional/legacy/non-transitional are spec terms so they are unlikely to change abruptly. OTOH virtio TC can just decide next version is 2.0 on a drop of a hat. And I strongly believe command line users really really do not want all this mess. Even adding "pci" is the name confuses people (what are the other options?). For command line model=virtio is pretty much perfect. So all these names are there primarily for libvirt's benefit. And the only input from libvirt devs so far has been that it's unclear how does cross version migration work. That needs to be addressed in some way. So can we maybe start with a libvirt domain xml patch, with an implementation for existing QEMU, get that acked, and then just map it back to qemu command line as directly as possible? -- MST -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Fri, 16 Nov 2018 01:45:51 -0200 Eduardo Habkost wrote: > On Thu, Nov 15, 2018 at 05:29:24PM +0100, Andrea Bolognani wrote: > > One thing that I'm very much not convinced about is the naming, > > specifically leaving the virtio revision out: I get it that we > > Should Never Need™ another major version of the spec, but I'm > > afraid discounting the possibility outright might prove to be > > shortsighted and come back to bite us later, so I'd much rather > > keep it. > > > > And once that's done, "non-transitional" (while matching the > > language of the spec) starts to look a bit unnecessary when you > > could simply have > > > > virtio-*-pci > > virtio-*-pci-1 > > virtio-*-pci-1-transitional > > > > instead. But I don't feel as strongly about this as I do about > > keeping the virtio revision in the device name :) > > I like that suggestion. Makes the device names more explicit > _and_ shorter. I'll do that in v3. OTOH, that would mean we'd need to introduce new device types if we ever start to support a virtio 2.x standard. My understanding was that we'll want separate device types for transitional and non-transitional for two reasons: the bus which a device can be plugged into, and changing ids. Do we really expect huge changes in a possible 2.x standard that affect virtio-pci only, and not other virtio transports as well? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Thu, Nov 15, 2018 at 05:29:24PM +0100, Andrea Bolognani wrote:
> On Wed, 2018-11-14 at 21:38 -0200, Eduardo Habkost wrote:
> > Many of the current virtio-*-pci device types actually represent
> > 3 different types of devices:
> > * virtio 1.0 non-transitional devices
> > * virtio 1.0 transitional devices
> > * virtio 0.9 ("legacy device" in virtio 1.0 terminology)
> >
> > That would be just an annoyance if it didn't break our device/bus
> > compatibility QMP interfaces. With this multi-purpose device
> > type, there's no way to tell management software that
> > transitional devices and legacy devices require a Conventional
> > PCI bus.
> >
> > The multi-purpose device types would also prevent us from telling
> > management software what's the PCI vendor/device ID for them,
> > because their PCI IDs change at runtime depending on the bus
> > where they were plugged.
> >
> > This patch adds separate device types for each of those virtio
> > device flavors:
> >
> > - virtio-*-pci: the existing multi-purpose device types
> > - Configurable using `disable-legacy` and `disable-modern`
> > properties
> > - Legacy driver support is automatically enabled/disabled
> > depending on the bus where it is plugged
> > - Supports Conventional PCI and PCI Express buses
> > (but Conventional PCI is incompatible with
> > disable-legacy=off)
> > - Changes PCI vendor/device IDs at runtime
> > - virtio-*-pci-transitional: virtio-1.0 device supporting legacy drivers
> > - Supports Conventional PCI buses only, because
> > it has a PIO BAR
> > - virtio-*-pci-non-transitional: modern-only
> > - Supports both Conventional PCI and PCI Express buses
>
> So, my understanding was that transitional devices would be suitable
> for both PCI and PCIe slots and non-transitional devices could only
> work in PCIe slots, but based on the above it looks like I got it
> pretty much completely wrong? I'm not too surprised that would be
> the case, to be honest: keeping this stuff straight in my head has
> always been a bit of a challenge, so I can't possibly not welcome a
> proposal like this, which will spell it out a bit more :)
That's possibly my fault. I described it completely wrong in one
message in the v1 thread.
>
> Let me try to map the interactions out:
>
> * virtio-*-pci-transitional
> + plugged into PCI slot
> - shows up as vendor1/device1
> + plugged into PCIe slot
> - doesn't work
>
> * virtio-*-pci-non-transitional
> + plugged into PCI slot
> - shows up as vendor2/device2
> + plugged into PCIe slot
> - shows up as vendor2/device2
>
> * virtio-*-pci
> + plugged into PCI slot
> - shows up as vendor1/device1
> (same as virtio-*-pci-transitional)
> + plugged into PCIe slot
> - shows up as vendor2/device2
> (same as virtio-*-pci-non-transitional)
>
> Does that look about right?
Exactly.
>
> Once all the various pieces have fallen into place, when adding a
> device to a guest running a modern OS we would find out through
> libosinfo that it supports vendor2/device2 (and vendor1/device1
> too, I guess?) so we would choose the non-transitional variant and
> plug it into PCIe when possible (q35) or PCI otherwise (pc); on
> the other hand, an older guest OS like CentOS 6 will only advertise
> support for vendor1/device1, so we'd have to use the transitional
> variant instead and plug it into a PCI slot regardless of the
> machine type, which more specifically means building a
> pcie.0 <- pcie-root-port <- pcie-pci-bridge topology for q35
> guests.
>
> If all of the above is correct, then it sounds like a feasible
> enough plan to me, though of course it be a long time before users
> and management applications can rely on these new device types
> being available in downstream distributions...
>
> One thing that I'm very much not convinced about is the naming,
> specifically leaving the virtio revision out: I get it that we
> Should Never Need™ another major version of the spec, but I'm
> afraid discounting the possibility outright might prove to be
> shortsighted and come back to bite us later, so I'd much rather
> keep it.
>
> And once that's done, "non-transitional" (while matching the
> language of the spec) starts to look a bit unnecessary when you
> could simply have
>
> virtio-*-pci
> virtio-*-pci-1
> virtio-*-pci-1-transitional
>
> instead. But I don't feel as strongly about this as I do about
> keeping the virtio revision in the device name :)
I like that suggestion. Makes the device names more explicit
_and_ shorter. I'll do that in v3.
--
Eduardo
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Wed, 2018-11-14 at 21:38 -0200, Eduardo Habkost wrote:
> Many of the current virtio-*-pci device types actually represent
> 3 different types of devices:
> * virtio 1.0 non-transitional devices
> * virtio 1.0 transitional devices
> * virtio 0.9 ("legacy device" in virtio 1.0 terminology)
>
> That would be just an annoyance if it didn't break our device/bus
> compatibility QMP interfaces. With this multi-purpose device
> type, there's no way to tell management software that
> transitional devices and legacy devices require a Conventional
> PCI bus.
>
> The multi-purpose device types would also prevent us from telling
> management software what's the PCI vendor/device ID for them,
> because their PCI IDs change at runtime depending on the bus
> where they were plugged.
>
> This patch adds separate device types for each of those virtio
> device flavors:
>
> - virtio-*-pci: the existing multi-purpose device types
> - Configurable using `disable-legacy` and `disable-modern`
> properties
> - Legacy driver support is automatically enabled/disabled
> depending on the bus where it is plugged
> - Supports Conventional PCI and PCI Express buses
> (but Conventional PCI is incompatible with
> disable-legacy=off)
> - Changes PCI vendor/device IDs at runtime
> - virtio-*-pci-transitional: virtio-1.0 device supporting legacy drivers
> - Supports Conventional PCI buses only, because
> it has a PIO BAR
> - virtio-*-pci-non-transitional: modern-only
> - Supports both Conventional PCI and PCI Express buses
So, my understanding was that transitional devices would be suitable
for both PCI and PCIe slots and non-transitional devices could only
work in PCIe slots, but based on the above it looks like I got it
pretty much completely wrong? I'm not too surprised that would be
the case, to be honest: keeping this stuff straight in my head has
always been a bit of a challenge, so I can't possibly not welcome a
proposal like this, which will spell it out a bit more :)
Let me try to map the interactions out:
* virtio-*-pci-transitional
+ plugged into PCI slot
- shows up as vendor1/device1
+ plugged into PCIe slot
- doesn't work
* virtio-*-pci-non-transitional
+ plugged into PCI slot
- shows up as vendor2/device2
+ plugged into PCIe slot
- shows up as vendor2/device2
* virtio-*-pci
+ plugged into PCI slot
- shows up as vendor1/device1
(same as virtio-*-pci-transitional)
+ plugged into PCIe slot
- shows up as vendor2/device2
(same as virtio-*-pci-non-transitional)
Does that look about right?
Once all the various pieces have fallen into place, when adding a
device to a guest running a modern OS we would find out through
libosinfo that it supports vendor2/device2 (and vendor1/device1
too, I guess?) so we would choose the non-transitional variant and
plug it into PCIe when possible (q35) or PCI otherwise (pc); on
the other hand, an older guest OS like CentOS 6 will only advertise
support for vendor1/device1, so we'd have to use the transitional
variant instead and plug it into a PCI slot regardless of the
machine type, which more specifically means building a
pcie.0 <- pcie-root-port <- pcie-pci-bridge topology for q35
guests.
If all of the above is correct, then it sounds like a feasible
enough plan to me, though of course it be a long time before users
and management applications can rely on these new device types
being available in downstream distributions...
One thing that I'm very much not convinced about is the naming,
specifically leaving the virtio revision out: I get it that we
Should Never Need™ another major version of the spec, but I'm
afraid discounting the possibility outright might prove to be
shortsighted and come back to bite us later, so I'd much rather
keep it.
And once that's done, "non-transitional" (while matching the
language of the spec) starts to look a bit unnecessary when you
could simply have
virtio-*-pci
virtio-*-pci-1
virtio-*-pci-1-transitional
instead. But I don't feel as strongly about this as I do about
keeping the virtio revision in the device name :)
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Thu, 15 Nov 2018 12:21:55 +0100 Cornelia Huck wrote: > After a quick look, this seems fine; have not actually tried to run it > yet. Played a bit with it (with zpci devices for a s390x machine), seems to work as expected. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Wed, 14 Nov 2018 21:38:31 -0200
Eduardo Habkost wrote:
> diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
> index 813082b0d7..1d2a11504f 100644
> --- a/hw/virtio/virtio-pci.h
> +++ b/hw/virtio/virtio-pci.h
(...)
> +/**
> + * VirtioPCIDeviceTypeInfo:
> + *
> + * Template for virtio PCI device types. See virtio_pci_types_register()
> + * for details.
> + */
> +typedef struct VirtioPCIDeviceTypeInfo {
> +/* Prefix for the class names */
> +const char *name_prefix;
Maybe call this the vpci_name instead? It's not really a
prefix in the way I would usually use the term, but rather a type name
with a possible suffix tacked onto it.
> +/* Parent type. If NULL, TYPE_VIRTIO_PCI is used */
> +const char *parent;
> +/* If modern_only is true, only type will be registered */
> +bool modern_only;
> +
> +/* Same as TypeInfo fields: */
> +size_t instance_size;
> +void (*instance_init)(Object *obj);
> +void (*class_init)(ObjectClass *klass, void *data);
> +} VirtioPCIDeviceTypeInfo;
> +
> +/*
> + * Register virtio-pci types. Each virtio-pci device type will be available
> + * in 3 flavors:
> + * - -transitional: modern device supporting legacy drivers
> + * - Supports Conventional PCI buses only
> + * - -non-transitional: modern-only
> + * - Supports Conventional PCI and PCI Express buses
> + * - : virtio version configurable, legacy driver support
> + * automatically selected when device is plugged
> + * _ This was the only flavor supported until QEMU 3.1
s/_/-/
s/until/up to/ ?
> + * - Supports Conventional PCI and PCI Express buses
> + *
> + * All the types above will inherit from "-base", so generic
> + * code can use "-base" on type casts.
> + *
> + * We need a separate "-base" type instead of making all types
> inherit
> + * from for two reasons:
> + * 1) will implement INTERFACE_PCIE_DEVICE, but
> + *-transitional won't.
> + * 2) will have the "disable-legacy" and "disable-modern"
> properties,
> + *-transitional and -non-transitional won't.
I'd formulate this rather as "x implements/has something, y
and z do not", as the code actually does that (and does not just intend
to do so :)
> + */
> +void virtio_pci_types_register(const VirtioPCIDeviceTypeInfo *t);
> +
> #endif
(...)
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index a954799267..0fa248d68c 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
(...)
> +static void virtio_pci_1_0_instance_init(Object *obj)
Ditch the _0? I don't expect this to change the name when virtio 1.1
arrives.
> +{
> +VirtIOPCIProxy *proxy = VIRTIO_PCI(obj);
> +
> +proxy->disable_legacy = ON_OFF_AUTO_ON;
> +proxy->disable_modern = false;
> +}
(...)
After a quick look, this seems fine; have not actually tried to run it
yet.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Thu, 15 Nov 2018 10:05:59 +
Daniel P. Berrangé wrote:
> On Wed, Nov 14, 2018 at 09:38:31PM -0200, Eduardo Habkost wrote:
> > Many of the current virtio-*-pci device types actually represent
> > 3 different types of devices:
> > * virtio 1.0 non-transitional devices
> > * virtio 1.0 transitional devices
> > * virtio 0.9 ("legacy device" in virtio 1.0 terminology)
> >
> > That would be just an annoyance if it didn't break our device/bus
> > compatibility QMP interfaces. With this multi-purpose device
> > type, there's no way to tell management software that
> > transitional devices and legacy devices require a Conventional
> > PCI bus.
> >
> > The multi-purpose device types would also prevent us from telling
> > management software what's the PCI vendor/device ID for them,
> > because their PCI IDs change at runtime depending on the bus
> > where they were plugged.
> >
> > This patch adds separate device types for each of those virtio
> > device flavors:
> >
> > - virtio-*-pci: the existing multi-purpose device types
> > - Configurable using `disable-legacy` and `disable-modern`
> > properties
> > - Legacy driver support is automatically enabled/disabled
> > depending on the bus where it is plugged
> > - Supports Conventional PCI and PCI Express buses
> > (but Conventional PCI is incompatible with
> > disable-legacy=off)
> > - Changes PCI vendor/device IDs at runtime
> > - virtio-*-pci-transitional: virtio-1.0 device supporting legacy drivers
It's a virtio-1 (not 1.0) device. Otherwise, I like this terminology
better.
> > - Supports Conventional PCI buses only, because
> > it has a PIO BAR
>
> Am I right in thinking that this is basically identical
> to virtio-*-pci, aside from only being valid for PCI
> buses ?
>
> IOW, libvirt can expose this device even if QEMU does
> not support it, by simply using the existing device
> type and only ever placing it in a PCI bus ?
>
> If libvirt did this compatibility approach, can you
> confirm this would be live migration state compatible.
>
> ie can live migrate virtio-*-pci -> virtio-*-pci-transitional,
> provided only PCI bus was used.
It also needs to make sure that neither disable-legacy nor
disable-modern is set. Then this would have a compatible state AFAICS.
>
> > - virtio-*-pci-non-transitional: modern-only
> > - Supports both Conventional PCI and PCI Express buses
>
> IIUC, libvirt can again provide compatibility with old
> QEMU by simply using the existing device type and setting
> disable-legacy ? Can you confirm this would be live
> migration compatible
>
> virtio-*-pci + disable-legacy -> virtio-*pci-non-transitional
I think yes.
[Out of curiosity, libvirt does not do anything with virtio-ccw's max
revision attribute, does it? QEMU uses this on a machine-type level for
compat handling, but I don't think it is useful beyond that.
Fortunately, virtio-ccw does not have complications like the
PCI/PCI-Express bus dependency.]
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Thu, Nov 15, 2018 at 11:50:56AM +0100, Cornelia Huck wrote:
> On Thu, 15 Nov 2018 10:05:59 +
> Daniel P. Berrangé wrote:
>
> > On Wed, Nov 14, 2018 at 09:38:31PM -0200, Eduardo Habkost wrote:
> > > Many of the current virtio-*-pci device types actually represent
> > > 3 different types of devices:
> > > * virtio 1.0 non-transitional devices
> > > * virtio 1.0 transitional devices
> > > * virtio 0.9 ("legacy device" in virtio 1.0 terminology)
> > >
> > > That would be just an annoyance if it didn't break our device/bus
> > > compatibility QMP interfaces. With this multi-purpose device
> > > type, there's no way to tell management software that
> > > transitional devices and legacy devices require a Conventional
> > > PCI bus.
> > >
> > > The multi-purpose device types would also prevent us from telling
> > > management software what's the PCI vendor/device ID for them,
> > > because their PCI IDs change at runtime depending on the bus
> > > where they were plugged.
> > >
> > > This patch adds separate device types for each of those virtio
> > > device flavors:
> > >
> > > - virtio-*-pci: the existing multi-purpose device types
> > > - Configurable using `disable-legacy` and `disable-modern`
> > > properties
> > > - Legacy driver support is automatically enabled/disabled
> > > depending on the bus where it is plugged
> > > - Supports Conventional PCI and PCI Express buses
> > > (but Conventional PCI is incompatible with
> > > disable-legacy=off)
> > > - Changes PCI vendor/device IDs at runtime
> > > - virtio-*-pci-transitional: virtio-1.0 device supporting legacy drivers
>
> It's a virtio-1 (not 1.0) device. Otherwise, I like this terminology
> better.
>
> > > - Supports Conventional PCI buses only, because
> > > it has a PIO BAR
> >
> > Am I right in thinking that this is basically identical
> > to virtio-*-pci, aside from only being valid for PCI
> > buses ?
> >
> > IOW, libvirt can expose this device even if QEMU does
> > not support it, by simply using the existing device
> > type and only ever placing it in a PCI bus ?
> >
> > If libvirt did this compatibility approach, can you
> > confirm this would be live migration state compatible.
> >
> > ie can live migrate virtio-*-pci -> virtio-*-pci-transitional,
> > provided only PCI bus was used.
>
> It also needs to make sure that neither disable-legacy nor
> disable-modern is set. Then this would have a compatible state AFAICS.
That's ok, as libvirt doesn't expose disable-modern or
disable-legacy right now.
> > > - virtio-*-pci-non-transitional: modern-only
> > > - Supports both Conventional PCI and PCI Express buses
> >
> > IIUC, libvirt can again provide compatibility with old
> > QEMU by simply using the existing device type and setting
> > disable-legacy ? Can you confirm this would be live
> > migration compatible
> >
> > virtio-*-pci + disable-legacy -> virtio-*pci-non-transitional
>
> I think yes.
>
> [Out of curiosity, libvirt does not do anything with virtio-ccw's max
> revision attribute, does it? QEMU uses this on a machine-type level for
> compat handling, but I don't think it is useful beyond that.
> Fortunately, virtio-ccw does not have complications like the
> PCI/PCI-Express bus dependency.]
I don't believe we ever set max revision.
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 :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
On Wed, Nov 14, 2018 at 09:38:31PM -0200, Eduardo Habkost wrote:
> Many of the current virtio-*-pci device types actually represent
> 3 different types of devices:
> * virtio 1.0 non-transitional devices
> * virtio 1.0 transitional devices
> * virtio 0.9 ("legacy device" in virtio 1.0 terminology)
>
> That would be just an annoyance if it didn't break our device/bus
> compatibility QMP interfaces. With this multi-purpose device
> type, there's no way to tell management software that
> transitional devices and legacy devices require a Conventional
> PCI bus.
>
> The multi-purpose device types would also prevent us from telling
> management software what's the PCI vendor/device ID for them,
> because their PCI IDs change at runtime depending on the bus
> where they were plugged.
>
> This patch adds separate device types for each of those virtio
> device flavors:
>
> - virtio-*-pci: the existing multi-purpose device types
> - Configurable using `disable-legacy` and `disable-modern`
> properties
> - Legacy driver support is automatically enabled/disabled
> depending on the bus where it is plugged
> - Supports Conventional PCI and PCI Express buses
> (but Conventional PCI is incompatible with
> disable-legacy=off)
> - Changes PCI vendor/device IDs at runtime
> - virtio-*-pci-transitional: virtio-1.0 device supporting legacy drivers
> - Supports Conventional PCI buses only, because
> it has a PIO BAR
Am I right in thinking that this is basically identical
to virtio-*-pci, aside from only being valid for PCI
buses ?
IOW, libvirt can expose this device even if QEMU does
not support it, by simply using the existing device
type and only ever placing it in a PCI bus ?
If libvirt did this compatibility approach, can you
confirm this would be live migration state compatible.
ie can live migrate virtio-*-pci -> virtio-*-pci-transitional,
provided only PCI bus was used.
> - virtio-*-pci-non-transitional: modern-only
> - Supports both Conventional PCI and PCI Express buses
IIUC, libvirt can again provide compatibility with old
QEMU by simply using the existing device type and setting
disable-legacy ? Can you confirm this would be live
migration compatible
virtio-*-pci + disable-legacy -> virtio-*pci-non-transitional
> Reference to previous discussion that originated this idea:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg558389.html
>
> Changes v1 -> v2:
> * Removed *-0.9 devices. Nobody will want to use them, if
> transitional devices work with legacy drivers
> (Gerd Hoffmann, Michael S. Tsirkin)
> * Drop virtio version from name: rename -1.0-transitional to
> -transitional (Michael S. Tsirkin)
> * Renamed -1.0 to -non-transitional
> * Don't add any extra variants to modern-only device types
> (they don't need it)
> * Fix typo on TYPE_VIRTIO_INPUT_HOST_PCI (crash reported by
> Cornelia Huck)
> * No need to change cast macros for modern-only devices
> * Rename virtio_register_types() to virtio_pci_types_register()
>
> Note about points discussed in the v1 thread:
>
> Andrea suggested making separate transitional Conventional PCi
> and transitional PCI Express device types[1]. I didn't do that
> because I don't see which problems this solves. We have many
> other device types that are hybrid (support both PCI Express and
> Conventional PCI) and this was never a problem for us[2].
>
> [1]
> http://mid.mail-archive.com/6f8d59b8ee2d92d73d2957b520bd8bac989fc796.camel@redhat.com
> [2] http://mid.mail-archive.com/20181017155637.GC31060@habkost.net
> ---
> hw/virtio/virtio-pci.h | 80 +--
> hw/display/virtio-gpu-pci.c| 8 +-
> hw/display/virtio-vga.c| 8 +-
> hw/virtio/virtio-crypto-pci.c | 8 +-
> hw/virtio/virtio-pci.c | 215 -
> tests/acceptance/virtio_version.py | 177
> 6 files changed, 406 insertions(+), 90 deletions(-)
> create mode 100644 tests/acceptance/virtio_version.py
>
> diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
> index 813082b0d7..1d2a11504f 100644
> --- a/hw/virtio/virtio-pci.h
> +++ b/hw/virtio/virtio-pci.h
> @@ -216,7 +216,8 @@ static inline void
> virtio_pci_disable_modern(VirtIOPCIProxy *proxy)
> /*
> * virtio-scsi-pci: This extends VirtioPCIProxy.
> */
> -#define TYPE_VIRTIO_SCSI_PCI "virtio-scsi-pci"
> +#define TYPE_VIRTIO_SCSI_PCI_PREFIX "virtio-scsi-pci"
> +#define TYPE_VIRTIO_SCSI_PCI (TYPE_VIRTIO_SCSI_PCI_PREFIX "-base")
> #define VIRTIO_SCSI_PCI(obj) \
> OBJECT_CHECK(VirtIOSCSIPCI, (obj), TYPE_VIRTIO_SCSI_PCI)
>
> @@ -229,7 +230,8 @@ struct VirtIOSCSIPCI {
> /*
> * vhost-scsi-pci: This extends VirtioPCIProxy.
> */
> -#define TYPE_VHOST_SCSI_PCI "vhost-scsi-pci"
> +#define TYPE_VHOST_SCSI_PCI_PREFIX "vhost-scsi-pci"
> +#define TYPE_VHOST_SCSI_PCI (TYPE_VHOST_SCSI_PCI_PREFIX "-base")
> #define VHOST_SCSI_PCI(obj) \
> OBJECT_CHECK(VHostSCSIPCI, (obj),
