From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35540) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5BzZ-0004rP-Pu for qemu-devel@nongnu.org; Wed, 17 Jun 2015 07:58:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5BzW-0006qf-Fu for qemu-devel@nongnu.org; Wed, 17 Jun 2015 07:58:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42824) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5BzW-0006qT-2s for qemu-devel@nongnu.org; Wed, 17 Jun 2015 07:58:50 -0400 Message-ID: <558160F4.3010604@redhat.com> Date: Wed, 17 Jun 2015 13:58:44 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <878uborigh.fsf@linaro.org> In-Reply-To: <878uborigh.fsf@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] RFC Multi-threaded TCG design document List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QWxleCBCZW5uw6ll?= , qemu-devel@nongnu.org, mttcg@greensocs.com Cc: peter.maydell@linaro.org, fred.konrad@greensocs.com, mark.burton@greensocs.com, agraf@suse.de, guillaume.delbergue@greensocs.com On 12/06/2015 18:37, Alex Benn=C3=A9e wrote: > Emulated hardware state > ----------------------- >=20 > 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. >=20 > 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. >=20 > DESIGN REQUIREMENTS: >=20 > - 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) >=20 > IO Subsystem > ------------ >=20 > The I/O subsystem is heavily used by KVM and has seen a lot of > improvements to offload I/O tasks to dedicated IOThreads. There should > be no additional locking required once we reach the Block Driver. >=20 > DESIGN REQUIREMENTS: >=20 > - The dataplane should continue to be protected by the iothread locks >=20 >=20 > References > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/pla= in/Documentation/memory-barriers.txt > [2] http://thread.gmane.org/gmane.comp.emulators.qemu/334561 > [3] http://thread.gmane.org/gmane.comp.emulators.qemu/335297 >=20 >=20 >=20