On Wed, 2010-10-20 at 17:17 +0200, Avi Kivity wrote: > On 10/20/2010 03:43 PM, Michael S. Tsirkin wrote: > > > >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. > > > > > > > > > > But if we emulate the entire msix bar in vfio, that's not needed, right? > > > > Yes, I think it is. How does kvm know which interrupt to inject? > > Either vfio needs to pass that info to qemu and qemu would pass it > > to kvm, or vfio would have some way to pass that info to kvm > > directly. > > Wait. We can't emulate the BAR in vfio, we have to emulate it in kvm > where we emulate the write instruction. We then need to tell vfio, > perhaps via userspace, that masking state has changed. > > Seems very intrusive. We wouldn't direct map the vector table or pending bits, so we could trap and emulate in qemu, which could then call into reads/writes in vfio. Alex > We can perhaps use the new semaphore capability in eventfd to pass > mask/unmask information from kvm to userspace. We'd usually hook it to > the corresponding vfio facility. > > > > How far away is vfio? If it's merged soon, we might avoid making > > > changes to the old assigned device infrastructure and instead update > > > vfio. > > > > Hard to be sure, hopefully 2.6.38 material. > > My question was how to implement this with vfio. But your list is > interesting as well. > > -- 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
