Re: [Xen-devel] [PATCH 02/18] xen/arm: Restore HCR_EL2 register

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 22 Mar 2017, Mark Rutland wrote:
> On Wed, Mar 22, 2017 at 10:54:11AM -0700, Stefano Stabellini wrote:
> > When we receive an SError in Xen, we determine if it should be injected
> > into the guest or "handled" in Xen (by "handle" I mean crash the
> > system). In case it should be injected into the guest, we set the
> > relevant bit in vcpu->arch.hcr_el2 (the saved version of HCR_EL2). This
> > patch moves the WRITE(vcpu->arch.hcr_el2, HCR_EL2) from context switch
> > related functions (p2m_restore_state) to leave_hypervisor_tail, which is
> > the last point we can move it to, before exiting Xen. That way, we are
> > sure to inject an abort into the guest, no matter exactly when we
> > receive the SError. So far so good, right?
> 
> I assume you're in the context of the guest at this point, so what's the
> problem with doing:
> 
>       vcpu->arch.hcr_el2 |= HCR_VA;
>       WRITE(vcpu->arch.hcr_el2, HCR_EL2);
> 
> That way you don't need to move the restoration of HCR_EL2, and it workd
> regardless of whether you get preempted, at the cost of a potentially
> redundant system register write on what should be an incredibly rare
> path...
> 
> Within Linux we do similar when we manipulate system registers which are
> context switched with the thread, e.g. when setting tpidrro_el0 in
> tls_thread_flush() [1].
> 
> Surely similar applies for the manipulation of other system registers
> while in the guest context?

Yes, this looks like the better option.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel