From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG4hh-00070h-Ew for qemu-devel@nongnu.org; Thu, 14 Mar 2013 05:44:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UG4hc-0000C4-Fz for qemu-devel@nongnu.org; Thu, 14 Mar 2013 05:44:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54078) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG4hc-0000Bz-8X for qemu-devel@nongnu.org; Thu, 14 Mar 2013 05:44:00 -0400 Message-ID: <51419BCF.8030003@redhat.com> Date: Thu, 14 Mar 2013 10:43:43 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <5d85837fd58683b7e13ac78d6d468af6e152a512.1363243596.git.hutao@cn.fujitsu.com> <514194E4.3040208@redhat.com> <20130314091919.GD11223@redhat.com> In-Reply-To: <20130314091919.GD11223@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Gleb Natapov Cc: Peter Maydell , "Michael S. Tsirkin" , Hu Tao , qemu-devel , Markus Armbruster , Blue Swirl , Orit Wasserman , Juan Quintela , Alexander Graf , Christian Borntraeger , Jan Kiszka , Andrew Jones , Alex Williamson , Sasha Levin , Stefan Hajnoczi , Luiz Capitulino , KAMEZAWA Hiroyuki , Kevin Wolf , Anthony Liguori , Marcelo Tosatti 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 support is provided just for convenience of the OSPM. In this case, "-device pvevent" should just add handlers for the port. The ACPI support is similar to what we do for other on-board ISA devices, for example serial ports (the serial ports use PIIX PCI configuration instead of fw-cfg, but that's a minor detail). It only needs to work for port 0x505, so the fw-cfg data can be a single yes/no value and only the _STA method needs patching. See piix4_pm_machine_ready in hw/acpi_piix4.c. * ACPI support is a first-class part of the device. Each instance of the device should be there in the ACPI tables. In this case the fw-cfg data needs to be a list of ports, and it is probably simpler to combine all the definitions in an SSDT that is dynamically-built (similar to what we do for PCI hotplug slots). Or even provide a separate SSDT for each instance of the device. I prefer the first, the second seems to be over-engineered. >> So these patches can go in already, with the sole change that the HID >> must be in the QEMU namespace rather than MSFT. >> > We should request one for QEMU. Yes. BTW, the QEMU patches can go in only in the first of the two cases above. Paolo