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.
Presumably this applies for all register accesses, not just atomic instructions? thanks -- PMM
