On 06/03/2015 08:47 AM, Chen Gang wrote:
On 06/03/2015 08:34 PM, Peter Maydell wrote:
On 3 June 2015 at 13:30, Chen Gang <xili_gchen_5...@hotmail.com> wrote:
On 06/03/2015 01:40 AM, Peter Maydell wrote:
On 30 May 2015 at 22:10, Chen Gang <xili_gchen_5...@hotmail.com> wrote:
+#ifdef TARGET_TILEGX
+
+static uint64_t get_regval(CPUTLGState *env, uint8_t reg)
+{
+ if (likely(reg < TILEGX_R_COUNT)) {
+ return env->regs[reg];
+ } else if (reg != TILEGX_R_ZERO) {
+ fprintf(stderr, "invalid register r%d for reading.\n", reg);
+ g_assert_not_reached();
You don't appear to be guaranteeing that the register value
is < TILEGX_R_COUNT anywhere: get_SrcA_X1() and friends
mask with 0x3f, but that only means you're guaranteed the
value is between 0 and 63, wherease TILEGX_R_COUNT is 56.
What does real hardware do if the encoded register value
is 56..63 ?
At present, it will g_assert_not_reached() too.
No, it is not possible for hardware to assert!
56..62 are hidden to
outside. So I did not implement them, either. Need we still implement
them?
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.
The tilegx hypervisor uses idn0/idn1 internally, and userspace
applications can use udn0..udn3 after setting up a suitable
hardwall with the kernel (see arch/tile/kernel/hardwall.c), but
you almost certainly don't want to care about any of that.
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
