From: Gleb Natapov <gleb@redhat.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
Date: Sun, 20 Dec 2009 18:15:32 +0200 [thread overview]
Message-ID: <20091220161531.GQ4490@redhat.com> (raw)
In-Reply-To: <f43fc5580912200808v6e9fce6fta1f252ff01ae3926@mail.gmail.com>
On Sun, Dec 20, 2009 at 04:08:32PM +0000, Blue Swirl wrote:
> On Sun, Dec 20, 2009 at 3:52 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Sun, Dec 20, 2009 at 09:39:38AM -0600, Anthony Liguori wrote:
> >> Gleb Natapov wrote:
> >> >>More importantly though, what's the use-case here?
> >> >>
> >> >Use-case for what? This just what need to be done for correct HW
> >> >emulation.
> >>
> >> Live migration is transparent to the guest. The fact that firmware
> >> can upgrade itself without the guest doing anything is not something
> >> that really has a real world equivalent.
> >>
> >> Even if it did, whether that automatic upgrade happens after a
> >> reboot vs. a hard power cycle is irrelevant. The guest has no
> >> knowledge of the fact that the automatic firmware upgrade happened
> >> so if it gets delayed indefinitely, it doesn't matter.
> >>
> >> It's not a matter of correctness IMHO.
> >>
> > Ah now I see what you mean. New FW has to be used after reboot because old
> > one may not be able to init HW any longer. Suppose some bug in cirrus
> > emulation has being fixed and old vga bios should be accommodated to
> > those changes, if old vga bios will run after reset video output may not
> > work. Thinking about it we'll have the same problem if migration happens
> > during vga bios loading, but this is MUCH less likely to happen.
> >
> >> I can understand an argument for predictability wrt wanted to be
> >> able to guarantee that after the first reboot during a live
> >> migration, you'll get the new firmware. I'm not sure that's less
> >> predictable then hard shutdown/start-up and I'm not sure I can
> >> really make an argument for one way vs. the other.
> >>
> > system_reset _is_ hard shutdown/start-up. If it is not it is a bug, we
> > just arguing if the same applies for the case that migration was done
> > between boot and reset.
>
> Some devices are careful enough to implement warm reset using a flag,
> see for example hw/sun4u.c. If you want more precision, you could
> introduce for example system_off_on with the memory clearing behavior
> you want.
I am not familiar with other architectures. All I am saying applies to
IBM PC only. Of course it is possible to design a system that impossible
to reset completely from software or by pushing reset button. (To design
general purpose computer like that one should be braindead though). On
IBM PC there are ways to reset different parts of the system and there
are ways to completely reset the system. We support only the later and
ACPI spec mandates this kind of reset if reset is done via ACPI.
--
Gleb.
next prev parent reply other threads:[~2009-12-20 16:15 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-18 11:01 [Qemu-devel] [PATCH 0/8] option rom loading overhaul Gerd Hoffmann
2009-12-18 11:01 ` [Qemu-devel] [PATCH 1/8] Support PCI based option rom loading Gerd Hoffmann
2009-12-19 10:57 ` Blue Swirl
2009-12-20 15:34 ` Anthony Liguori
2009-12-20 17:02 ` Blue Swirl
2009-12-20 17:18 ` Alexander Graf
2009-12-20 17:55 ` Anthony Liguori
2009-12-20 18:01 ` Alexander Graf
2009-12-20 18:24 ` Andreas Färber
2009-12-20 18:53 ` Blue Swirl
2009-12-20 21:24 ` Benjamin Herrenschmidt
2009-12-20 21:23 ` Benjamin Herrenschmidt
2009-12-18 11:01 ` [Qemu-devel] [PATCH 2/8] pci romfiles: add property, add default to PCIDeviceInfo Gerd Hoffmann
2010-01-11 21:18 ` [Qemu-devel] [RFC] New naming rules for GPXE romfiles Stefan Weil
2010-01-11 21:34 ` Anthony Liguori
2010-01-12 10:23 ` Kevin Wolf
2009-12-18 11:01 ` [Qemu-devel] [PATCH 3/8] fw_cfg: make calls typesafe Gerd Hoffmann
2009-12-18 11:01 ` [Qemu-devel] [PATCH 4/8] fw_cfg: add API for file transfer Gerd Hoffmann
2009-12-19 12:06 ` Blue Swirl
2009-12-20 8:42 ` [Qemu-devel] Re: [SeaBIOS] " Gleb Natapov
2009-12-18 11:01 ` [Qemu-devel] [PATCH 5/8] roms: use new fw_cfg file xfer support Gerd Hoffmann
2009-12-20 8:45 ` [Qemu-devel] Re: [SeaBIOS] " Gleb Natapov
2009-12-18 11:01 ` [Qemu-devel] [PATCH 6/8] roms: remove option rom packing logic Gerd Hoffmann
2009-12-18 11:01 ` [Qemu-devel] [PATCH 7/8] updated seabios binary for testing convinience Gerd Hoffmann
2009-12-18 11:01 ` [Qemu-devel] [PATCH 8/8] debug: enable bios messages Gerd Hoffmann
2009-12-18 14:35 ` [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul Anthony Liguori
2009-12-18 16:34 ` Gerd Hoffmann
2009-12-18 16:42 ` Anthony Liguori
2009-12-18 17:03 ` Gerd Hoffmann
2009-12-18 17:12 ` Anthony Liguori
2009-12-19 1:48 ` Kevin O'Connor
2009-12-19 3:07 ` Anthony Liguori
2009-12-18 17:14 ` Anthony Liguori
2009-12-18 18:04 ` Gerd Hoffmann
2009-12-18 19:41 ` Sebastian Herbszt
2009-12-18 19:53 ` Anthony Liguori
2009-12-18 20:10 ` Sebastian Herbszt
2009-12-20 8:38 ` Gleb Natapov
2009-12-20 14:43 ` Anthony Liguori
2009-12-20 14:52 ` Gleb Natapov
2009-12-20 14:58 ` Anthony Liguori
2009-12-20 15:07 ` Gleb Natapov
2009-12-20 15:11 ` Anthony Liguori
2009-12-20 15:20 ` Avi Kivity
2009-12-20 15:31 ` Anthony Liguori
2009-12-20 15:35 ` Avi Kivity
2009-12-22 13:04 ` Paul Brook
2009-12-22 13:09 ` Avi Kivity
2009-12-22 15:11 ` Anthony Liguori
2009-12-22 15:54 ` Paul Brook
2009-12-22 16:16 ` Anthony Liguori
2009-12-20 15:23 ` Gleb Natapov
2009-12-20 15:28 ` Anthony Liguori
2009-12-20 15:33 ` Gleb Natapov
2009-12-20 15:39 ` Anthony Liguori
2009-12-20 15:52 ` Gleb Natapov
2009-12-20 16:08 ` Blue Swirl
2009-12-20 16:15 ` Gleb Natapov [this message]
2009-12-20 16:23 ` Blue Swirl
2009-12-20 17:48 ` Anthony Liguori
2009-12-21 1:59 ` Kevin O'Connor
2009-12-21 7:32 ` Gleb Natapov
2009-12-21 16:40 ` Anthony Liguori
2009-12-21 16:43 ` Gleb Natapov
2009-12-21 17:26 ` Anthony Liguori
2009-12-21 17:43 ` Gleb Natapov
2009-12-21 18:24 ` [Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul Sebastian Herbszt
2009-12-21 18:36 ` Gleb Natapov
2009-12-21 19:28 ` Sebastian Herbszt
2009-12-21 19:57 ` Gleb Natapov
2009-12-21 19:17 ` [Qemu-devel] " Anthony Liguori
2009-12-21 19:39 ` Sebastian Herbszt
2009-12-21 19:53 ` Gleb Natapov
2009-12-21 20:16 ` Sebastian Herbszt
2009-12-22 7:58 ` Gleb Natapov
2009-12-22 14:57 ` Anthony Liguori
2009-12-21 19:48 ` Gleb Natapov
2009-12-21 19:13 ` [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul Anthony Liguori
2009-12-21 19:43 ` Gleb Natapov
2009-12-21 23:54 ` Anthony Liguori
2009-12-22 20:50 ` [Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul Sebastian Herbszt
2009-12-21 7:40 ` [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul Gleb Natapov
2009-12-21 17:27 ` Michael S. Tsirkin
2010-01-12 4:48 ` Jamie Lokier
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=20091220161531.GQ4490@redhat.com \
--to=gleb@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=kraxel@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).