Re: [Qemu-devel] MTTCG next version?

["Alex Bennée" <alex.bennee@linaro.org>]

Paolo Bonzini <pbonzini@redhat.com> 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 [mark.burton@greensocs.com]
> Received: mercoledì, 26 ago 2015, 14:21
> To: KONRAD Frédéric [fred.konrad@greensocs.com]
> CC: qemu-devel [qemu-devel@nongnu.org]; Alex Bennée [alex.bennee@linaro.org]; mttcg@greensocs.com, Paolo Bonzini [pbonzini@redhat.com]; Guillaume Delbergue [guillaume.delbergue@greensocs.com]; Edgar E. Iglesias [edgar.iglesias@gmail.com]; Emilio G. Cota [cota@braap.org]
> 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 <fred.konrad@greensocs.com> 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