From: Richard Henderson <rth@twiddle.net>
To: Alvise Rigo <a.rigo@virtualopensystems.com>,
qemu-devel@nongnu.org, mttcg@greensocs.com
Cc: claudio.fontana@huawei.com, jani.kokkonen@huawei.com,
tech@virtualopensystems.com, alex.bennee@linaro.org,
pbonzini@redhat.com
Subject: Re: [Qemu-devel] [RFC v5 3/6] softmmu: Add helpers for a new slowpath
Date: Wed, 30 Sep 2015 13:58:31 +1000 [thread overview]
Message-ID: <560B5DE7.2040109@twiddle.net> (raw)
In-Reply-To: <1443083566-10994-4-git-send-email-a.rigo@virtualopensystems.com>
On 09/24/2015 06:32 PM, Alvise Rigo wrote:
> The new helpers rely on the legacy ones to perform the actual read/write.
>
> The LoadLink helper (helper_ldlink_name) prepares the way for the
> following SC operation. It sets the linked address and the size of the
> access.
> These helper also update the TLB entry of the page involved in the
> LL/SC for those vCPUs that have the bit set (dirty), so that the
> following accesses made by all the vCPUs will follow the slow path.
>
> The StoreConditional helper (helper_stcond_name) returns 1 if the
> store has to fail due to a concurrent access to the same page by
> another vCPU. A 'concurrent access' can be a store made by *any* vCPU
> (although, some implementations allow stores made by the CPU that issued
> the LoadLink).
>
> Suggested-by: Jani Kokkonen <jani.kokkonen@huawei.com>
> Suggested-by: Claudio Fontana <claudio.fontana@huawei.com>
> Signed-off-by: Alvise Rigo <a.rigo@virtualopensystems.com>
> ---
> cputlb.c | 3 ++
> softmmu_llsc_template.h | 124 ++++++++++++++++++++++++++++++++++++++++++++++++
> softmmu_template.h | 12 +++++
> tcg/tcg.h | 30 ++++++++++++
> 4 files changed, 169 insertions(+)
> create mode 100644 softmmu_llsc_template.h
>
> diff --git a/cputlb.c b/cputlb.c
> index 1e25a2a..d5aae7c 100644
> --- a/cputlb.c
> +++ b/cputlb.c
> @@ -416,6 +416,8 @@ static inline void lookup_and_reset_cpus_ll_addr(hwaddr addr, hwaddr size)
>
> #define MMUSUFFIX _mmu
>
> +/* Generates LoadLink/StoreConditional helpers in softmmu_template.h */
> +#define GEN_EXCLUSIVE_HELPERS
> #define SHIFT 0
> #include "softmmu_template.h"
>
> @@ -428,6 +430,7 @@ static inline void lookup_and_reset_cpus_ll_addr(hwaddr addr, hwaddr size)
> #define SHIFT 3
> #include "softmmu_template.h"
> #undef MMUSUFFIX
> +#undef GEN_EXCLUSIVE_HELPERS
>
> #define MMUSUFFIX _cmmu
> #undef GETPC_ADJ
> diff --git a/softmmu_llsc_template.h b/softmmu_llsc_template.h
> new file mode 100644
> index 0000000..9f22834
> --- /dev/null
> +++ b/softmmu_llsc_template.h
> @@ -0,0 +1,124 @@
> +/*
> + * Software MMU support (esclusive load/store operations)
> + *
> + * Generate helpers used by TCG for qemu_ldlink/stcond ops.
> + *
> + * Included from softmmu_template.h only.
> + *
> + * Copyright (c) 2015 Virtual Open Systems
> + *
> + * Authors:
> + * Alvise Rigo <a.rigo@virtualopensystems.com>
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +/* This template does not generate together the le and be version, but only one
> + * of the two depending on whether BIGENDIAN_EXCLUSIVE_HELPERS has been set.
> + * The same nomenclature as softmmu_template.h is used for the exclusive
> + * helpers. */
> +
> +#ifdef BIGENDIAN_EXCLUSIVE_HELPERS
> +
> +#define helper_ldlink_name glue(glue(helper_be_ldlink, USUFFIX), MMUSUFFIX)
> +#define helper_stcond_name glue(glue(helper_be_stcond, SUFFIX), MMUSUFFIX)
> +#define helper_ld glue(glue(helper_be_ld, USUFFIX), MMUSUFFIX)
> +#define helper_st glue(glue(helper_be_st, SUFFIX), MMUSUFFIX)
> +
> +#else /* LE helpers + 8bit helpers (generated only once for both LE end BE) */
> +
> +#if DATA_SIZE > 1
> +#define helper_ldlink_name glue(glue(helper_le_ldlink, USUFFIX), MMUSUFFIX)
> +#define helper_stcond_name glue(glue(helper_le_stcond, SUFFIX), MMUSUFFIX)
> +#define helper_ld glue(glue(helper_le_ld, USUFFIX), MMUSUFFIX)
> +#define helper_st glue(glue(helper_le_st, SUFFIX), MMUSUFFIX)
> +#else /* DATA_SIZE <= 1 */
> +#define helper_ldlink_name glue(glue(helper_ret_ldlink, USUFFIX), MMUSUFFIX)
> +#define helper_stcond_name glue(glue(helper_ret_stcond, SUFFIX), MMUSUFFIX)
> +#define helper_ld glue(glue(helper_ret_ld, USUFFIX), MMUSUFFIX)
> +#define helper_st glue(glue(helper_ret_st, SUFFIX), MMUSUFFIX)
> +#endif
> +
> +#endif
> +
> +WORD_TYPE helper_ldlink_name(CPUArchState *env, target_ulong addr,
> + TCGMemOpIdx oi, uintptr_t retaddr)
> +{
> + WORD_TYPE ret;
> + int index;
> + CPUState *cpu;
> + hwaddr hw_addr;
> + unsigned mmu_idx = get_mmuidx(oi);
> +
> + /* Use the proper load helper from cpu_ldst.h */
> + ret = helper_ld(env, addr, mmu_idx, retaddr);
> +
> + index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
> +
> + /* hw_addr = hwaddr of the page (i.e. section->mr->ram_addr + xlat)
> + * plus the offset (i.e. addr & ~TARGET_PAGE_MASK) */
> + hw_addr = (env->iotlb[mmu_idx][index].addr & TARGET_PAGE_MASK) + addr;
> +
> + cpu_physical_memory_clear_excl_dirty(hw_addr, ENV_GET_CPU(env)->cpu_index);
> + /* If all the vCPUs have the EXCL bit set for this page there is no need
> + * to request any flush. */
> + if (cpu_physical_memory_excl_is_dirty(hw_addr, smp_cpus)) {
> + CPU_FOREACH(cpu) {
> + if (current_cpu != cpu) {
> + if (cpu_physical_memory_excl_is_dirty(hw_addr,
> + cpu->cpu_index)) {
> + cpu_physical_memory_clear_excl_dirty(hw_addr,
> + cpu->cpu_index);
> + tlb_flush(cpu, 1);
> + }
Why would you need to indicate that another cpu has started an exclusive
operation on this page? That seems definitely wrong.
I think that all you wanted was to flush the other cpu, so that it notices that
this cpu has started an exclusive operation.
It would be great if most of this were pulled out to a subroutine so that these
helper functions didn't accrue so much duplicate code.
It would be fantastic to implement a tlb_flush_phys_page to that we didn't have
to flush the entire tlb of the other cpus.
> + /* We set it preventively to true to distinguish the following legacy
> + * access as one made by the store conditional wrapper. If the store
> + * conditional does not succeed, the value will be set to 0.*/
> + env->excl_succeeded = 1;
Ah -- "distinguish" is the word that was missing from the comments in the
previous patches.
> diff --git a/softmmu_template.h b/softmmu_template.h
> index e4431e8..ad65d20 100644
> --- a/softmmu_template.h
> +++ b/softmmu_template.h
> @@ -640,6 +640,18 @@ void probe_write(CPUArchState *env, target_ulong addr, int mmu_idx,
> #endif
> #endif /* !defined(SOFTMMU_CODE_ACCESS) */
>
> +#ifdef GEN_EXCLUSIVE_HELPERS
> +
> +#if DATA_SIZE > 1 /* The 8-bit helpers are generate along with LE helpers */
> +#define BIGENDIAN_EXCLUSIVE_HELPERS
> +#include "softmmu_llsc_template.h"
> +#undef BIGENDIAN_EXCLUSIVE_HELPERS
> +#endif
> +
> +#include "softmmu_llsc_template.h"
> +
> +#endif /* !defined(GEN_EXCLUSIVE_HELPERS) */
I'm not especially keen on this. Not that what we currently have in
softmmu_template.h is terribly better.
I wonder what can be done to clean all of this up, short of actually
transitioning to c++ templates...
r~
next prev parent reply other threads:[~2015-09-30 4:03 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-24 8:32 [Qemu-devel] [RFC v5 0/6] Slow-path for atomic instruction translation Alvise Rigo
2015-09-24 8:32 ` [Qemu-devel] [RFC v5 1/6] exec.c: Add new exclusive bitmap to ram_list Alvise Rigo
2015-09-26 17:15 ` Richard Henderson
2015-09-28 7:28 ` alvise rigo
2015-09-24 8:32 ` [Qemu-devel] [RFC v5 2/6] softmmu: Add new TLB_EXCL flag Alvise Rigo
2015-09-30 3:34 ` Richard Henderson
2015-09-30 9:24 ` alvise rigo
2015-09-30 11:09 ` Peter Maydell
2015-09-30 12:44 ` alvise rigo
2015-09-30 20:37 ` Richard Henderson
2015-09-24 8:32 ` [Qemu-devel] [RFC v5 3/6] softmmu: Add helpers for a new slowpath Alvise Rigo
2015-09-30 3:58 ` Richard Henderson [this message]
2015-09-30 9:46 ` alvise rigo
2015-09-30 20:42 ` Richard Henderson
2015-10-01 8:05 ` alvise rigo
2015-10-01 19:34 ` Richard Henderson
2015-09-24 8:32 ` [Qemu-devel] [RFC v5 4/6] target-arm: Create new runtime helpers for excl accesses Alvise Rigo
2015-09-30 4:03 ` Richard Henderson
2015-09-30 10:16 ` alvise rigo
2015-09-24 8:32 ` [Qemu-devel] [RFC v5 5/6] configure: Use slow-path for atomic only when the softmmu is enabled Alvise Rigo
2015-09-30 4:05 ` Richard Henderson
2015-09-30 9:51 ` alvise rigo
2015-09-24 8:32 ` [Qemu-devel] [RFC v5 6/6] target-arm: translate: Use ld/st excl for atomic insns Alvise Rigo
2015-09-30 4:44 ` [Qemu-devel] [RFC v5 0/6] Slow-path for atomic instruction translation Paolo Bonzini
2015-09-30 8:14 ` alvise rigo
2015-09-30 13:20 ` Paolo Bonzini
2015-10-01 19:32 ` Emilio G. Cota
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=560B5DE7.2040109@twiddle.net \
--to=rth@twiddle.net \
--cc=a.rigo@virtualopensystems.com \
--cc=alex.bennee@linaro.org \
--cc=claudio.fontana@huawei.com \
--cc=jani.kokkonen@huawei.com \
--cc=mttcg@greensocs.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=tech@virtualopensystems.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).