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

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.

-- PMM

Reply via email to