On Wed, Aug 22, 2018 at 11:18:28AM -0300, Eduardo Habkost wrote:
> On Wed, Aug 22, 2018 at 02:44:40PM +0100, Daniel P. Berrangé wrote:
> > On Wed, Aug 22, 2018 at 09:54:55AM -0300, Eduardo Habkost wrote:
> > > On Wed, Aug 22, 2018 at 01:26:01PM +0100, Daniel P. Berrangé wrote:
> > > > On Wed, Aug 22, 2018 at 09:01:35AM -0300, Eduardo Habkost wrote:
> > > > > On Wed, Aug 22, 2018 at 12:36:27PM +0200, Andrea Bolognani wrote:
> > > > > > On Tue, 2018-08-21 at 14:21 -0400, Laine Stump wrote:
> > > > > > > On 08/17/2018 06:35 AM, Andrea Bolognani wrote:
> > > > > > > > If we decide we want to explicitly spell out the options instead
> > > > > > > > of relying on QEMU changing behavior based on the slot type,
> > > > > > > > which
> > > > > > > > is probably a good idea anyway, I think we should have
> > > > > > > >
> > > > > > > > virtio-0.9 => disable-legacy=no,disable-modern=no
> > > > > > > > virtio-1.0 => disable-legacy=yes,disable-modern=no
> > > > > > > >
> > > > > > > > There's basically no reason to have a device legacy-only rather
> > > > > > > > than transitional, and spelling out both options instead of only
> > > > > > > > one of them just seems more robust.
> > > > > > >
> > > > > > > I agree with both of those, but the counter-argument is that
> > > > > > > "virtio"
> > > > > > > already describes a transitional device like your proposal for
> > > > > > > virtio-0.9 (at least today), and it makes the versioned models
> > > > > > > less
> > > > > > > orthogonal. In the end, I could go either way...
> > > > > >
> > > > > > Yeah, Dan already made that argument and convinced me that we
> > > > > > should use virtio-0.9 for legacy only, virtio-1.0 for modern only
> > > > > > and plain virtio for no enforced behavior / transitional.
> > > > >
> > > > > I don't understand why we are optimizing the new system for the
> > > > > less useful use cases:
> > > > >
> > > > > I don't see a use case where virtio-0.9 (legacy-only) would be
> > > > > more useful than virtio-transitional. I don't see why anybody
> > > > > would prefer a legacy-only device instead of a transitional
> > > > > device. Even if your guest has only legacy drivers, it might be
> > > > > upgraded and get new drivers in the future.
> > > > >
> > > > > I don't see a use case where virtio-1.0 (modern-only) would be
> > > > > more useful than "virtio". If you are running i440fx, you get a
> > > > > transitional device with "virtio", and I don't see why anybody
> > > > > would prefer a modern-only device. If you are running Q35, you
> > > > > already get a modern-only device with "virtio".
> > > > >
> > > > > The most useful feature users need is the ability to ask for a
> > > > > transitional virtio device on Q35, and this use case is
> > > > > explicitly being left out of the proposal. Why?
> > > >
> > > > You can already get a transitional device on Q35, albeit with manual
> > > > placement. Adding flags for magic placement for the existing devices
> > > > is not something that is suitable for the XML. The ability to get
> > > > legacy-only, or modern-only doesn't exist today in any way, so that
> > > > would be a valid new feature.
> > >
> > > Transitional devices and modern-only devices are different kinds
> > > of devices. Making the guest see a different type of device
> > > depending on where it's plugged is why we got into this mess, why
> > > would we recommend applications to rely on this behavior?
> > >
> > > That's why I like your virtio-0.9/virtio-1.0 proposal. I just
> > > don't see why you think virtio-transitional should be out of it.
> >
> > An explicit virtio-transitional device is still two separate
> > devices pretending to be the same thing, but magically changing
> > their identity at runtime. We've already got that situation with
> > existing device models, and I'm loathe to see us add 2nd device
> > model with that same behaviour, just for sake of having a slightly
> > different PCI bus placement strategy to support outdated guest OS.
>
> Your seem to be describing what the current "virtio" device is:
> it becomes a non-transitional (modern-only) Virtio device on some
> cases, and becomes a transitional Virtio device on other cases.
> It is two devices pretending to be the same thing. That's
> exactly what I would like applications to get rid of.
>
> Now, the above is really not an accurate description of
> transitional Virtio devices. A transitional Virtio device is
> something clearly specified in the Virtio spec, and it just means
> a device that supports two types of drivers. It's not different
> from a x86_64 CPU that can run 32-bit OSes.
>
> See:
> http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-60001
> http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-3090004
When I say a device pretending to be 2 different devices, I'm
generally referring to the fact that a single QEMU device model
can expose two different PCI device IDs depending on how it is
configured and/or placed.
> > > > Honestly though, the longer this discussion goes on, the more I think
> > > > the answer is just "do nothing". All this time spent on discussion,
> > > > and future time spent on implementing new logic in apps, is merely
> > > > to support running RHEL-6 on Q35. I think we should just say that
> > > > RHEL-6 should use i440fx forever and be done with it.
> > >
> > > I'm not sure if you are saying that we (Red Hat) shouldn't spend
> > > time implementing it, or that the libvirt upstream project should
> > > reject the patches if somebody implements it. I would understand
> > > the former, but not the latter.
> >
> > Even if someone is willing to implement it in libvirt, we have to
> > consider the cost of supporting it in both libvirt and applications
> > using libvirt and the complexity it adds to our story about the
> > docs / best practices for configuring guests.
> >
> > Even though I do kind of like the virtio-0.9/virtio-1.0 device model
> > as concepts, I'm yet to be convinced that implementing them in libvirt
> > and then also in all the downstream applications (oVirt, OpenStack,
> > virt-manager, cockpit, etc) is actually worth the cost.
> >
> > There's little compelling reason to care about running outdated OS
> > like RHEL-6 on Q35 in general. The motivation behind it is just
> > coming from an artifically created problem downstream, by wishing
> > to drop the i440fx machine at some still undeteremined point in the
> > future. By the time that future comes, RHEL-6 may well even be
> > end of life making the entire exercise a pointless.
>
> I'm all for making a cost/benefit analysis, but I don't think you
> are taking into account the costs of keeping the confusing
> semantics of existing "virtio" devices.
>
> If you still want to refuse to provide a sane way to configure
> transitional Virtio devices, I really won't care. But I believe
> the interface you are trying to keep is actually the one you are
> criticizing ("two separate devices pretending to be the same
> thing, but magically changing their identity at runtime").
Yeah, I guess I should make a distinction between what I would
do if it was a clean slate, and what we should do given our existing
practice.
If we had a clean slate I would not like to see our current impl
done. Given that it already exists, however, we're stuck with
that forever. So the question is whether implementing any of
the alternative options is a net benefit for libvirt & mgmt apps
overall. My gut feeling is that despite the downsides of the
current impl, it is not worth trying todo something different.
The thing that has really tipped my mind this way is that even
if we provide new device models, mgmt apps will be loathe to
actually use them because it will prevent live migration of
those guests to hosts with older libvirt.
So my feeling is we should do the work to enable use of Q35
by default in mgmt apps, for guest OS where it is known to
work correctly today. Every other OS should just stick with
i440fx as we already know that works for them today and Q35
doesn't offer legacy OS compelling enough benefits to switch.
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
