From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 3/3] KVM: Add documents for MSI-X MMIO API Date: Tue, 25 Jan 2011 14:47:38 +0200 Message-ID: <4D3EC66A.2050207@redhat.com> References: <1294309185-21417-1-git-send-email-sheng@linux.intel.com> <201101172035.31664.sheng@linux.intel.com> <4D343A03.4000904@redhat.com> <201101191621.06840.sheng@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , "Michael S. Tsirkin" , kvm@vger.kernel.org To: Sheng Yang Return-path: Received: from mx1.redhat.com ([209.132.183.28]:9439 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752356Ab1AYMrm (ORCPT ); Tue, 25 Jan 2011 07:47:42 -0500 In-Reply-To: <201101191621.06840.sheng@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. -- error compiling committee.c: too many arguments to function