On Sun, Sep 11, 2011 at 12:23:57PM +0300, Michael S. Tsirkin wrote: > On Fri, Sep 09, 2011 at 03:34:26PM -0300, Marcelo Tosatti wrote: > > > > something I noted when readin our acpi code: > > > > we currently pass eject request for function 0 only: > > > > Name (_ADR, nr##0000) > > > > We either need a device per function there (acpi 1.0), > > > > send eject request for them all, or use ffff > > > > as function number (newer acpi, not sure which version). > > > > Need to see which guests (windows,linux) can handle which form. > > > > > > I'd guess we need to change that to ffff. > > > > No need, only make sure function 0 is there and all other functions > > should be removed automatically by the guest on eject notification. > > Hmm, the ACPI spec explicitly says: > > High word = Device #, Low word = Function #. > (e.g., device 3, function 2 is 0x00030002). To refer > to all the functions on a device #, use a function > number of FFFF).
Right, but this is the _ADR of the device instance in ACPI. The communication between QEMU and the ACPI DSL code is all based in slots. > > ACPI PCI hotplug is based on slots, not on functions. It does not > > support addition/removal of individual functions. > > Interesting. Is this just based on general logic, > reading of the linux driver or the ACPI spec? Its based on Seabios ACPI DST implementation and its relationship with the QEMU implementation in acpi_piix4.c. > The ACPI spec itself seems pretty vague. All tables > list devices, where each device has an _ADR entry, > which is built up of PCI device # and function #. Yes, it is vague. Given the mandate from the PCI spec a device _must contain_ function 0, usage (including hotplug/unplug) of individual functions other than 0 as separate devices is a no-go.