qemu-devel
[Top][All Lists]
Advanced

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

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


From: Chen Gang
Subject: Re: [Qemu-devel] [PATCH 02/10 v11] linux-user: Support tilegx architecture in linux-user
Date: Thu, 4 Jun 2015 20:39:45 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

On 06/04/2015 08:29 PM, Peter Maydell wrote:
> 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.
> 

OK, Thanks.

And I shall try to send patch v12 within next week (2015-06-14).


-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed



reply via email to

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