On 05/10/2015 14:50, Peter Maydell wrote: > If you want to try to support "firmware might also be reading > fw_cfg at the same time as the kernel" this is a (painful) > problem regardless of how the kernel figures out whether a > fw_cfg device is present. I had assumed that one of the design > assumptions of this series was that firmware would only > read the fw_cfg before booting the guest kernel and never touch > it afterwards. If it might touch it later then letting the > guest kernel also mess with fw_cfg seems like a really bad idea. The idea of tinkering with fw_cfg from the AML code (DSDT/SSDT) has been proposed many times, and always dropped. One of the reasons was that the OS could have a driver for fw_cfg. So I think that we can define the QEMU0002 id as owned by the OSPM, similar to the various standard ACPI ids that are usually found in the x86 world (e.g. PNP0B00 is a mc146818 RTC, PNP0303 is an 8042 keyboard controller, PNP0501 is a 16550 or similar UART, and so on). This basically sanctions _CRS as the way to pass information from the firmware to the OSPM, also similarly to those standard PNP ids. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
