Hi Andrew, On 11/08/2020 15:53, Andrew Scull wrote: > On Wed, Aug 05, 2020 at 03:34:11PM +0100, James Morse wrote: >> On 30/07/2020 23:31, Andrew Scull wrote: >>> On Thu, Jul 30, 2020 at 04:18:23PM +0100, Andrew Scull wrote: >>>> The ESB at the start of the vectors causes any SErrors to be consumed to >>>> DISR_EL1. If the exception came from the host and the ESB caught an >>> I think the host's DISR_EL1 would need to be saved and restored in the >>> vcpu context switch which, from a cursory read of the ARM, is possible >>> without having to virtualize SErrors for the host. >> >> ... I thought this was a redirected register. Reads from EL1 when HCR_EL2.AMO is set get >> the value from VDISR_EL2, meaning the guest can't read DISR_EL1 at all. >> (see 'Accessing DISR_EL1' in the register description, "D13.7.1 >> DISR_EL1, Deferred Interrupt Status Register" of DDI0487F.a > The host doesn't run with HCR_EL2.AMO set so it uses DISR_EL1 directly, > but hyp also uses DISR_EL1 directly during __guest_exit. That is the > clobbering I was concerned about. It may not be a problem most of the > time given what you said above, but I think something like the diff > below should be enough to be sure it is preserved: On guest-exit, can't we just clobber the register, and make it the hosts problem to ensure it always cleared it after use? (as it does today). Save restore here is extra work to do all the time, to preserve a value the the host should never need anyway. I think this is just another weird case where the host really isn't like a vcpu. Thanks, James _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
