[Qemu-devel] tcg: improve MAX_CODE_GEN_BUFFER_SIZE for arm

[Qemu-devel] tcg: improve MAX_CODE_GEN_BUFFER_SIZE for arm

[TeLeMan]

I know MAX_CODE_GEN_BUFFER_SIZE is limited by the host direct branch
instructions.But the arm's MAX_CODE_GEN_BUFFER_SIZE is so small.I
tried improving MAX_CODE_GEN_BUFFER_SIZE.I wrote some check codes for
the overflow offset in tcg_out_b(), tcg_out_bl(),
tcg_out_blx_imm(),reloc_pc24(). But I didn't catch any overflow case
when tb_size and MAX_CODE_GEN_BUFFER_SIZE were larger than 32MB. After
the generated code size was larger than 32MB, qemu crashed.

Any suggest for this issue?

--
SUN OF A BEACH

Re: [Qemu-devel] tcg: improve MAX_CODE_GEN_BUFFER_SIZE for arm

[Aurelien Jarno]

On 2015-12-08 10:43, TeLeMan wrote:
> I know MAX_CODE_GEN_BUFFER_SIZE is limited by the host direct branch
> instructions.But the arm's MAX_CODE_GEN_BUFFER_SIZE is so small.I
> tried improving MAX_CODE_GEN_BUFFER_SIZE.I wrote some check codes for
> the overflow offset in tcg_out_b(), tcg_out_bl(),
> tcg_out_blx_imm(),reloc_pc24(). But I didn't catch any overflow case
> when tb_size and MAX_CODE_GEN_BUFFER_SIZE were larger than 32MB. After
> the generated code size was larger than 32MB, qemu crashed.

Instrumenting all the tcg_out_* branch related functions do not work
here as the address is actually not known at code generation:

    case INDEX_op_goto_tb:
        if (s->tb_jmp_offset) {
            /* Direct jump method */
            s->tb_jmp_offset[args[0]] = tcg_current_code_size(s);
            tcg_out_b_noaddr(s, COND_AL);

It is patched later during TB linking.

> Any suggest for this issue?

I already posted a patch a long time ago to remove the 16MB limit on ARM
hosts:

http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg01684.html

However as you can see in the thread, it has been rejected as it doesn't
not bring improvement in all cases.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] tcg: improve MAX_CODE_GEN_BUFFER_SIZE for arm

[Laurent Desnogues]

Hello,

On Tue, Dec 8, 2015 at 11:39 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
[...]
> I already posted a patch a long time ago to remove the 16MB limit on ARM
> hosts:
>
> http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg01684.html
>
> However as you can see in the thread, it has been rejected as it doesn't
> not bring improvement in all cases.

We could perhaps resurrect it and do some more benchmarking?  Who
would be able to do testing on (recent) ARM hardware?


Laurent

Re: [Qemu-devel] tcg: improve MAX_CODE_GEN_BUFFER_SIZE for arm

[Aurelien Jarno]

On 2015-12-08 11:51, Laurent Desnogues wrote:
> Hello,
> 
> On Tue, Dec 8, 2015 at 11:39 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> [...]
> > I already posted a patch a long time ago to remove the 16MB limit on ARM
> > hosts:
> >
> > http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg01684.html
> >
> > However as you can see in the thread, it has been rejected as it doesn't
> > not bring improvement in all cases.
> 
> We could perhaps resurrect it and do some more benchmarking?  Who
> would be able to do testing on (recent) ARM hardware?

I can provide an updated patch, but I would prefer if someone else does
the benchmarking on a really recent hardware. Not sure the hardware I
have (cortex A7) is really representative of a modern ARM CPU.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] tcg: improve MAX_CODE_GEN_BUFFER_SIZE for arm

[TeLeMan]

On Tue, Dec 8, 2015 at 7:21 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On 2015-12-08 11:51, Laurent Desnogues wrote:
>> Hello,
>>
>> On Tue, Dec 8, 2015 at 11:39 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> [...]
>> > I already posted a patch a long time ago to remove the 16MB limit on ARM
>> > hosts:
>> >
>> > http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg01684.html
>> >
>> > However as you can see in the thread, it has been rejected as it doesn't
>> > not bring improvement in all cases.
>>
>> We could perhaps resurrect it and do some more benchmarking?  Who
>> would be able to do testing on (recent) ARM hardware?
>
> I can provide an updated patch, but I would prefer if someone else does
> the benchmarking on a really recent hardware. Not sure the hardware I
> have (cortex A7) is really representative of a modern ARM CPU.

ok,I wait your new patch, thanks. I have arm A7 too.

> Aurelien
>
> --
> Aurelien Jarno                          GPG: 4096R/1DDD8C9B
> aurelien@aurel32.net                 http://www.aurel32.net