Re: [RFC PATCH] support multifunction PCI device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 13, 2011 at 10:14:20AM +0200, Paolo Bonzini wrote:
> 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. [....]"

So if I'm understanding correctly, the only difference we'll see with
assigning devices to functions, instead of slots, is that hotplug of
individual devices is not possible. From a guest (driver) POV everything
else is 100% functionally unchanged.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]