On Mon, Apr 01, 2013 at 08:22:57PM -0400, Kevin O'Connor wrote:
> On Sun, Mar 31, 2013 at 05:34:10PM +0300, Gleb Natapov wrote:
> > On Sat, Mar 30, 2013 at 09:20:09AM -0400, Kevin O'Connor wrote:
> > > On Fri, Mar 29, 2013 at 02:49:12PM +0100, Paolo Bonzini wrote:
> > > > Il 29/03/2013 14:33, Kevin O'Connor ha scritto:
> > > > > On Fri, Mar 29, 2013 at 04:18:44PM +0800, Hu Tao wrote:
> > > > >> pvpanic device is used to notify host(qemu) when guest panic happens.
> > > > >
> > > > > Thanks. However, we're planning a move of ACPI tables from SeaBIOS to
> > > > > QEMU. I think this should wait until after the move.
> > > >
> > > > The device should be in QEMU 1.5, and the SSDT probably will still be in
> > > > SeaBIOS by then (and might even be the last to move, since it's quite
> > > > complex and dynamic). I don't think it is fair to block this patch on
> > > > those grounds...
> > >
> > > What is the user visible impact of not having a panic device?
> > >
> > > My main concern is that the patch creates a new fw_cfg channel between
> > > qemu and seabios thats sole purpose is to alter the OS visible ACPI
> > > tables. These types of QEMU->SeaBIOS interfaces are fragile and are
> > > (in sum) quite complex.
> > >
> > The patch uses existing channel between qemu and seabios, one
> > romfile_loadint() is all it takes. We already have number of interfaces
> > to change OS visible ACPI tables, that's why we want to move ACPI table
> > creation to QEMU in the first place. It is unfortunate to start blocking
> > features now before we have an alternative. When ACPI table creation
> > will move into QEMU the code in this patch will be dropped along with
> > all the other code that serves similar purpose.
>
> Hi Gleb,
>
> If there is a general consensus that this feature is important then
> we'll go forward with adding it as is. To be clear though, my
> preference would be to go forward with moving ACPI tables into QEMU,
> and then add this stuff on top of that. If no one beats me to it,
> I'll send some initial patches myself.
>
If we can accomplish the move before next major QEMU release we do not
need this new fw_cfg file obviously. Paolo thinks this is not feasible,
I haven't followed this work to close to have informed opinion.
> If we do merge this feature as is, it will also require a SeaBIOS
> release (followed by a SeaBIOS pull into QEMU). There weren't any
> short-term plans for a new SeaBIOS release - if this feature demands
> that then we need to start planning it now.
>
It is always good to have latest BIOS with new QEMU release IMO, so lest
plan it regardless.
--
Gleb.
