Re: [Qemu-devel] [PATCH v14 3/4] introduce pvevent device to deal with panicked event

[Paolo Bonzini]

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