On 6 April 2018 at 18:28, Abdallah Bouassida <abdallah.bouass...@lauterbach.com> wrote: > Alex wrote: >> There is something odd going on here because if I run a simple little >> features binary >> (https://github.com/stsquad/testcases/blob/master/aarch64/features.c) I >> get: >> >> ID_AA64ISAR0_EL1 : 0x0000000000011120 >> ID_AA64ISAR1_EL1 : 0x0000000000000000 >> ID_AA64MMFR0_EL1 : 0x00000000ff000000 >> ID_AA64MMFR1_EL1 : 0x0000000000000000 >> ID_AA64PFR0_EL1 : 0x0000000000000011 >> ID_AA64PFR1_EL1 : 0x0000000000000000 >> ID_AA64DFR0_EL1 : 0x0000000000000006 >> ID_AA64DFR1_EL1 : 0x0000000000000000 >> MIDR_EL1 : 0x00000000411fd070 >> MPIDR_EL1 : 0x0000000080000000 >> REVIDR_EL1 : 0x0000000000000000 >> >> However in the gdb output we see: >> >> ID_AA64ISAR0_EL1 0x11120 69920 >> ID_AA64ISAR1_EL1 0x0 0 >> ID_AA64MMFR0_EL1 0x1124 4388 <-? >> ID_AA64MMFR1_EL1 0x0 0 >> ID_PFR0 0x131 305 <-name and value? >> ID_AA64PFR1_EL1 0x0 0 >> ID_AA64DFR0_EL1 0x10305106 271601926 <-? >> ID_AA64DFR1_EL1 0x0 0 >> REVIDR_EL1 0x0 0 >> >> So why the discrepancies? > >> ID_AA64MMFR0_EL1 0x1124 4388 <-? >> ID_AA64DFR0_EL1 0x10305106 271601926 <-? > I get the same value in x1 (= 0x1124) and x2 (= 0x10305106) when I execute > the following instructions on the guest: > MRS x1, ID_AA64MMFR0_EL1 > MRS x2, ID_AA64DFR0_EL1
Alex's test program looks like a Linux userspace one -- in which case it will be reading whatever faked-up values the guest kernel is providing, rather than directly accessing the registers (since they're not EL0-readable in hardware). That may be the cause of the discrepancies. (As an aside, we probably need to add support for userspace accessing of ID regs to our linux-user code at some point.) >> ID_PFR0 0x131 305 <-name and value? > This is not ID_AA64PFR0_EL1 - the ID_AA64PFR0_EL1 is not registered in our > dynamic XML as it has "ARM_CP_NO_RAW" type. > So should we add some modifications to handle this special case? Hmm, this is an interesting case. I'm not entirely sure this register absolutely needs to be NO_RAW. Deciding whether we could drop the NO_RAW requires more thought than I have time for right now, though. In any case, it's quite plausible we may have registers which we want to be not migrated (so NO_RAW) but which we do want to allow the gdb stub to read (and perhaps write). I think that handling those special cases with a .gdbreadfn and .gdbwritefn as and when we need to would be the best approach. For the moment, this patchset is intended to be a "reasonable effort" reflection of the system registers into the gdbstub, so I don't think we need to do that now. If users have genuine need to read particular registers we can add the special casing code then. thanks -- PMM
