| From: Sheng Yang <sheng@xxxxxxxxxxxxxxx> | 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
