[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Poking a sun4v machine

From: Blue Swirl
Subject: Re: [Qemu-devel] Poking a sun4v machine
Date: Tue, 1 May 2012 13:54:42 +0000

On Tue, May 1, 2012 at 13:33, Artyom Tarasenko <address@hidden> wrote:
> On Tue, May 1, 2012 at 11:19 AM, Blue Swirl <address@hidden> wrote:
>> On Mon, Apr 30, 2012 at 16:39, Artyom Tarasenko <address@hidden> wrote:
>>> Tried to boot QEMU Niagara machine with the firmware from the
>>> OpenSPARC T1 emulator ( www.opensparc.net/opensparc-t1/download.html )
>>> , and it dies very early.
>>> The reason: in translate.c
>>> #define hypervisor(dc) (dc->mem_idx == MMU_HYPV_IDX)
>>> #define supervisor(dc) (dc->mem_idx >= MMU_KERNEL_IDX)
>>> and the dc->mem_idx is initialized like this:
>>>    if (env1->tl > 0) {
>>>        return MMU_NUCLEUS_IDX;
>>>    } else if (cpu_hypervisor_mode(env1)) {
>>>        return MMU_HYPV_IDX;
>>>    } else if (cpu_supervisor_mode(env1)) {
>>>        return MMU_KERNEL_IDX;
>>>    } else {
>>>        return MMU_USER_IDX;
>>>    }
>>> Which seems to be conceptually incorrect. After reset tl == MAXTL, but
>>> still super- and hyper-visor bits are set, so both supervisor(dc) and
>>> hypervisor(dc) must return 1 which is impossible in the current
>>> implementation.
>> I don't think this is needed. The MMU index tells which TLB is used
>> for guest virtual to host address translations, during tl == MAXTL we
>> want to use hypervisor mode translations.
> Is just about the address translations? I thought it affects TB cache
> as well, which has to be invalidated between nucleus, super- and
> hypervisor switches?

This is (should be) handled by cpu_get_tb_cpu_state(). But it looks
like only supervisor mode (PS_PRIV) is taken into account, not others.

Also when D/I MMU is enabled or disabled, TLB is flushed, so there's
no need to store these bits.

I'm not sure TL is interesting either.

>>> What would be the proper way to fix it? Make mem_idx bitmap, add two
>>> more variables to DisasContext, or ...?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]