From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:56925) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gzR08-00080m-PP for qemu-devel@nongnu.org; Thu, 28 Feb 2019 14:05:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gzR07-0000VP-Qp for qemu-devel@nongnu.org; Thu, 28 Feb 2019 14:05:48 -0500 References: <20190226113915.20150-1-david@redhat.com> <20190226113915.20150-15-david@redhat.com> <864f3ba7-3115-c6f8-e018-15425ca67a72@twiddle.net> From: David Hildenbrand Message-ID: Date: Thu, 28 Feb 2019 20:05:42 +0100 MIME-Version: 1.0 In-Reply-To: <864f3ba7-3115-c6f8-e018-15425ca67a72@twiddle.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v1 14/33] s390x/tcg: Implement VECTOR LOAD MULTIPLE List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , Richard Henderson , qemu-devel@nongnu.org Cc: qemu-s390x@nongnu.org, Cornelia Huck , Thomas Huth On 28.02.19 18:15, Richard Henderson wrote: > On 2/28/19 12:36 AM, David Hildenbrand wrote: >> On 27.02.19 17:02, Richard Henderson wrote: >>> On 2/26/19 3:38 AM, David Hildenbrand wrote: >>>> Also fairly easy to implement. One issue we have is that exceptions = will >>>> result in some vectors already being modified. At least handle it >>>> consistently per vector by using a temporary vector. Good enough for >>>> now, add a FIXME. >>>> >>>> Signed-off-by: David Hildenbrand >>>> --- >>>> target/s390x/insn-data.def | 2 ++ >>>> target/s390x/translate_vx.inc.c | 26 ++++++++++++++++++++++++++ >>>> 2 files changed, 28 insertions(+) >>> >>> I suppose the fixme is good enough. For the record, I think you coul= d do the >>> check with just two loads -- the first and last quadword. After that= , none of >>> the other loads can fault, and you can store everything else into the >>> destination vectors as you read them. >> >> Aren't such approaches prone to races if other VCPUs invalidate page >> tables/TLB entries? >=20 > No, because... >=20 >> (or am I messing up things and the MMU of this VCPU won't be touched >> while in this block and once we touched all applicable pages, it canno= t >> fail anymore?) >=20 > Correct. >=20 > If vcpu 1 does a global invalidate, the time at which vcpu 2 acknowledg= es that > invalidate is somewhat fluid. VCPU 2 will see an interrupt, exit at a = TB > boundary, and then acknowledge. >=20 > VCPU 1 has to wait for the ack before it knows the operation is complet= e. >=20 > Thus no race within any given instruction's execution. Okay, rings a bell, thanks! :) So for writing from helpers, I can use probe_write(). What about testing write access from TCG code? I could do a load, followed by a store of the loaded value. This should work in most cases (but eventually could be observed by somebody really wanting to observe it - which is highly unlikely). --=20 Thanks, David / dhildenb