From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG8YH-0005R6-9V for qemu-devel@nongnu.org; Thu, 14 Mar 2013 09:50:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UG8YC-0000no-Ao for qemu-devel@nongnu.org; Thu, 14 Mar 2013 09:50:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG8YC-0000nk-3E for qemu-devel@nongnu.org; Thu, 14 Mar 2013 09:50:32 -0400 Message-ID: <5141D57C.7000303@redhat.com> Date: Thu, 14 Mar 2013 14:49:48 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <5d85837fd58683b7e13ac78d6d468af6e152a512.1363243596.git.hutao@cn.fujitsu.com> <514194E4.3040208@redhat.com> <20130314091919.GD11223@redhat.com> <51419BCF.8030003@redhat.com> <20130314123440.GP11223@redhat.com> In-Reply-To: <20130314123440.GP11223@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 13:34, Gleb Natapov ha scritto: >> * 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. No guesses here on part of the guest, and no probing in the firmware two. The same number is hard-coded in QEMU and the DSDT, which go in pairs anyway, but _not_ in the guest kernel (also thanks to Hu's nice trick with the methods). I think it's a nice compromise. >> * 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? No, but why should it fail? Paolo