Hi Peter, On 09/03/18 14:37, Peter Maydell wrote: > On 9 March 2018 at 13:19, Auger Eric <eric.au...@redhat.com> wrote: >> On 08/03/18 15:27, Peter Maydell wrote: >>> Consider specifically catching 8-byte accesses to non-64-bit registers? >>> This is CONSTRAINED UNPREDICTABLE (see spec section 6.2), and "one >>> of the registers is read/written and other half is RAZ/WI" is permitted >>> behaviour, but it does mean you need to be a little careful about not >>> letting the top 32 bits of val become non-zero for the 32-bit register >>> codepaths. Logging bad 64-bit accesses as LOG_GUEST_ERROR and making >>> them RAZ/WI might be nicer for guest software developers. >> >> I moved to ops with attrs and if a 64-bit access is attempted on >> something not a 64b reg base, I return an error + log a guest error. > > Ah, you probably don't want to return MEMTX_ERROR, because that > becomes a guest CPU external-abort exception. An abort is listed > as one of the permitted constrained-unpredictable behaviours for > bad 64-bit accesses, but there is a note that "strongly recommends" > not to abort for cases where the registers might be used by software > associated with lower exception levels. Rather than trying to decide > which registers do or don't get to return MEMTX_ERROR, it's probably > easier just to RAZ/WI and return MEMTX_OK. > > (We had to fix a bug like this in the gicv3 in commits f1945632b43e3 > and 0cf09852015e when we started making MEMTX_ERROR generate aborts, > though in that case the spec is more definite that abort is not a > permitted behaviour.)
Yes saw those modifs in gic. I will check & fix this. Thanks Eric > > thanks > -- PMM >
