On Wednesday, December 17, 2008 3:42 am Fischer, Anna wrote: > I have two minor comments on this topic. > > 1) Currently the PF driver is called before the kernel initializes VFs and > their resources, and the current API does not allow the PF driver to > detect that easily if the allocation of the VFs and their resources > has succeeded or not. It would be quite useful if the PF driver gets > notified when the VFs have been created successfully as it might have > to do further device-specific work *after* IOV has been enabled. You're thinking of after the VFs are created the VF drivers (which may or may not be part of the PF driver) may not be able to communicate back to the PF driver that something else needs to be done (I remember seeing this in the earlier thread, should have included it in my post, sorry)? I'm not sure if it makes sense to add an interface like that to the core until we have feel for what the PF/VF drivers are going to want... Or do you have something specific in mind right now? If/until we have something in the core, it seems like this could be done on a per PF/VF driver basis for now. > 2) Configuration of SR-IOV: the current API allows to enable/disable > VFs from userspace via SYSFS. At the moment I am not quite clear what > exactly is supposed to control these capabilities. This could be > Linux tools or, on a virtualized system, hypervisor control tools. > One thing I am missing though is an in-kernel API for this which I > think might be useful. After all the PF driver controls the device, > and, for example, when a device error occurs (e.g. a hardware failure > which only the PF driver will be able to detect, not Linux), then the > PF driver might have to de-allocate all resources, shut down VFs and > reset the device, or something like that. In that case the PF driver > needs to have a way to notify the Linux SR-IOV code about this and > initiate cleaning up of VFs and their resources. At the moment, this > would have to go through userspace, I believe, and I think that is not > an optimal solution. Yu, do you have an opinion on how this would be > realized? That's a good point, Yu? -- Jesse Barnes, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
