All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Andrea Bolognani <abologna@redhat.com>,
	Libvirt <libvir-list@redhat.com>,
	qemu list <qemu-devel@nongnu.org>, Laine Stump <laine@laine.org>
Subject: Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0
Date: Wed, 22 Aug 2018 13:26:01 +0100	[thread overview]
Message-ID: <20180822122601.GI12750@redhat.com> (raw)
In-Reply-To: <20180822120135.GN18995@localhost.localdomain>

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.

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.

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 :|

  reply	other threads:[~2018-08-22 12:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-16 22:20 [Qemu-devel] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0 Laine Stump
2018-08-17  7:05 ` [Qemu-devel] [libvirt] " Gerd Hoffmann
2018-08-17  9:29 ` [Qemu-devel] " Daniel P. Berrangé
2018-08-17 10:35   ` [Qemu-devel] [libvirt] " Andrea Bolognani
2018-08-17 10:43     ` Daniel P. Berrangé
2018-08-17 13:13       ` Markus Armbruster
2018-08-17 13:24         ` Daniel P. Berrangé
2018-08-29 11:25           ` Markus Armbruster
2018-08-17 13:59       ` Andrea Bolognani
2018-08-21 18:21     ` Laine Stump
2018-08-22 10:36       ` Andrea Bolognani
2018-08-22 10:52         ` Daniel P. Berrangé
2018-08-22 12:01         ` Eduardo Habkost
2018-08-22 12:26           ` Daniel P. Berrangé [this message]
2018-08-22 12:54             ` Eduardo Habkost
2018-08-22 13:44               ` Daniel P. Berrangé
2018-08-22 14:18                 ` Eduardo Habkost
2018-08-22 14:57                   ` Daniel P. Berrangé
2018-08-22 15:49                     ` Eduardo Habkost
2018-08-22 16:02                       ` Daniel P. Berrangé
2018-08-22 14:37                 ` Laine Stump
2018-08-22 15:01                   ` Daniel P. Berrangé
2018-08-23 16:08               ` Markus Armbruster
2018-08-23 16:26                 ` Daniel P. Berrangé
2018-08-23 17:04                   ` Eduardo Habkost
2018-08-23 19:10                     ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180822122601.GI12750@redhat.com \
    --to=berrange@redhat.com \
    --cc=abologna@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=laine@laine.org \
    --cc=libvir-list@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.