From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH 0/8][v2] MSI-X mask emulation support for assigned device Date: Wed, 20 Oct 2010 17:59:44 +0200 Message-ID: <20101020155944.GA23185@redhat.com> References: <1287563192-29685-1-git-send-email-sheng@linux.intel.com> <4CBEBB85.4000706@redhat.com> <20101020104447.GD12878@redhat.com> <1287586034.3007.12.camel@x201> <4CBF0985.408@redhat.com> <1287589134.3007.45.camel@x201> <4CBF10AC.30309@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alex Williamson , Sheng Yang , Marcelo Tosatti , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:47911 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751906Ab0JTQGQ (ORCPT ); Wed, 20 Oct 2010 12:06:16 -0400 Content-Disposition: inline In-Reply-To: <4CBF10AC.30309@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Oct 20, 2010 at 05:54:20PM +0200, Avi Kivity wrote: > On 10/20/2010 05:38 PM, Alex Williamson wrote: > >> > We'll need to optimize interrupt injection and eoi via KVM, > >> > but it should only be a performance optimization, not a functional > >> > requirement. > >> > >> For level-triggered interrupts only, yes? MSI EOI does not involve any > >> device or interrupt controller visible action? > > > >Right, the EOI is for legacy interrupts only. Perhaps we don't care > >enough about performance of those to route it through KVM so long as we > >can co-exist with the KVM APIC. > > We will need a way to get the EOI out to userspace, then. > > Perhaps that will give us motivation to split the ioapic from the > kernel (though I suppose fear of regressions will stop us). > > Anyway EOI notifiers are also useful for timekeeping. > > > MSIs are currently still bouncing from > >VFIO to QEMU to the guest, which seems inefficient. > > Why is that? Can't you use irqfd like 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. > >> > >> I would much like to see in-band information (which mask/unmask is for > >> older Linux) done via eventfds so userspace is not involved. > > > >Hmm, I'm not sure how to do that yet. > > One ugly way is to use two eventfds, one counting mask events, one > counting unmask events. The difference is the value if the masked > bit. > > Another option is to use > http://permalink.gmane.org/gmane.linux.kernel.commits.head/188038 > which allows kvm to maintain a counter using eventfd. The vfio > state machine then looks like: > > interrupt: > if counter == 0 mask interrupts, set pending bit, wait for counter > to become 1 > if counter == 1 forward it > counter becomes 1: unmask, forward interrupt if pending One issue is that this page has a ton of other info. KVM would have to keep all that in kernel... -- MST