From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38532) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Fhb-0003M2-Gy for qemu-devel@nongnu.org; Wed, 17 Jun 2015 11:56:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5FhX-0002sl-6i for qemu-devel@nongnu.org; Wed, 17 Jun 2015 11:56:35 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:34853) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5FhX-0002se-1G for qemu-devel@nongnu.org; Wed, 17 Jun 2015 11:56:31 -0400 Received: by wiga1 with SMTP id a1so144224319wig.0 for ; Wed, 17 Jun 2015 08:56:30 -0700 (PDT) References: <878uborigh.fsf@linaro.org> <558160F4.3010604@redhat.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <558160F4.3010604@redhat.com> Date: Wed, 17 Jun 2015 16:57:01 +0100 Message-ID: <87lhfi72gi.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] RFC Multi-threaded TCG design document List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: mttcg@greensocs.com, peter.maydell@linaro.org, mark.burton@greensocs.com, qemu-devel@nongnu.org, agraf@suse.de, guillaume.delbergue@greensocs.com, fred.konrad@greensocs.com Paolo Bonzini writes: > On 12/06/2015 18:37, Alex Bennée wrote: >> Emulated hardware state >> ----------------------- >> >> Currently the hardware emulation has no protection against >> multiple-accesses. However guest systems accessing emulated hardware >> should be carrying out their own locking to prevent multiple CPUs >> confusing the hardware. Of course there is no guarantee the there >> couldn't be a broken guest that doesn't lock so you could get racing >> accesses to the hardware. >> >> There is the class of paravirtualized hardware (VIRTIO) that works in >> a purely mmio mode. Often setting flags directly in guest memory as a >> result of a guest triggered transaction. >> >> DESIGN REQUIREMENTS: >> >> - Access to IO Memory should be serialised by an IOMem mutex > > This should simply be the "big QEMU lock", which also protects the I/O > subsystem. > > With BQL-free TCG (a subset of multi-threaded TCG), the code in > qemu_mutex_lock_iothread that forces VCPUs to relinquish the mutex can > be dropped. > > Paolo > >> - The mutex should be recursive (e.g. allowing pid to relock >> itself) Paolo, But would there be a risk is we make the BQL recursive? I had to do this because the iomem accesses either side of a virt-io transaction would deadlock otherwise. -- Alex Bennée