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

[Peter Maydell]

On 4 June 2015 at 13:25, Chen Gang <address@hidden> wrote:
> On 06/03/2015 11:20 PM, Chris Metcalf wrote:
>> On 06/03/2015 11:19 AM, Peter Maydell wrote:
>>> On 3 June 2015 at 16:10, Chris Metcalf <address@hidden> wrote:
>>>> On 06/03/2015 08:47 AM, Chen Gang wrote:
>>>>> On 06/03/2015 08:34 PM, Peter Maydell wrote:
>>>>>> 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.
>
> OK, thank you very much for your details. I will implement it according
> to the details above.
>
>>> Presumably this applies for all register accesses, not
>>> just atomic instructions?
>
> Excuse me, I do not quite understand what it is meaning, welcome any
> more details for it.

Chris says that all instructions that use these registers
generate an exception. Atomic instructions are not "special".
This means you should handle these registers in translate.c
(in the same place you handle their use in all other kinds
of instruction).

If you do that then it's OK to assert in main.c, because
you know that translate.c has already made sure those cases
are handled and won't generate the "do an atomic operation"
exception for them.

thanks
-- PMM