All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
	pbonzini@redhat.com, qemu-devel@nongnu.org, rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH RFC] hw/pc: set q35 as the default x86 machine
Date: Mon, 4 Jun 2018 15:30:46 -0300	[thread overview]
Message-ID: <20180604183046.GR7451@localhost.localdomain> (raw)
In-Reply-To: <20180604194913-mutt-send-email-mst@kernel.org>

On Mon, Jun 04, 2018 at 08:17:23PM +0300, Michael S. Tsirkin wrote:
> On Mon, Jun 04, 2018 at 10:26:24AM -0300, Eduardo Habkost wrote:
> > On Mon, Jun 04, 2018 at 02:01:29PM +0100, Daniel P. Berrangé wrote:
> > > On Mon, Jun 04, 2018 at 09:54:15AM -0300, Eduardo Habkost wrote:
> > > > On Mon, Jun 04, 2018 at 04:38:22AM +0300, Michael S. Tsirkin wrote:
> > > > > On Sun, Jun 03, 2018 at 12:27:49PM +0300, Marcel Apfelbaum wrote:
> > > > > > Moving to QEMU 3.0 seems like a good opportunity for such a change.
> > > > > > 
> > > > > > I440FX is really old and does not support modern features like IOMMU.
> > > > > > Q35's SATA emulation is faster than pc's IDE, native PCI express hotplug
> > > > > > is cleaner than ACPI based one and so on...
> > > > > > 
> > > > > > Also the libvirt guys added very good support for the Q35 machine (thanks!).
> > > > > > 
> > > > > > Management software should always specify the machine type and for the
> > > > > > current setups, adding '-machine pc' to the command line is not such a
> > > > > > big deal.
> > > > > > 
> > > > > > In time the pc machine will fade out and we will probably stop adding
> > > > > > new versions at some point.
> > > > > > 
> > > > > > Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
> > > > > 
> > > > > For command line users, I think changing the default isn't nice.
> > > > > 
> > > > > Yes it's easy to add -machine pc but there's no documentation
> > > > > that tells you to do so. Add to that shortcuts like -cdrom
> > > > > stop working, hotplug needs extra bridges to work, and one
> > > > > can see that while management tool users benefit from q35,
> > > > > command line users will suffer.
> > > > > 
> > > > > Can't we add a tag for management without changing the command line
> > > > > default? How about "management-default"? "recommended"? "latest"?
> > > > 
> > > > We could add new aliases if they are useful for management
> > > > software, but we would need a well-defined use case and set of
> > > > requirements+expectations for the new alias.
> > > 
> > > I'm not convinced by the idea of adding a distinct default "for mgmt". All
> > > the problems described wrt 'q35' vs 'pc' apply equally to management apps
> > > as they do to humans. It just happens that one common mgmt layer (libvirt)
> > > knows how to handle some of the complexity of q35. Other mgmt apps though
> > > are just as likely to be hurt by the change as humans are. So effectively
> > > the proposed "for mgmt" is actually  "for libvirt >= some version", which
> > > feels like a layering violation to me.
> > 
> > This means the new alias would be used only if requested
> > explicitly by management software (not used automatically by
> > libvirt).
> > 
> > Taking that into account, I still don't see what exactly would be
> > the use case here, and what exactly users can/can't expect when
> > using the new alias.
> 
> Let's see what we have now first:
> 
> 1. We have a requirement for the user to save the machine type on install
> and maintain it with the image (a separate thread discusses saving that
> as part of a qcow2 image).
> 
> 2. If you use an alias instead you are supposed to resolve it
> and save the resolved value. If you save the alias instead,
> you can't do cross-version live migration.
> 
> 3. If you don't specify anything you get a machine tagged default.  You are
> supposed to find it and save the value found.  If you don't and just
> keep using the default, you can't do cross-version live migration.
> 
> ---
> 
> So now we would like to relax 3 to say
> 	"If you don't and just keep using the default, some images might not
> 	boot".
> 
> unfortunately we probably can't change 3 like this.
> So what I propose instead is simply:
> 
> 4. If you find a machine type value tagged "qmp-default" you must save
>    the value found.  If you don't and just keep using the qmp-default each
>    time, then existing guest images won't boot.
>    This relaxed compatibility requirement allows for advanced features
>    as compared to default.

What problems would this system solve?  Who would prefer to use
the "qmp-default" machine-type instead of the "pc" or "q35"
aliases?

-- 
Eduardo

  reply	other threads:[~2018-06-04 18:30 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-03  9:27 [Qemu-devel] [PATCH RFC] hw/pc: set q35 as the default x86 machine Marcel Apfelbaum
2018-06-04  1:38 ` Michael S. Tsirkin
2018-06-04 12:24   ` Igor Mammedov
2018-06-04 12:35     ` Paolo Bonzini
2018-06-04 18:09       ` John Snow
2018-06-04 12:54   ` Eduardo Habkost
2018-06-04 13:01     ` Daniel P. Berrangé
2018-06-04 13:26       ` Eduardo Habkost
2018-06-04 17:17         ` Michael S. Tsirkin
2018-06-04 18:30           ` Eduardo Habkost [this message]
2018-06-04 16:48       ` Michael S. Tsirkin
2018-06-04 16:56         ` Daniel P. Berrangé
2018-06-04 18:40           ` Marcel Apfelbaum
2018-06-04 21:08             ` Eduardo Habkost
2018-06-04 18:29   ` Marcel Apfelbaum
2018-06-05  7:27     ` Gerd Hoffmann
2018-06-05  8:43       ` Daniel P. Berrangé
2018-06-05 13:06         ` [Qemu-devel] libvirt default machine-type guarantees? (was Re: [PATCH RFC] hw/pc: set q35 as the default x86 machine) Eduardo Habkost
2018-06-05 13:12           ` Daniel P. Berrangé
2018-06-05 13:35             ` Eduardo Habkost
2018-06-05 13:41               ` Daniel P. Berrangé
2018-06-05 13:44               ` [Qemu-devel] [libvirt] " Pavel Hrdina
2018-06-05 14:03                 ` Eduardo Habkost
2018-06-05 14:07                   ` Daniel P. Berrangé
2018-06-05 14:36                     ` Pavel Hrdina
2018-06-05 14:14                   ` Pavel Hrdina
2018-06-05 16:16             ` [Qemu-devel] " Michael S. Tsirkin
2018-06-05 16:22               ` Daniel P. Berrangé
2018-06-05 13:20         ` [Qemu-devel] [PATCH RFC] hw/pc: set q35 as the default x86 machine Marcel Apfelbaum
2018-06-05 13:29           ` Daniel P. Berrangé
2018-06-05 13:44             ` Laszlo Ersek
2018-06-05 13:51               ` Daniel P. Berrangé
2018-06-05 16:22                 ` Michael S. Tsirkin
2018-06-05 15:56             ` Marcel Apfelbaum
2018-06-05 16:01               ` Daniel P. Berrangé
2018-06-05 16:20             ` Michael S. Tsirkin
2018-06-05 16:23               ` Daniel P. Berrangé
2018-06-05 16:33                 ` Michael S. Tsirkin
2018-06-13 18:05         ` Eduardo Habkost
2018-06-14  8:09           ` Daniel P. Berrangé
2018-06-15  2:50             ` Eduardo Habkost
2018-06-15  9:03               ` Daniel P. Berrangé
2018-06-18 17:14                 ` Eduardo Habkost
2018-06-18 17:18                   ` Michael S. Tsirkin
2018-06-20 17:28                     ` Eduardo Habkost
2018-06-21  7:39                       ` Daniel P. Berrangé
2018-06-20 17:33                     ` Peter Maydell
2018-06-21  7:37                       ` Daniel P. Berrangé

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=20180604183046.GR7451@localhost.localdomain \
    --to=ehabkost@redhat.com \
    --cc=berrange@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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.