From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH 6/6] KVM: assigned dev: MSI-X mask support Date: Thu, 18 Nov 2010 20:08:03 +0800 Message-ID: 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=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Sheng Yang , Marcelo Tosatti , "Michael S. Tsirkin" , kvm@vger.kernel.org, Alex Williamson To: Avi Kivity Return-path: Received: from mail-ww0-f44.google.com ([74.125.82.44]:62790 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754190Ab0KRMIG convert rfc822-to-8bit (ORCPT ); Thu, 18 Nov 2010 07:08:06 -0500 Received: by wwa36 with SMTP id 36so3252464wwa.1 for ; Thu, 18 Nov 2010 04:08:04 -0800 (PST) In-Reply-To: <4CE4F1A2.9010604@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Nov 18, 2010 at 5:28 PM, Avi Kivity wrote: > On 11/18/2010 03:58 AM, Sheng Yang wrote: >> >> On Wednesday 17 November 2010 21:58:00 Avi Kivity wrote: >> > =A0On 11/15/2010 11:15 AM, Sheng Yang wrote: >> > =A0> =A0This patch enable per-vector mask for assigned devices usi= ng MSI-X. >> > =A0> >> > =A0> =A0This patch provided two new APIs: one is for guest to spec= ific >> > device's >> > =A0> =A0MSI-X table address in MMIO, the other is for userspace to= get >> > =A0> =A0information about mask bit. >> > =A0> >> > =A0> =A0All the mask bit operation are kept in kernel, in order to >> > accelerate. >> > =A0> =A0Userspace shouldn't access the device MMIO directly for th= e >> > information, >> > =A0> =A0instead it should uses provided API to do so. >> > =A0> >> > =A0> =A0Signed-off-by: Sheng Yang >> > =A0> =A0--- >> > =A0> >> > =A0> =A0 =A0arch/x86/kvm/x86.c =A0 =A0 =A0 | =A0 =A01 + >> > =A0> =A0 =A0include/linux/kvm.h =A0 =A0 =A0| =A0 32 +++++ >> > =A0> =A0 =A0include/linux/kvm_host.h | =A0 =A05 + >> > =A0> =A0 =A0virt/kvm/assigned-dev.c =A0| =A0318 >> > =A0> =A0 =A0+++++++++++++++++++++++++++++++++++++++++++++- 4 files= changed, >> 355 >> > =A0> =A0 =A0insertions(+), 1 deletions(-) >> > >> > =A0Documentation? >> >> For we are keeping changing the API for last several versions, I'd l= ike to >> settle >> down the API first. Would bring back the document after API was agre= ed. > > Maybe for APIs we should start with only the documentation patch, agr= ee on > that, and move on to the implementation. Yes, would follow it next time. And I would bring back the documents in the next edition, for Michael and I have reached agreement on API. > >> > =A0What 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. Um... Which API you're talking about? I think userspace API(set msix mmio, and get mask bit status) is unrelated here? > >> > >> > =A0That's not very good. =A0We should do the entire thing in the k= ernel or >> > in >> > =A0userspace. =A0We can have a new EXIT_REASON to let userspace kn= ow an msix >> > =A0entry 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 compon= ents. So how about removing the reading acceleration part in the patch temporarily? Kernel owns mask bit and userspace owns others. That should be better. I can add the reading part later when we can find an elegant way to do so. > >> But if we can modify the routing in kernel, it would be raise some s= ync >> issues due >> to both kernel and userspace own routing. So maybe the better soluti= on is >> move the >> routing to kernel. > > That may work, but I don't think we can do this for vfio. --=20 regards, Yang, Sheng > > -- > error compiling committee.c: too many arguments to function > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at =A0http://vger.kernel.org/majordomo-info.html >