On 2/12/20 7:49 PM, Gavin Shan wrote: > On 2/12/20 10:34 PM, Peter Maydell wrote: >> Yeah, this is on my list to look at; Richard Henderson also could >> have a look at it. From a quick scan I suspect you may be missing >> handling for AArch32. >> > > [Thanks for copying Richard Henderson] > > Yes, the functionality is only supported on aarch64 currently by intention > because the next patch enables it on "max" and "host" CPU models and both > of them are running in aarch64 mode.
We shouldn't leave the aarch32 exception entry paths unimplemented though. C.f. AArch32.TakePhysicalSErrorException() AArch32.TakeVirtualSErrorException() It really shouldn't be more than a couple of lines, just like arm_cpu_do_interrupt_aarch64. Remember both arm_cpu_do_interrupt_aarch32 and arm_cpu_do_interrupt_aarch32_hyp. > However, it seems there is a long list of aarch32 CPU models, defined > in target/arm/cpu.c::arm_cpus. so which CPU models you prefer to see with > this supported? I think we might choose one or two popular CPU models if > you agree. Even qemu-system-aarch64 -cpu max can exercise this path when EL1 is running in aarch32 mode. Admittedly it would be easier if we had the rest of the plumbing so that -cpu max,aarch64=off worked. FWIW, the rest of the patch looks good. r~