From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH 3/3] KVM: Add documents for MSI-X MMIO API Date: Tue, 1 Feb 2011 12:26:25 +0800 Message-ID: <20110201042625.GB9593@syang10-desktop> References: <1294309185-21417-1-git-send-email-sheng@linux.intel.com> <201101191621.06840.sheng@linux.intel.com> <4D3EC66A.2050207@redhat.com> <201101261705.56266.sheng@linux.intel.com> <4D46B80B.4080700@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Marcelo Tosatti , "Michael S. Tsirkin" , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mga02.intel.com ([134.134.136.20]:3755 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753353Ab1BAEZh (ORCPT ); Mon, 31 Jan 2011 23:25:37 -0500 Content-Disposition: inline In-Reply-To: <4D46B80B.4080700@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Jan 31, 2011 at 03:24:27PM +0200, Avi Kivity wrote: > On 01/26/2011 11:05 AM, Sheng Yang wrote: > >On Tuesday 25 January 2011 20:47:38 Avi Kivity wrote: > >> On 01/19/2011 10:21 AM, Sheng Yang wrote: > >> > > > We already got an guest MMIO address for that in the exit > >> > > > information. I've created a chain of handler in qemu to handle it. > >> > > > >> > > But we already decoded the table and entry... > >> > > >> > But the handler is still wrapped by vcpu_mmio_write(), as a part of MMIO. > >> > So it's not quite handy to get the table and entry out. > >> > >> The kernel handler can create a new kvm_run exit description. > >> > >> > Also the updater in the userspace > >> > > >> > can share the most logic with ordinary userspace MMIO handler, which take > >> > address as parameter. So I think we don't need to pass the decoded > >> > table_id and entry to userspace. > >> > >> It's mixing layers, which always leads to trouble. For one, the user > >> handler shouldn't do anything with the write since the kernel already > >> wrote it into the table. For another, if two vcpus write to the same > >> entry simultaneously, you could see different ordering in the kernel and > >> userspace, and get inconsistent results. > > > >The shared logic is not about writing, but about interpret what's written. Old > >MMIO handler would write the data, then interpret it; and our new MMIO would only > >share the logic of interpretation. I think that's fair enough? > > It dosn't make sense for an API point of view. You registered a > table of entries, you expect an exit on that table to point to the > table and entry that got changed. OK, I would update this when I come back to work(about two weeks later...). -- regards Yang, Sheng > > -- > error compiling committee.c: too many arguments to function >