On Thursday 21 October 2010 03:02:24 Marcelo Tosatti wrote: > On Wed, Oct 20, 2010 at 04:26:24PM +0800, Sheng Yang wrote: > > Here is v2. > > > > Changelog: > > > > v1->v2 > > > > The major change from v1 is I've added the in-kernel MSI-X mask emulation > > support, as well as adding shortcuts for reading MSI-X table. > > > > I've taken Michael's advice to use mask/unmask directly, but unsure about > > exporting irq_to_desc() for module... > > > > Also add flush_work() according to Marcelo's comments. > > > > Sheng Yang (8): > > PCI: MSI: Move MSI-X entry definition to pci_regs.h > > irq: Export irq_to_desc() to modules > > KVM: x86: Enable ENABLE_CAP capability for x86 > > KVM: Move struct kvm_io_device to kvm_host.h > > KVM: Add kvm_get_irq_routing_entry() func > > KVM: assigned dev: Preparation for mask support in userspace > > KVM: assigned dev: Introduce io_device for MSI-X MMIO accessing > > KVM: Emulation MSI-X mask bits for assigned devices > > Why does the current scheme, without msix per-vector mask support, is > functional at all? Luck? Well, I believe we are lucky... We just ignored the operation in the past. I had raised this issue when Michael begin to work on MSI-X support in QEmu long ago, but then I was busy on some other things. Until now when Eddie want to add MSI-X in-kernel acceleration, we back to it... And about the "flush_work()" you commented, I still think even for the native device, it's possible that the short time after OS write to the mask bit, the interrupt may be delivered, if the device already send the message out on the bus(I just guess, haven't observed)... The spec didn't say that the finish of writing mask bit behavior would also get all message on the bus delivered. So I think leave the work a little late would also be fine. -- regards Yang, Sheng -- 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
