From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [PATCH 0/8][v2] MSI-X mask emulation support for assigned device Date: Wed, 20 Oct 2010 09:38:54 -0600 Message-ID: <1287589134.3007.45.camel@x201> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: "Michael S. Tsirkin" , Sheng Yang , Marcelo Tosatti , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:30125 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753767Ab0JTPi4 (ORCPT ); Wed, 20 Oct 2010 11:38:56 -0400 In-Reply-To: <4CBF0985.408@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, 2010-10-20 at 17:23 +0200, Avi Kivity wrote: > On 10/20/2010 04:47 PM, Alex Williamson wrote: > > > > > > 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. > > Me, too. Perhaps even more than you. > > > 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. MSIs are currently still bouncing from VFIO to QEMU to the guest, which seems inefficient. > > 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. Alex