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 <cmetc...@ezchip.com> 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. > > Correct. > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
