From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40372) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuKuH-0003gJ-Vt for qemu-devel@nongnu.org; Fri, 28 Nov 2014 07:44:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XuKu8-0006Y2-UG for qemu-devel@nongnu.org; Fri, 28 Nov 2014 07:44:17 -0500 Received: from mail-wg0-x22c.google.com ([2a00:1450:400c:c00::22c]:44124) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuKu8-0006Xu-N8 for qemu-devel@nongnu.org; Fri, 28 Nov 2014 07:44:08 -0500 Received: by mail-wg0-f44.google.com with SMTP id b13so8845851wgh.31 for ; Fri, 28 Nov 2014 04:44:08 -0800 (PST) Date: Fri, 28 Nov 2014 12:44:05 +0000 From: Stefan Hajnoczi Message-ID: <20141128124405.GJ13631@stefanha-thinkpad.redhat.com> References: <1417091366-4469-1-git-send-email-stefanha@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cN519qCC4CN1mUcX" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [RFC 0/6] memory: make dirty_memory[] accesses atomic List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Paolo Bonzini , Richard Henderson , QEMU Developers , Stefan Hajnoczi , Juan Quintela --cN519qCC4CN1mUcX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 27, 2014 at 01:21:54PM +0000, Peter Maydell wrote: > On 27 November 2014 at 12:29, Stefan Hajnoczi wrote: > > 1. Convert all cpu_physical_memory_*_dirty() callers to use the API ato= mically. > > There are TCG callers who things along the lines of: > > > > if (!cpu_physical_memory_get_dirty(addr)) { > > cpu_physical_memory_set_dirty(addr); /* not atomic! */ > > } >=20 > Which bit of code is this? Note that for the TCG DIRTY_MEMORY_CODE > flag you have bigger problems than just whether the bitmap updates > are atomic, because the sequence is: > write to memory > if (!dirty) { > flush generated code tbs; > set dirty; > } >=20 > and what you care about is that the existence of cached translations > for this area of memory should be in sync with the state of the dirty > bit, so the whole operation of "flush affected translations and set > the dirty bit" needs to be thread-safe, I think. This is an example of what I mean. I'm not going to work on making TCG thread-safe in this series, and there is no dangerous race condition in this code if we leave it as is. But I'm not 100% sure of all cases, so I'll audit them again. Stefan --cN519qCC4CN1mUcX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUeG4VAAoJEJykq7OBq3PIXmEH/iUlFdXecagatgUY8NunTyur QFzqc2FysBuMl5k69q0EYuCBIEBmXvTehNB75vjvxwRaEgSYu3yx7bBx5WEzQd1P l3zNtGl+fNQA8r87pNTWzszxjOBixDt7IgXSwTnLI95RRk1Ke1o0e5IINhrO4xNt Q7dBKzpsTH024IA3jwsLtCuwtwdOXHBc3cVMIlqSMFum7nLIhl+40llPix6lmSHi cIvxtjxkYgjSG8EKB3TBf+SIWI6y5WdSnCG7aXPXxLnqlhpbrXRYOOqX06WdQeND KRg8knFFyDrSo04eAB4xbj+WWkCtevfmwCjQnEv5ScCMN3fndA49yiLONnNH9mY= =OiIO -----END PGP SIGNATURE----- --cN519qCC4CN1mUcX--