Re: [Qemu-devel] Poking a sun4v machine

[Blue Swirl]

On Wed, May 2, 2012 at 2:50 PM, Artyom Tarasenko <address@hidden> wrote:
> On Tue, May 1, 2012 at 3:54 PM, Blue Swirl <address@hidden> wrote:
>> 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.
>
> And what about the MMU contexts? UA2005 does have 3 ones: Primary,
> Secondary and Nucleus.
> Is it not relevant here?

We also flush the TLB when the context registers are changed. This is
not optimal, we'd want to add context numbers to TB flags but there's
not enough space. New flags or context numbers should be added, they
would be useful for other architectures too. Probably only primary
context is interesting for Sparc guests, flushes for secondary and
nucleus could be OK. Sparc32 MMU also has context numbers which is
handled by flushing ATM.

>
> --
> Regards,
> Artyom Tarasenko
>
> solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu