Re: [Qemu-devel] MTTCG next version?

[Alex Bennée]

Paolo Bonzini <address@hidden> writes:

> I am on vacation so no calls for me, but I *might* be able to send a pull 
> request with the linux-user patches (and signal-free kick if reviewed). My 
> queue is already long, and Emilio had useful fixups so he obviously 
> tested/reviewed them. It will not be signed though as I tend not to have the 
> key with me when travelling.
>
> Just one thing: do not squash too much into existing patches if possible. 
> Leaving things protected by the BQL and only moving it to tb_lock in a 
> subsequent patch is perfectly fine.
>
> Alex, please post the to-do list when you have time. More
> parallelization of the work or possible, especially as the focus
> slowly moves from "getting it working" to covering more architectures.

I too am on holiday but I'll get the notes tidied up and posted later in
the week when the kids are back to school ;-)

>
> Paolo
>
>
> -----Original Message-----
> From: Mark Burton address@hidden
> Received: mercoledì, 26 ago 2015, 14:21
> To: KONRAD Frédéric address@hidden
> CC: qemu-devel address@hidden; Alex Bennée address@hidden; address@hidden, 
> Paolo Bonzini address@hidden; Guillaume Delbergue address@hidden; Edgar E. 
> Iglesias address@hidden; Emilio G. Cota address@hidden
> Subject: Re: MTTCG next version?
>
> Just to remind everybody as well - we’ll have a call next Monday to 
> co-ordinate.
> It would be good to make sure everybody knows which bit of this everybody 
> else is committing to do, so we avoid replication and treading on each others 
> patch sets.
>
> Cheers
>
> Mark.
>
>> On 26 Aug 2015, at 14:18, Frederic Konrad <address@hidden> wrote:
>> 
>> Hi everybody,
>> 
>> I'm trying to do the next version of the MTTCG work:
>> 
>> I would like to rebase on Alvise atomic instruction branch:
>>  - Alvise can you rebase it on the 2.4.0 version without MTTCG support and 
>> then
>>    point me to the MTTCG specific changes so I can include them in my tree?
>> I will add Paolo's linux-user and signal free qemu_cpu_kick series as well.
>> 
>> About tb_flush we think to do that without exiting:
>>  - Use two buffers for tbs.
>>  - Use a per tb invalidated flag.
>>  - when tb_flush just invalidate all tb from the buffer and swap to the 
>> second buffer:
>>    VCPU which are executing code will discard their tb_jmp_cache when they 
>> exit
>>    (eg: run_on_cpu).
>> 
>> We need also to fix emulated data barrier so tlb_flush are finished before 
>> the
>> instruction is executed. (That might be only data barrier breaks the TB).
>> 
>> Protecting page->code_bitmap and cpu_breakpoint_insert changes will be 
>> squashed in the tb_lock patch.
>> 
>> More tests must be done especially with gdbstub and icount.
>> 
>> Do that make sense?
>> Fred
>
>
>        +44 (0)20 7100 3485 x 210
>  +33 (0)5 33 52 01 77x 210
>
>       +33 (0)603762104
>       mark.burton

-- 
Alex Bennée