Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support

* Greg KH (greg@kroah.com) wrote:

On Thu, Nov 06, 2008 at 10:47:41AM -0700, Matthew Wilcox wrote:

quoted

On Thu, Nov 06, 2008 at 08:49:19AM -0800, Greg KH wrote:

quoted

On Thu, Nov 06, 2008 at 08:41:53AM -0800, H L wrote:

quoted

I have not modified any existing drivers, but instead I threw together
a bare-bones module enabling me to make a call to pci_iov_register()
and then poke at an SR-IOV adapter's /sys entries for which no driver
was loaded.

It appears from my perusal thus far that drivers using these new
SR-IOV patches will require modification; i.e. the driver associated
with the Physical Function (PF) will be required to make the
pci_iov_register() call along with the requisite notify() function.
Essentially this suggests to me a model for the PF driver to perform
any "global actions" or setup on behalf of VFs before enabling them
after which VF drivers could be associated.

Where would the VF drivers have to be associated?  On the "pci_dev"
level or on a higher one?

Will all drivers that want to bind to a "VF" device need to be
rewritten?

The current model being implemented by my colleagues has separate
drivers for the PF (aka native) and VF devices.  I don't personally
believe this is the correct path, but I'm reserving judgement until I
see some code.

Hm, I would like to see that code before we can properly evaluate this
interface.  Especially as they are all tightly tied together.

quoted

I don't think we really know what the One True Usage model is for VF
devices.  Chris Wright has some ideas, I have some ideas and Yu Zhao has
some ideas.  I bet there's other people who have other ideas too.

I'd love to hear those ideas.

First there's the question of how to represent the VF on the host.
Ideally (IMO) this would show up as a normal interface so that normal tools
can configure the interface.  This is not exactly how the first round of
patches were designed.

Second there's the question of reserving the BDF on the host such that
we don't have two drivers (one in the host and one in a guest) trying to
drive the same device (an issue that shows up for device assignment as
well as VF assignment).

Third there's the question of whether the VF can be used in the host at
all.

Fourth there's the question of whether the VF and PF drivers are the
same or separate.

The typical usecase is assigning the VF to the guest directly, so
there's only enough functionality in the host side to allocate a VF,
configure it, and assign it (and propagate AER).  This is with separate
PF and VF driver.

As Anthony mentioned, we are interested in allowing the host to use the
VF.  This could be useful for containers as well as dedicating a VF (a
set of device resources) to a guest w/out passing it through.

thanks,
-chris