On 05/11/2011 09:55 AM, Daniel P. Berrange wrote:
Hmm, that's kinda wierd& i'm suprised it works, particularly for LSI since I thought guest drivers would need support for multifunction too.
For well-behaved {kernel,device,driver}s multifunction should be totally transparent.
Example from http://msdn.microsoft.com/en-us/library/ff542756%28v=vs.85%29.aspx
"Since the system-supplied bus driver handles the multifunction semantics, the function drivers can be the same drivers that would be used if the functions were packaged as individual devices. Rather than enumerating one multifunction device, the PCI driver enumerates two child devices. The PnP manager treats each child device like a typical device. [...] The PCI driver arbitrates the resources for the child devices and manages any other multifunction aspects of the device.
And an old whitepaper also from MS at http://msdn.microsoft.com/en-us/windows/hardware/gg463194
"Each functional unit must be able to operate as a separate device, even if it happens to be serviced by an instance of the same driver(s) as another functional unit on the device. The operating system must be able to separately access each logical device that is individually enumerated, configure the device resources independently, and disable individual devices. [...]
Each separate functional unit on a multifunction device must not share addresses or registers with other functional units [...]
No start-order dependencies. The operating system must be able to configure and manage functions in any order. Therefore, no function on a multifunction device can depend on another device (that is, another function) to be started before the function can be started by the operating system. [...]
No hidden dependencies. Separate functional units must be able to operate concurrently, without interfering with each other or with other devices on the system. [...]
Vendors of multifunction devices should implement a separate configuration space with a unique device ID and independent resources for each function. [....]"
Paolo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list