Re: KVM vs. PCI-E Function Level Reset (FLR) ...

[Casey Leedom <leedom@chelsio.com>]

| From: Sheng Yang <sheng@linux.intel.com>
| Date: Thursday, July 15, 2010 05:56 pm
| 
| Yeah, the detection of reset is not that straightforward... Maybe we need
| an ioctl for reset event in qemu-kvm kvm_reset_vcpu().
| 
| We don't need assign/deassign device when reboot/reset, we only need to
| notify KVM that the reset is happening, then KVM know what's to do.

  I'm not familiar enough with the KVM/QEmu to know where how to make these 
changes easily.  I'd be happy to test such changes or even take a whack at 
making the changes if someone could point me at the relevant repositories/files.  
Alternatively, I could file a bug if KVM has its own bug database ...

| >   [Calling pci_reset_function() in our driver->probe() routine] was
| > mostly for device driver load/unload support.  I.e. being able
| > to issue a Function Level Reset to a PCI Device Function (regardless of
| > it being an SR-IOV Virtual Function or not) is a nice way to zap the
| > device back to a canonical state.
| 
| OK.
| 
| What I meant was, before your driver, there is no such requirement in the
| code. And no one can predict every usage of the code in the future, so
| it's quite reasonable you called the "deadlock" is there. And I can't say
| it's a "deadlock" because there is no code in the current tree make it
| "deadlock" IIUR.
| 
| So now you have this requirement, you can modify it to fit your need.
| That's quite straightforward...
| 
| >   Oh, and the driver has been posted to net-next.  I'm guessing that it
| > 
| > _should_ get merged into 2.6.35 ... or maybe 2.6.36 ... I'm really not
| > sure of how the merge schedule between net-next and the core kernel runs
| > ...
| 
| That's good. So you can modify the function to provide a lockless version.
| That make sense now. :)

  Okay, I'll ask Yu Zhao why he added the lock in pci_dev_reset() (changeset 
8c1c699fec9e9021bf6ff0285dee086bb27aec90) and if he feels that adding a non-
locking path would make sense -- this is an area of the kernel which I've only 
perused so I don't want to propose random changes ... :-)

Casey