From: "Alex Bennée" <alex.bennee@linaro.org>
To: "Emilio G. Cota" <cota@braap.org>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v3 3/4] cputlb: serialize tlb updates with env->tlb_lock
Date: Mon, 08 Oct 2018 15:30:28 +0100 [thread overview]
Message-ID: <87y3b8mry3.fsf@linaro.org> (raw)
In-Reply-To: <20181008141219.GB19899@flamenco>
Emilio G. Cota <cota@braap.org> writes:
> On Mon, Oct 08, 2018 at 14:57:18 +0100, Alex Bennée wrote:
>> Emilio G. Cota <cota@braap.org> writes:
>> > The readers that do not hold tlb_lock must use atomic reads when
>> > reading .addr_write, since this field can be updated by other threads;
>> > the conversion to atomic reads is done in the next patch.
>>
>> We don't enforce this for the TCG code - but rely on the backend ISA's
>> to avoid torn reads from updates from cputlb that could invalidate an
>> entry.
>
> We do enforce it though; the TLB reads we emit in TCG backend
> code are appropriately sized to guarantee atomic reads.
>
>> > -/* For atomic correctness when running MTTCG we need to use the right
>> > - * primitives when copying entries */
>> > -static inline void copy_tlb_helper(CPUTLBEntry *d, CPUTLBEntry *s,
>> > - bool atomic_set)
>> > +/* Called with tlb_lock held */
>> > +static inline void copy_tlb_helper_locked(CPUTLBEntry *d, const CPUTLBEntry *s)
>> > {
>> > -#if TCG_OVERSIZED_GUEST
>> > *d = *s;
>>
>> In general I'm happy with the patch set but what ensures that this
>> always DRT with respect to the TCG code reads that race with it?
>
> copy_tlb_helper is only called by the "owner" CPU, so it cannot
> race with TCG code (i.e. the owner thread cannot race with itself).
>
> I wanted to add an assert_cpu_is_self(cpu) here, but that needs
> a CPUState pointer. Maybe I should just get rid of the function?
> All the callers have the assert, so that might make the code
> clearer.
I'm happy keeping the function and just expanding the comment:
/* Called with tlb_lock held and only ever from the vCPU context */
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
>
> Thanks,
>
> Emilio
--
Alex Bennée
next prev parent reply other threads:[~2018-10-08 14:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-05 21:14 [Qemu-devel] [PATCH v3 0/4] per-TLB lock Emilio G. Cota
2018-10-05 21:14 ` [Qemu-devel] [PATCH v3 1/4] exec: introduce tlb_init Emilio G. Cota
2018-10-05 21:14 ` [Qemu-devel] [PATCH v3 2/4] cputlb: fix assert_cpu_is_self macro Emilio G. Cota
2018-10-05 21:14 ` [Qemu-devel] [PATCH v3 3/4] cputlb: serialize tlb updates with env->tlb_lock Emilio G. Cota
2018-10-08 13:57 ` Alex Bennée
2018-10-08 14:12 ` Emilio G. Cota
2018-10-08 14:30 ` Alex Bennée [this message]
2018-10-05 21:14 ` [Qemu-devel] [PATCH v3 4/4] cputlb: read CPUTLBEntry.addr_write atomically Emilio G. Cota
2018-10-16 2:52 ` Richard Henderson
2018-10-16 6:03 ` Paolo Bonzini
2018-10-16 15:12 ` Emilio G. Cota
2018-10-16 15:56 ` Richard Henderson
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=87y3b8mry3.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=cota@braap.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).