xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v8 1/6] monitor: rename and relocate vm_event_monitor_traps
@ 2016-07-05 18:37 Tamas K Lengyel
  2016-07-05 18:37 ` [PATCH v8 2/6] arm: filter SMC exceptions with failed condition checks Tamas K Lengyel
                   ` (5 more replies)
  0 siblings, 6 replies; 24+ messages in thread
From: Tamas K Lengyel @ 2016-07-05 18:37 UTC (permalink / raw)
  To: xen-devel; +Cc: Tamas K Lengyel, Razvan Cojocaru, Jan Beulich, Andrew Cooper

The function vm_event_monitor_traps actually belongs in the monitor subsystem.
As part of this patch we fix the sync input's type to bool_t to match how
the callers use it.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
---
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Razvan Cojocaru <rcojocaru@bitdefender.com>
---
 xen/arch/x86/hvm/monitor.c |  7 ++++---
 xen/common/monitor.c       | 44 +++++++++++++++++++++++++++++++++++++++++++-
 xen/common/vm_event.c      | 45 ---------------------------------------------
 xen/include/xen/monitor.h  |  6 +++++-
 xen/include/xen/vm_event.h |  6 ------
 5 files changed, 52 insertions(+), 56 deletions(-)

diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index bbe5952..fb493bb 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -23,6 +23,7 @@
  */
 
 #include <xen/vm_event.h>
+#include <xen/monitor.h>
 #include <asm/hvm/monitor.h>
 #include <asm/monitor.h>
 #include <asm/vm_event.h>
@@ -48,7 +49,7 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long value, unsigned long old
             .u.write_ctrlreg.old_value = old
         };
 
-        if ( vm_event_monitor_traps(curr, sync, &req) >= 0 )
+        if ( monitor_traps(curr, sync, &req) >= 0 )
             return 1;
     }
 
@@ -68,7 +69,7 @@ void hvm_monitor_msr(unsigned int msr, uint64_t value)
             .u.mov_to_msr.value = value,
         };
 
-        vm_event_monitor_traps(curr, 1, &req);
+        monitor_traps(curr, 1, &req);
     }
 }
 
@@ -131,7 +132,7 @@ int hvm_monitor_debug(unsigned long rip, enum hvm_monitor_debug_type type,
 
     req.vcpu_id = curr->vcpu_id;
 
-    return vm_event_monitor_traps(curr, sync, &req);
+    return monitor_traps(curr, sync, &req);
 }
 
 /*
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index 436214a..5fce61e 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -19,12 +19,15 @@
  * License along with this program; If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <xen/event.h>
 #include <xen/monitor.h>
 #include <xen/sched.h>
 #include <xen/vm_event.h>
 #include <xsm/xsm.h>
 #include <public/domctl.h>
+#include <asm/altp2m.h>
 #include <asm/monitor.h>
+#include <asm/vm_event.h>
 
 int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
 {
@@ -85,6 +88,45 @@ int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
     return 0;
 }
 
+int monitor_traps(struct vcpu *v, bool_t sync, vm_event_request_t *req)
+{
+    int rc;
+    struct domain *d = v->domain;
+
+    rc = vm_event_claim_slot(d, &d->vm_event->monitor);
+    switch ( rc )
+    {
+    case 0:
+        break;
+    case -ENOSYS:
+        /*
+         * If there was no ring to handle the event, then
+         * simply continue executing normally.
+         */
+        return 0;
+    default:
+        return rc;
+    };
+
+    if ( sync )
+    {
+        req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
+        vm_event_vcpu_pause(v);
+        rc = 1;
+    }
+
+    if ( altp2m_active(d) )
+    {
+        req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
+        req->altp2m_idx = altp2m_vcpu_idx(v);
+    }
+
+    vm_event_fill_regs(req);
+    vm_event_put_request(d, &d->vm_event->monitor, req);
+
+    return rc;
+}
+
 void monitor_guest_request(void)
 {
     struct vcpu *curr = current;
@@ -97,7 +139,7 @@ void monitor_guest_request(void)
             .vcpu_id = curr->vcpu_id,
         };
 
-        vm_event_monitor_traps(curr, d->monitor.guest_request_sync, &req);
+        monitor_traps(curr, d->monitor.guest_request_sync, &req);
     }
 }
 
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 17d2716..22bbfc1 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -26,7 +26,6 @@
 #include <xen/vm_event.h>
 #include <xen/mem_access.h>
 #include <asm/p2m.h>
-#include <asm/altp2m.h>
 #include <asm/monitor.h>
 #include <asm/vm_event.h>
 #include <xsm/xsm.h>
@@ -789,50 +788,6 @@ void vm_event_vcpu_unpause(struct vcpu *v)
 }
 
 /*
- * Monitor vm-events
- */
-
-int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
-                           vm_event_request_t *req)
-{
-    int rc;
-    struct domain *d = v->domain;
-
-    rc = vm_event_claim_slot(d, &d->vm_event->monitor);
-    switch ( rc )
-    {
-    case 0:
-        break;
-    case -ENOSYS:
-        /*
-         * If there was no ring to handle the event, then
-         * simply continue executing normally.
-         */
-        return 0;
-    default:
-        return rc;
-    };
-
-    if ( sync )
-    {
-        req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
-        vm_event_vcpu_pause(v);
-        rc = 1;
-    }
-
-    if ( altp2m_active(d) )
-    {
-        req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
-        req->altp2m_idx = altp2m_vcpu_idx(v);
-    }
-
-    vm_event_fill_regs(req);
-    vm_event_put_request(d, &d->vm_event->monitor, req);
-
-    return rc;
-}
-
-/*
  * Local variables:
  * mode: C
  * c-file-style: "BSD"
diff --git a/xen/include/xen/monitor.h b/xen/include/xen/monitor.h
index 204d5cc..2171d04 100644
--- a/xen/include/xen/monitor.h
+++ b/xen/include/xen/monitor.h
@@ -3,7 +3,7 @@
  *
  * Common monitor_op domctl handler.
  *
- * Copyright (c) 2015 Tamas K Lengyel (tamas@tklengyel.com)
+ * Copyright (c) 2015-2016 Tamas K Lengyel (tamas@tklengyel.com)
  * Copyright (c) 2016, Bitdefender S.R.L.
  *
  * This program is free software; you can redistribute it and/or
@@ -22,10 +22,14 @@
 #ifndef __XEN_MONITOR_H__
 #define __XEN_MONITOR_H__
 
+#include <public/vm_event.h>
+
 struct domain;
 struct xen_domctl_monitor_op;
 
 int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *op);
 void monitor_guest_request(void);
 
+int monitor_traps(struct vcpu *v, bool_t sync, vm_event_request_t *req);
+
 #endif /* __XEN_MONITOR_H__ */
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index 89e6243..42bd9f6 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -75,12 +75,6 @@ int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *vec,
 void vm_event_vcpu_pause(struct vcpu *v);
 void vm_event_vcpu_unpause(struct vcpu *v);
 
-/*
- * Monitor vm-events
- */
-int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
-                           vm_event_request_t *req);
-
 #endif /* __VM_EVENT_H__ */
 
 
-- 
2.8.1


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

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* [PATCH v8 2/6] arm: filter SMC exceptions with failed condition checks
  2016-07-05 18:37 [PATCH v8 1/6] monitor: rename and relocate vm_event_monitor_traps Tamas K Lengyel
@ 2016-07-05 18:37 ` Tamas K Lengyel
  2016-07-06 17:31   ` Julien Grall
  2016-07-05 18:37 ` [PATCH v8 3/6] monitor: ARM SMC events Tamas K Lengyel
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 24+ messages in thread
From: Tamas K Lengyel @ 2016-07-05 18:37 UTC (permalink / raw)
  To: xen-devel; +Cc: Tamas K Lengyel, Julien Grall, Stefano Stabellini

In AArch32 state, the ARMv8-A architecture permits, but does not require,
this trap to apply to conditional SMC instructions that fail their condition
code check, in the same way as with traps on other conditional instructions.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
Suggested-by: Julien Grall <julien.grall@arm.com>
---
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Julien Grall <julien.grall@arm.com>
---
 xen/arch/arm/traps.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 44926ca..627e8c9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2507,6 +2507,17 @@ bad_data_abort:
     inject_dabt_exception(regs, info.gva, hsr.len);
 }
 
+static void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
+{
+    if ( !check_conditional_instr(regs, hsr) )
+    {
+        advance_pc(regs, hsr);
+        return;
+    }
+
+    inject_undef_exception(regs, hsr);
+}
+
 static void enter_hypervisor_head(struct cpu_user_regs *regs)
 {
     if ( guest_mode(regs) )
@@ -2582,7 +2593,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
          */
         GUEST_BUG_ON(!psr_mode_is_32bit(regs->cpsr));
         perfc_incr(trap_smc32);
-        inject_undef32_exception(regs);
+        do_trap_smc(regs, hsr);
         break;
     case HSR_EC_HVC32:
         GUEST_BUG_ON(!psr_mode_is_32bit(regs->cpsr));
@@ -2615,7 +2626,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
          */
         GUEST_BUG_ON(psr_mode_is_32bit(regs->cpsr));
         perfc_incr(trap_smc64);
-        inject_undef64_exception(regs, hsr.len);
+        do_trap_smc(regs, hsr);
         break;
     case HSR_EC_SYSREG:
         GUEST_BUG_ON(psr_mode_is_32bit(regs->cpsr));
-- 
2.8.1


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

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* [PATCH v8 3/6] monitor: ARM SMC events
  2016-07-05 18:37 [PATCH v8 1/6] monitor: rename and relocate vm_event_monitor_traps Tamas K Lengyel
  2016-07-05 18:37 ` [PATCH v8 2/6] arm: filter SMC exceptions with failed condition checks Tamas K Lengyel
@ 2016-07-05 18:37 ` Tamas K Lengyel
  2016-07-05 18:37 ` [PATCH v8 4/6] arm/vm_event: get/set registers Tamas K Lengyel
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 24+ messages in thread
From: Tamas K Lengyel @ 2016-07-05 18:37 UTC (permalink / raw)
  To: xen-devel; +Cc: Tamas K Lengyel, Julien Grall, Stefano Stabellini

Add support for monitoring ARM SMC events. This patch only adds the required
bits to enable/disable monitoring and forwarding the event through vm_event.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
---
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Julien Grall <julien.grall@arm.com>
---
 xen/arch/arm/Makefile         |  1 +
 xen/arch/arm/monitor.c        | 82 +++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/traps.c          |  9 ++++-
 xen/include/asm-arm/domain.h  |  5 +++
 xen/include/asm-arm/monitor.h | 22 +++---------
 xen/include/public/domctl.h   |  1 +
 xen/include/public/vm_event.h | 10 ++++++
 7 files changed, 112 insertions(+), 18 deletions(-)
 create mode 100644 xen/arch/arm/monitor.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9e38da3..ffb0e96 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -41,6 +41,7 @@ obj-y += decode.o
 obj-y += processor.o
 obj-y += smc.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
+obj-y += monitor.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/monitor.c b/xen/arch/arm/monitor.c
new file mode 100644
index 0000000..d609f4f
--- /dev/null
+++ b/xen/arch/arm/monitor.c
@@ -0,0 +1,82 @@
+/*
+ * arch/arm/monitor.c
+ *
+ * Arch-specific monitor_op domctl handler.
+ *
+ * Copyright (c) 2016 Tamas K Lengyel (tamas.lengyel@zentific.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <asm/monitor.h>
+#include <xen/monitor.h>
+
+int arch_monitor_domctl_event(struct domain *d,
+                              struct xen_domctl_monitor_op *mop)
+{
+    struct arch_domain *ad = &d->arch;
+    bool_t requested_status = (XEN_DOMCTL_MONITOR_OP_ENABLE == mop->op);
+
+    switch ( mop->event )
+    {
+    case XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL:
+    {
+        bool_t old_status = ad->monitor.privileged_call_enabled;
+
+        if ( unlikely(old_status == requested_status) )
+            return -EEXIST;
+
+        domain_pause(d);
+        ad->monitor.privileged_call_enabled = requested_status;
+        domain_unpause(d);
+        break;
+    }
+
+    default:
+        /*
+         * Should not be reached unless arch_monitor_get_capabilities() is
+         * not properly implemented.
+         */
+        ASSERT_UNREACHABLE();
+        return -EOPNOTSUPP;
+    }
+
+    return 0;
+}
+
+int monitor_smc()
+{
+    struct vcpu *curr = current;
+
+    if ( curr->domain->arch.monitor.privileged_call_enabled )
+    {
+        vm_event_request_t req = { 0 };
+
+        req.reason = VM_EVENT_REASON_PRIVILEGED_CALL;
+        req.vcpu_id = curr->vcpu_id;
+        req.u.privcall.type = PRIVCALL_SMC;
+
+        return monitor_traps(curr, 1, &req);
+    }
+
+    return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 627e8c9..846ba26 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -42,6 +42,7 @@
 #include <asm/mmio.h>
 #include <asm/cpufeature.h>
 #include <asm/flushtlb.h>
+#include <asm/monitor.h>
 
 #include "decode.h"
 #include "vtimer.h"
@@ -2509,13 +2510,19 @@ bad_data_abort:
 
 static void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
 {
+    int rc;
+
     if ( !check_conditional_instr(regs, hsr) )
     {
         advance_pc(regs, hsr);
         return;
     }
 
-    inject_undef_exception(regs, hsr);
+    rc = monitor_smc();
+    if ( rc < 0 )
+        domain_crash_synchronous();
+    if ( !rc )
+        inject_undef_exception(regs, hsr);
 }
 
 static void enter_hypervisor_head(struct cpu_user_regs *regs)
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 979f7de..a97bee7 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -127,6 +127,11 @@ struct arch_domain
     paddr_t efi_acpi_gpa;
     paddr_t efi_acpi_len;
 #endif
+
+    /* Monitor options */
+    struct {
+        uint8_t privileged_call_enabled : 1;
+    } monitor;
 }  __cacheline_aligned;
 
 struct arch_vcpu
diff --git a/xen/include/asm-arm/monitor.h b/xen/include/asm-arm/monitor.h
index 4af707a..dcb0c5d 100644
--- a/xen/include/asm-arm/monitor.h
+++ b/xen/include/asm-arm/monitor.h
@@ -32,19 +32,8 @@ int arch_monitor_domctl_op(struct domain *d, struct xen_domctl_monitor_op *mop)
     return -EOPNOTSUPP;
 }
 
-static inline
 int arch_monitor_domctl_event(struct domain *d,
-                              struct xen_domctl_monitor_op *mop)
-{
-    /*
-     * No arch-specific monitor vm-events on ARM.
-     *
-     * Should not be reached unless arch_monitor_get_capabilities() is not
-     * properly implemented.
-     */
-    ASSERT_UNREACHABLE();
-    return -EOPNOTSUPP;
-}
+                              struct xen_domctl_monitor_op *mop);
 
 static inline
 int arch_monitor_init_domain(struct domain *d)
@@ -61,11 +50,10 @@ void arch_monitor_cleanup_domain(struct domain *d)
 
 static inline uint32_t arch_monitor_get_capabilities(struct domain *d)
 {
-    uint32_t capabilities = 0;
-
-    capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
-
-    return capabilities;
+    return (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
+           (1U << XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL);
 }
 
+int monitor_smc(void);
+
 #endif /* __ASM_ARM_MONITOR_H__ */
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 30020ba..8503291 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1081,6 +1081,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cmt_op_t);
 #define XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT   3
 #define XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST         4
 #define XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION       5
+#define XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL       6
 
 struct xen_domctl_monitor_op {
     uint32_t op; /* XEN_DOMCTL_MONITOR_OP_* */
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index 7bfe6cc..66e27b7 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -122,6 +122,8 @@
 #define VM_EVENT_REASON_GUEST_REQUEST           8
 /* A debug exception was caught */
 #define VM_EVENT_REASON_DEBUG_EXCEPTION         9
+/* Privileged call executed (e.g. SMC) */
+#define VM_EVENT_REASON_PRIVILEGED_CALL         10
 
 /* Supported values for the vm_event_write_ctrlreg index. */
 #define VM_EVENT_X86_CR0    0
@@ -222,6 +224,13 @@ struct vm_event_mov_to_msr {
     uint64_t value;
 };
 
+#define PRIVCALL_SMC    0
+
+struct vm_event_privcall {
+    uint32_t type; /* PRIVCALL_* */
+    uint32_t _pad;
+};
+
 #define MEM_PAGING_DROP_PAGE       (1 << 0)
 #define MEM_PAGING_EVICT_FAIL      (1 << 1)
 
@@ -260,6 +269,7 @@ typedef struct vm_event_st {
         struct vm_event_singlestep            singlestep;
         struct vm_event_debug                 software_breakpoint;
         struct vm_event_debug                 debug_exception;
+        struct vm_event_privcall              privcall;
     } u;
 
     union {
-- 
2.8.1


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

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* [PATCH v8 4/6] arm/vm_event: get/set registers
  2016-07-05 18:37 [PATCH v8 1/6] monitor: rename and relocate vm_event_monitor_traps Tamas K Lengyel
  2016-07-05 18:37 ` [PATCH v8 2/6] arm: filter SMC exceptions with failed condition checks Tamas K Lengyel
  2016-07-05 18:37 ` [PATCH v8 3/6] monitor: ARM SMC events Tamas K Lengyel
@ 2016-07-05 18:37 ` Tamas K Lengyel
  2016-07-06  7:43   ` Jan Beulich
  2016-07-06 18:04   ` Julien Grall
  2016-07-05 18:37 ` [PATCH v8 5/6] tools/libxc: add xc_monitor_privileged_call Tamas K Lengyel
                   ` (2 subsequent siblings)
  5 siblings, 2 replies; 24+ messages in thread
From: Tamas K Lengyel @ 2016-07-05 18:37 UTC (permalink / raw)
  To: xen-devel; +Cc: Tamas K Lengyel, Julien Grall, Stefano Stabellini

Add support for getting/setting registers through vm_event on ARM.
The set of registers can be expanded in the future to include other registers
as well if required. The set is limited to the GPRs, PC, CPSR and TTBR0/1 in
this patch.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
---
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Julien Grall <julien.grall@arm.com>
---
 xen/arch/arm/Makefile          |   1 +
 xen/arch/arm/vm_event.c        | 163 +++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/vm_event.h |  11 ---
 xen/include/asm-x86/vm_event.h |   4 -
 xen/include/public/vm_event.h  |  76 ++++++++++++++++++-
 xen/include/xen/vm_event.h     |   3 +
 6 files changed, 240 insertions(+), 18 deletions(-)
 create mode 100644 xen/arch/arm/vm_event.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index ffb0e96..82ac34c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -42,6 +42,7 @@ obj-y += processor.o
 obj-y += smc.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
 obj-y += monitor.o
+obj-y += vm_event.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/vm_event.c b/xen/arch/arm/vm_event.c
new file mode 100644
index 0000000..0e59fae
--- /dev/null
+++ b/xen/arch/arm/vm_event.c
@@ -0,0 +1,163 @@
+/*
+ * arch/arm/vm_event.c
+ *
+ * Architecture-specific vm_event handling routines
+ *
+ * Copyright (c) 2016 Tamas K Lengyel (tamas@tklengyel.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <xen/sched.h>
+#include <asm/vm_event.h>
+
+void vm_event_fill_regs(vm_event_request_t *req)
+{
+    const struct cpu_user_regs *regs = guest_cpu_user_regs();
+
+    req->data.regs.arm.cpsr = regs->cpsr;
+    req->data.regs.arm.ttbr0 = READ_SYSREG64(TTBR0_EL1);
+    req->data.regs.arm.ttbr1 = READ_SYSREG64(TTBR1_EL1);
+
+    if ( psr_mode_is_32bit(regs->cpsr) )
+    {
+        req->data.regs.arm.arch.arm32.r0 = regs->r0;
+        req->data.regs.arm.arch.arm32.r1 = regs->r1;
+        req->data.regs.arm.arch.arm32.r2 = regs->r2;
+        req->data.regs.arm.arch.arm32.r3 = regs->r3;
+        req->data.regs.arm.arch.arm32.r4 = regs->r4;
+        req->data.regs.arm.arch.arm32.r5 = regs->r5;
+        req->data.regs.arm.arch.arm32.r6 = regs->r6;
+        req->data.regs.arm.arch.arm32.r7 = regs->r7;
+        req->data.regs.arm.arch.arm32.r8 = regs->r8;
+        req->data.regs.arm.arch.arm32.r9 = regs->r9;
+        req->data.regs.arm.arch.arm32.r10 = regs->r10;
+        req->data.regs.arm.arch.arm32.r11 = regs->fp;
+        req->data.regs.arm.arch.arm32.r12 = regs->r12;
+        req->data.regs.arm.arch.arm32.r13 = regs->sp;
+        req->data.regs.arm.arch.arm32.r14 = regs->lr;
+        req->data.regs.arm.arch.arm32.pc = regs->pc32;
+    }
+#ifdef CONFIG_ARM_64
+    else
+    {
+        req->data.regs.arm.arch.arm64.x0 = regs->x0;
+        req->data.regs.arm.arch.arm64.x1 = regs->x1;
+        req->data.regs.arm.arch.arm64.x2 = regs->x2;
+        req->data.regs.arm.arch.arm64.x3 = regs->x3;
+        req->data.regs.arm.arch.arm64.x4 = regs->x4;
+        req->data.regs.arm.arch.arm64.x5 = regs->x5;
+        req->data.regs.arm.arch.arm64.x6 = regs->x6;
+        req->data.regs.arm.arch.arm64.x7 = regs->x7;
+        req->data.regs.arm.arch.arm64.x8 = regs->x8;
+        req->data.regs.arm.arch.arm64.x9 = regs->x9;
+        req->data.regs.arm.arch.arm64.x10 = regs->x10;
+        req->data.regs.arm.arch.arm64.x11 = regs->x11;
+        req->data.regs.arm.arch.arm64.x12 = regs->x12;
+        req->data.regs.arm.arch.arm64.x13 = regs->x13;
+        req->data.regs.arm.arch.arm64.x14 = regs->x14;
+        req->data.regs.arm.arch.arm64.x15 = regs->x15;
+        req->data.regs.arm.arch.arm64.x16 = regs->x16;
+        req->data.regs.arm.arch.arm64.x17 = regs->x17;
+        req->data.regs.arm.arch.arm64.x18 = regs->x18;
+        req->data.regs.arm.arch.arm64.x19 = regs->x19;
+        req->data.regs.arm.arch.arm64.x20 = regs->x20;
+        req->data.regs.arm.arch.arm64.x21 = regs->x21;
+        req->data.regs.arm.arch.arm64.x22 = regs->x22;
+        req->data.regs.arm.arch.arm64.x23 = regs->x23;
+        req->data.regs.arm.arch.arm64.x24 = regs->x24;
+        req->data.regs.arm.arch.arm64.x25 = regs->x25;
+        req->data.regs.arm.arch.arm64.x26 = regs->x26;
+        req->data.regs.arm.arch.arm64.x27 = regs->x27;
+        req->data.regs.arm.arch.arm64.x28 = regs->x28;
+        req->data.regs.arm.arch.arm64.x29 = regs->fp;
+        req->data.regs.arm.arch.arm64.x30 = regs->lr;
+        req->data.regs.arm.arch.arm64.pc = regs->pc;
+    }
+#endif
+}
+
+void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp)
+{
+    struct cpu_user_regs *regs = &v->arch.cpu_info->guest_cpu_user_regs;
+
+    regs->cpsr = rsp->data.regs.arm.cpsr;
+    v->arch.ttbr0 = rsp->data.regs.arm.ttbr0;
+    v->arch.ttbr1 = rsp->data.regs.arm.ttbr1;
+
+    if ( psr_mode_is_32bit(regs->cpsr) )
+    {
+        regs->r0 = rsp->data.regs.arm.arch.arm32.r0;
+        regs->r1 = rsp->data.regs.arm.arch.arm32.r1;
+        regs->r2 = rsp->data.regs.arm.arch.arm32.r2;
+        regs->r3 = rsp->data.regs.arm.arch.arm32.r3;
+        regs->r4 = rsp->data.regs.arm.arch.arm32.r4;
+        regs->r5 = rsp->data.regs.arm.arch.arm32.r5;
+        regs->r6 = rsp->data.regs.arm.arch.arm32.r6;
+        regs->r7 = rsp->data.regs.arm.arch.arm32.r7;
+        regs->r8 = rsp->data.regs.arm.arch.arm32.r8;
+        regs->r9 = rsp->data.regs.arm.arch.arm32.r9;
+        regs->r10 = rsp->data.regs.arm.arch.arm32.r10;
+        regs->fp = rsp->data.regs.arm.arch.arm32.r11;
+        regs->r12 = rsp->data.regs.arm.arch.arm32.r12;
+        regs->sp = rsp->data.regs.arm.arch.arm32.r13;
+        regs->lr = rsp->data.regs.arm.arch.arm32.r14;
+        regs->pc32 = rsp->data.regs.arm.arch.arm32.pc;
+    }
+#ifdef CONFIG_ARM_64
+    else
+    {
+        regs->x0 = rsp->data.regs.arm.arch.arm64.x0;
+        regs->x1 = rsp->data.regs.arm.arch.arm64.x1;
+        regs->x2 = rsp->data.regs.arm.arch.arm64.x2;
+        regs->x3 = rsp->data.regs.arm.arch.arm64.x3;
+        regs->x4 = rsp->data.regs.arm.arch.arm64.x4;
+        regs->x5 = rsp->data.regs.arm.arch.arm64.x5;
+        regs->x6 = rsp->data.regs.arm.arch.arm64.x6;
+        regs->x7 = rsp->data.regs.arm.arch.arm64.x7;
+        regs->x8 = rsp->data.regs.arm.arch.arm64.x8;
+        regs->x9 = rsp->data.regs.arm.arch.arm64.x9;
+        regs->x10 = rsp->data.regs.arm.arch.arm64.x10;
+        regs->x11 = rsp->data.regs.arm.arch.arm64.x11;
+        regs->x12 = rsp->data.regs.arm.arch.arm64.x12;
+        regs->x13 = rsp->data.regs.arm.arch.arm64.x13;
+        regs->x14 = rsp->data.regs.arm.arch.arm64.x14;
+        regs->x15 = rsp->data.regs.arm.arch.arm64.x15;
+        regs->x16 = rsp->data.regs.arm.arch.arm64.x16;
+        regs->x17 = rsp->data.regs.arm.arch.arm64.x17;
+        regs->x18 = rsp->data.regs.arm.arch.arm64.x18;
+        regs->x19 = rsp->data.regs.arm.arch.arm64.x19;
+        regs->x20 = rsp->data.regs.arm.arch.arm64.x20;
+        regs->x21 = rsp->data.regs.arm.arch.arm64.x21;
+        regs->x22 = rsp->data.regs.arm.arch.arm64.x22;
+        regs->x23 = rsp->data.regs.arm.arch.arm64.x23;
+        regs->x24 = rsp->data.regs.arm.arch.arm64.x24;
+        regs->x25 = rsp->data.regs.arm.arch.arm64.x25;
+        regs->x26 = rsp->data.regs.arm.arch.arm64.x26;
+        regs->x27 = rsp->data.regs.arm.arch.arm64.x27;
+        regs->x28 = rsp->data.regs.arm.arch.arm64.x28;
+        regs->fp = rsp->data.regs.arm.arch.arm64.x29;
+        regs->lr = rsp->data.regs.arm.arch.arm64.x30;
+        regs->pc = rsp->data.regs.arm.arch.arm64.pc;
+    }
+#endif
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index a3fc4ce..a4922b3 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -48,15 +48,4 @@ void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t *rsp)
     /* Not supported on ARM. */
 }
 
-static inline
-void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp)
-{
-    /* Not supported on ARM. */
-}
-
-static inline void vm_event_fill_regs(vm_event_request_t *req)
-{
-    /* Not supported on ARM. */
-}
-
 #endif /* __ASM_ARM_VM_EVENT_H__ */
diff --git a/xen/include/asm-x86/vm_event.h b/xen/include/asm-x86/vm_event.h
index 026f42e..cf2077c 100644
--- a/xen/include/asm-x86/vm_event.h
+++ b/xen/include/asm-x86/vm_event.h
@@ -40,8 +40,4 @@ void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v);
 
 void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t *rsp);
 
-void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp);
-
-void vm_event_fill_regs(vm_event_request_t *req);
-
 #endif /* __ASM_X86_VM_EVENT_H__ */
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index 66e27b7..d3b0c4d 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -132,8 +132,8 @@
 #define VM_EVENT_X86_XCR0   3
 
 /*
- * Using a custom struct (not hvm_hw_cpu) so as to not fill
- * the vm_event ring buffer too quickly.
+ * Using custom vCPU structs (i.e. not hvm_hw_cpu) for both x86 and ARM
+ * so as to not fill the vm_event ring buffer too quickly.
  */
 struct vm_event_regs_x86 {
     uint64_t rax;
@@ -171,6 +171,71 @@ struct vm_event_regs_x86 {
     uint32_t _pad;
 };
 
+struct vm_event_regs_arm32 {
+    uint32_t r0;
+    uint32_t r1;
+    uint32_t r2;
+    uint32_t r3;
+    uint32_t r4;
+    uint32_t r5;
+    uint32_t r6;
+    uint32_t r7;
+    uint32_t r8;
+    uint32_t r9;
+    uint32_t r10;
+    uint32_t r11;
+    uint32_t r12;
+    uint32_t r13;
+    uint32_t r14;
+    uint32_t pc;
+};
+
+struct vm_event_regs_arm64 {
+    uint64_t x0;
+    uint64_t x1;
+    uint64_t x2;
+    uint64_t x3;
+    uint64_t x4;
+    uint64_t x5;
+    uint64_t x6;
+    uint64_t x7;
+    uint64_t x8;
+    uint64_t x9;
+    uint64_t x10;
+    uint64_t x11;
+    uint64_t x12;
+    uint64_t x13;
+    uint64_t x14;
+    uint64_t x15;
+    uint64_t x16;
+    uint64_t x17;
+    uint64_t x18;
+    uint64_t x19;
+    uint64_t x20;
+    uint64_t x21;
+    uint64_t x22;
+    uint64_t x23;
+    uint64_t x24;
+    uint64_t x25;
+    uint64_t x26;
+    uint64_t x27;
+    uint64_t x28;
+    uint64_t x29;
+    uint64_t x30;
+    uint64_t pc;
+};
+
+struct vm_event_regs_arm {
+    uint32_t cpsr; /* PSR_MODE_BIT is set iff arm32 is used below */
+    uint32_t _pad;
+    uint64_t ttbr0;
+    uint64_t ttbr1;
+    union {
+        struct vm_event_regs_arm32 arm32;
+        struct vm_event_regs_arm64 arm64;
+    } arch;
+};
+
 /*
  * mem_access flag definitions
  *
@@ -246,10 +311,14 @@ struct vm_event_sharing {
     uint32_t _pad;
 };
 
+#define VM_EVENT_MAX_DATA_SIZE \
+    (sizeof(struct vm_event_regs_x86) > sizeof(struct vm_event_regs_arm) ? \
+        sizeof(struct vm_event_regs_x86) : sizeof(struct vm_event_regs_arm))
+
 struct vm_event_emul_read_data {
     uint32_t size;
     /* The struct is used in a union with vm_event_regs_x86. */
-    uint8_t  data[sizeof(struct vm_event_regs_x86) - sizeof(uint32_t)];
+    uint8_t  data[VM_EVENT_MAX_DATA_SIZE - sizeof(uint32_t)];
 };
 
 typedef struct vm_event_st {
@@ -275,6 +344,7 @@ typedef struct vm_event_st {
     union {
         union {
             struct vm_event_regs_x86 x86;
+            struct vm_event_regs_arm arm;
         } regs;
 
         struct vm_event_emul_read_data emul_read_data;
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index 42bd9f6..95420f8 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -75,6 +75,9 @@ int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *vec,
 void vm_event_vcpu_pause(struct vcpu *v);
 void vm_event_vcpu_unpause(struct vcpu *v);
 
+void vm_event_fill_regs(vm_event_request_t *req);
+void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp);
+
 #endif /* __VM_EVENT_H__ */
 
 
-- 
2.8.1


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

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* [PATCH v8 5/6] tools/libxc: add xc_monitor_privileged_call
  2016-07-05 18:37 [PATCH v8 1/6] monitor: rename and relocate vm_event_monitor_traps Tamas K Lengyel
                   ` (2 preceding siblings ...)
  2016-07-05 18:37 ` [PATCH v8 4/6] arm/vm_event: get/set registers Tamas K Lengyel
@ 2016-07-05 18:37 ` Tamas K Lengyel
  2016-07-05 18:37 ` [PATCH v8 6/6] tools/xen-access: add test-case for ARM SMC Tamas K Lengyel
  2016-07-05 19:15 ` [PATCH v8 1/6] monitor: rename and relocate vm_event_monitor_traps Razvan Cojocaru
  5 siblings, 0 replies; 24+ messages in thread
From: Tamas K Lengyel @ 2016-07-05 18:37 UTC (permalink / raw)
  To: xen-devel; +Cc: Tamas K Lengyel, Ian Jackson

These are the user-space components for the new ARM SMC events.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxc/include/xenctrl.h |  3 +++
 tools/libxc/xc_monitor.c      | 14 ++++++++++++++
 2 files changed, 17 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 4a85b4a..5249d06 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2167,6 +2167,9 @@ int xc_monitor_guest_request(xc_interface *xch, domid_t domain_id,
                              bool enable, bool sync);
 int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
                                 bool enable, bool sync);
+int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
+                               bool enable);
+
 /**
  * This function enables / disables emulation for each REP for a
  * REP-compatible instruction.
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 264992c..61da88d 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -172,6 +172,20 @@ int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
     return do_domctl(xch, &domctl);
 }
 
+int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
+                               bool enable)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_monitor_op;
+    domctl.domain = domain_id;
+    domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+                                    : XEN_DOMCTL_MONITOR_OP_DISABLE;
+    domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL;
+
+    return do_domctl(xch, &domctl);
+}
+
 /*
  * Local variables:
  * mode: C
-- 
2.8.1


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

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* [PATCH v8 6/6] tools/xen-access: add test-case for ARM SMC
  2016-07-05 18:37 [PATCH v8 1/6] monitor: rename and relocate vm_event_monitor_traps Tamas K Lengyel
                   ` (3 preceding siblings ...)
  2016-07-05 18:37 ` [PATCH v8 5/6] tools/libxc: add xc_monitor_privileged_call Tamas K Lengyel
@ 2016-07-05 18:37 ` Tamas K Lengyel
  2016-07-07 10:05   ` Julien Grall
  2016-07-05 19:15 ` [PATCH v8 1/6] monitor: rename and relocate vm_event_monitor_traps Razvan Cojocaru
  5 siblings, 1 reply; 24+ messages in thread
From: Tamas K Lengyel @ 2016-07-05 18:37 UTC (permalink / raw)
  To: xen-devel; +Cc: Tamas K Lengyel, Ian Jackson

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/tests/xen-access/xen-access.c | 45 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/tools/tests/xen-access/xen-access.c b/tools/tests/xen-access/xen-access.c
index 02655d5..a04dbff 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -338,6 +338,8 @@ void usage(char* progname)
     fprintf(stderr, "Usage: %s [-m] <domain_id> write|exec", progname);
 #if defined(__i386__) || defined(__x86_64__)
             fprintf(stderr, "|breakpoint|altp2m_write|altp2m_exec|debug");
+#elif defined(__arm__) || defined(__aarch64__)
+            fprintf(stderr, "|privcall");
 #endif
             fprintf(stderr,
             "\n"
@@ -426,6 +428,11 @@ int main(int argc, char *argv[])
     {
         debug = 1;
     }
+#elif defined(__arm__) || defined(__aarch64__)
+    else if ( !strcmp(argv[0], "privcall") )
+    {
+        privcall = 1;
+    }
 #endif
     else
     {
@@ -548,6 +555,16 @@ int main(int argc, char *argv[])
         }
     }
 
+    if ( privcall )
+    {
+        rc = xc_monitor_privileged_call(xch, domain_id, 1);
+        if ( rc < 0 )
+        {
+            ERROR("Error %d setting privileged call trapping with vm_event\n", rc);
+            goto exit;
+        }
+    }
+
     /* Wait for access */
     for (;;)
     {
@@ -560,7 +577,8 @@ int main(int argc, char *argv[])
                 rc = xc_monitor_software_breakpoint(xch, domain_id, 0);
             if ( debug )
                 rc = xc_monitor_debug_exceptions(xch, domain_id, 0, 0);
-
+            if ( privcall )
+                rc = xc_monitor_privileged_call(xch, domain_id, 0);
             if ( altp2m )
             {
                 rc = xc_altp2m_switch_to_view( xch, domain_id, 0 );
@@ -716,6 +734,31 @@ int main(int argc, char *argv[])
                 }
 
                 break;
+#if defined(__arm__) || defined(__aarch64__)
+            case VM_EVENT_REASON_PRIVILEGED_CALL:
+                {
+                    const struct vm_event_regs_arm *in_regs = &req.data.regs.arm;
+                    struct vm_event_regs_arm *out_regs = &rsp.data.regs.arm;
+                    bool is32bit = !!(in_regs->cpsr & PSR_MODE_BIT);
+                    uint64_t pc;
+
+                    *out_regs = *in_regs;
+
+                    if ( is32bit ) {
+                        pc = in_regs->arch.arm32.pc;
+                        out_regs->arch.arm32.pc += 4;
+                    } else {
+                        pc = in_regs->arch.arm64.pc;
+                        out_regs->arch.arm64.pc += 8;
+                    }
+
+                    printf("Privileged call: pc=%016"PRIx64" (vcpu %d)\n",
+                           pc, req.vcpu_id);
+
+                    rsp.flags |= VM_EVENT_FLAG_SET_REGISTERS;
+                }
+                break;
+#endif
             default:
                 fprintf(stderr, "UNKNOWN REASON CODE %d\n", req.reason);
             }
-- 
2.8.1


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

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 1/6] monitor: rename and relocate vm_event_monitor_traps
  2016-07-05 18:37 [PATCH v8 1/6] monitor: rename and relocate vm_event_monitor_traps Tamas K Lengyel
                   ` (4 preceding siblings ...)
  2016-07-05 18:37 ` [PATCH v8 6/6] tools/xen-access: add test-case for ARM SMC Tamas K Lengyel
@ 2016-07-05 19:15 ` Razvan Cojocaru
  5 siblings, 0 replies; 24+ messages in thread
From: Razvan Cojocaru @ 2016-07-05 19:15 UTC (permalink / raw)
  To: Tamas K Lengyel, xen-devel; +Cc: Andrew Cooper, Jan Beulich

On 07/05/16 21:37, Tamas K Lengyel wrote:
> The function vm_event_monitor_traps actually belongs in the monitor subsystem.
> As part of this patch we fix the sync input's type to bool_t to match how
> the callers use it.
> 
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
> ---
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: Razvan Cojocaru <rcojocaru@bitdefender.com>
> ---
>  xen/arch/x86/hvm/monitor.c |  7 ++++---
>  xen/common/monitor.c       | 44 +++++++++++++++++++++++++++++++++++++++++++-
>  xen/common/vm_event.c      | 45 ---------------------------------------------
>  xen/include/xen/monitor.h  |  6 +++++-
>  xen/include/xen/vm_event.h |  6 ------
>  5 files changed, 52 insertions(+), 56 deletions(-)

Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>


Thanks,
Razvan

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 4/6] arm/vm_event: get/set registers
  2016-07-05 18:37 ` [PATCH v8 4/6] arm/vm_event: get/set registers Tamas K Lengyel
@ 2016-07-06  7:43   ` Jan Beulich
  2016-07-06  7:59     ` Razvan Cojocaru
                       ` (2 more replies)
  2016-07-06 18:04   ` Julien Grall
  1 sibling, 3 replies; 24+ messages in thread
From: Jan Beulich @ 2016-07-06  7:43 UTC (permalink / raw)
  To: Tamas K Lengyel; +Cc: xen-devel, Julien Grall, Stefano Stabellini

>>> On 05.07.16 at 20:37, <tamas.lengyel@zentific.com> wrote:
> +struct vm_event_regs_arm64 {
> +    uint64_t x0;
> +    uint64_t x1;
> +    uint64_t x2;
> +    uint64_t x3;
> +    uint64_t x4;
> +    uint64_t x5;
> +    uint64_t x6;
> +    uint64_t x7;
> +    uint64_t x8;
> +    uint64_t x9;
> +    uint64_t x10;
> +    uint64_t x11;
> +    uint64_t x12;
> +    uint64_t x13;
> +    uint64_t x14;
> +    uint64_t x15;
> +    uint64_t x16;
> +    uint64_t x17;
> +    uint64_t x18;
> +    uint64_t x19;
> +    uint64_t x20;
> +    uint64_t x21;
> +    uint64_t x22;
> +    uint64_t x23;
> +    uint64_t x24;
> +    uint64_t x25;
> +    uint64_t x26;
> +    uint64_t x27;
> +    uint64_t x28;
> +    uint64_t x29;
> +    uint64_t x30;
> +    uint64_t pc;
> +};

Isn't the stack pointer a fully separate register in aarch64? Not
making available something as essential as that seems wrong to
me.

> @@ -246,10 +311,14 @@ struct vm_event_sharing {
>      uint32_t _pad;
>  };
>  
> +#define VM_EVENT_MAX_DATA_SIZE \
> +    (sizeof(struct vm_event_regs_x86) > sizeof(struct vm_event_regs_arm) ? \
> +        sizeof(struct vm_event_regs_x86) : sizeof(struct vm_event_regs_arm))
> +
>  struct vm_event_emul_read_data {
>      uint32_t size;
>      /* The struct is used in a union with vm_event_regs_x86. */
> -    uint8_t  data[sizeof(struct vm_event_regs_x86) - sizeof(uint32_t)];
> +    uint8_t  data[VM_EVENT_MAX_DATA_SIZE - sizeof(uint32_t)];
>  };

Would there be a problem leaving this alone, i.e. not growing the
current limit? I ask because the way VM_EVENT_MAX_DATA_SIZE gets
established doesn't look very scalable - just think about how that
would look like after half a dozen more architectures got added.

> @@ -275,6 +344,7 @@ typedef struct vm_event_st {
>      union {
>          union {
>              struct vm_event_regs_x86 x86;
> +            struct vm_event_regs_arm arm;
>          } regs;

So the growth in size here then is not really a problem?

Jan


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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 4/6] arm/vm_event: get/set registers
  2016-07-06  7:43   ` Jan Beulich
@ 2016-07-06  7:59     ` Razvan Cojocaru
  2016-07-06 17:39     ` Julien Grall
  2016-07-06 19:23     ` Tamas K Lengyel
  2 siblings, 0 replies; 24+ messages in thread
From: Razvan Cojocaru @ 2016-07-06  7:59 UTC (permalink / raw)
  To: Jan Beulich, Tamas K Lengyel; +Cc: xen-devel, Julien Grall, Stefano Stabellini

On 07/06/16 10:43, Jan Beulich wrote:
>>>> On 05.07.16 at 20:37, <tamas.lengyel@zentific.com> wrote:
>> +struct vm_event_regs_arm64 {
>> +    uint64_t x0;
>> +    uint64_t x1;
>> +    uint64_t x2;
>> +    uint64_t x3;
>> +    uint64_t x4;
>> +    uint64_t x5;
>> +    uint64_t x6;
>> +    uint64_t x7;
>> +    uint64_t x8;
>> +    uint64_t x9;
>> +    uint64_t x10;
>> +    uint64_t x11;
>> +    uint64_t x12;
>> +    uint64_t x13;
>> +    uint64_t x14;
>> +    uint64_t x15;
>> +    uint64_t x16;
>> +    uint64_t x17;
>> +    uint64_t x18;
>> +    uint64_t x19;
>> +    uint64_t x20;
>> +    uint64_t x21;
>> +    uint64_t x22;
>> +    uint64_t x23;
>> +    uint64_t x24;
>> +    uint64_t x25;
>> +    uint64_t x26;
>> +    uint64_t x27;
>> +    uint64_t x28;
>> +    uint64_t x29;
>> +    uint64_t x30;
>> +    uint64_t pc;
>> +};
> 
> Isn't the stack pointer a fully separate register in aarch64? Not
> making available something as essential as that seems wrong to
> me.
> 
>> @@ -246,10 +311,14 @@ struct vm_event_sharing {
>>      uint32_t _pad;
>>  };
>>  
>> +#define VM_EVENT_MAX_DATA_SIZE \
>> +    (sizeof(struct vm_event_regs_x86) > sizeof(struct vm_event_regs_arm) ? \
>> +        sizeof(struct vm_event_regs_x86) : sizeof(struct vm_event_regs_arm))
>> +
>>  struct vm_event_emul_read_data {
>>      uint32_t size;
>>      /* The struct is used in a union with vm_event_regs_x86. */
>> -    uint8_t  data[sizeof(struct vm_event_regs_x86) - sizeof(uint32_t)];
>> +    uint8_t  data[VM_EVENT_MAX_DATA_SIZE - sizeof(uint32_t)];
>>  };
> 
> Would there be a problem leaving this alone, i.e. not growing the
> current limit? I ask because the way VM_EVENT_MAX_DATA_SIZE gets
> established doesn't look very scalable - just think about how that
> would look like after half a dozen more architectures got added.
> 
>> @@ -275,6 +344,7 @@ typedef struct vm_event_st {
>>      union {
>>          union {
>>              struct vm_event_regs_x86 x86;
>> +            struct vm_event_regs_arm arm;
>>          } regs;
> 
> So the growth in size here then is not really a problem?

Should be fine for our purposes.


Thanks,
Razvan

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 2/6] arm: filter SMC exceptions with failed condition checks
  2016-07-05 18:37 ` [PATCH v8 2/6] arm: filter SMC exceptions with failed condition checks Tamas K Lengyel
@ 2016-07-06 17:31   ` Julien Grall
  2016-07-06 18:52     ` Tamas K Lengyel
  0 siblings, 1 reply; 24+ messages in thread
From: Julien Grall @ 2016-07-06 17:31 UTC (permalink / raw)
  To: Tamas K Lengyel, xen-devel; +Cc: Stefano Stabellini

On 05/07/16 19:37, Tamas K Lengyel wrote:
> In AArch32 state, the ARMv8-A architecture permits, but does not require,
> this trap to apply to conditional SMC instructions that fail their condition
> code check, in the same way as with traps on other conditional instructions.

Please add a quote to the spec.

> Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
> Suggested-by: Julien Grall <julien.grall@arm.com>
> ---
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: Julien Grall <julien.grall@arm.com>
> ---
>   xen/arch/arm/traps.c | 15 +++++++++++++--
>   1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 44926ca..627e8c9 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2507,6 +2507,17 @@ bad_data_abort:
>       inject_dabt_exception(regs, info.gva, hsr.len);
>   }
>
> +static void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
> +{
> +    if ( !check_conditional_instr(regs, hsr) )

This function is checking the EC, it considers that EC > 0x10 will be 
unconditional. However, the SMC exception class is 0x13 when taken from 
AArch32 and 0x17 when taken from AArch64.

Furthermore, for ARMv7, the register is Reserved UNK/SBZP (see B3-1431 
in ARM DDI 0406C.c). I.e the software should not rely on the field 
reading as all 0s (see Glossary-2736).

For ARMv8, when the SMC is taken from AArch64 (see D7-1942 in ARM DDI 
0487A.j), the register is RES0 which means the software should not rely 
on the value to always be 0 (see Glossary-5734). When the SMC is taken 
from AArch32, the field CV is only valid if CCKNOWNPASS is 1 (this field 
does not exist for the other exception class).

So this code need more extra care. It would also be nice to have a 
description in the code explaining what's going on.

> +    {
> +        advance_pc(regs, hsr);
> +        return;
> +    }
> +
> +    inject_undef_exception(regs, hsr);
> +}
> +
>   static void enter_hypervisor_head(struct cpu_user_regs *regs)
>   {
>       if ( guest_mode(regs) )
> @@ -2582,7 +2593,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
>            */
>           GUEST_BUG_ON(!psr_mode_is_32bit(regs->cpsr));
>           perfc_incr(trap_smc32);
> -        inject_undef32_exception(regs);
> +        do_trap_smc(regs, hsr);
>           break;
>       case HSR_EC_HVC32:
>           GUEST_BUG_ON(!psr_mode_is_32bit(regs->cpsr));
> @@ -2615,7 +2626,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
>            */
>           GUEST_BUG_ON(psr_mode_is_32bit(regs->cpsr));
>           perfc_incr(trap_smc64);
> -        inject_undef64_exception(regs, hsr.len);
> +        do_trap_smc(regs, hsr);
>           break;
>       case HSR_EC_SYSREG:
>           GUEST_BUG_ON(psr_mode_is_32bit(regs->cpsr));
>

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 4/6] arm/vm_event: get/set registers
  2016-07-06  7:43   ` Jan Beulich
  2016-07-06  7:59     ` Razvan Cojocaru
@ 2016-07-06 17:39     ` Julien Grall
  2016-07-06 19:23     ` Tamas K Lengyel
  2 siblings, 0 replies; 24+ messages in thread
From: Julien Grall @ 2016-07-06 17:39 UTC (permalink / raw)
  To: Jan Beulich, Tamas K Lengyel; +Cc: xen-devel, Stefano Stabellini



On 06/07/16 08:43, Jan Beulich wrote:
>>>> On 05.07.16 at 20:37, <tamas.lengyel@zentific.com> wrote:
>> +struct vm_event_regs_arm64 {
>> +    uint64_t x0;
>> +    uint64_t x1;
>> +    uint64_t x2;
>> +    uint64_t x3;
>> +    uint64_t x4;
>> +    uint64_t x5;
>> +    uint64_t x6;
>> +    uint64_t x7;
>> +    uint64_t x8;
>> +    uint64_t x9;
>> +    uint64_t x10;
>> +    uint64_t x11;
>> +    uint64_t x12;
>> +    uint64_t x13;
>> +    uint64_t x14;
>> +    uint64_t x15;
>> +    uint64_t x16;
>> +    uint64_t x17;
>> +    uint64_t x18;
>> +    uint64_t x19;
>> +    uint64_t x20;
>> +    uint64_t x21;
>> +    uint64_t x22;
>> +    uint64_t x23;
>> +    uint64_t x24;
>> +    uint64_t x25;
>> +    uint64_t x26;
>> +    uint64_t x27;
>> +    uint64_t x28;
>> +    uint64_t x29;
>> +    uint64_t x30;
>> +    uint64_t pc;
>> +};
>
> Isn't the stack pointer a fully separate register in aarch64?

It is. Actually, there are 2 stack pointers (one for the kernel, the 
other for userspace. See sp_el0 and sp_el1.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 4/6] arm/vm_event: get/set registers
  2016-07-05 18:37 ` [PATCH v8 4/6] arm/vm_event: get/set registers Tamas K Lengyel
  2016-07-06  7:43   ` Jan Beulich
@ 2016-07-06 18:04   ` Julien Grall
  2016-07-06 19:12     ` Tamas K Lengyel
  1 sibling, 1 reply; 24+ messages in thread
From: Julien Grall @ 2016-07-06 18:04 UTC (permalink / raw)
  To: Tamas K Lengyel, xen-devel; +Cc: Stefano Stabellini



On 05/07/16 19:37, Tamas K Lengyel wrote:
> +void vm_event_fill_regs(vm_event_request_t *req)
> +{
> +    const struct cpu_user_regs *regs = guest_cpu_user_regs();
> +
> +    req->data.regs.arm.cpsr = regs->cpsr;
> +    req->data.regs.arm.ttbr0 = READ_SYSREG64(TTBR0_EL1);
> +    req->data.regs.arm.ttbr1 = READ_SYSREG64(TTBR1_EL1);
> +
> +    if ( psr_mode_is_32bit(regs->cpsr) )
> +    {
> +        req->data.regs.arm.arch.arm32.r0 = regs->r0;
> +        req->data.regs.arm.arch.arm32.r1 = regs->r1;
> +        req->data.regs.arm.arch.arm32.r2 = regs->r2;
> +        req->data.regs.arm.arch.arm32.r3 = regs->r3;
> +        req->data.regs.arm.arch.arm32.r4 = regs->r4;
> +        req->data.regs.arm.arch.arm32.r5 = regs->r5;
> +        req->data.regs.arm.arch.arm32.r6 = regs->r6;
> +        req->data.regs.arm.arch.arm32.r7 = regs->r7;
> +        req->data.regs.arm.arch.arm32.r8 = regs->r8;
> +        req->data.regs.arm.arch.arm32.r9 = regs->r9;
> +        req->data.regs.arm.arch.arm32.r10 = regs->r10;
> +        req->data.regs.arm.arch.arm32.r11 = regs->fp;
> +        req->data.regs.arm.arch.arm32.r12 = regs->r12;
> +        req->data.regs.arm.arch.arm32.r13 = regs->sp;

Please look at the description of "sp" in cpu_user_regs. You will notice 
this is only valid for the hypervisor.

There are multiple stack pointers for the guest depending on the running 
mode (see B9.2.1 in ARM DDI 0406C.c), so you may want to pass all of them.

> +        req->data.regs.arm.arch.arm32.r14 = regs->lr;

Whilst lr is an union with lr_usr on ARM32 port, for the ARM64 port they 
are distinct (see cpu_users). So you would use the wrong register here.

However, as for sp, there are multiple lr pointers for the guest 
depending on the running mode. So you will pass the wrong lr if the 
guest is running in another mode than user.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 2/6] arm: filter SMC exceptions with failed condition checks
  2016-07-06 17:31   ` Julien Grall
@ 2016-07-06 18:52     ` Tamas K Lengyel
  0 siblings, 0 replies; 24+ messages in thread
From: Tamas K Lengyel @ 2016-07-06 18:52 UTC (permalink / raw)
  To: Julien Grall; +Cc: xen-devel, Stefano Stabellini

On Wed, Jul 6, 2016 at 11:31 AM, Julien Grall <julien.grall@arm.com> wrote:
> On 05/07/16 19:37, Tamas K Lengyel wrote:
>>
>> In AArch32 state, the ARMv8-A architecture permits, but does not require,
>> this trap to apply to conditional SMC instructions that fail their
>> condition
>> code check, in the same way as with traps on other conditional
>> instructions.
>
>
> Please add a quote to the spec.
>
>> Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
>> Suggested-by: Julien Grall <julien.grall@arm.com>
>> ---
>> Cc: Stefano Stabellini <sstabellini@kernel.org>
>> Cc: Julien Grall <julien.grall@arm.com>
>> ---
>>   xen/arch/arm/traps.c | 15 +++++++++++++--
>>   1 file changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>> index 44926ca..627e8c9 100644
>> --- a/xen/arch/arm/traps.c
>> +++ b/xen/arch/arm/traps.c
>> @@ -2507,6 +2507,17 @@ bad_data_abort:
>>       inject_dabt_exception(regs, info.gva, hsr.len);
>>   }
>>
>> +static void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
>> +{
>> +    if ( !check_conditional_instr(regs, hsr) )
>
>
> This function is checking the EC, it considers that EC > 0x10 will be
> unconditional. However, the SMC exception class is 0x13 when taken from
> AArch32 and 0x17 when taken from AArch64.
>
> Furthermore, for ARMv7, the register is Reserved UNK/SBZP (see B3-1431 in
> ARM DDI 0406C.c). I.e the software should not rely on the field reading as
> all 0s (see Glossary-2736).
>
> For ARMv8, when the SMC is taken from AArch64 (see D7-1942 in ARM DDI
> 0487A.j), the register is RES0 which means the software should not rely on
> the value to always be 0 (see Glossary-5734). When the SMC is taken from
> AArch32, the field CV is only valid if CCKNOWNPASS is 1 (this field does not
> exist for the other exception class).
>
> So this code need more extra care. It would also be nice to have a
> description in the code explaining what's going on.

Ack, there seems to be enough corner-cases here that I'm unfamiliar
with that I would rather not attempt implementing this as I likely
would miss something. I'll wait for your patch with the rest of my
series as that route will likely have less overhead anyway.

Thanks,
Tamas

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 4/6] arm/vm_event: get/set registers
  2016-07-06 18:04   ` Julien Grall
@ 2016-07-06 19:12     ` Tamas K Lengyel
  2016-07-07  8:23       ` Jan Beulich
  0 siblings, 1 reply; 24+ messages in thread
From: Tamas K Lengyel @ 2016-07-06 19:12 UTC (permalink / raw)
  To: Julien Grall; +Cc: xen-devel, Stefano Stabellini

On Wed, Jul 6, 2016 at 12:04 PM, Julien Grall <julien.grall@arm.com> wrote:
>
>
> On 05/07/16 19:37, Tamas K Lengyel wrote:
>>
>> +void vm_event_fill_regs(vm_event_request_t *req)
>> +{
>> +    const struct cpu_user_regs *regs = guest_cpu_user_regs();
>> +
>> +    req->data.regs.arm.cpsr = regs->cpsr;
>> +    req->data.regs.arm.ttbr0 = READ_SYSREG64(TTBR0_EL1);
>> +    req->data.regs.arm.ttbr1 = READ_SYSREG64(TTBR1_EL1);
>> +
>> +    if ( psr_mode_is_32bit(regs->cpsr) )
>> +    {
>> +        req->data.regs.arm.arch.arm32.r0 = regs->r0;
>> +        req->data.regs.arm.arch.arm32.r1 = regs->r1;
>> +        req->data.regs.arm.arch.arm32.r2 = regs->r2;
>> +        req->data.regs.arm.arch.arm32.r3 = regs->r3;
>> +        req->data.regs.arm.arch.arm32.r4 = regs->r4;
>> +        req->data.regs.arm.arch.arm32.r5 = regs->r5;
>> +        req->data.regs.arm.arch.arm32.r6 = regs->r6;
>> +        req->data.regs.arm.arch.arm32.r7 = regs->r7;
>> +        req->data.regs.arm.arch.arm32.r8 = regs->r8;
>> +        req->data.regs.arm.arch.arm32.r9 = regs->r9;
>> +        req->data.regs.arm.arch.arm32.r10 = regs->r10;
>> +        req->data.regs.arm.arch.arm32.r11 = regs->fp;
>> +        req->data.regs.arm.arch.arm32.r12 = regs->r12;
>> +        req->data.regs.arm.arch.arm32.r13 = regs->sp;
>
>
> Please look at the description of "sp" in cpu_user_regs. You will notice
> this is only valid for the hypervisor.
>
> There are multiple stack pointers for the guest depending on the running
> mode (see B9.2.1 in ARM DDI 0406C.c), so you may want to pass all of them.
>
>> +        req->data.regs.arm.arch.arm32.r14 = regs->lr;
>
>
> Whilst lr is an union with lr_usr on ARM32 port, for the ARM64 port they are
> distinct (see cpu_users). So you would use the wrong register here.
>
> However, as for sp, there are multiple lr pointers for the guest depending
> on the running mode. So you will pass the wrong lr if the guest is running
> in another mode than user.
>

This patch is becoming a lot more work then what I need it for so I'm
inclined to just reduce it to the bare minimum my use-case requires,
which is only cpsr, pc and ttbr0 and ttbr1. I had reservation about
growing the data field in the vm_event struct anyway, especially since
there is no use-case that requires it. In case someone has an actual
use-case in the future that requires other registers to be submitted
through vm_event, the interface is available for extension.

Thanks,
Tamas

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 4/6] arm/vm_event: get/set registers
  2016-07-06  7:43   ` Jan Beulich
  2016-07-06  7:59     ` Razvan Cojocaru
  2016-07-06 17:39     ` Julien Grall
@ 2016-07-06 19:23     ` Tamas K Lengyel
  2016-07-06 21:12       ` Julien Grall
  2 siblings, 1 reply; 24+ messages in thread
From: Tamas K Lengyel @ 2016-07-06 19:23 UTC (permalink / raw)
  To: Jan Beulich; +Cc: xen-devel, Julien Grall, Stefano Stabellini

On Wed, Jul 6, 2016 at 1:43 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 05.07.16 at 20:37, <tamas.lengyel@zentific.com> wrote:
>> +struct vm_event_regs_arm64 {
>> +    uint64_t x0;
>> +    uint64_t x1;
>> +    uint64_t x2;
>> +    uint64_t x3;
>> +    uint64_t x4;
>> +    uint64_t x5;
>> +    uint64_t x6;
>> +    uint64_t x7;
>> +    uint64_t x8;
>> +    uint64_t x9;
>> +    uint64_t x10;
>> +    uint64_t x11;
>> +    uint64_t x12;
>> +    uint64_t x13;
>> +    uint64_t x14;
>> +    uint64_t x15;
>> +    uint64_t x16;
>> +    uint64_t x17;
>> +    uint64_t x18;
>> +    uint64_t x19;
>> +    uint64_t x20;
>> +    uint64_t x21;
>> +    uint64_t x22;
>> +    uint64_t x23;
>> +    uint64_t x24;
>> +    uint64_t x25;
>> +    uint64_t x26;
>> +    uint64_t x27;
>> +    uint64_t x28;
>> +    uint64_t x29;
>> +    uint64_t x30;
>> +    uint64_t pc;
>> +};
>
> Isn't the stack pointer a fully separate register in aarch64? Not
> making available something as essential as that seems wrong to
> me.
>

The register is available for access already, so unless there is an
actual use-case that requires it to be transmitted through vm_event I
don't see the point for transmitting it. So as I mentioned in my other
response, I'm inclined to reduce this patch to the bare essentials my
use-case requires at this point and leave the extensions up for the
future when - and if - it will be of use. Since this patch is just an
optimization, if transmitting such reduced set is not acceptable for
some reason, I'll forgo this patch entirely.

Thanks,
Tamas

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 4/6] arm/vm_event: get/set registers
  2016-07-06 19:23     ` Tamas K Lengyel
@ 2016-07-06 21:12       ` Julien Grall
  2016-07-06 22:01         ` Tamas K Lengyel
  0 siblings, 1 reply; 24+ messages in thread
From: Julien Grall @ 2016-07-06 21:12 UTC (permalink / raw)
  To: Tamas K Lengyel, Jan Beulich; +Cc: xen-devel, Stefano Stabellini



On 06/07/2016 20:23, Tamas K Lengyel wrote:
> On Wed, Jul 6, 2016 at 1:43 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 05.07.16 at 20:37, <tamas.lengyel@zentific.com> wrote:
>>> +struct vm_event_regs_arm64 {
>>> +    uint64_t x0;
>>> +    uint64_t x1;
>>> +    uint64_t x2;
>>> +    uint64_t x3;
>>> +    uint64_t x4;
>>> +    uint64_t x5;
>>> +    uint64_t x6;
>>> +    uint64_t x7;
>>> +    uint64_t x8;
>>> +    uint64_t x9;
>>> +    uint64_t x10;
>>> +    uint64_t x11;
>>> +    uint64_t x12;
>>> +    uint64_t x13;
>>> +    uint64_t x14;
>>> +    uint64_t x15;
>>> +    uint64_t x16;
>>> +    uint64_t x17;
>>> +    uint64_t x18;
>>> +    uint64_t x19;
>>> +    uint64_t x20;
>>> +    uint64_t x21;
>>> +    uint64_t x22;
>>> +    uint64_t x23;
>>> +    uint64_t x24;
>>> +    uint64_t x25;
>>> +    uint64_t x26;
>>> +    uint64_t x27;
>>> +    uint64_t x28;
>>> +    uint64_t x29;
>>> +    uint64_t x30;
>>> +    uint64_t pc;
>>> +};
>>
>> Isn't the stack pointer a fully separate register in aarch64? Not
>> making available something as essential as that seems wrong to
>> me.
>>
>
> The register is available for access already, so unless there is an
> actual use-case that requires it to be transmitted through vm_event I
> don't see the point for transmitting it. So as I mentioned in my other
> response, I'm inclined to reduce this patch to the bare essentials my
> use-case requires at this point and leave the extensions up for the
> future when - and if - it will be of use. Since this patch is just an
> optimization, if transmitting such reduced set is not acceptable for
> some reason, I'll forgo this patch entirely.

Here we go with again the same argument: "this is not necessary for my 
use-case". This data structure is part of the ABI between the hypervisor 
and the vm-event app, i.e modifying this structure for adding ARM64/ARM 
registers will result to an incompatibility with a previous version of 
the hypervisor. Better to do it now than in a couple of years when 
vm-event will have more users. I agree that it is time consuming to get 
an ABI correct, but it will save users to recompile/ship another version 
of their vm-event app because of this incompatibility.

As mentioned in a previous thread, the main use-case for trapping an SMC 
is emulating the call, hence a vm-event app would want to have access to 
the general-purpose registers. And yes, I know that your use-case is 
different and does not require those registers, I already expressed my 
concerns about it.

Now, if you drop this patch, how will you retrieve the vCPU register? I 
guess via DOMCTL_getvcpucontext? If so, if the vCPU has not been paused, 
you will get a context which is different compare to the time the 
vm-event has occurred. And yes, I know that in your use-case the vCPU is 
paused. This call will always be more expensive than passing the 
registers with event.

Anyway, I really don't think we ask for something really difficult to 
accomplish.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 4/6] arm/vm_event: get/set registers
  2016-07-06 21:12       ` Julien Grall
@ 2016-07-06 22:01         ` Tamas K Lengyel
  0 siblings, 0 replies; 24+ messages in thread
From: Tamas K Lengyel @ 2016-07-06 22:01 UTC (permalink / raw)
  To: Julien Grall; +Cc: xen-devel, Stefano Stabellini, Jan Beulich

On Wed, Jul 6, 2016 at 3:12 PM, Julien Grall <julien.grall@arm.com> wrote:
>
>
> On 06/07/2016 20:23, Tamas K Lengyel wrote:
>>
>> On Wed, Jul 6, 2016 at 1:43 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>
>>>>>> On 05.07.16 at 20:37, <tamas.lengyel@zentific.com> wrote:
>>>>
>>>> +struct vm_event_regs_arm64 {
>>>> +    uint64_t x0;
>>>> +    uint64_t x1;
>>>> +    uint64_t x2;
>>>> +    uint64_t x3;
>>>> +    uint64_t x4;
>>>> +    uint64_t x5;
>>>> +    uint64_t x6;
>>>> +    uint64_t x7;
>>>> +    uint64_t x8;
>>>> +    uint64_t x9;
>>>> +    uint64_t x10;
>>>> +    uint64_t x11;
>>>> +    uint64_t x12;
>>>> +    uint64_t x13;
>>>> +    uint64_t x14;
>>>> +    uint64_t x15;
>>>> +    uint64_t x16;
>>>> +    uint64_t x17;
>>>> +    uint64_t x18;
>>>> +    uint64_t x19;
>>>> +    uint64_t x20;
>>>> +    uint64_t x21;
>>>> +    uint64_t x22;
>>>> +    uint64_t x23;
>>>> +    uint64_t x24;
>>>> +    uint64_t x25;
>>>> +    uint64_t x26;
>>>> +    uint64_t x27;
>>>> +    uint64_t x28;
>>>> +    uint64_t x29;
>>>> +    uint64_t x30;
>>>> +    uint64_t pc;
>>>> +};
>>>
>>>
>>> Isn't the stack pointer a fully separate register in aarch64? Not
>>> making available something as essential as that seems wrong to
>>> me.
>>>
>>
>> The register is available for access already, so unless there is an
>> actual use-case that requires it to be transmitted through vm_event I
>> don't see the point for transmitting it. So as I mentioned in my other
>> response, I'm inclined to reduce this patch to the bare essentials my
>> use-case requires at this point and leave the extensions up for the
>> future when - and if - it will be of use. Since this patch is just an
>> optimization, if transmitting such reduced set is not acceptable for
>> some reason, I'll forgo this patch entirely.
>
>
> Here we go with again the same argument: "this is not necessary for my
> use-case". This data structure is part of the ABI between the hypervisor and
> the vm-event app, i.e modifying this structure for adding ARM64/ARM
> registers will result to an incompatibility with a previous version of the
> hypervisor. Better to do it now than in a couple of years when vm-event will
> have more users. I agree that it is time consuming to get an ABI correct,
> but it will save users to recompile/ship another version of their vm-event
> app because of this incompatibility.
>
> As mentioned in a previous thread, the main use-case for trapping an SMC is
> emulating the call, hence a vm-event app would want to have access to the
> general-purpose registers. And yes, I know that your use-case is different
> and does not require those registers, I already expressed my concerns about
> it.
>
> Now, if you drop this patch, how will you retrieve the vCPU register? I
> guess via DOMCTL_getvcpucontext? If so, if the vCPU has not been paused, you
> will get a context which is different compare to the time the vm-event has
> occurred. And yes, I know that in your use-case the vCPU is paused. This
> call will always be more expensive than passing the registers with event.

Ack but as right now this patch is just an optimization with no
use-case where it is required, so I'll just drop it from my series.

>
> Anyway, I really don't think we ask for something really difficult to
> accomplish.
>

That may be so and it can be revisited in the future when and if it
will be a hard requirement.

Thanks,
Tamas

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 4/6] arm/vm_event: get/set registers
  2016-07-06 19:12     ` Tamas K Lengyel
@ 2016-07-07  8:23       ` Jan Beulich
  2016-07-07  9:46         ` Julien Grall
  0 siblings, 1 reply; 24+ messages in thread
From: Jan Beulich @ 2016-07-07  8:23 UTC (permalink / raw)
  To: Tamas K Lengyel; +Cc: xen-devel, Julien Grall, Stefano Stabellini

>>> On 06.07.16 at 21:12, <tamas.lengyel@zentific.com> wrote:
> On Wed, Jul 6, 2016 at 12:04 PM, Julien Grall <julien.grall@arm.com> wrote:
>>
>>
>> On 05/07/16 19:37, Tamas K Lengyel wrote:
>>>
>>> +void vm_event_fill_regs(vm_event_request_t *req)
>>> +{
>>> +    const struct cpu_user_regs *regs = guest_cpu_user_regs();
>>> +
>>> +    req->data.regs.arm.cpsr = regs->cpsr;
>>> +    req->data.regs.arm.ttbr0 = READ_SYSREG64(TTBR0_EL1);
>>> +    req->data.regs.arm.ttbr1 = READ_SYSREG64(TTBR1_EL1);
>>> +
>>> +    if ( psr_mode_is_32bit(regs->cpsr) )
>>> +    {
>>> +        req->data.regs.arm.arch.arm32.r0 = regs->r0;
>>> +        req->data.regs.arm.arch.arm32.r1 = regs->r1;
>>> +        req->data.regs.arm.arch.arm32.r2 = regs->r2;
>>> +        req->data.regs.arm.arch.arm32.r3 = regs->r3;
>>> +        req->data.regs.arm.arch.arm32.r4 = regs->r4;
>>> +        req->data.regs.arm.arch.arm32.r5 = regs->r5;
>>> +        req->data.regs.arm.arch.arm32.r6 = regs->r6;
>>> +        req->data.regs.arm.arch.arm32.r7 = regs->r7;
>>> +        req->data.regs.arm.arch.arm32.r8 = regs->r8;
>>> +        req->data.regs.arm.arch.arm32.r9 = regs->r9;
>>> +        req->data.regs.arm.arch.arm32.r10 = regs->r10;
>>> +        req->data.regs.arm.arch.arm32.r11 = regs->fp;
>>> +        req->data.regs.arm.arch.arm32.r12 = regs->r12;
>>> +        req->data.regs.arm.arch.arm32.r13 = regs->sp;
>>
>>
>> Please look at the description of "sp" in cpu_user_regs. You will notice
>> this is only valid for the hypervisor.
>>
>> There are multiple stack pointers for the guest depending on the running
>> mode (see B9.2.1 in ARM DDI 0406C.c), so you may want to pass all of them.
>>
>>> +        req->data.regs.arm.arch.arm32.r14 = regs->lr;
>>
>>
>> Whilst lr is an union with lr_usr on ARM32 port, for the ARM64 port they are
>> distinct (see cpu_users). So you would use the wrong register here.
>>
>> However, as for sp, there are multiple lr pointers for the guest depending
>> on the running mode. So you will pass the wrong lr if the guest is running
>> in another mode than user.
>>
> 
> This patch is becoming a lot more work then what I need it for so I'm
> inclined to just reduce it to the bare minimum my use-case requires,
> which is only cpsr, pc and ttbr0 and ttbr1. I had reservation about
> growing the data field in the vm_event struct anyway, especially since
> there is no use-case that requires it. In case someone has an actual
> use-case in the future that requires other registers to be submitted
> through vm_event, the interface is available for extension.

Rather than dropping this patch entirely (as you suggest in your
other reply) I am, fwiw, fine with a register set not including any
GPRs at all. Not sure about Julien though.

Jan


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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 4/6] arm/vm_event: get/set registers
  2016-07-07  8:23       ` Jan Beulich
@ 2016-07-07  9:46         ` Julien Grall
  2016-07-07  9:57           ` Jan Beulich
  0 siblings, 1 reply; 24+ messages in thread
From: Julien Grall @ 2016-07-07  9:46 UTC (permalink / raw)
  To: Jan Beulich, Tamas K Lengyel; +Cc: xen-devel, Stefano Stabellini



On 07/07/16 09:23, Jan Beulich wrote:
>>>> On 06.07.16 at 21:12, <tamas.lengyel@zentific.com> wrote:
>> On Wed, Jul 6, 2016 at 12:04 PM, Julien Grall <julien.grall@arm.com> wrote:
>>>
>>>
>>> On 05/07/16 19:37, Tamas K Lengyel wrote:
>>>>
>>>> +void vm_event_fill_regs(vm_event_request_t *req)
>>>> +{
>>>> +    const struct cpu_user_regs *regs = guest_cpu_user_regs();
>>>> +
>>>> +    req->data.regs.arm.cpsr = regs->cpsr;
>>>> +    req->data.regs.arm.ttbr0 = READ_SYSREG64(TTBR0_EL1);
>>>> +    req->data.regs.arm.ttbr1 = READ_SYSREG64(TTBR1_EL1);
>>>> +
>>>> +    if ( psr_mode_is_32bit(regs->cpsr) )
>>>> +    {
>>>> +        req->data.regs.arm.arch.arm32.r0 = regs->r0;
>>>> +        req->data.regs.arm.arch.arm32.r1 = regs->r1;
>>>> +        req->data.regs.arm.arch.arm32.r2 = regs->r2;
>>>> +        req->data.regs.arm.arch.arm32.r3 = regs->r3;
>>>> +        req->data.regs.arm.arch.arm32.r4 = regs->r4;
>>>> +        req->data.regs.arm.arch.arm32.r5 = regs->r5;
>>>> +        req->data.regs.arm.arch.arm32.r6 = regs->r6;
>>>> +        req->data.regs.arm.arch.arm32.r7 = regs->r7;
>>>> +        req->data.regs.arm.arch.arm32.r8 = regs->r8;
>>>> +        req->data.regs.arm.arch.arm32.r9 = regs->r9;
>>>> +        req->data.regs.arm.arch.arm32.r10 = regs->r10;
>>>> +        req->data.regs.arm.arch.arm32.r11 = regs->fp;
>>>> +        req->data.regs.arm.arch.arm32.r12 = regs->r12;
>>>> +        req->data.regs.arm.arch.arm32.r13 = regs->sp;
>>>
>>>
>>> Please look at the description of "sp" in cpu_user_regs. You will notice
>>> this is only valid for the hypervisor.
>>>
>>> There are multiple stack pointers for the guest depending on the running
>>> mode (see B9.2.1 in ARM DDI 0406C.c), so you may want to pass all of them.
>>>
>>>> +        req->data.regs.arm.arch.arm32.r14 = regs->lr;
>>>
>>>
>>> Whilst lr is an union with lr_usr on ARM32 port, for the ARM64 port they are
>>> distinct (see cpu_users). So you would use the wrong register here.
>>>
>>> However, as for sp, there are multiple lr pointers for the guest depending
>>> on the running mode. So you will pass the wrong lr if the guest is running
>>> in another mode than user.
>>>
>>
>> This patch is becoming a lot more work then what I need it for so I'm
>> inclined to just reduce it to the bare minimum my use-case requires,
>> which is only cpsr, pc and ttbr0 and ttbr1. I had reservation about
>> growing the data field in the vm_event struct anyway, especially since
>> there is no use-case that requires it. In case someone has an actual
>> use-case in the future that requires other registers to be submitted
>> through vm_event, the interface is available for extension.
>
> Rather than dropping this patch entirely (as you suggest in your
> other reply) I am, fwiw, fine with a register set not including any
> GPRs at all. Not sure about Julien though.

Well, the SMC instructions are used to communicate with the secure mode 
(usually a trusted firmware).

In general, if you want to trap the SMC instructions it is for emulating 
them and not using them for breakpoint in the guest (as for Tamas's 
use-case). In this case, you want to have the set of GPRs available in 
the vm_event request to avoid the overhead of the DOMCTL_getvcpucontext 
(assuming the vCPU has been paused).

Adding the GPRs in the vm_event will likely require to bump the version 
number (VM_EVENT_INTERFACE_VERSION) because the ABI will not be 
compatible. If we consider that it is ok to ask developers to rebuild 
their vm-event app, then fine.

Anyway, I think this patch was in a good state (though few registers 
were needed clarification). Assuming it is ok to break the compatibility 
later on, I will not oppose to have a reduce set.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 4/6] arm/vm_event: get/set registers
  2016-07-07  9:46         ` Julien Grall
@ 2016-07-07  9:57           ` Jan Beulich
  2016-07-07 10:09             ` Julien Grall
  0 siblings, 1 reply; 24+ messages in thread
From: Jan Beulich @ 2016-07-07  9:57 UTC (permalink / raw)
  To: Julien Grall; +Cc: xen-devel, Stefano Stabellini, Tamas K Lengyel

>>> On 07.07.16 at 11:46, <julien.grall@arm.com> wrote:
> Anyway, I think this patch was in a good state (though few registers 
> were needed clarification). Assuming it is ok to break the compatibility 
> later on, I will not oppose to have a reduce set.

Iirc we did bump that interface version already after the tree got
opened for 4.8.

Jan


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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 6/6] tools/xen-access: add test-case for ARM SMC
  2016-07-05 18:37 ` [PATCH v8 6/6] tools/xen-access: add test-case for ARM SMC Tamas K Lengyel
@ 2016-07-07 10:05   ` Julien Grall
  2016-07-07 15:54     ` Tamas K Lengyel
  0 siblings, 1 reply; 24+ messages in thread
From: Julien Grall @ 2016-07-07 10:05 UTC (permalink / raw)
  To: Tamas K Lengyel, xen-devel; +Cc: Ian Jackson



On 05/07/16 19:37, Tamas K Lengyel wrote:
> +#if defined(__arm__) || defined(__aarch64__)
> +            case VM_EVENT_REASON_PRIVILEGED_CALL:
> +                {
> +                    const struct vm_event_regs_arm *in_regs = &req.data.regs.arm;
> +                    struct vm_event_regs_arm *out_regs = &rsp.data.regs.arm;
> +                    bool is32bit = !!(in_regs->cpsr & PSR_MODE_BIT);
> +                    uint64_t pc;
> +
> +                    *out_regs = *in_regs;
> +
> +                    if ( is32bit ) {

The open-bracket should be on a separate line.

> +                        pc = in_regs->arch.arm32.pc;
> +                        out_regs->arch.arm32.pc += 4;

I suspect you will have to update the CSPR if the SMC instruction is 
part of an IT block (see advance_pc code in arch/arm/traps.c).

> +                    } else {

The open-bracket should be on a separate line.

> +                        pc = in_regs->arch.arm64.pc;
> +                        out_regs->arch.arm64.pc += 8;

SMC instruction length is 4 bytes not 8 (see encoding in C6.2.165 in DDI 
0487A.j).

> +                    }
> +
> +                    printf("Privileged call: pc=%016"PRIx64" (vcpu %d)\n",
> +                           pc, req.vcpu_id);
> +
> +                    rsp.flags |= VM_EVENT_FLAG_SET_REGISTERS;
> +                }
> +                break;
> +#endif
>               default:
>                   fprintf(stderr, "UNKNOWN REASON CODE %d\n", req.reason);
>               }
>

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 4/6] arm/vm_event: get/set registers
  2016-07-07  9:57           ` Jan Beulich
@ 2016-07-07 10:09             ` Julien Grall
  2016-07-07 15:53               ` Tamas K Lengyel
  0 siblings, 1 reply; 24+ messages in thread
From: Julien Grall @ 2016-07-07 10:09 UTC (permalink / raw)
  To: Jan Beulich; +Cc: xen-devel, Stefano Stabellini, Tamas K Lengyel



On 07/07/16 10:57, Jan Beulich wrote:
>>>> On 07.07.16 at 11:46, <julien.grall@arm.com> wrote:
>> Anyway, I think this patch was in a good state (though few registers
>> were needed clarification). Assuming it is ok to break the compatibility
>> later on, I will not oppose to have a reduce set.
>
> Iirc we did bump that interface version already after the tree got
> opened for 4.8.

I had the impression that Tamas does not plan to add the full set of the 
registers for 4.8. If so, we would have to bump another time later.

Maybe he can clarify whether the full set will be added for Xen 4.8 or not.

Cheers,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 4/6] arm/vm_event: get/set registers
  2016-07-07 10:09             ` Julien Grall
@ 2016-07-07 15:53               ` Tamas K Lengyel
  0 siblings, 0 replies; 24+ messages in thread
From: Tamas K Lengyel @ 2016-07-07 15:53 UTC (permalink / raw)
  To: Julien Grall; +Cc: xen-devel, Stefano Stabellini, Jan Beulich

On Thu, Jul 7, 2016 at 4:09 AM, Julien Grall <julien.grall@arm.com> wrote:
>
>
> On 07/07/16 10:57, Jan Beulich wrote:
>>>>>
>>>>> On 07.07.16 at 11:46, <julien.grall@arm.com> wrote:
>>>
>>> Anyway, I think this patch was in a good state (though few registers
>>> were needed clarification). Assuming it is ok to break the compatibility
>>> later on, I will not oppose to have a reduce set.
>>
>>
>> Iirc we did bump that interface version already after the tree got
>> opened for 4.8.
>
>
> I had the impression that Tamas does not plan to add the full set of the
> registers for 4.8. If so, we would have to bump another time later.

I have no current plans for sending the full set of registers. As
Razvan pointed pointed out earlier, it would be better to do that as
part of a bigger extension of vm_event that would allow the ring to be
multi-page. That however is well beyond what I'm aiming to achieve
here at the moment. I rewrote the vm_event system specifically to
allow extensions to it that break the ABI in a way that applications
can safely deal with it. Yes, it may require applications to be
recompiled for newer versions of Xen but that is to be expected and
should not be a show-stopper.

Thanks,
Tamas

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v8 6/6] tools/xen-access: add test-case for ARM SMC
  2016-07-07 10:05   ` Julien Grall
@ 2016-07-07 15:54     ` Tamas K Lengyel
  0 siblings, 0 replies; 24+ messages in thread
From: Tamas K Lengyel @ 2016-07-07 15:54 UTC (permalink / raw)
  To: Julien Grall; +Cc: xen-devel, Ian Jackson

On Thu, Jul 7, 2016 at 4:05 AM, Julien Grall <julien.grall@arm.com> wrote:
>
>
> On 05/07/16 19:37, Tamas K Lengyel wrote:
>>
>> +#if defined(__arm__) || defined(__aarch64__)
>> +            case VM_EVENT_REASON_PRIVILEGED_CALL:
>> +                {
>> +                    const struct vm_event_regs_arm *in_regs =
>> &req.data.regs.arm;
>> +                    struct vm_event_regs_arm *out_regs =
>> &rsp.data.regs.arm;
>> +                    bool is32bit = !!(in_regs->cpsr & PSR_MODE_BIT);
>> +                    uint64_t pc;
>> +
>> +                    *out_regs = *in_regs;
>> +
>> +                    if ( is32bit ) {
>
>
> The open-bracket should be on a separate line.
>
>> +                        pc = in_regs->arch.arm32.pc;
>> +                        out_regs->arch.arm32.pc += 4;
>
>
> I suspect you will have to update the CSPR if the SMC instruction is part of
> an IT block (see advance_pc code in arch/arm/traps.c).
>
>> +                    } else {
>
>
> The open-bracket should be on a separate line.
>
>> +                        pc = in_regs->arch.arm64.pc;
>> +                        out_regs->arch.arm64.pc += 8;
>
>
> SMC instruction length is 4 bytes not 8 (see encoding in C6.2.165 in DDI
> 0487A.j).
>
>> +                    }
>> +
>> +                    printf("Privileged call: pc=%016"PRIx64" (vcpu
>> %d)\n",
>> +                           pc, req.vcpu_id);
>> +
>> +                    rsp.flags |= VM_EVENT_FLAG_SET_REGISTERS;
>> +                }
>> +                break;
>> +#endif
>>               default:
>>                   fprintf(stderr, "UNKNOWN REASON CODE %d\n", req.reason);
>>               }
>>
>
> Regards,
>
> --
> Julien Grall

Good points, thanks!

Tamas

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2016-07-07 15:54 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-05 18:37 [PATCH v8 1/6] monitor: rename and relocate vm_event_monitor_traps Tamas K Lengyel
2016-07-05 18:37 ` [PATCH v8 2/6] arm: filter SMC exceptions with failed condition checks Tamas K Lengyel
2016-07-06 17:31   ` Julien Grall
2016-07-06 18:52     ` Tamas K Lengyel
2016-07-05 18:37 ` [PATCH v8 3/6] monitor: ARM SMC events Tamas K Lengyel
2016-07-05 18:37 ` [PATCH v8 4/6] arm/vm_event: get/set registers Tamas K Lengyel
2016-07-06  7:43   ` Jan Beulich
2016-07-06  7:59     ` Razvan Cojocaru
2016-07-06 17:39     ` Julien Grall
2016-07-06 19:23     ` Tamas K Lengyel
2016-07-06 21:12       ` Julien Grall
2016-07-06 22:01         ` Tamas K Lengyel
2016-07-06 18:04   ` Julien Grall
2016-07-06 19:12     ` Tamas K Lengyel
2016-07-07  8:23       ` Jan Beulich
2016-07-07  9:46         ` Julien Grall
2016-07-07  9:57           ` Jan Beulich
2016-07-07 10:09             ` Julien Grall
2016-07-07 15:53               ` Tamas K Lengyel
2016-07-05 18:37 ` [PATCH v8 5/6] tools/libxc: add xc_monitor_privileged_call Tamas K Lengyel
2016-07-05 18:37 ` [PATCH v8 6/6] tools/xen-access: add test-case for ARM SMC Tamas K Lengyel
2016-07-07 10:05   ` Julien Grall
2016-07-07 15:54     ` Tamas K Lengyel
2016-07-05 19:15 ` [PATCH v8 1/6] monitor: rename and relocate vm_event_monitor_traps Razvan Cojocaru

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).