From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60894) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG7N8-0003lH-7F for qemu-devel@nongnu.org; Thu, 14 Mar 2013 08:35:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UG7N6-00071p-NZ for qemu-devel@nongnu.org; Thu, 14 Mar 2013 08:35:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27242) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG7N6-00071f-Dx for qemu-devel@nongnu.org; Thu, 14 Mar 2013 08:35:00 -0400 Date: Thu, 14 Mar 2013 14:34:40 +0200 From: Gleb Natapov Message-ID: <20130314123440.GP11223@redhat.com> References: <5d85837fd58683b7e13ac78d6d468af6e152a512.1363243596.git.hutao@cn.fujitsu.com> <514194E4.3040208@redhat.com> <20130314091919.GD11223@redhat.com> <51419BCF.8030003@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51419BCF.8030003@redhat.com> 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: Paolo Bonzini 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 On Thu, Mar 14, 2013 at 10:43:43AM +0100, 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 > 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. > Again I think there is a big difference between well knows device and PV devices that we add at random location. And if we make the later configurable i.e it may or may not be present and location where it is present can be changed then we better not make a guest to do guesses. > * 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. > Second is over-engineering indeed. The device should be singleton and fail if second instance is created. Do we have such capability in qdev? -- Gleb.