qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Paul Mackerras" <paulus@samba.org>,
	"Andreas Färber" <afaerber@suse.de>,
	"Alexander Graf" <agraf@suse.com>
Subject: [Qemu-devel] machines and versions - why so many?
Date: Tue, 24 Jun 2014 00:15:07 +1000	[thread overview]
Message-ID: <53A8366B.1020301@ozlabs.ru> (raw)

Hi!

I have been hearing recently that we (server PPC) should have more that
just one pseries machine in QEMU because this is what everybody else does :)

My current understanding is that multiple machines (like
pc-i440fx-1.4..2.1, and many others) are needed:

1) for the -nodefaults case when a lot of devices are still created and
there is no other way to configure them;

in "pseries", only CPU + empty VIO + empty PCI buses are created,
everything else can be created explicitly; nothing to tweak;

2) to enable/disable CPUID_EXT_xxx bits (saw in x86);

in "pseries", there is a "compat" property on CPU and that seems to be enough;

3) for devices which are created explicitly and for which we want some
capabilities be disabled and we do not want to bother about this every time
we run QEMU;

ok, this one makes some sense for "pseries" to have (and upcoming
endianness register on VGA seems to be the case) but it seems that adding a
"compat" or "feature" property to the VGA device (and other devices which
deal with this kind of compatibility) is still more architecturally correct
thing to do, and let libvirt deal with the rest.

Since I (almost) always miss the bigger picture, what do I miss now? :) Thanks!


-- 
Alexey

             reply	other threads:[~2014-06-23 14:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-23 14:15 Alexey Kardashevskiy [this message]
2014-06-23 14:59 ` [Qemu-devel] machines and versions - why so many? Paolo Bonzini
2014-06-23 21:35   ` Alexey Kardashevskiy
2014-06-23 21:41     ` Andreas Färber
2014-06-23 22:33       ` Alexey Kardashevskiy
2014-06-24  5:21         ` Paolo Bonzini
2014-06-24 11:15           ` Andreas Färber
2014-06-24 13:05             ` Alexey Kardashevskiy
2014-06-24 12:38       ` Marcel Apfelbaum
2014-06-23 21:41     ` Peter Maydell
2014-06-24  5:15     ` Paolo Bonzini
2014-06-24  5:37       ` Alexey Kardashevskiy
2014-06-24  8:17         ` Markus Armbruster
2014-06-24  9:10           ` Alexey Kardashevskiy
2014-06-24 11:22           ` Andreas Färber
2014-06-24 12:56             ` Alexey Kardashevskiy
2014-06-23 15:16 ` Markus Armbruster
2014-06-24  1:06   ` Alexey Kardashevskiy

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=53A8366B.1020301@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.com \
    --cc=paulus@samba.org \
    --cc=pbonzini@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).