From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMxCG-00066F-Sl for qemu-devel@nongnu.org; Tue, 02 Apr 2013 05:08:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UMxCF-00051N-OZ for qemu-devel@nongnu.org; Tue, 02 Apr 2013 05:08:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMxCF-00051C-HX for qemu-devel@nongnu.org; Tue, 02 Apr 2013 05:08:03 -0400 Date: Tue, 2 Apr 2013 12:07:46 +0300 From: Gleb Natapov Message-ID: <20130402090746.GZ3889@redhat.com> References: <1364545124-9781-1-git-send-email-hutao@cn.fujitsu.com> <20130329133310.GA9206@morn.localdomain> <51559BD8.5080502@redhat.com> <20130330132009.GA12564@morn.localdomain> <20130331143410.GC21968@redhat.com> <20130402002257.GB15818@morn.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130402002257.GB15818@morn.localdomain> Subject: Re: [Qemu-devel] [SeaBIOS] [PATCH v16] Add pvpanic device driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: Peter Maydell , "Michael S. Tsirkin" , Jan Kiszka , seabios@seabios.org, qemu-devel , Markus Armbruster , Blue Swirl , Orit Wasserman , Juan Quintela , Alexander Graf , Christian Borntraeger , Hu Tao , Andrew Jones , Alex Williamson , Sasha Levin , Stefan Hajnoczi , Luiz Capitulino , KAMEZAWA Hiroyuki , Anthony Liguori , Marcelo Tosatti , Paolo Bonzini 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.