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: > > > 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. > > What does KVM add to the masking? VFIO owns the interrupt handler, > which can decide if the interrupt is masked and set a pending bit in an > emulated PBA, or if unmasked it sends it to qemu via eventfd. For KVM, > I think we'd just augment that last bit to relay the interrupt to KVM > for direct guest injection. Right. MAsking in KVM is good for old style assignment and for vhost-net. > > > 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. > > Alex I just mean write() instead of an ioctl() -- 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
