Re: [Qemu-devel] [PATCH 02/10 v11] linux-user: Support tilegx architecture in linux-user

[Chris Metcalf <cmetcalf@ezchip.com>]

On 06/03/2015 08:47 AM, Chen Gang wrote:
> On 06/03/2015 08:34 PM, Peter Maydell wrote:
>> On 3 June 2015 at 13:30, Chen Gang <xili_gchen_5257@hotmail.com> wrote:
>>> On 06/03/2015 01:40 AM, Peter Maydell wrote:
>>>> On 30 May 2015 at 22:10, Chen Gang <xili_gchen_5257@hotmail.com> wrote:
>>>>> +#ifdef TARGET_TILEGX
>>>>> +
>>>>> +static uint64_t get_regval(CPUTLGState *env, uint8_t reg)
>>>>> +{
>>>>> +    if (likely(reg < TILEGX_R_COUNT)) {
>>>>> +        return env->regs[reg];
>>>>> +    } else if (reg != TILEGX_R_ZERO) {
>>>>> +        fprintf(stderr, "invalid register r%d for reading.\n", reg);
>>>>> +        g_assert_not_reached();
>>>> You don't appear to be guaranteeing that the register value
>>>> is < TILEGX_R_COUNT anywhere: get_SrcA_X1() and friends
>>>> mask with 0x3f, but that only means you're guaranteed the
>>>> value is between 0 and 63, wherease TILEGX_R_COUNT is 56.
>>>> What does real hardware do if the encoded register value
>>>> is 56..63 ?
>>>>
>>> At present, it will g_assert_not_reached() too.
>> No, it is not possible for hardware to assert!
>>
>>> 56..62 are hidden to
>>> outside. So I did not implement them, either. Need we still implement
>>> them?
>> You must do something. You can't allow guest code (even
>> broken guest code) to make QEMU assert. You need to find
>> out what the hardware does here, and do that.
>>
> OK, what you said sounds reasonable to me. I will check what to do next
> for the 56..62 registers (at present, I guess, we need generate a
> hardware exception, and its default handler will do nothing).

The registers in question are mapped directly to the on-chip
networks.

56 - sn (static network)
57 - idn0 (internal dynamic network, demux 0)
58 - idn1 (internal dynamic network, demux 1)
59 - udn0 (user dynamic network, demux 0)
60 - udn1 (user dynamic network, demux 1)
61 - udn2 (user dynamic network, demux 2)
62 - udn3 (user dynamic network, demux 3)

The "sn" is obsoleted in tilegx so acts just like "zero".

Accessing idn0 or idn1 will generate an IDN_ACCESS exception,
and accessing udn0..udn3 will generate a UDN_ACCESS exception;
either of those becomes a SIGILL to a userspace application
with code ILL_PRVREG.

The tilegx hypervisor uses idn0/idn1 internally, and userspace
applications can use udn0..udn3 after setting up a suitable
hardwall with the kernel (see arch/tile/kernel/hardwall.c), but
you almost certainly don't want to care about any of that.

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com