qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] TCG multithread plan.


From: Lluís Vilanova
Subject: Re: [Qemu-devel] TCG multithread plan.
Date: Mon, 15 Dec 2014 12:29:24 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Mark Burton writes:

> (please note the address of the match list server is
> address@hidden)

>     On 9 Dec 2014, at 18:57, Lluís Vilanova <address@hidden> wrote:
    
>     Frederic Konrad writes:
    
>         Hi everybody,
>         Here is the plan we will follow:
        

>     We will be focusing - from the outset - on the end goal of multi-threaded
>         TCG in full system emulation mode. On the way, we expect this will 
> ‘fix’
>         user mode.
        

>     The plan is:
        

>     * Create one cache per CPU as a first step. We can do more next and share 
> a
>         cache.
>         * Update tb_* to add a pointer to their cache.
>         * Add atomic instruction support to the TGC (first on ARM).
>         * Make tb_invalidate work between all cache.
>         * Modify main-loop for multi-thread.
>         * Memory access (eg: for device) are not thread safe that need to be
>         fixed. Initial plan simply globally mutex memory accesses - this may 
> be
>         optimised later.
>         * For now, irq handler for CPU seems ok but we need to check.
        

>     We will discuss this during the call tomorrow.
        

>     Is there any plan to have the notion of "memory coherency domains"?
>     (shortened
>     as MCD in the wiki)
    
>     Even though it's not that useful now, it could be used in the future to
>     relax
>     the atomicity of operations when different devices operate on different 
> MCDs
>     and
>     TCG is not able to map that into an atomic host operation (aka, has to use
>     locks). A system with a CPU and a GPU would be a good example of that.
    
    

> This would - I think - be a vote for doing atomicity via the ‘io’ path I
> believe?

I'm not sure what you mean by that (I wasn't on any of the conference
calls).

What I mean is that atomic TCG operations that are not (or cannot) be translated
to atomic host operations need to use a lock, and different MCDs can use
different locks (to avoid unnecessary contention).


Best,
  Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth



reply via email to

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