Re: [PATCH 16/16 v6] PCI: document the new PCI boot parameters
--- On Wed, 12/10/08, Grant Grundler <[EMAIL PROTECTED]> wrote: > Date: Wednesday, December 10, 2008, 10:33 PM > On Thu, Dec 11, 2008 at 09:43:13AM +0800, Yu Zhao wrote: > ... > > I believe this is the only problem that preclude us > having the run-time > > resource rebalance. And I'm not sure how much > effort we can fix it. Any > > comments? > > Figure out the right sequence for driver resume so the > probe function > can call resume as well? > > Document the change and then start modifying drivers > one-by-one. > API changes are alot of work. > > grant > -- I've been lurking awaiting to see such a discussion. Alerting the PCI drivers that their resources have been changed from underneath them by extending the suspend/resume model, or perhaps (heresy?) adding a new callback entry point specifically for instructing PCI drivers to re-read their BARs, etc. would be a step in the right direction to enable this whole re-balancing work; well, granted root/paging devs bound to PCI devs could be tricky. It seems entirely natural (to me) that Microsoft would shudder at the amount of work and verification of all drivers to do this, but the Linux community's attitude seems to embrace sweeping changes ;-). -- LH -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git repository for SR-IOV development?
--- On Thu, 11/6/08, Greg KH <[EMAIL PROTECTED]> wrote: > On Thu, Nov 06, 2008 at 08:51:09AM -0800, H L wrote: > > > > Has anyone initiated or given consideration to the > creation of a git > > repository (say, on kernel.org) for SR-IOV > development? > > Why? It's only a few patches, right? Why would it > need a whole new git > tree? So as to minimize the time and effort patching a kernel, especially if the tree (and/or hash level) against which the patches were created fails to be specified on a mailing-list. Plus, there appears to be questions raised on how, precisely, the implementation should ultimately be modeled and especially given that, who knows at this point what number of patches will ultimately be submitted? I know I've built the "7-patch" one (painfully, by the way), and I'm aware there's another 15-patch set out there which I've not yet examined. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
--- On Thu, 11/6/08, Greg KH <[EMAIL PROTECTED]> wrote: > On Thu, Nov 06, 2008 at 08:41:53AM -0800, H L wrote: > > 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? I have not yet fully grocked Yu Zhao's model to answer this. That said, I would *hope* to find it on the "pci_dev" level. > Will all drivers that want to bind to a "VF" > device need to be > rewritten? Not necessarily, or perhaps minimally; depends on hardware/firmware and actions the driver wants to take. An example here might assist. Let's just say someone has created, oh, I don't know, maybe an SR-IOV NIC. Now, for 'general' I/O operations to pass network traffic back and forth there would ideally be no difference in the actions and therefore behavior of a PF driver and a VF driver. But, what do you do in the instance a VF wants to change link-speed? As that physical characteristic affects all VFs, how do you handle that? This is where the hardware/firmware implementation part comes to play. If a VF driver performs some actions to initiate the change in link speed, the logic in the adapter could be anything like: 1. Acknowledge the request as if it were really done, but effectively ignore it. The Independent Hardware Vendor (IHV) might dictate that if you want to change any "global" characteristics of an adapter, you may only do so via the PF driver. Granted, this, depending on the device class, may just not be acceptable. 2. Acknowledge the request and then trigger an interrupt to the PF driver to have it assist. The PF driver might then just set the new link-speed, or it could result in a PF driver communicating by some mechanism to all of the VF driver instances that this change of link-speed was requested. 3. Acknowledge the request and perform inner PF and VF communication of this event within the logic of the card (e.g. to "vote" on whether or not to perform this action) with interrupts and associated status delivered to all PF and VF drivers. The list goes on. > > > I have so far only seen Yu Zhao's > "7-patch" set. I've not yet looked > > at his subsequently tendered "15-patch" set > so I don't know what has > > changed.The hardware/firmware implementation for > any given SR-IOV > > compatible device, will determine the extent of > differences required > > between a PF driver and a VF driver. > > Yeah, that's what I'm worried/curious about. > Without seeing the code > for such a driver, how can we properly evaluate if this > infrastructure > is the correct one and the proper way to do all of this? As the example above demonstrates, that's a tough question to answer. Ideally, in my view, there would only be one driver written per SR-IOV device and it would contain the logic to "do the right things" based on whether its running as a PF or VF with that determination easily accomplished by testing the existence of the SR-IOV extended capability.Then, in an effort to minimize (if not eliminate) the complexities of driver-to-driver actions for fielding "global events", contain as much of the logic as is possible within the adapter. Minimizing the efforts required for the device driver writers in my opinion paves the way to greater adoption of this technology. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git repository for SR-IOV development?
Has anyone initiated or given consideration to the creation of a git repository (say, on kernel.org) for SR-IOV development? -- Lance Hartmann -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
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. I have so far only seen Yu Zhao's "7-patch" set. I've not yet looked at his subsequently tendered "15-patch" set so I don't know what has changed.The hardware/firmware implementation for any given SR-IOV compatible device, will determine the extent of differences required between a PF driver and a VF driver. -- Lance Hartmann --- On Thu, 11/6/08, Greg KH <[EMAIL PROTECTED]> wrote: > Date: Thursday, November 6, 2008, 9:43 AM > On Thu, Nov 06, 2008 at 07:40:12AM -0800, H L wrote: > > > > Greetings (from a new lurker to the list), > > Welcome! > > > To your question Greg, "yes" and "sort > of" ;-). I have started taking > > a look at these patches with a strong interest in > understanding how > > they work. I've built a kernel with them and > tried out a few things > > with real SR-IOV hardware. > > Did you have to modify individual drivers to take advantage > of this > code? It looks like the core code will run on this type of > hardware, > but there seems to be no real advantage until a driver is > modified to > use it, right? > > Or am I missing some great advantage to having this code > without > modified drivers? > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
Greetings (from a new lurker to the list), To your question Greg, "yes" and "sort of" ;-). I have started taking a look at these patches with a strong interest in understanding how they work. I've built a kernel with them and tried out a few things with real SR-IOV hardware. -- Lance Hartmann --- On Wed, 11/5/08, Greg KH <[EMAIL PROTECTED]> wrote: > > Is there any actual users of this API around yet? How was > it tested as > there is no hardware to test on? Which drivers are going > to have to be > rewritten to take advantage of this new interface? > > thanks, > > greg k-h > ___ > Virtualization mailing list > [EMAIL PROTECTED] > https://lists.linux-foundation.org/mailman/listinfo/virtualization -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
