(please note the address of the match list server is mt...@listserver.greensocs.com <mailto: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? 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
