From: Paolo Bonzini <pbonzini@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
Juan Quintela <quintela@redhat.com>
Cc: qemu-devel@nongnu.org, dgilbert@redhat.com
Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize
Date: Wed, 19 Nov 2014 14:44:32 +0100 [thread overview]
Message-ID: <546C9EC0.5000105@redhat.com> (raw)
In-Reply-To: <20141119132851.GA27435@redhat.com>
On 19/11/2014 14:28, Michael S. Tsirkin wrote:
> >
> > qemu-2.0 -M pc-2.0 -> qemu-2.2 -M pc-2.0
> >
> > what BIOS should the second qemu use? the one that existed on qemu-2.0
> > time or the one that existed on qemu-2.2 time? You can allow for
> > bugfixes, but not for big changes like moving where the acpi tables were
> > generated, etc, etc.
>
> > I really think that we should use the BIOS from qemu-2.0 era. And my
> > understanding is that you defend that we should use the qemu-2.2 era
> > BIOS.
>
> Not only that. We already do. And we don't intend to change that for 2.2.
Am I missing a part of the discussion? When we migrate, the second QEMU
uses the BIOS from the first.
So:
qemu-2.0 -M pc-2.0 -> qemu-2.2 -M pc-2.0
uses 2.0 BIOS
qemu-2.2 -M pc-2.0 -> qemu-2.0 -M pc-2.0
uses 2.2 BIOS
Both should work, in general. BIOS is rarely the reason for
incompatibilities. However, breakage can happen, for example I know
that RHEL7 SeaBIOS does not work on RHEL6. RHEL6 SeaBIOS works on
RHEL7, but it needs a couple workarounds.
Shipping a separate BIOS for different machine types is unrealistic and
pointless. It would also be a good terrain for bug reports, unless you
also do things like "forbid creating -device megasas-gen2 on 2.1 because
it was introduced in 2.2". Remember that libvirt keeps the same machine
type for the whole life of a virtual machine definition, even if other
parts of the hardware (e.g. disks or NICs) change.
Paolo
next prev parent reply other threads:[~2014-11-19 13:44 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-17 20:08 [Qemu-devel] [PATCH 0/5] pc: make ROMs resizeable Michael S. Tsirkin
2014-11-17 20:08 ` [Qemu-devel] [PATCH 1/5] cpu: add cpu_physical_memory_clear_dirty_range_nocode Michael S. Tsirkin
2014-11-19 9:10 ` Juan Quintela
2014-11-17 20:08 ` [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize Michael S. Tsirkin
2014-11-17 20:15 ` Michael S. Tsirkin
2014-11-18 6:03 ` Paolo Bonzini
2014-11-18 7:49 ` Michael S. Tsirkin
2014-11-19 9:19 ` Juan Quintela
2014-11-19 9:33 ` Michael S. Tsirkin
2014-11-19 10:11 ` Juan Quintela
2014-11-19 10:21 ` Michael S. Tsirkin
2014-11-19 10:45 ` Juan Quintela
2014-11-19 13:28 ` Michael S. Tsirkin
2014-11-19 13:44 ` Paolo Bonzini [this message]
2014-11-19 13:57 ` Juan Quintela
2014-11-19 14:13 ` Dr. David Alan Gilbert
2014-11-19 14:22 ` Paolo Bonzini
2014-11-19 14:26 ` Dr. David Alan Gilbert
2014-11-19 14:28 ` Paolo Bonzini
2014-11-19 14:59 ` Dr. David Alan Gilbert
2014-11-19 15:38 ` Michael S. Tsirkin
2014-11-19 15:53 ` Dr. David Alan Gilbert
2014-11-19 14:22 ` Juan Quintela
2014-11-19 14:20 ` Paolo Bonzini
2014-11-19 16:39 ` Juan Quintela
2014-11-19 16:56 ` Paolo Bonzini
2014-11-19 16:27 ` Kevin O'Connor
2014-11-19 17:01 ` Paolo Bonzini
2014-11-20 8:12 ` Gerd Hoffmann
2014-11-20 10:00 ` Paolo Bonzini
2014-11-19 13:49 ` Juan Quintela
2014-11-19 13:51 ` Paolo Bonzini
2014-11-19 14:03 ` Juan Quintela
2014-11-19 14:11 ` Paolo Bonzini
2014-11-19 14:16 ` Dr. David Alan Gilbert
2014-11-19 14:28 ` Paolo Bonzini
2014-11-19 14:20 ` Juan Quintela
2014-11-19 15:43 ` Michael S. Tsirkin
2014-11-19 10:16 ` Markus Armbruster
2014-11-19 10:30 ` Michael S. Tsirkin
2014-11-19 10:50 ` Juan Quintela
2014-11-19 13:36 ` Michael S. Tsirkin
2014-11-19 13:51 ` Juan Quintela
2014-11-19 15:46 ` Michael S. Tsirkin
2014-11-19 16:45 ` Juan Quintela
2014-11-19 18:28 ` Paolo Bonzini
2014-11-20 13:35 ` Markus Armbruster
2014-11-20 14:04 ` Michael S. Tsirkin
2014-11-24 13:48 ` Paolo Bonzini
2014-11-19 13:58 ` Peter Maydell
2014-11-19 14:07 ` Juan Quintela
2014-11-19 14:10 ` Peter Maydell
2014-11-19 14:18 ` Juan Quintela
2014-11-19 16:08 ` Stefan Hajnoczi
2014-11-19 14:19 ` Paolo Bonzini
2014-11-19 14:21 ` Peter Maydell
2014-11-19 14:30 ` Paolo Bonzini
2014-11-19 15:16 ` Michael S. Tsirkin
2014-11-19 16:50 ` Juan Quintela
2014-11-19 15:12 ` Michael S. Tsirkin
2014-11-19 15:04 ` Michael S. Tsirkin
2014-11-17 20:08 ` [Qemu-devel] [PATCH 3/5] arch_init: support resizing on incoming migration Michael S. Tsirkin
2014-11-17 20:08 ` [Qemu-devel] [PATCH 4/5] memory: interface to allocate device ram Michael S. Tsirkin
2014-11-17 20:21 ` Peter Maydell
2014-11-18 11:54 ` Michael S. Tsirkin
2014-11-17 20:09 ` [Qemu-devel] [PATCH 5/5] acpi-build: make ROMs device RAM, make them resizeable Michael S. Tsirkin
2014-11-17 20:11 ` [Qemu-devel] [PATCH 0/5] pc: make ROMs resizeable Michael S. Tsirkin
2014-11-19 7:29 ` Amit Shah
2014-11-18 14:47 ` Markus Armbruster
2014-11-18 15:00 ` Michael S. Tsirkin
2014-11-19 8:16 ` Markus Armbruster
2014-11-19 13:41 ` Michael S. Tsirkin
2014-11-19 7:31 ` Amit Shah
2014-11-19 8:15 ` Michael S. Tsirkin
2014-11-19 8:22 ` Amit Shah
2014-11-19 13:33 ` Michael S. Tsirkin
2014-11-19 13:52 ` Juan Quintela
2014-11-19 16:01 ` Michael S. Tsirkin
2014-11-19 13:52 ` Peter Maydell
2014-11-19 14:41 ` Paolo Bonzini
2014-11-19 15:34 ` Michael S. Tsirkin
2014-11-19 16:40 ` Juan Quintela
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=546C9EC0.5000105@redhat.com \
--to=pbonzini@redhat.com \
--cc=dgilbert@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/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).