Re: [Xen-devel] [PATCH v2 07/19] xen/arm: Introduce a virtual abort injection helper

2017-03-30 Thread Wei Chen
On 2017/3/31 1:20, Julien Grall wrote:
> Hi Wei,
>
> On 30/03/17 10:13, Wei Chen wrote:
>> When guest triggers async aborts, in most platform, such aborts
>> will be routed to hypervisor. But we don't want the hypervisor
>> to handle such aborts, so we have to route such aborts back to
>> the guest.
>>
>> This helper is using the HCR_EL2.VSE (HCR.VA for aarch32) bit to
>> route such aborts back to the guest. If the guest PC had been
>> advanced by SVC/HVC/SMC instructions before we caught the SError
>> in hypervisor, we have to adjust the guest PC to exact address
>> while the SError generated.
>>
>> About HSR_EC_SVC32/64, even thought we don't trap SVC32/64 today,
>> we would like them to be handled here. This would be useful when
>> VM introspection will gain support of SVC32/64 trapping.
>>
>> This helper will be used by the later patches in this series, we
>> use #if 0 to disable it in this patch temporarily to remove the
>> warning message of unused function from compiler.
>>
>> Signed-off-by: Wei Chen 
>> Acked-by: Stefano Stabellini 
>> ---
>> v1->v2:
>> 1. After updating HCR_EL2.VSE bit of vCPU HCR_EL2, write the value
>>to HCR_EL2 immediately. In this case we don't need to move the
>>restoration of HCR_EL2 to leave_hypervisor_tail, and it worked
>>regardless of whether we get preempted.
>
> This should have been explained in the commit message and ...

Ok.

>
>> 2. Add Stefano's Acked-by.
>
> I would not keep Acked-by/Reviewed-by with a change like above. Or at
> least, I would ask whether they are fine with this change.

Thanks, I understand now.

>
> Cheers,
>


-- 
Regards,
Wei Chen

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


Re: [Xen-devel] [PATCH v2 07/19] xen/arm: Introduce a virtual abort injection helper

2017-03-30 Thread Stefano Stabellini
On Thu, 30 Mar 2017, Julien Grall wrote:
> Hi Wei,
> 
> On 30/03/17 10:13, Wei Chen wrote:
> > When guest triggers async aborts, in most platform, such aborts
> > will be routed to hypervisor. But we don't want the hypervisor
> > to handle such aborts, so we have to route such aborts back to
> > the guest.
> > 
> > This helper is using the HCR_EL2.VSE (HCR.VA for aarch32) bit to
> > route such aborts back to the guest. If the guest PC had been
> > advanced by SVC/HVC/SMC instructions before we caught the SError
> > in hypervisor, we have to adjust the guest PC to exact address
> > while the SError generated.
> > 
> > About HSR_EC_SVC32/64, even thought we don't trap SVC32/64 today,
> > we would like them to be handled here. This would be useful when
> > VM introspection will gain support of SVC32/64 trapping.
> > 
> > This helper will be used by the later patches in this series, we
> > use #if 0 to disable it in this patch temporarily to remove the
> > warning message of unused function from compiler.
> > 
> > Signed-off-by: Wei Chen 
> > Acked-by: Stefano Stabellini 
> > ---
> > v1->v2:
> > 1. After updating HCR_EL2.VSE bit of vCPU HCR_EL2, write the value
> >to HCR_EL2 immediately. In this case we don't need to move the
> >restoration of HCR_EL2 to leave_hypervisor_tail, and it worked
> >regardless of whether we get preempted.
> 
> This should have been explained in the commit message and ...
> 
> > 2. Add Stefano's Acked-by.
> 
> I would not keep Acked-by/Reviewed-by with a change like above. Or at least, I
> would ask whether they are fine with this change.

That's true. Regardless, for this patch:

Reviewed-by: Stefano Stabellini 

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


Re: [Xen-devel] [PATCH v2 07/19] xen/arm: Introduce a virtual abort injection helper

2017-03-30 Thread Julien Grall

Hi Wei,

On 30/03/17 10:13, Wei Chen wrote:

When guest triggers async aborts, in most platform, such aborts
will be routed to hypervisor. But we don't want the hypervisor
to handle such aborts, so we have to route such aborts back to
the guest.

This helper is using the HCR_EL2.VSE (HCR.VA for aarch32) bit to
route such aborts back to the guest. If the guest PC had been
advanced by SVC/HVC/SMC instructions before we caught the SError
in hypervisor, we have to adjust the guest PC to exact address
while the SError generated.

About HSR_EC_SVC32/64, even thought we don't trap SVC32/64 today,
we would like them to be handled here. This would be useful when
VM introspection will gain support of SVC32/64 trapping.

This helper will be used by the later patches in this series, we
use #if 0 to disable it in this patch temporarily to remove the
warning message of unused function from compiler.

Signed-off-by: Wei Chen 
Acked-by: Stefano Stabellini 
---
v1->v2:
1. After updating HCR_EL2.VSE bit of vCPU HCR_EL2, write the value
   to HCR_EL2 immediately. In this case we don't need to move the
   restoration of HCR_EL2 to leave_hypervisor_tail, and it worked
   regardless of whether we get preempted.


This should have been explained in the commit message and ...


2. Add Stefano's Acked-by.


I would not keep Acked-by/Reviewed-by with a change like above. Or at 
least, I would ask whether they are fine with this change.


Cheers,

--
Julien Grall

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


[Xen-devel] [PATCH v2 07/19] xen/arm: Introduce a virtual abort injection helper

2017-03-30 Thread Wei Chen
When guest triggers async aborts, in most platform, such aborts
will be routed to hypervisor. But we don't want the hypervisor
to handle such aborts, so we have to route such aborts back to
the guest.

This helper is using the HCR_EL2.VSE (HCR.VA for aarch32) bit to
route such aborts back to the guest. If the guest PC had been
advanced by SVC/HVC/SMC instructions before we caught the SError
in hypervisor, we have to adjust the guest PC to exact address
while the SError generated.

About HSR_EC_SVC32/64, even thought we don't trap SVC32/64 today,
we would like them to be handled here. This would be useful when
VM introspection will gain support of SVC32/64 trapping.

This helper will be used by the later patches in this series, we
use #if 0 to disable it in this patch temporarily to remove the
warning message of unused function from compiler.

Signed-off-by: Wei Chen 
Acked-by: Stefano Stabellini 
---
v1->v2:
1. After updating HCR_EL2.VSE bit of vCPU HCR_EL2, write the value
   to HCR_EL2 immediately. In this case we don't need to move the
   restoration of HCR_EL2 to leave_hypervisor_tail, and it worked
   regardless of whether we get preempted.
2. Add Stefano's Acked-by.
---
 xen/arch/arm/traps.c| 33 +
 xen/include/asm-arm/processor.h |  1 +
 2 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 7762d18..7850115 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -599,6 +599,39 @@ static void inject_dabt_exception(struct cpu_user_regs 
*regs,
 #endif
 }
 
+#if 0
+/* Inject a virtual Abort/SError into the guest. */
+static void inject_vabt_exception(struct cpu_user_regs *regs)
+{
+const union hsr hsr = { .bits = regs->hsr };
+
+/*
+ * SVC/HVC/SMC already have an adjusted PC (See ARM ARM DDI 0487A.j
+ * D1.10.1 for more details), which we need to correct in order to
+ * return to after having injected the SError.
+ */
+switch ( hsr.ec )
+{
+case HSR_EC_SVC32:
+case HSR_EC_HVC32:
+case HSR_EC_SMC32:
+#ifdef CONFIG_ARM_64
+case HSR_EC_SVC64:
+case HSR_EC_HVC64:
+case HSR_EC_SMC64:
+#endif
+regs->pc -= hsr.len ? 4 : 2;
+break;
+
+default:
+break;
+}
+
+current->arch.hcr_el2 |= HCR_VA;
+WRITE_SYSREG(current->arch.hcr_el2, HCR_EL2);
+}
+#endif
+
 struct reg_ctxt {
 /* Guest-side state */
 uint32_t sctlr_el1;
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index afc0e9a..47e7026 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -252,6 +252,7 @@
 #define HSR_EC_HVC320x12
 #define HSR_EC_SMC320x13
 #ifdef CONFIG_ARM_64
+#define HSR_EC_SVC640x15
 #define HSR_EC_HVC640x16
 #define HSR_EC_SMC640x17
 #define HSR_EC_SYSREG   0x18
-- 
2.7.4


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