Mark Burton writes:
> (please note the address of the match list server is
> mt...@listserver.greensocs.com)
> On 9 Dec 2014, at 18:57, Lluís Vilanova <vilan...@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
