From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [patch 2/4] KVM: move coalesced_mmio locking to its own device Date: Wed, 20 May 2009 18:22:43 +0300 Message-ID: <4A142043.1090504@redhat.com> References: <20090518165601.747763120@localhost.localdomain> <20090518170855.346048603@localhost.localdomain> <4A13F242.7090404@redhat.com> <20090520140956.GA3370@amt.cnet> <4A1413C3.4020606@redhat.com> <20090520151303.GA14582@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from mx2.redhat.com ([66.187.237.31]:36738 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755333AbZETPWo (ORCPT ); Wed, 20 May 2009 11:22:44 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n4KFMkuK015840 for ; Wed, 20 May 2009 11:22:46 -0400 In-Reply-To: <20090520151303.GA14582@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: Marcelo Tosatti wrote: >> Yes it's correct but we'll get an endless stream of patches to 'fix' it >> because it is so unorthodox. >> > > Does it have to guarantee any kind of ordering in case of parallel > writes by distincting vcpus? This is what it does now (so if a vcpu > arrives first, the second will wait until the first is finished > processing). > No. > I suppose that is the responsability of the guest (if it does MMIO > writes to a device in parallel it'll screwup in real HW too). > Yes. > Because in such case, you can drop the mutex and protect only the kvm > data. > One has to be before the other. The order doesn't matter, but both have to be there. -- error compiling committee.c: too many arguments to function