From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.4 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47847C2D0CE for ; Sun, 29 Dec 2019 15:21:12 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 012332071E for ; Sun, 29 Dec 2019 15:21:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fo5hGigP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 012332071E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:52790 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilaNT-0004zb-1I for qemu-devel@archiver.kernel.org; Sun, 29 Dec 2019 10:21:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38348) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilaMX-0004V8-Pd for qemu-devel@nongnu.org; Sun, 29 Dec 2019 10:20:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ilaMU-0007B5-6Q for qemu-devel@nongnu.org; Sun, 29 Dec 2019 10:20:13 -0500 Received: from mail-ot1-x341.google.com ([2607:f8b0:4864:20::341]:35119) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ilaMT-000764-QJ for qemu-devel@nongnu.org; Sun, 29 Dec 2019 10:20:10 -0500 Received: by mail-ot1-x341.google.com with SMTP id k16so38483829otb.2 for ; Sun, 29 Dec 2019 07:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SsvcxihDIrQNiNsy0fbrUbqVYY3Rx3Qt26NA1y7JJZc=; b=fo5hGigP/qCygW8+iNMYp40j1P7MUw3Zx90XgwxoFgzvtHVYyydFQgh6KUC/+0jt5M 567Aty/+i9hVheDyrtNjDvk38PkBzwLTiHttmzPeYJpGwW2vJ+sc6Pr0TQtfJIRJP4tF 0jmN9GrP3Ep5Lb6/1qFQRLacZ95hOsxE/AV3wXKfJ8xeYiBhloUSG+6cekCl4t5JZNOP 65jN8azbPNhJ3qneFHfFthid45WAow8Kk7E+vKXri9cVTI/U0yV5kxYVKbVMlVHc5BkT qYCsaeSobR3MKhx3qaMIBDmSriHPVVXCa3x9ksdW+aLQfDTs0CzxJX3xPfvpqbasNH8M uLsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SsvcxihDIrQNiNsy0fbrUbqVYY3Rx3Qt26NA1y7JJZc=; b=Swn/iCoMXicuXsIVZgAvQ1UN49qc5giPTssRGWOQe5PJtAEJ8MoZ1er5iBxX6N0Raq 3WN52/hrIjHFF6DQ/gU/jPWGgRk62GBJ8ZwHLf5Y9Ggrzvqswiz490hjH1Vk/hsXxXI6 2BVMVAM/HQmfMG/ROysc9XAN2rRwzcMS8aQhYnIrxi+7bHxZQ+2MgGoexIDSVRkytlcx JVsp7A95LZsHVc9bRRXITGs5p8mbTn1qZdjEAvWgrrHgf3U6TmBYhaxDxqj1IoG2BEzh jOrYJ3HNytUDYtYtdbe8o/KGRECPAAQuntZ71yMZDgPAlYW73lwQ3a8zRdFPXLJyijYz GzcQ== X-Gm-Message-State: APjAAAXM7LT86dSIxcSrlMBuch6zi8ZsIlmGjx996sG1uqkbBgiYmlSg v2fgpF6wjdTIBZ8ycPmJ7ZU+L2cMLtV2013qJLE= X-Google-Smtp-Source: APXvYqyaNZ4C6DIRXRaDa8ELI58QiNN4zorR0G6LZ1GW30lUrq/4exmwLdVqHdUvIOBesGIqdadxVPN8poPvD5Gy8rI= X-Received: by 2002:a05:6830:1042:: with SMTP id b2mr69209463otp.306.1577632808845; Sun, 29 Dec 2019 07:20:08 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a9d:d21:0:0:0:0:0 with HTTP; Sun, 29 Dec 2019 07:20:08 -0800 (PST) In-Reply-To: <20191228231124.18307-14-richard.henderson@linaro.org> References: <20191228231124.18307-1-richard.henderson@linaro.org> <20191228231124.18307-14-richard.henderson@linaro.org> From: Aleksandar Markovic Date: Sun, 29 Dec 2019 16:20:08 +0100 Message-ID: Subject: Re: [PATCH v3 13/29] cputlb: Provide cpu_(ld, st}*_mmuidx_ra for user-only To: Richard Henderson Content-Type: multipart/alternative; boundary="0000000000002844ff059ad943c8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::341 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?B?QWxleCBCZW5uw6ll?= , "qemu-devel@nongnu.org" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --0000000000002844ff059ad943c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sunday, December 29, 2019, Richard Henderson < richard.henderson@linaro.org> wrote: > This finishes the new interface began with the previous patch. > Document the interface and deprecate MMU_MODE_SUFFIX. > > Reviewed-by: Alex Benn=C3=A9e > Signed-off-by: Richard Henderson > --- > include/exec/cpu_ldst.h | 80 +++++++++++++- > docs/devel/loads-stores.rst | 211 ++++++++++++++++++++++++++---------- > 2 files changed, 230 insertions(+), 61 deletions(-) > > Reviewed-by: Aleksandar Markovic > diff --git a/include/exec/cpu_ldst.h b/include/exec/cpu_ldst.h > index ef59ed61e4..41b98ba801 100644 > --- a/include/exec/cpu_ldst.h > +++ b/include/exec/cpu_ldst.h > @@ -25,9 +25,13 @@ > * > * The syntax for the accessors is: > * > - * load: cpu_ld{sign}{size}_{mmusuffix}(env, ptr) > + * load: cpu_ld{sign}{size}_{mmusuffix}(env, ptr) > + * cpu_ld{sign}{size}_{mmusuffix}_ra(env, ptr, retaddr) > + * cpu_ld{sign}{size}_mmuidx_ra(env, ptr, mmu_idx, retaddr) > * > - * store: cpu_st{sign}{size}_{mmusuffix}(env, ptr, val) > + * store: cpu_st{size}_{mmusuffix}(env, ptr, val) > + * cpu_st{size}_{mmusuffix}_ra(env, ptr, val, retaddr) > + * cpu_st{size}_mmuidx_ra(env, ptr, val, mmu_idx, retaddr) > * > * sign is: > * (empty): for 32 and 64 bit sizes > @@ -40,9 +44,10 @@ > * l: 32 bits > * q: 64 bits > * > - * mmusuffix is one of the generic suffixes "data" or "code", or > - * (for softmmu configs) a target-specific MMU mode suffix as defined > - * in target cpu.h. > + * mmusuffix is one of the generic suffixes "data" or "code", or "mmuidx= ". > + * The "mmuidx" suffix carries an extra mmu_idx argument that specifies > + * the index to use; the "data" and "code" suffixes take the index from > + * cpu_mmu_index(). > */ > #ifndef CPU_LDST_H > #define CPU_LDST_H > @@ -145,6 +150,71 @@ static inline void clear_helper_retaddr(void) > #undef MEMSUFFIX > #undef CODE_ACCESS > > +/* > + * Provide the same *_mmuidx_ra interface as for softmmu. > + * The mmu_idx argument is ignored. > + */ > + > +static inline uint32_t cpu_ldub_mmuidx_ra(CPUArchState *env, abi_ptr > addr, > + int mmu_idx, uintptr_t ra) > +{ > + return cpu_ldub_data_ra(env, addr, ra); > +} > + > +static inline uint32_t cpu_lduw_mmuidx_ra(CPUArchState *env, abi_ptr > addr, > + int mmu_idx, uintptr_t ra) > +{ > + return cpu_lduw_data_ra(env, addr, ra); > +} > + > +static inline uint32_t cpu_ldl_mmuidx_ra(CPUArchState *env, abi_ptr addr= , > + int mmu_idx, uintptr_t ra) > +{ > + return cpu_ldl_data_ra(env, addr, ra); > +} > + > +static inline uint64_t cpu_ldq_mmuidx_ra(CPUArchState *env, abi_ptr addr= , > + int mmu_idx, uintptr_t ra) > +{ > + return cpu_ldq_data_ra(env, addr, ra); > +} > + > +static inline int cpu_ldsb_mmuidx_ra(CPUArchState *env, abi_ptr addr, > + int mmu_idx, uintptr_t ra) > +{ > + return cpu_ldsb_data_ra(env, addr, ra); > +} > + > +static inline int cpu_ldsw_mmuidx_ra(CPUArchState *env, abi_ptr addr, > + int mmu_idx, uintptr_t ra) > +{ > + return cpu_ldsw_data_ra(env, addr, ra); > +} > + > +static inline void cpu_stb_mmuidx_ra(CPUArchState *env, abi_ptr addr, > + uint32_t val, int mmu_idx, uintptr_= t > ra) > +{ > + cpu_stb_data_ra(env, addr, val, ra); > +} > + > +static inline void cpu_stw_mmuidx_ra(CPUArchState *env, abi_ptr addr, > + uint32_t val, int mmu_idx, uintptr_= t > ra) > +{ > + cpu_stw_data_ra(env, addr, val, ra); > +} > + > +static inline void cpu_stl_mmuidx_ra(CPUArchState *env, abi_ptr addr, > + uint32_t val, int mmu_idx, uintptr_= t > ra) > +{ > + cpu_stl_data_ra(env, addr, val, ra); > +} > + > +static inline void cpu_stq_mmuidx_ra(CPUArchState *env, abi_ptr addr, > + uint64_t val, int mmu_idx, uintptr_= t > ra) > +{ > + cpu_stq_data_ra(env, addr, val, ra); > +} > + > #else > > /* Needed for TCG_OVERSIZED_GUEST */ > diff --git a/docs/devel/loads-stores.rst b/docs/devel/loads-stores.rst > index 8a5bc912a5..03aa9e7ff8 100644 > --- a/docs/devel/loads-stores.rst > +++ b/docs/devel/loads-stores.rst > @@ -72,31 +72,34 @@ Regexes for git grep > - ``\`` > - ``\`` > > -``cpu_{ld,st}_*`` > -~~~~~~~~~~~~~~~~~ > +``cpu_{ld,st}*_mmuidx_ra`` > +~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -These functions operate on a guest virtual address. Be aware > -that these functions may cause a guest CPU exception to be > -taken (e.g. for an alignment fault or MMU fault) which will > -result in guest CPU state being updated and control longjumping > -out of the function call. They should therefore only be used > -in code that is implementing emulation of the target CPU. > +These functions operate on a guest virtual address plus a context, > +known as a "mmu index" or ``mmuidx``, which controls how that virtual > +address is translated. The meaning of the indexes are target specific, > +but specifying a particular index might be necessary if, for instance, > +the helper requires an "always as non-privileged" access rather that > +the default access for the current state of the guest CPU. > > -These functions may throw an exception (longjmp() back out > -to the top level TCG loop). This means they must only be used > -from helper functions where the translator has saved all > -necessary CPU state before generating the helper function call. > -It's usually better to use the ``_ra`` variants described below > -from helper functions, but these functions are the right choice > -for calls made from hooks like the CPU do_interrupt hook or > -when you know for certain that the translator had to save all > -the CPU state that ``cpu_restore_state()`` would restore anyway. > +These functions may cause a guest CPU exception to be taken > +(e.g. for an alignment fault or MMU fault) which will result in > +guest CPU state being updated and control longjmp'ing out of the > +function call. They should therefore only be used in code that is > +implementing emulation of the guest CPU. > + > +The ``retaddr`` parameter is used to control unwinding of the > +guest CPU state in case of a guest CPU exception. This is passed > +to ``cpu_restore_state()``. Therefore the value should either be 0, > +to indicate that the guest CPU state is already synchronized, or > +the result of ``GETPC()`` from the top level ``HELPER(foo)`` > +function, which is a return address into the generated code. > > Function names follow the pattern: > > -load: ``cpu_ld{sign}{size}_{mmusuffix}(env, ptr)`` > +load: ``cpu_ld{sign}{size}_mmuidx_ra(env, ptr, mmuidx, retaddr)`` > > -store: ``cpu_st{size}_{mmusuffix}(env, ptr, val)`` > +store: ``cpu_st{size}_mmuidx_ra(env, ptr, val, mmuidx, retaddr)`` > > ``sign`` > - (empty) : for 32 or 64 bit sizes > @@ -109,56 +112,151 @@ store: ``cpu_st{size}_{mmusuffix}(env, ptr, val)`` > - ``l`` : 32 bits > - ``q`` : 64 bits > > -``mmusuffix`` is one of the generic suffixes ``data`` or ``code``, or > -(for softmmu configs) a target-specific MMU mode suffix as defined > -in the target's ``cpu.h``. > +Regexes for git grep: > + - ``\`` > + - ``\`` > > -Regexes for git grep > - - ``\`` > - - ``\`` > +``cpu_{ld,st}*_data_ra`` > +~~~~~~~~~~~~~~~~~~~~~~~~ > > -``cpu_{ld,st}_*_ra`` > -~~~~~~~~~~~~~~~~~~~~ > - > -These functions work like the ``cpu_{ld,st}_*`` functions except > -that they also take a ``retaddr`` argument. This extra argument > -allows for correct unwinding of any exception that is taken, > -and should generally be the result of GETPC() called directly > -from the top level HELPER(foo) function (i.e. the return address > -in the generated code). > +These functions work like the ``cpu_{ld,st}_mmuidx_ra`` functions > +except that the ``mmuidx`` parameter is taken from the current mode > +of the guest CPU, as determined by ``cpu_mmu_index(env, false)``. > > These are generally the preferred way to do accesses by guest > -virtual address from helper functions; see the documentation > -of the non-``_ra`` variants for when those would be better. > - > -Calling these functions with a ``retaddr`` argument of 0 is > -equivalent to calling the non-``_ra`` version of the function. > +virtual address from helper functions, unless the access should > +be performed with a context other than the default. > > Function names follow the pattern: > > -load: ``cpu_ld{sign}{size}_{mmusuffix}_ra(env, ptr, retaddr)`` > +load: ``cpu_ld{sign}{size}_data_ra(env, ptr, ra)`` > > -store: ``cpu_st{sign}{size}_{mmusuffix}_ra(env, ptr, val, retaddr)`` > +store: ``cpu_st{size}_data_ra(env, ptr, val, ra)`` > + > +``sign`` > + - (empty) : for 32 or 64 bit sizes > + - ``u`` : unsigned > + - ``s`` : signed > + > +``size`` > + - ``b`` : 8 bits > + - ``w`` : 16 bits > + - ``l`` : 32 bits > + - ``q`` : 64 bits > + > +Regexes for git grep: > + - ``\`` > + - ``\`` > + > +``cpu_{ld,st}*_data`` > +~~~~~~~~~~~~~~~~~~~~~ > + > +These functions work like the ``cpu_{ld,st}_data_ra`` functions > +except that the ``retaddr`` parameter is 0, and thus does not > +unwind guest CPU state. > + > +This means they must only be used from helper functions where the > +translator has saved all necessary CPU state. These functions are > +the right choice for calls made from hooks like the CPU ``do_interrupt`` > +hook or when you know for certain that the translator had to save all > +the CPU state anyway. > + > +Function names follow the pattern: > + > +load: ``cpu_ld{sign}{size}_data(env, ptr)`` > + > +store: ``cpu_st{size}_data(env, ptr, val)`` > + > +``sign`` > + - (empty) : for 32 or 64 bit sizes > + - ``u`` : unsigned > + - ``s`` : signed > + > +``size`` > + - ``b`` : 8 bits > + - ``w`` : 16 bits > + - ``l`` : 32 bits > + - ``q`` : 64 bits > > Regexes for git grep > - - ``\`` > - - ``\`` > + - ``\`` > + - ``\`` > > -``helper_*_{ld,st}*mmu`` > -~~~~~~~~~~~~~~~~~~~~~~~~ > +``cpu_ld*_code`` > +~~~~~~~~~~~~~~~~ > + > +These functions perform a read for instruction execution. The ``mmuidx`= ` > +parameter is taken from the current mode of the guest CPU, as determined > +by ``cpu_mmu_index(env, true)``. The ``retaddr`` parameter is 0, and > +thus does not unwind guest CPU state, because CPU state is always > +synchronized while translating instructions. Any guest CPU exception > +that is raised will indicate an instruction execution fault rather than > +a data read fault. > + > +In general these functions should not be used directly during translatio= n. > +There are wrapper functions that are to be used which also take care of > +plugins for tracing. > + > +Function names follow the pattern: > + > +load: ``cpu_ld{sign}{size}_code(env, ptr)`` > + > +``sign`` > + - (empty) : for 32 or 64 bit sizes > + - ``u`` : unsigned > + - ``s`` : signed > + > +``size`` > + - ``b`` : 8 bits > + - ``w`` : 16 bits > + - ``l`` : 32 bits > + - ``q`` : 64 bits > + > +Regexes for git grep: > + - ``\`` > + > +``translator_ld*`` > +~~~~~~~~~~~~~~~~~~ > + > +These functions are a wrapper for ``cpu_ld*_code`` which also perform > +any actions required by any tracing plugins. They are only to be > +called during the translator callback ``translate_insn``. > + > +There is a set of functions ending in ``_swap`` which, if the parameter > +is true, returns the value in the endianness that is the reverse of > +the guest native endianness, as determined by ``TARGET_WORDS_BIGENDIAN``= . > + > +Function names follow the pattern: > + > +load: ``translator_ld{sign}{size}(env, ptr)`` > + > +swap: ``translator_ld{sign}{size}_swap(env, ptr, swap)`` > + > +``sign`` > + - (empty) : for 32 or 64 bit sizes > + - ``u`` : unsigned > + - ``s`` : signed > + > +``size`` > + - ``b`` : 8 bits > + - ``w`` : 16 bits > + - ``l`` : 32 bits > + - ``q`` : 64 bits > + > +Regexes for git grep > + - ``\`` > + > +``helper_*_{ld,st}*_mmu`` > +~~~~~~~~~~~~~~~~~~~~~~~~~ > > These functions are intended primarily to be called by the code > generated by the TCG backend. They may also be called by target > -CPU helper function code. Like the ``cpu_{ld,st}_*_ra`` functions > -they perform accesses by guest virtual address; the difference is > -that these functions allow you to specify an ``opindex`` parameter > -which encodes (among other things) the mmu index to use for the > -access. This is necessary if your helper needs to make an access > -via a specific mmu index (for instance, an "always as non-privileged" > -access) rather than using the default mmu index for the current state > -of the guest CPU. > +CPU helper function code. Like the ``cpu_{ld,st}_mmuidx_ra`` functions > +they perform accesses by guest virtual address, with a given ``mmuidx``. > > -The ``opindex`` parameter should be created by calling > ``make_memop_idx()``. > +These functions specify an ``opindex`` parameter which encodes > +(among other things) the mmu index to use for the access. This paramete= r > +should be created by calling ``make_memop_idx()``. > > The ``retaddr`` parameter should be the result of GETPC() called directl= y > from the top level HELPER(foo) function (or 0 if no guest CPU state > @@ -166,8 +264,9 @@ unwinding is required). > > **TODO** The names of these functions are a bit odd for historical > reasons because they were originally expected to be called only from > -within generated code. We should rename them to bring them > -more in line with the other memory access functions. > +within generated code. We should rename them to bring them more in > +line with the other memory access functions. The explicit endianness > +is the only feature they have beyond ``*_mmuidx_ra``. > > load: ``helper_{endian}_ld{sign}{size}_mmu(env, addr, opindex, retaddr)`= ` > > -- > 2.20.1 > > > --0000000000002844ff059ad943c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sunday, December 29, 2019, Richard Henderson <richard.henderson@linaro.org> wrote= :
This finishes the new interface began w= ith the previous patch.
Document the interface and deprecate MMU_MODE<N>_SUFFIX.

Reviewed-by: Alex Benn=C3=A9e <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---
=C2=A0include/exec/cpu_ldst.h=C2=A0 =C2=A0 =C2=A0|=C2=A0 80 +++++++++++++-<= br> =C2=A0docs/devel/loads-stores.rst | 211 ++++++++++++++++++++++++++----= ------
=C2=A02 files changed, 230 insertions(+), 61 deletions(-)



Reviewed-by: Ale= ksandar Markovic <amarkovic@wavecomp.com>

diff --git a/include/exec/cpu_ldst.h b/include/exec/cpu_ldst.h
index ef59ed61e4..41b98ba801 100644
--- a/include/exec/cpu_ldst.h
+++ b/include/exec/cpu_ldst.h
@@ -25,9 +25,13 @@
=C2=A0 *
=C2=A0 * The syntax for the accessors is:
=C2=A0 *
- * load: cpu_ld{sign}{size}_{mmusuffix}(env, ptr)
+ * load:=C2=A0 cpu_ld{sign}{size}_{mmusuffix}(env, ptr)
+ *=C2=A0 =C2=A0 =C2=A0 =C2=A0 cpu_ld{sign}{size}_{mmusuffix}_ra(env, = ptr, retaddr)
+ *=C2=A0 =C2=A0 =C2=A0 =C2=A0 cpu_ld{sign}{size}_mmuidx_ra(env, ptr, = mmu_idx, retaddr)
=C2=A0 *
- * store: cpu_st{sign}{size}_{mmusuffix}(env, ptr, val)
+ * store: cpu_st{size}_{mmusuffix}(env, ptr, val)
+ *=C2=A0 =C2=A0 =C2=A0 =C2=A0 cpu_st{size}_{mmusuffix}_ra(env, ptr, v= al, retaddr)
+ *=C2=A0 =C2=A0 =C2=A0 =C2=A0 cpu_st{size}_mmuidx_ra(env, ptr, val, mmu_id= x, retaddr)
=C2=A0 *
=C2=A0 * sign is:
=C2=A0 * (empty): for 32 and 64 bit sizes
@@ -40,9 +44,10 @@
=C2=A0 *=C2=A0 =C2=A0l: 32 bits
=C2=A0 *=C2=A0 =C2=A0q: 64 bits
=C2=A0 *
- * mmusuffix is one of the generic suffixes "data" or "code= ", or
- * (for softmmu configs)=C2=A0 a target-specific MMU mode suffix as define= d
- * in target cpu.h.
+ * mmusuffix is one of the generic suffixes "data" or "code= ", or "mmuidx".
+ * The "mmuidx" suffix carries an extra mmu_idx argument that sp= ecifies
+ * the index to use; the "data" and "code" suffixes ta= ke the index from
+ * cpu_mmu_index().
=C2=A0 */
=C2=A0#ifndef CPU_LDST_H
=C2=A0#define CPU_LDST_H
@@ -145,6 +150,71 @@ static inline void clear_helper_retaddr(void)
=C2=A0#undef MEMSUFFIX
=C2=A0#undef CODE_ACCESS

+/*
+ * Provide the same *_mmuidx_ra interface as for softmmu.
+ * The mmu_idx argument is ignored.
+ */
+
+static inline uint32_t cpu_ldub_mmuidx_ra(CPUArchState *env, abi_ptr = addr,
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i= nt mmu_idx, uintptr_t ra)
+{
+=C2=A0 =C2=A0 return cpu_ldub_data_ra(env, addr, ra);
+}
+
+static inline uint32_t cpu_lduw_mmuidx_ra(CPUArchState *env, abi_ptr = addr,
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i= nt mmu_idx, uintptr_t ra)
+{
+=C2=A0 =C2=A0 return cpu_lduw_data_ra(env, addr, ra);
+}
+
+static inline uint32_t cpu_ldl_mmuidx_ra(CPUArchState *env, abi_ptr addr,<= br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in= t mmu_idx, uintptr_t ra)
+{
+=C2=A0 =C2=A0 return cpu_ldl_data_ra(env, addr, ra);
+}
+
+static inline uint64_t cpu_ldq_mmuidx_ra(CPUArchState *env, abi_ptr addr,<= br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in= t mmu_idx, uintptr_t ra)
+{
+=C2=A0 =C2=A0 return cpu_ldq_data_ra(env, addr, ra);
+}
+
+static inline int cpu_ldsb_mmuidx_ra(CPUArchState *env, abi_ptr addr,=
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int mmu_idx, uin= tptr_t ra)
+{
+=C2=A0 =C2=A0 return cpu_ldsb_data_ra(env, addr, ra);
+}
+
+static inline int cpu_ldsw_mmuidx_ra(CPUArchState *env, abi_ptr addr,=
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int mmu_idx, uin= tptr_t ra)
+{
+=C2=A0 =C2=A0 return cpu_ldsw_data_ra(env, addr, ra);
+}
+
+static inline void cpu_stb_mmuidx_ra(CPUArchState *env, abi_ptr addr,
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32_t val, in= t mmu_idx, uintptr_t ra)
+{
+=C2=A0 =C2=A0 cpu_stb_data_ra(env, addr, val, ra);
+}
+
+static inline void cpu_stw_mmuidx_ra(CPUArchState *env, abi_ptr addr,
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32_t val, in= t mmu_idx, uintptr_t ra)
+{
+=C2=A0 =C2=A0 cpu_stw_data_ra(env, addr, val, ra);
+}
+
+static inline void cpu_stl_mmuidx_ra(CPUArchState *env, abi_ptr addr,
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32_t val, in= t mmu_idx, uintptr_t ra)
+{
+=C2=A0 =C2=A0 cpu_stl_data_ra(env, addr, val, ra);
+}
+
+static inline void cpu_stq_mmuidx_ra(CPUArchState *env, abi_ptr addr,
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint64_t val, in= t mmu_idx, uintptr_t ra)
+{
+=C2=A0 =C2=A0 cpu_stq_data_ra(env, addr, val, ra);
+}
+
=C2=A0#else

=C2=A0/* Needed for TCG_OVERSIZED_GUEST */
diff --git a/docs/devel/loads-stores.rst b/docs/devel/loads-stores.rst
index 8a5bc912a5..03aa9e7ff8 100644
--- a/docs/devel/loads-stores.rst
+++ b/docs/devel/loads-stores.rst
@@ -72,31 +72,34 @@ Regexes for git grep
=C2=A0 - ``\<ldn_\([hbl]e\)?_p\>``
=C2=A0 - ``\<stn_\([hbl]e\)?_p\>``

-``cpu_{ld,st}_*``
-~~~~~~~~~~~~~~~~~
+``cpu_{ld,st}*_mmuidx_ra``
+~~~~~~~~~~~~~~~~~~~~~~~~~~

-These functions operate on a guest virtual address. Be aware
-that these functions may cause a guest CPU exception to be
-taken (e.g. for an alignment fault or MMU fault) which will
-result in guest CPU state being updated and control longjumping
-out of the function call. They should therefore only be used
-in code that is implementing emulation of the target CPU.
+These functions operate on a guest virtual address plus a context,
+known as a "mmu index" or ``mmuidx``, which controls how that vi= rtual
+address is translated.=C2=A0 The meaning of the indexes are target specifi= c,
+but specifying a particular index might be necessary if, for instance,
+the helper requires an "always as non-privileged" access rather = that
+the default access for the current state of the guest CPU.

-These functions may throw an exception (longjmp() back out
-to the top level TCG loop). This means they must only be used
-from helper functions where the translator has saved all
-necessary CPU state before generating the helper function call.
-It's usually better to use the ``_ra`` variants described below
-from helper functions, but these functions are the right choice
-for calls made from hooks like the CPU do_interrupt hook or
-when you know for certain that the translator had to save all
-the CPU state that ``cpu_restore_state()`` would restore anyway.
+These functions may cause a guest CPU exception to be taken
+(e.g. for an alignment fault or MMU fault) which will result in
+guest CPU state being updated and control longjmp'ing out of the
+function call.=C2=A0 They should therefore only be used in code that is +implementing emulation of the guest CPU.
+
+The ``retaddr`` parameter is used to control unwinding of the
+guest CPU state in case of a guest CPU exception.=C2=A0 This is passed
+to ``cpu_restore_state()``.=C2=A0 Therefore the value should either be 0,<= br> +to indicate that the guest CPU state is already synchronized, or
+the result of ``GETPC()`` from the top level ``HELPER(foo)``
+function, which is a return address into the generated code.

=C2=A0Function names follow the pattern:

-load: ``cpu_ld{sign}{size}_{mmusuffix}(env, ptr)``
+load: ``cpu_ld{sign}{size}_mmuidx_ra(env, ptr, mmuidx, retaddr)``

-store: ``cpu_st{size}_{mmusuffix}(env, ptr, val)``
+store: ``cpu_st{size}_mmuidx_ra(env, ptr, val, mmuidx, retaddr)``

=C2=A0``sign``
=C2=A0 - (empty) : for 32 or 64 bit sizes
@@ -109,56 +112,151 @@ store: ``cpu_st{size}_{mmusuffix}(env, ptr, val= )``
=C2=A0 - ``l`` : 32 bits
=C2=A0 - ``q`` : 64 bits

-``mmusuffix`` is one of the generic suffixes ``data`` or ``code``, or
-(for softmmu configs) a target-specific MMU mode suffix as defined
-in the target's ``cpu.h``.
+Regexes for git grep:
+ - ``\<cpu_ld[us]\?[bwlq]_mmuidx_ra\>``
+ - ``\<cpu_st[bwlq]_mmuidx_ra\>``

-Regexes for git grep
- - ``\<cpu_ld[us]\?[bwlq]_[a-zA-Z0-9]\+\>``
- - ``\<cpu_st[bwlq]_[a-zA-Z0-9]\+\>``
+``cpu_{ld,st}*_data_ra``
+~~~~~~~~~~~~~~~~~~~~~~~~

-``cpu_{ld,st}_*_ra``
-~~~~~~~~~~~~~~~~~~~~
-
-These functions work like the ``cpu_{ld,st}_*`` functions except
-that they also take a ``retaddr`` argument. This extra argument
-allows for correct unwinding of any exception that is taken,
-and should generally be the result of GETPC() called directly
-from the top level HELPER(foo) function (i.e. the return address
-in the generated code).
+These functions work like the ``cpu_{ld,st}_mmuidx_ra`` functions
+except that the ``mmuidx`` parameter is taken from the current mode
+of the guest CPU, as determined by ``cpu_mmu_index(env, false)``.

=C2=A0These are generally the preferred way to do accesses by guest
-virtual address from helper functions; see the documentation
-of the non-``_ra`` variants for when those would be better.
-
-Calling these functions with a ``retaddr`` argument of 0 is
-equivalent to calling the non-``_ra`` version of the function.
+virtual address from helper functions, unless the access should
+be performed with a context other than the default.

=C2=A0Function names follow the pattern:

-load: ``cpu_ld{sign}{size}_{mmusuffix}_ra(env, ptr, retaddr)``
+load: ``cpu_ld{sign}{size}_data_ra(env, ptr, ra)``

-store: ``cpu_st{sign}{size}_{mmusuffix}_ra(env, ptr, val, retaddr)``<= br> +store: ``cpu_st{size}_data_ra(env, ptr, val, ra)``
+
+``sign``
+ - (empty) : for 32 or 64 bit sizes
+ - ``u`` : unsigned
+ - ``s`` : signed
+
+``size``
+ - ``b`` : 8 bits
+ - ``w`` : 16 bits
+ - ``l`` : 32 bits
+ - ``q`` : 64 bits
+
+Regexes for git grep:
+ - ``\<cpu_ld[us]\?[bwlq]_data_ra\>``
+ - ``\<cpu_st[bwlq]_data_ra\>``
+
+``cpu_{ld,st}*_data``
+~~~~~~~~~~~~~~~~~~~~~
+
+These functions work like the ``cpu_{ld,st}_data_ra`` functions
+except that the ``retaddr`` parameter is 0, and thus does not
+unwind guest CPU state.
+
+This means they must only be used from helper functions where the
+translator has saved all necessary CPU state.=C2=A0 These functions are +the right choice for calls made from hooks like the CPU ``do_interrupt`` +hook or when you know for certain that the translator had to save all
+the CPU state anyway.
+
+Function names follow the pattern:
+
+load: ``cpu_ld{sign}{size}_data(env, ptr)``
+
+store: ``cpu_st{size}_data(env, ptr, val)``
+
+``sign``
+ - (empty) : for 32 or 64 bit sizes
+ - ``u`` : unsigned
+ - ``s`` : signed
+
+``size``
+ - ``b`` : 8 bits
+ - ``w`` : 16 bits
+ - ``l`` : 32 bits
+ - ``q`` : 64 bits

=C2=A0Regexes for git grep
- - ``\<cpu_ld[us]\?[bwlq]_[a-zA-Z0-9]\+_ra\>``
- - ``\<cpu_st[bwlq]_[a-zA-Z0-9]\+_ra\>``
+ - ``\<cpu_ld[us]\?[bwlq]_data\>``
+ - ``\<cpu_st[bwlq]_data\+\>``

-``helper_*_{ld,st}*mmu``
-~~~~~~~~~~~~~~~~~~~~~~~~
+``cpu_ld*_code``
+~~~~~~~~~~~~~~~~
+
+These functions perform a read for instruction execution.=C2=A0 The ``mmui= dx``
+parameter is taken from the current mode of the guest CPU, as determined +by ``cpu_mmu_index(env, true)``.=C2=A0 The ``retaddr`` parameter is 0, and=
+thus does not unwind guest CPU state, because CPU state is always
+synchronized while translating instructions.=C2=A0 Any guest CPU exception=
+that is raised will indicate an instruction execution fault rather than +a data read fault.
+
+In general these functions should not be used directly during translation.=
+There are wrapper functions that are to be used which also take care of +plugins for tracing.
+
+Function names follow the pattern:
+
+load: ``cpu_ld{sign}{size}_code(env, ptr)``
+
+``sign``
+ - (empty) : for 32 or 64 bit sizes
+ - ``u`` : unsigned
+ - ``s`` : signed
+
+``size``
+ - ``b`` : 8 bits
+ - ``w`` : 16 bits
+ - ``l`` : 32 bits
+ - ``q`` : 64 bits
+
+Regexes for git grep:
+ - ``\<cpu_ld[us]\?[bwlq]_code\>``
+
+``translator_ld*``
+~~~~~~~~~~~~~~~~~~
+
+These functions are a wrapper for ``cpu_ld*_code`` which also perform
+any actions required by any tracing plugins.=C2=A0 They are only to be
+called during the translator callback ``translate_insn``.
+
+There is a set of functions ending in ``_swap`` which, if the parameter +is true, returns the value in the endianness that is the reverse of
+the guest native endianness, as determined by ``TARGET_WORDS_BIGENDIAN``.<= br> +
+Function names follow the pattern:
+
+load: ``translator_ld{sign}{size}(env, ptr)``
+
+swap: ``translator_ld{sign}{size}_swap(env, ptr, swap)``
+
+``sign``
+ - (empty) : for 32 or 64 bit sizes
+ - ``u`` : unsigned
+ - ``s`` : signed
+
+``size``
+ - ``b`` : 8 bits
+ - ``w`` : 16 bits
+ - ``l`` : 32 bits
+ - ``q`` : 64 bits
+
+Regexes for git grep
+ - ``\<translator_ld[us]\?[bwlq]\(_swap\)\?\>``
+
+``helper_*_{ld,st}*_mmu``
+~~~~~~~~~~~~~~~~~~~~~~~~~

=C2=A0These functions are intended primarily to be called by the code
=C2=A0generated by the TCG backend. They may also be called by target
-CPU helper function code. Like the ``cpu_{ld,st}_*_ra`` functions
-they perform accesses by guest virtual address; the difference is
-that these functions allow you to specify an ``opindex`` parameter
-which encodes (among other things) the mmu index to use for the
-access. This is necessary if your helper needs to make an access
-via a specific mmu index (for instance, an "always as non-privileged&= quot;
-access) rather than using the default mmu index for the current state
-of the guest CPU.
+CPU helper function code. Like the ``cpu_{ld,st}_mmuidx_ra`` functions
+they perform accesses by guest virtual address, with a given ``mmuidx``.
-The ``opindex`` parameter should be created by calling ``make_memop_idx()`= `.
+These functions specify an ``opindex`` parameter which encodes
+(among other things) the mmu index to use for the access.=C2=A0 This param= eter
+should be created by calling ``make_memop_idx()``.

=C2=A0The ``retaddr`` parameter should be the result of GETPC() called dire= ctly
=C2=A0from the top level HELPER(foo) function (or 0 if no guest CPU state @@ -166,8 +264,9 @@ unwinding is required).

=C2=A0**TODO** The names of these functions are a bit odd for historical =C2=A0reasons because they were originally expected to be called only from<= br> -within generated code. We should rename them to bring them
-more in line with the other memory access functions.
+within generated code. We should rename them to bring them more in
+line with the other memory access functions. The explicit endianness
+is the only feature they have beyond ``*_mmuidx_ra``.

=C2=A0load: ``helper_{endian}_ld{sign}{size}_mmu(env, addr, opindex, r= etaddr)``
=C2=A0
--
2.20.1


--0000000000002844ff059ad943c8--