On 12/08/2020 20:06, Evgenii Stepanov wrote:
On Wed, Aug 12, 2020 at 11:03 AM Andrey Konovalov
< andreyknvl@google.com> wrote:
On Wed, Aug 12, 2020 at
7:52 PM Richard Henderson
<richard.henderson@linaro.org>
wrote:
>
> On 8/12/20 10:38 AM, Andrey Konovalov wrote:
> > On Wed, Aug 12, 2020 at 7:19 PM Richard Henderson
> > <richard.henderson@linaro.org>
wrote:
> >>
> >> As reported by Andrey, I was missing the
complete ISS info for
> >> the Data Abort raised upon a synchronous tag
check fail.
> >>
> >> The following should fix that. All the twisty
little rules for
> >> the ISS.ISV bit are already handled by
merge_syn_data_abort.
> >> Probably the most important bit that was
missing was ISS.WnR,
> >> as that is independent of ISS.ISV.
> >>
> >> Andrey, will you please test?
> >
> > Looks like WnR is now being set properly, but SAS
is still always 0.
>
> Are you looking at ESR_EL1?
>
> On page D13-2992 of revision F.a:
>
> # ISV is 0 for all faults reported in ESR_EL1 or
ESR_EL3.
>
> which means that ISS[23:14] are RES0, which includes
SAS.
+more Arm and Google people
Is this known? Do we not get access size when MTE fault
happens?
It sounds like this applies to all data abort exceptions,
no matter MTE or not.
Correct. For data aborts in general, the extra syndrome information
in ISS[23:14] is only provided at EL2, in order to help hypervisors
emulate simple loads/stores (that access device memory) by looking
at ESR_EL2 without having to decode the trapped instruction. Did you
have any particular use-case in mind for SAS being set even in
ESR_EL1?
Kevin
|