From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: Ensure the exit frequency to QEmu for coalesced MMIO Date: Wed, 20 Jan 2010 13:04:46 +0200 Message-ID: <4B56E34E.7010001@redhat.com> References: <1263976559-15480-1-git-send-email-sheng@linux.intel.com> <201001201734.54129.sheng@linux.intel.com> <4B56D144.5030501@redhat.com> <201001201757.02289.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 , kvm@vger.kernel.org To: Sheng Yang Return-path: Received: from mx1.redhat.com ([209.132.183.28]:35503 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751202Ab0ATLEu (ORCPT ); Wed, 20 Jan 2010 06:04:50 -0500 In-Reply-To: <201001201757.02289.sheng@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On 01/20/2010 11:57 AM, Sheng Yang wrote: > >>> No protection for ring->first and ring->last? Seems it can writing the >>> same element pointed by ring->first twice, then skip one element at >>> (ring->first + 1)... >>> >> ring->first is owned by userspace, while ring->last is owned by the >> kernel, so no protection is necessary except for the memory barrier. >> Can you elaborate on how it would fail? >> >> > This piece of code can only be executed on one thread/vcpu at same time? I > think different vcpus accessing/modifying ring->first at the same time would > cause problem. > Yes, it's protected by qemu_lock. > But for a separate iothread which handle all userspace accessing, it should be > fine. > coalesced mmio processing can happen as part of vcpu processing (due to an mmio exit) or by the iothread (forced by the display refresh timer for example), but still serialized by qemu_lock. -- error compiling committee.c: too many arguments to function