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
