[Qemu-devel] MTTCG next version?

[Qemu-devel] MTTCG next version?

[Frederic Konrad]

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

Re: [Qemu-devel] MTTCG next version?

[Mark Burton]

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

Re: [Qemu-devel] MTTCG next version?

[Paolo Bonzini]

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

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.

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





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

Re: [Qemu-devel] MTTCG next version?

[Alex Bennée]

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

Re: [Qemu-devel] MTTCG next version?

[Emilio G. Cota]

On Wed, Aug 26, 2015 at 14:18:24 +0200, Frederic Konrad wrote:
> Do that make sense?

A few decisions here don't make that much sense to me, but maybe
I'm missing context:

> 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?

This breaks usermode--what's the way forward for that?

> 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).

What's wrong with exiting? tb_flush is called very rarely so the perf
impact is not a factor--reliability and simplicity are more important
goals. Exiting/halting all CPUs seems like the easiest way to
achieve said goals.

> 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).

I suggest to look at solutions that make the requesting CPU thread
to wait until all TLB invalidations have completed--in other words,
the effect of said actions from the guest's viewpoint should be 'immediate'.
This way we don't have to worry about interactions between the TLB
invalidation instruction and subsequent instructions.

This principle applies to other actions on global state, such as tb_flush.

FWIW the patchset I sent on Sunday is one way of doing this.

Cheers,

		Emilio

Re: [Qemu-devel] MTTCG next version?

[alvise rigo]

Hi Frederic,

On Wed, Aug 26, 2015 at 2:18 PM, 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?

Yes, I will do it.
Regarding the changes, it will not be that difficult to port the whole
thing to MTTCG. Basically, something along the lines of "Atomic
slow-path for mttcg v4" has to be done.
In any case, let's discuss it during the telco.

Regards,
alvise


> 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