[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kernel/process.c?h=v4.11-rc3#n217

Thanks,
Mark.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.