[Qemu-devel] TCG multithread plan.

[Qemu-devel] TCG multithread plan.

[Frederic Konrad]

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.

Thanks,
Fred

Re: [Qemu-devel] TCG multithread plan.

[Lluís Vilanova]

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.


Thanks,
  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

Re: [Qemu-devel] TCG multithread plan.

[Mark Burton]

[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]

(please note the address of the match list server is mttcg@listserver.greensocs.com <mailto:mttcg@listserver.greensocs.com>)

> On 9 Dec 2014, at 18:57, Lluís Vilanova <vilanova@ac.upc.edu> 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?

Cheers

Mark.

> 
> Thanks,
> 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



[-- Attachment #2: Type: text/html, Size: 2937 bytes --]

Re: [Qemu-devel] TCG multithread plan.

[Lluís Vilanova]

Mark Burton writes:

> (please note the address of the match list server is
> mttcg@listserver.greensocs.com)

>     On 9 Dec 2014, at 18:57, Lluís Vilanova <vilanova@ac.upc.edu> 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