All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Libvirt <libvir-list@redhat.com>,
	Andrea Bolognani <abologna@redhat.com>,
	Laine Stump <laine@redhat.com>, qemu list <qemu-devel@nongnu.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, 29 Aug 2018 13:25:51 +0200	[thread overview]
Message-ID: <875zzte7nk.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20180817132415.GQ11124@redhat.com> ("Daniel P. =?utf-8?Q?Ber?= =?utf-8?Q?rang=C3=A9=22's?= message of "Fri, 17 Aug 2018 14:24:15 +0100")

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Fri, Aug 17, 2018 at 03:13:22PM +0200, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:
>> 
>> > On Fri, Aug 17, 2018 at 12:35:11PM +0200, Andrea Bolognani wrote:
>> >> On Fri, 2018-08-17 at 10:29 +0100, Daniel P. Berrangé wrote:
>> >> > On Thu, Aug 16, 2018 at 06:20:29PM -0400, Laine Stump wrote:
>> >> > > 5) Some guest OSes that we still want to support (and which would
>> >> > > otherwise work okay on a Q35 virtual machine) have virtio drivers too
>> >> > > old to support virtio-1.0 (CentOS6 and RHEL6 are examples of such OSes),
>> >> > > but due to the chain of reasons listed above, the "standard" config for
>> >> > > a Q35 guest generated by libvirt doesn't support virtio-0.9, hence
>> >> > > doesn't support these guest OSes.
>> >> > 
>> >> > Note when talking about "support" you're really saying it from the
>> >> > downstream vendor, specifically RHEL, POV. From upstream or Fedora POV
>> >> > essentially all x86 OS ever made are in scope for running under QEMU
>> >> > if suitable virtual hardware models have been provided. QEMU doesn't
>> >> > maintain any whitelist of "supported" OS that differs from what is
>> >> > technically capable of being run, in the way downstream vendors do.
>> >> 
>> >> Well, at least in the case of RHEL 6, "not supported" means that it
>> >> will not boot at all on q35 with the default guest topology created
>> >> by libvirt, so that's not really a downstream-only problem :)
>> >
>> > I mean from an upstream POV we still support RHEL-6 fine in i440fx,
>> > so there's no reason to particularly care about RHEL-6 with q35
>> > upstream.
>> 
>> Only true if Q35 provides nothing of value over i440FX for RHEL-6
>> guests.  Does it?
>
> Q35 has little technical benefit over i440fx for the majority of guest
> deployments, regardless of guest OS.

Alright, I can look it up myself.  This list is from Marcel's slide deck
"Q35 - QEMU" <https://wiki.qemu.org/images/4/4e/Q35.pdf>, August 2016,
page 13:

    Q35-only features
    ● PCIe “goodies”
    – Extended configuration space (MMCFG)
    – PCIe native hotplug
    – Advanced Error Reporting (AER)
    – Alternative Routing-ID Interpretation (ARI)
    – Native Power Management
    – Function Level Reset (FLR)
    – Address Translation Services (ATS)
    ● AHCI storage controller
    ● vIOMMU emulation
    ● “Secure” Secure Boot

We can debate the actual value of these items.  Perhaps this will then
result in a "little technical benefit over i440fx for the majority of
guest deployments, regardless of guest OS" verdict.  That's okay.  What
doesn't work for me is making such sweeping claims without presenting
the evidence.

  reply	other threads:[~2018-08-29 11:42 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 [this message]
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é
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=875zzte7nk.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=abologna@redhat.com \
    --cc=berrange@redhat.com \
    --cc=laine@redhat.com \
    --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.