On Wed, Oct 20, 2010 at 08:47:14AM -0600, Alex Williamson wrote: > On Wed, 2010-10-20 at 12:44 +0200, Michael S. Tsirkin wrote: > > On Wed, Oct 20, 2010 at 11:51:01AM +0200, Avi Kivity wrote: > > > On 10/20/2010 10:26 AM, 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. > > > > > > > > > > Any performance numbers? What are the affected guests? just RHEL > > > 4, or any others? > > > > Likely any old linux. > > > > > Alex, Michael, how would you do this with vfio? > > > > With current VFIO we would catch mask writes in qemu and > > call a KVM ioctl. We would also need an ioctl to retrieve > > pending bits long term. > > Ugh, no. VFIO us currently independent of KVM. I'd like to keep it > that way. We'll need to optimize interrupt injection and eoi via KVM, > but it should only be a performance optimization, not a functional > requirement. So ideally masking would be optimizeable too. > It would probably make sense to request a mask/unmask ioctl in VFIO for > MSI-X, then perhaps the pending bits would only support read/write (no > mmap), so we could avoid an ioctl there. Why not mask/unmask with a write? > > I think that it is unfortunate that we need to do this in userspace > > while rest of configuration is done in kernel. > > I would be much happier with userspace simply forwarding > > everything to VFIO, so emulation does not have to > > be split. That would be a clean interface: just mmap > > MSIX BAR and forget about it. > > > > If instead of eventfd we had a file descriptor that can pass vector > > information from vfio to kvm and back, that would fix it, > > as we would not need to set us GSIs at all, > > and not need for userspace to handle MSIX specially. > > Sounds good except that I'd like to get away from forcing device > assignment interfaces into KVM. > > Alex How to split up the modules is an implementation detail though. -- MST -- 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
