From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v2 1/2] KVM: MMIO: Lock coalesced device when checking for available entry Date: Mon, 18 Jul 2011 15:29:03 +0300 Message-ID: <4E24270F.6010809@redhat.com> References: <1310729869-1451-1-git-send-email-levinsasha928@gmail.com> <4E23EACD.1020407@redhat.com> <1310981389.8209.3.camel@lappy> <4E2401E6.8020200@redhat.com> <1310984151.8209.7.camel@lappy> <4E241C67.1080404@redhat.com> <1310990625.8209.12.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Ingo Molnar , Marcelo Tosatti , Pekka Enberg To: Sasha Levin Return-path: Received: from mx1.redhat.com ([209.132.183.28]:52265 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751625Ab1GRM3M (ORCPT ); Mon, 18 Jul 2011 08:29:12 -0400 In-Reply-To: <1310990625.8209.12.camel@lappy> Sender: kvm-owner@vger.kernel.org List-ID: On 07/18/2011 03:03 PM, Sasha Levin wrote: > On Mon, 2011-07-18 at 14:43 +0300, Avi Kivity wrote: > > On 07/18/2011 01:15 PM, Sasha Levin wrote: > > > On Mon, 2011-07-18 at 12:50 +0300, Avi Kivity wrote: > > > > On 07/18/2011 12:29 PM, Sasha Levin wrote: > > > > > > Hmm. This means we take the lock for every I/O, whether it hits > > > > > > coalesced mmio or not. > > > > > > > > > > > > We need to do the range check before taking the lock and the space check > > > > > > after taking the lock. > > > > > > > > > > > > > > > > I'll fix that. > > > > > > > > > > Shouldn't the range check be also locked somehow? Currently it is > > > > > possible that a coalesced region was removed while we are checking the > > > > > ranges, and we won't issue a mmio exit as the host expects > > > > > > > > It's "locked" using rcu. > > > > > > > > > > Where is that happening? > > > > > > All the coalesced zones are stored under the coalesced "device" in a > > > simple array. When adding and removing zones, kvm->slots_lock is taken - > > > I don't see anything which prevents a range check during zone removal > > > unless slots_lock prevents IO. > > > > Range check during slot removal is legal. While you are removing a > > slot, a concurrent write may hit or miss the slot; it doesn't matter. > > > > Userspace should flush the coalesced mmio buffer after removal to ensure > > there are no pending writes. > > > > But the write may hit a non-existent slot. > > Something like this: > > Thread 1 Thread 2 > ---------------------------------- > Check range | > Found slot | > | Remove slot > | Flush buffer > Get spinlock | > Write to buffer | > Cannot happen, due to rcu. The "remove slot" step waits until all rcu readers are gone. In other words: it's magic. -- error compiling committee.c: too many arguments to function