[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: KVM vs. PCI-E Function Level Reset (FLR) ...
From: |
Casey Leedom |
Subject: |
[Qemu-devel] Re: KVM vs. PCI-E Function Level Reset (FLR) ... |
Date: |
Fri, 16 Jul 2010 10:29:31 -0700 |
User-agent: |
KMail/1.13.2 (Linux/2.6.32-23-generic; KDE/4.4.2; x86_64; ; ) |
| From: Sheng Yang <address@hidden>
| 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