On Wed, Oct 20, 2010 at 02:13:01PM -0600, Alex Williamson wrote: > On Wed, 2010-10-20 at 17:13 +0200, Michael S. Tsirkin wrote: > > On Wed, Oct 20, 2010 at 09:07:12AM -0600, Alex Williamson wrote: > > > On Wed, 2010-10-20 at 16:46 +0200, Michael S. Tsirkin wrote: > > > > On Wed, Oct 20, 2010 at 08:47:14AM -0600, Alex Williamson wrote: > > > > > 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? > > > > > > That would be possible too, only trouble is then we have QEMU > > > intercepting and interpreting the write as well as VFIO intercepting and > > > interpreting the write. > > > If VFIO is only masking off the mask bit, > > > that'd be pretty trivial though. > > > > I just mean write() instead of an ioctl() > > Hmm, looking back through my vfio driver, I actually have some code that > passes guest writes of the vector control field down to vfio. With > interrupt remapping support, vfio should pass these to the device > masking the interrupt at the source so we don't even need pending bit > emulation. No, that would conflict with kernel using mask bits. If we do this this direct access is very wrong, we must use kernel APIs for this. > Then we just need to make sure we only filter out the vector > table for read/write of the page it lives on so we can support the PBA > being on the same page. > > Alex > > -- 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
