From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42972) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG6LU-0001oM-DA for qemu-devel@nongnu.org; Thu, 14 Mar 2013 07:29:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UG6LP-0000ay-K8 for qemu-devel@nongnu.org; Thu, 14 Mar 2013 07:29:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11986) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG6LP-0000ar-CP for qemu-devel@nongnu.org; Thu, 14 Mar 2013 07:29:11 -0400 Date: Thu, 14 Mar 2013 13:28:58 +0200 From: Gleb Natapov Message-ID: <20130314112858.GM11223@redhat.com> References: <5d85837fd58683b7e13ac78d6d468af6e152a512.1363243596.git.hutao@cn.fujitsu.com> <514194E4.3040208@redhat.com> <20130314091919.GD11223@redhat.com> <51419BCF.8030003@redhat.com> <5141AE79.5040602@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v14 3/4] introduce pvevent device to deal with panicked event List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , Michael Tsirkin , Jan Kiszka , qemu-devel qemu-devel , Luiz Capitulino , Blue Swirl , Orit Wasserman , Juan Quintela , Markus Armbruster , Christian Borntraeger , Hu Tao , Andrew Jones , Stefano Stabellini , Alex Williamson , Sasha Levin , Stefan Hajnoczi , KAMEZAWA Hiroyuki , Kevin Wolf , Anthony Liguori , Marcelo Tosatti , Paolo Bonzini On Thu, Mar 14, 2013 at 12:23:01PM +0100, Alexander Graf wrote: > > On 14.03.2013, at 12:03, Paolo Bonzini wrote: > > > Il 14/03/2013 12:00, Alexander Graf ha scritto: > >> > >> On 14.03.2013, at 10:43, Paolo Bonzini wrote: > >> > >>> Il 14/03/2013 10:19, Gleb Natapov ha scritto: > >>>> On Thu, Mar 14, 2013 at 10:14:12AM +0100, Paolo Bonzini wrote: > >>>>> Il 14/03/2013 09:15, Hu Tao ha scritto: > >>>>>> pvevent device is used to send guest panic event from guest to qemu. > >>>>>> > >>>>>> When guest panic happens, pvevent device driver will write a event > >>>>>> number to IO port 0x505(which is the IO port occupied by pvevent device, > >>>>>> by default). On receiving the event, pvevent device will pause guest > >>>>>> cpu(s), and send a qmp event QEVENT_GUEST_PANICKED. > >>>>>> > >>>>>> TODO: make the IO port configurable > >>>>> > >>>>> The port is already configurable as far as the device is concerned; when > >>>>> you add the port to the PC boards you will have to wind up fw-cfg. > >>>> > >>>> Why not add fw-cfg when device is created (with -device for instance)? > >>> > >>> It depends on what we decide is the supported interface for the device: > >>> > >>> * it can be an ISA device; the interface is the I/O port and ACPI > >> > >> Is there any particular reason it's an ISA device with a PIO port, > >> rather than a platform / sysbus device with MMIO access? With the > >> latter, we could easily reuse the device on other platforms (ppc, arm) > >> and even the guest driver code for platforms that do ACPI (arm?). > > > > Where would you place the MMIO area on x86? > > Wherever the board thinks it makes sense. > On x86 it makes sense to put it in IO space :) > > But anyway you can easily > > define an MMIO variant, the guest driver code will be shared (the ACPI > > in the firmware no, of course). > > Yes, at which point we have 2 variants where we could have had 1. I don't know if it's worth caring about it, just wanted to bring it up. > We can have the same device and control via properties what address space to use for the device. > > > >> Also, don't the Xen guys already have a similar interface? Could we at least share the guest side implementation maybe? > > > > I think Xen uses xenstore for this, or a hypercall I don't remember. > > But not something that can be shared unfortunately. > > At least the guest kernel hook could be shared. In fact, how does that one work with this device? I've only seen an ACPI patch so far. Does ACPI already support panic hooks? > > No need for any special hook to use the device. There was a separate patch with guest platform driver that uses the device. IN fact it should work on XEN too. -- Gleb.