On 06/04/2015 08:29 PM, Peter Maydell wrote: > On 4 June 2015 at 13:25, Chen Gang <xili_gchen_5...@hotmail.com> 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 <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. > > 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