On Mon, Mar 05, 2012 at 08:26:23AM +0200, Michael S. Tsirkin wrote:
On Sun, Mar 04, 2012 at 08:30:00PM -0700, Alex Williamson wrote:
On Sun, 2012-03-04 at 20:53 +0200, Michael S. Tsirkin wrote:
On Fri, Feb 24, 2012 at 04:21:17PM -0700, Alex Williamson wrote:
When a Status method is provided on a slot, the OSPM evaluates _STA in response to the device check notify on the slot. This allows some degree of a handshake between the platform and the OSPM that the hotplug has been acknowledged.
In order to implement _STA, we need to know which slots have devices. A slot with device returns 0x0F, a slot without a device returns Zero. We get this information from Qemu using the 0xae08 I/O port register. This was previously the read-side of the register written to commit a device eject and always returned 0 on read. It now returns a bitmap of present slots, so we know that reading 0 means we have and old Qemu and dynamically modify our SSDT to rename the _STA methods. This is necessary to allow backwards compatibility.
...
The _STA method also writes the slot identifier to I/O port register 0xae00 as an acknowledgment of the hotplug request.
To summarize my previous messages, my notes are
- not clear that we want to implement _STA: yes we can tell hypervisor what did _STA report to OSPM but this won't be needed without _STA
- assuming we do, it seems clear that we want hypervisor to know what it is that we told OSPM about slot status
- the specific interface used for the above is fairly tricky so it needs documentation explaining how both sides cooperate
Why have this up, down things at all? What's wrong with how CPU hotplug works. It has only one HW register that returns a single bitmask that has 1 for available cpu and 0 for non available. AML can figure out what changed by having local copy of the old register's value to compare new value with.
-- Gleb.