RE: [PATCH 6/6 v3] PCI: document the change

Matthew Wilcox wrote:

On Tue, Oct 14, 2008 at 10:14:35AM +0800, Yu Zhao wrote:

quoted

quoted

BTW, the SR-IOV patch is not only for network, some
other devices such as IDE will use same code base as
well and we image it could have other parameter to set
such as starting LBA of a IDE VF.   

As Eddie said, we have two problems here:
1) User has to set device specific parameters of a VF
when he wants to use this VF with KVM (assign this
device to KVM guest). In this case, 
VF driver is not loaded in the host environment. So
operations which 
are implemented as driver callback (e.g.
set_mac_address()) are not supported.

I suspect what you want to do is create, then configure
the device in the host, then assign it to the guest.

That is not true. Rememver the created VFs will be destroyed no matter
for PF power event or error recovery conducted reset.
So what we want is:

Config, create, assign, and then deassign and destroy and then
recreate...

quoted

2) For security reason, some SR-IOV devices prohibit the
VF driver configuring the VF via its own register space.
Instead, the configurations must be done through the PF
which the VF is associated with. This means PF driver
has to receive parameters that are used to configure its
VFs. These parameters obviously can be passed by
traditional tools, if without modification for SR-IOV. 

I think that idea also covers this point.

Sorry can u explain a little bit more? The SR-IOV patch won't define
what kind of entries should be created or not, we leave network
subsystem to decide what to do. Same for disk subsstem etc.

Thx, eddie

On Tue, Oct 14, 2008 at 12:18:40PM +0800, Dong, Eddie wrote:

Matthew Wilcox wrote:

quoted

On Tue, Oct 14, 2008 at 10:14:35AM +0800, Yu Zhao wrote:

quoted

As Eddie said, we have two problems here:
1) User has to set device specific parameters of a VF
when he wants to use this VF with KVM (assign this
device to KVM guest). In this case, 
VF driver is not loaded in the host environment. So
operations which 
are implemented as driver callback (e.g.
set_mac_address()) are not supported.

I suspect what you want to do is create, then configure
the device in the host, then assign it to the guest.

That is not true. Rememver the created VFs will be destroyed no matter
for PF power event or error recovery conducted reset.
So what we want is:

Config, create, assign, and then deassign and destroy and then
recreate...

Yes, but my point is this all happens in the _host_, not in the _guest_.

Sorry can u explain a little bit more? The SR-IOV patch won't define
what kind of entries should be created or not, we leave network
subsystem to decide what to do. Same for disk subsstem etc.

No entries should be created.  This needs to be not SR-IOV specific.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."