From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40412) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0VWI-0001zp-6v for qemu-devel@nongnu.org; Mon, 15 Dec 2014 08:17:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y0VWC-0000Vs-1u for qemu-devel@nongnu.org; Mon, 15 Dec 2014 08:17:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50202) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0VWB-0000Vm-QK for qemu-devel@nongnu.org; Mon, 15 Dec 2014 08:16:55 -0500 Message-ID: <548EDF3E.2070407@redhat.com> Date: Mon, 15 Dec 2014 14:16:46 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <5AD68BB8-35E0-4752-BD46-FA3CA9BC7F34@greensocs.com> In-Reply-To: <5AD68BB8-35E0-4752-BD46-FA3CA9BC7F34@greensocs.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] Atomic Instructions - comments please List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Burton , mttcg@greensocs.com Cc: Developers qemu-devel On 15/12/2014 13:56, Mark Burton wrote: > A third proposal is to mark pages as IO when a ld/st ex is performed to > them. Then to augment the memory API to indicate that a ld/st ex is in > hand, allowing the memory chain to decide if it should allow the write > or cause a fault. This would seem to be the closest approach to the real > H/W. However it means marking pages as IO (which could cause us issues > if there was code on that page?, or slow things down) - and it means > adding to the memory API. What are the intended semantics for reads/writes from the outside world? Should they cause the ll/sc pair to retry or not? If not, it should not need any change to the memory API; you can do it entirely within cputlb.c, roughly the same as the handling of TLB_NOTDIRTY. It also marks pages as I/O, but only internally within TCG. Paolo