From: "Michael S. Tsirkin" <mst@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: Amit Shah <amit.shah@redhat.com>,
pbonzini@redhat.com, qemu-devel@nongnu.org, dgilbert@redhat.com
Subject: Re: [Qemu-devel] [PATCH 0/5] pc: make ROMs resizeable
Date: Wed, 19 Nov 2014 18:01:00 +0200 [thread overview]
Message-ID: <20141119160100.GD28563@redhat.com> (raw)
In-Reply-To: <87mw7nmh5g.fsf@elfo.elfo>
On Wed, Nov 19, 2014 at 02:52:43PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Wed, Nov 19, 2014 at 01:52:35PM +0530, Amit Shah wrote:
> >> On (Wed) 19 Nov 2014 [10:15:16], Michael S. Tsirkin wrote:
> >> > On Wed, Nov 19, 2014 at 01:01:14PM +0530, Amit Shah wrote:
> >> > > On (Mon) 17 Nov 2014 [22:08:46], Michael S. Tsirkin wrote:
> >>
> >> > > > Note: migration stream is unaffected by these patches.
> >> > > > This makes it possible to enable this functionality
> >> > > > unconditionally, for all machine types.
> >> > > >
> >> > > > In the future, this might be handy for other things,
> >> > > > such as changing kernels loaded on command line
> >> > > > across migrations.
> >> > >
> >> > > I think that'll be too risky; unless we do S4 before / after
> >> > > migration to ensure the kernel realises things might be changing
> >> > > beneath its feet.
> >> >
> >> > Well - guest never sees the resizing. It happens before we start the VM.
> >> > So I don't see the issue - could you clarify please?
> >>
> >> Before we start the VM? That's a really odd corner case (ie not worth
> >> bothering about?). I took this to mean that the guest was running
> >> while migration happened.
> >>
> >>
> >> Amit
> >
> > At the moment you get old ROM before reboot, new ROM after reboot.
> > Anyway, let's argue about this when someone proposes this.
> >
> > Guys, please drop responding to patch 0. There's no code there.
> > Please review the actual code.
>
> How can we answer: The code does what it tell it does, we are not happy
> with the whole idea?
>
> Later, Juan.
My point is you seem to be unhappy with the general idea that ROMs
are migrated, because you think all ROMs should be bitwise
identical to what we shipped years ago, depending on machine type.
But that ship sailed in 1.7 I think.
If you want to revert that decision, start a new thread,
no need to respond to this patch.
All this patch does is remove the artificial "same size"
limitation, which - assuming we migrate ROMs with guests -
just makes sense.
--
MST
next prev parent reply other threads:[~2014-11-19 16:01 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
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 [this message]
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=20141119160100.GD28563@redhat.com \
--to=mst@redhat.com \
--cc=amit.shah@redhat.com \
--cc=dgilbert@redhat.com \
--cc=pbonzini@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).