qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Making cputlb.c operations safe for MTTCG


From: Alex Bennée
Subject: Re: [Qemu-devel] Making cputlb.c operations safe for MTTCG
Date: Wed, 28 Sep 2016 00:04:00 +0100
User-agent: mu4e 0.9.17; emacs 25.1.50.1

Emilio G. Cota <address@hidden> writes:

> On Tue, Sep 27, 2016 at 18:16:45 +0200, Paolo Bonzini wrote:
>> Anyhow, the next step is to merge either cmpxchg-based atomics
>> or iothread-free single-threaded TCG.  Either will do. :)
>>
>> I think that even iothread-free single-threaded TCG requires this
>> TLB stuff, because the iothread's address_space_write (and hence
>> invalidate_and_set_dirty) can race against the TCG thread's
>> code generation.
>
> What's a quick-and-dirty way to disable the fast-path TLB lookups?
> Alex: you told me the monitor has an option for this, but I can't
> find it. I'm looking for something that'd go in tcg/i386 to simply
> bypass the fast path.

Hack up tlb_set_page_with_attrs() to always set one of the TLB_FOO bits
(you might want to invent a new one as the other do have meanings).

>
> Forcing the slow TLB lookup would be an easy way to then implement
> a per-TLB seqlock. I think TLB corruption might explain the crashes I
> see when booting Ubuntu in a many-core guest (running on a many-core
> host).

TLB corruption is suspected but I've never come up with a clean test
case to force it. I find heavy compiles in a system image can do it but
my SMC torture test never crashes.

>
> Thanks,
>
>               Emilio


--
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]