From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH 6/6] KVM: assigned dev: MSI-X mask support Date: Thu, 18 Nov 2010 11:37:37 +0200 Message-ID: <20101118093737.GI16832@redhat.com> References: <1289812532-3227-1-git-send-email-sheng@linux.intel.com> <1289812532-3227-7-git-send-email-sheng@linux.intel.com> <4CE3DF68.7090309@redhat.com> <201011180958.55773.sheng@linux.intel.com> <4CE4F1A2.9010604@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sheng Yang , Marcelo Tosatti , kvm@vger.kernel.org, Alex Williamson To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:39274 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756005Ab0KRJhs (ORCPT ); Thu, 18 Nov 2010 04:37:48 -0500 Content-Disposition: inline In-Reply-To: <4CE4F1A2.9010604@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Nov 18, 2010 at 11:28:02AM +0200, Avi Kivity wrote: > On 11/18/2010 03:58 AM, Sheng Yang wrote: > >On Wednesday 17 November 2010 21:58:00 Avi Kivity wrote: > >> On 11/15/2010 11:15 AM, Sheng Yang wrote: > >> > This patch enable per-vector mask for assigned devices using MSI-X. > >> > > >> > This patch provided two new APIs: one is for guest to specific device's > >> > MSI-X table address in MMIO, the other is for userspace to get > >> > information about mask bit. > >> > > >> > All the mask bit operation are kept in kernel, in order to accelerate. > >> > Userspace shouldn't access the device MMIO directly for the information, > >> > instead it should uses provided API to do so. > >> > > >> > Signed-off-by: Sheng Yang > >> > --- > >> > > >> > arch/x86/kvm/x86.c | 1 + > >> > include/linux/kvm.h | 32 +++++ > >> > include/linux/kvm_host.h | 5 + > >> > virt/kvm/assigned-dev.c | 318 > >> > +++++++++++++++++++++++++++++++++++++++++++++- 4 files changed, > >355 > >> > insertions(+), 1 deletions(-) > >> > >> Documentation? > > > >For we are keeping changing the API for last several versions, I'd like to settle > >down the API first. Would bring back the document after API was agreed. > > Maybe for APIs we should start with only the documentation patch, > agree on that, and move on to the implementation. > > >> What if it's a 64-bit write on a 32-bit host? > > > >In fact we haven't support QWORD(64bit) accessing now. The reason is we haven't > >seen any OS is using it in this way now, so I think we can leave it later. > > > >Also seems QEmu doesn't got the way to handle 64bit MMIO. > > There's a difference, if the API doesn't support it, we can't add it > later without changing both kernel and userspace. > > >> > >> That's not very good. We should do the entire thing in the kernel or in > >> userspace. We can have a new EXIT_REASON to let userspace know an msix > >> entry changed, and it should read it from the kernel. > > > >If you look it in this way: > >1. Mask bit owned by kernel. > >2. Routing owned by userspace. > >3. Read the routing in kernel is an speed up for normal operation - because kernel > >can read from them. > > > >So I think the logic here is clear to understand. > > Still, it's complicated and the state is split across multiple components. > > >But if we can modify the routing in kernel, it would be raise some sync issues due > >to both kernel and userspace own routing. So maybe the better solution is move the > >routing to kernel. > > That may work, but I don't think we can do this for vfio. Actually, if done right it might work for VFIO: we would need 2 eventfds to notify it that it has to mask/unmask entries. The interface would need to be careful to keep programming of the guest side emulation and the masking in the backend device completely separate. > -- > error compiling committee.c: too many arguments to function