Re: [Qemu-devel] [RFC v2 0/5] Dynamic TLB sizing

[Alex Bennée]

Emilio G. Cota <address@hidden> writes:

> On Tue, Oct 09, 2018 at 15:45:36 +0100, Alex Bennée wrote:
>>
>> Emilio G. Cota <address@hidden> writes:
>>
>> > On Tue, Oct 09, 2018 at 13:34:40 +0100, Alex Bennée wrote:
>> >>
>> >> Emilio G. Cota <address@hidden> writes:
>> >>
>> >> > v1: https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg01146.html
>> >> >
>> >> > Changes since v1:
>> >>
>> >> Hmm I'm seeing some qtest failures, for example:
>> >>
>> >>   $ make check-qtest-alpha V=1
>> >>   ...
>> >>   QTEST_QEMU_BINARY=alpha-softmmu/qemu-system-alpha 
>> >> QTEST_QEMU_IMG=qemu-img MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( 
>> >> ${RANDOM:-0} % 255 + 1))} gtester -k --verbose -m=quick test
>> >>   s/boot-serial-test tests/qmp-test tests/qmp-cmd-test 
>> >> tests/device-introspect-test tests/cdrom-test tests/machine-none-test 
>> >> tests/qom-test tests/test-hmp
>> >>   TEST: tests/boot-serial-test... (pid=31091)
>> >>     /alpha/boot-serial/clipper:                                          
>> >> Broken pipe
>> >>   tests/libqtest.c:129: kill_qemu() detected QEMU death from signal 11 
>> >> (Segmentation fault) (core dumped)
>> >>   FAIL
>> >>   GTester: last random seed: R02S948c4a5112fd7682934f4d96e1aff38e
>> >>   (pid=31099)
>> >>   FAIL: tests/boot-serial-test
>> >
>> > I'm pretty sure that the problem is that tlb_init is not being
>> > called at all. Note that this applies to the tlb-lock series
>> > as well, although there we're just calling qemu_spin_init,
>> > which is not really necessary because CPUArchState is 0-allocated.
>> >
>> > I'll take a look.
>>
>> Yeah I hadn't tried to bisect it, but I'm on top of tlb-lock-v4 as
>> requested.
>
> It's the tlb_flush in alpha_cpu_initfn:
>
> static void alpha_cpu_initfn(Object *obj)
> {
>     CPUState *cs = CPU(obj);
>     AlphaCPU *cpu = ALPHA_CPU(obj);
>     CPUAlphaState *env = &cpu->env;
>
>     cs->env_ptr = env;
>     tlb_flush(cs);
>
> We call tlb_init later on at realize time.
>
> I think we can safely get rid of this tlb_flush.

Agreed.

> Unicore
> also has it. I'll add patches for both to the tlb-lock series.

Weirdly this didn't fail, but I agree it's superfluous.

>
>               Emilio


--
Alex Bennée