From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/8][v2] MSI-X mask emulation support for assigned device Date: Wed, 20 Oct 2010 17:54:20 +0200 Message-ID: <4CBF10AC.30309@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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Michael S. Tsirkin" , Sheng Yang , Marcelo Tosatti , kvm@vger.kernel.org To: Alex Williamson Return-path: Received: from mx1.redhat.com ([209.132.183.28]:43273 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753180Ab0JTPy0 (ORCPT ); Wed, 20 Oct 2010 11:54:26 -0400 In-Reply-To: <1287589134.3007.45.camel@x201> Sender: kvm-owner@vger.kernel.org List-ID: 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 -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.