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

[Paolo Bonzini <pbonzini@redhat.com>]

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