From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 2/2][RFC] KVM: Emulate MSI-X table and PBA in kernel Date: Sun, 02 Jan 2011 15:34:21 +0200 Message-ID: <4D207EDD.7060908@redhat.com> References: <1293007495-32325-1-git-send-email-sheng@linux.intel.com> <4D1C5124.2090409@redhat.com> <20101230103256.GB6441@redhat.com> <201012311105.28371.sheng@linux.intel.com> <4D2052C3.3020901@redhat.com> <20110102103928.GA32272@redhat.com> <4D205A6A.10900@redhat.com> <20110102115135.GA712@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sheng Yang , Marcelo Tosatti , kvm@vger.kernel.org, Alex Williamson To: "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:53077 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752644Ab1ABNfl (ORCPT ); Sun, 2 Jan 2011 08:35:41 -0500 In-Reply-To: <20110102115135.GA712@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 01/02/2011 01:51 PM, Michael S. Tsirkin wrote: > > > > > >I don't see how userspace can send interrupts with this > > >interface unfortunately. We also need irqfd support ... > > > > Sure we'll need additions to that interface. > > What I suggested is > 1. an ioctl to map phy address + size to table id > 2. a new gsi type with a table id + entry number. > > If we have that, assigned devices, virtio and vhost-net can work > mostly as is, with just the mask bits accelerated. > Ok. Please adopt this patch and send a series that does this. I'd like to see the whole thing working. > > What about vhost-net and vfio? I thought that they could emulate > > the mask bits: > > > > - KVM_MMIOFD(vmfd, mmio_range, fd1, fd2) associates an mmio range with an fd > > - writel(mmio_range) or readl(mmio_range) from the guest causes a > > command to be written to fd1 > > - for readl(), read from fd2 to see the result (works nicely for > > "pci read flushes posted writes") > > > > this allows interesting stuff to be implemented in separate > > processes, threads, or kernel modules. > > This could work. Some thought needs to be given to how we make sure that > an appropriate type of file is passed in. Maybe using a netlink > based connector for this a good idea? Why do we care what type of file is passed? We just write there, and whatever is on the other side needs to handle it. > OTOH if we have MSIX mask bit emulation in kvm anyway, using it makes > sense ... Yeah, except I'm not sure how the current proposal can interface with vfio. So we'll have two interfaces, until we vfio takes over completely. -- error compiling committee.c: too many arguments to function