[Xen-devel] [PATCH RFC 7/7] tools/tests: Remove superfluous and incomplete spinlock from xen-access

2014-11-12 Thread Tamas K Lengyel
The spin-lock implementation in the xen-access test program is implemented
in a fashion that is actually incomplete. The x86 assembly that guarantees that
the lock is held by only one thread lacks the lock; instruction.

However, the spin-lock is not actually necessary in xen-access as it is not
multithreaded. The presence of the faulty implementation of the lock in a non-
mulithreaded environment is unnecessarily complicated for developers who are
trying to follow this code as a guide in implementing their own applications.
Thus, removing it from the code improves the clarity on the behavior of the
system.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
 tools/tests/xen-access/xen-access.c | 68 -
 1 file changed, 6 insertions(+), 62 deletions(-)

diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index 3538323..428c459 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -45,56 +45,6 @@
 #define ERROR(a, b...) fprintf(stderr, a \n, ## b)
 #define PERROR(a, b...) fprintf(stderr, a : %s\n, ## b, strerror(errno))
 
-/* Spinlock and mem event definitions */
-
-#define SPIN_LOCK_UNLOCKED 0
-
-#define ADDR (*(volatile long *) addr)
-/**
- * test_and_set_bit - Set a bit and return its old value
- * @nr: Bit to set
- * @addr: Address to count from
- *
- * This operation is atomic and cannot be reordered.
- * It also implies a memory barrier.
- */
-static inline int test_and_set_bit(int nr, volatile void *addr)
-{
-int oldbit;
-
-asm volatile (
-btsl %2,%1\n\tsbbl %0,%0
-: =r (oldbit), =m (ADDR)
-: Ir (nr), m (ADDR) : memory);
-return oldbit;
-}
-
-typedef int spinlock_t;
-
-static inline void spin_lock(spinlock_t *lock)
-{
-while ( test_and_set_bit(1, lock) );
-}
-
-static inline void spin_lock_init(spinlock_t *lock)
-{
-*lock = SPIN_LOCK_UNLOCKED;
-}
-
-static inline void spin_unlock(spinlock_t *lock)
-{
-*lock = SPIN_LOCK_UNLOCKED;
-}
-
-static inline int spin_trylock(spinlock_t *lock)
-{
-return !test_and_set_bit(1, lock);
-}
-
-#define vm_event_ring_lock_init(_m)  spin_lock_init((_m)-ring_lock)
-#define vm_event_ring_lock(_m)   spin_lock((_m)-ring_lock)
-#define vm_event_ring_unlock(_m) spin_unlock((_m)-ring_lock)
-
 typedef struct vm_event {
 domid_t domain_id;
 xc_evtchn *xce_handle;
@@ -102,7 +52,6 @@ typedef struct vm_event {
 vm_event_back_ring_t back_ring;
 uint32_t evtchn_port;
 void *ring_page;
-spinlock_t ring_lock;
 } vm_event_t;
 
 typedef struct xenaccess {
@@ -241,9 +190,6 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t 
domain_id)
 /* Set domain id */
 xenaccess-vm_event.domain_id = domain_id;
 
-/* Initialise lock */
-vm_event_ring_lock_init(xenaccess-vm_event);
-
 /* Enable mem_access */
 xenaccess-vm_event.ring_page =
 xc_mem_access_enable(xenaccess-xc_handle,
@@ -320,13 +266,14 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t 
domain_id)
 return NULL;
 }
 
+/*
+ * Note that this function is not thread safe.
+ */
 int get_request(vm_event_t *vm_event, vm_event_request_t *req)
 {
 vm_event_back_ring_t *back_ring;
 RING_IDX req_cons;
 
-vm_event_ring_lock(vm_event);
-
 back_ring = vm_event-back_ring;
 req_cons = back_ring-req_cons;
 
@@ -338,18 +285,17 @@ int get_request(vm_event_t *vm_event, vm_event_request_t 
*req)
 back_ring-req_cons = req_cons;
 back_ring-sring-req_event = req_cons + 1;
 
-vm_event_ring_unlock(vm_event);
-
 return 0;
 }
 
+/*
+ * Note that this function is not thread safe.
+ */
 static int put_response(vm_event_t *vm_event, vm_event_response_t *rsp)
 {
 vm_event_back_ring_t *back_ring;
 RING_IDX rsp_prod;
 
-vm_event_ring_lock(vm_event);
-
 back_ring = vm_event-back_ring;
 rsp_prod = back_ring-rsp_prod_pvt;
 
@@ -361,8 +307,6 @@ static int put_response(vm_event_t *vm_event, 
vm_event_response_t *rsp)
 back_ring-rsp_prod_pvt = rsp_prod;
 RING_PUSH_RESPONSES(back_ring);
 
-vm_event_ring_unlock(vm_event);
-
 return 0;
 }
 
-- 
2.1.1


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


[Xen-devel] [PATCH RFC 2/7] xen/mem_event: Rename the mem_event ring from 'access' to 'monitor'

2014-11-12 Thread Tamas K Lengyel
The name of the ring still implies it is used only for memory accesses,
which is no longer the case. It is also used to deliver variuos HVM events,
thus the name monitor is more appropriate in this setting.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
 tools/libxc/xc_domain_restore.c | 14 +++---
 tools/libxc/xc_domain_save.c|  4 ++--
 tools/libxc/xc_hvm_build_x86.c  |  2 +-
 tools/libxc/xc_mem_access.c |  8 
 tools/libxc/xc_mem_event.c  |  8 
 tools/libxc/xg_save_restore.h   |  2 +-
 xen/arch/x86/hvm/hvm.c  |  4 ++--
 xen/arch/x86/hvm/vmx/vmcs.c |  2 +-
 xen/arch/x86/mm/p2m.c   |  2 +-
 xen/common/mem_access.c |  8 
 xen/common/mem_event.c  | 22 +++---
 xen/include/public/domctl.h | 12 ++--
 xen/include/public/hvm/params.h |  2 +-
 xen/include/xen/sched.h |  4 ++--
 14 files changed, 47 insertions(+), 47 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index d8bd9b3..bc6c618 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -734,7 +734,7 @@ typedef struct {
 uint64_t vcpumap[XC_SR_MAX_VCPUS/64];
 uint64_t identpt;
 uint64_t paging_ring_pfn;
-uint64_t access_ring_pfn;
+uint64_t monitor_ring_pfn;
 uint64_t sharing_ring_pfn;
 uint64_t vm86_tss;
 uint64_t console_pfn;
@@ -828,15 +828,15 @@ static int pagebuf_get_one(xc_interface *xch, struct 
restore_ctx *ctx,
 // DPRINTF(paging ring pfn address: %llx\n, buf-paging_ring_pfn);
 return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
-case XC_SAVE_ID_HVM_ACCESS_RING_PFN:
+case XC_SAVE_ID_HVM_MONITOR_RING_PFN:
 /* Skip padding 4 bytes then read the mem access ring location. */
-if ( RDEXACT(fd, buf-access_ring_pfn, sizeof(uint32_t)) ||
- RDEXACT(fd, buf-access_ring_pfn, sizeof(uint64_t)) )
+if ( RDEXACT(fd, buf-monitor_ring_pfn, sizeof(uint32_t)) ||
+ RDEXACT(fd, buf-monitor_ring_pfn, sizeof(uint64_t)) )
 {
 PERROR(error read the access ring pfn);
 return -1;
 }
-// DPRINTF(access ring pfn address: %llx\n, buf-access_ring_pfn);
+// DPRINTF(monitor ring pfn address: %llx\n, buf-monitor_ring_pfn);
 return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
 case XC_SAVE_ID_HVM_SHARING_RING_PFN:
@@ -1660,8 +1660,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, 
uint32_t dom,
 xc_hvm_param_set(xch, dom, HVM_PARAM_IDENT_PT, 
pagebuf.identpt);
 if ( pagebuf.paging_ring_pfn )
 xc_hvm_param_set(xch, dom, HVM_PARAM_PAGING_RING_PFN, 
pagebuf.paging_ring_pfn);
-if ( pagebuf.access_ring_pfn )
-xc_hvm_param_set(xch, dom, HVM_PARAM_ACCESS_RING_PFN, 
pagebuf.access_ring_pfn);
+if ( pagebuf.monitor_ring_pfn )
+xc_hvm_param_set(xch, dom, HVM_PARAM_MONITOR_RING_PFN, 
pagebuf.monitor_ring_pfn);
 if ( pagebuf.sharing_ring_pfn )
 xc_hvm_param_set(xch, dom, HVM_PARAM_SHARING_RING_PFN, 
pagebuf.sharing_ring_pfn);
 if ( pagebuf.vm86_tss )
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index 254fdb3..949ef64 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1664,9 +1664,9 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t 
dom, uint32_t max_iter
 goto out;
 }
 
-chunk.id = XC_SAVE_ID_HVM_ACCESS_RING_PFN;
+chunk.id = XC_SAVE_ID_HVM_MONITOR_RING_PFN;
 chunk.data = 0;
-xc_hvm_param_get(xch, dom, HVM_PARAM_ACCESS_RING_PFN, chunk.data);
+xc_hvm_param_get(xch, dom, HVM_PARAM_MONITOR_RING_PFN, chunk.data);
 
 if ( (chunk.data != 0) 
  wrexact(io_fd, chunk, sizeof(chunk)) )
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index c81a25b..30a929d 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -497,7 +497,7 @@ static int setup_guest(xc_interface *xch,
  special_pfn(SPECIALPAGE_CONSOLE));
 xc_hvm_param_set(xch, dom, HVM_PARAM_PAGING_RING_PFN,
  special_pfn(SPECIALPAGE_PAGING));
-xc_hvm_param_set(xch, dom, HVM_PARAM_ACCESS_RING_PFN,
+xc_hvm_param_set(xch, dom, HVM_PARAM_MONITOR_RING_PFN,
  special_pfn(SPECIALPAGE_ACCESS));
 xc_hvm_param_set(xch, dom, HVM_PARAM_SHARING_RING_PFN,
  special_pfn(SPECIALPAGE_SHARING));
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index 55d0e9f..1c979ed 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -26,22 +26,22 @@
 
 void *xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t 
*port)
 {
-return xc_mem_event_enable(xch, domain_id, HVM_PARAM_ACCESS_RING_PFN,
+return

[Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem

2014-11-12 Thread Tamas K Lengyel
This patch series aims to clean up the mem_event subsystem within Xen. The
original use-case for this system was to allow external helper applications
running in privileged domains to control various memory operations performed
by Xen. Amongs these were paging, sharing and access control. The subsystem
has since been extended to also deliver non-memory related events, namely
various HVM debugging events (INT3, MTF, MOV-TO-CR). The structures and naming
of related functions however has not caught up to these new use-cases, thus
leaving many ambigouities in the code.

In this series we convert the mem_event structures to a union of sub-structures
which clearly define the scope of information that is transmitted via the event
delivery mechanism. Afterwards, we clean up the naming of the structures and
related functions to more clearly be in line with their actual operations.

This PATCH RFC series is also available at:
https://github.com/tklengyel/xen/tree/mem_event_cleanup

Razvan Cojocaru (1):
  xen/mem_event: Cleanup of mem_event structures

Tamas K Lengyel (6):
  xen/mem_event: Rename the mem_event ring from 'access' to 'monitor'
  xen/mem_paging: Convert mem_event_op to mem_paging_op
  x86/hvm: rename hvm_memory_event_* functions to hvm_event_*
  xen/mem_event: Rename mem_event to vm_event
  xen/vm_event: Decouple vm_event and mem_access.
  tools/tests: Remove superfluous and incomplete spinlock from
xen-access

 docs/misc/pvh-readme.txt|   2 +-
 tools/libxc/Makefile|   2 +-
 tools/libxc/xc_domain_restore.c |  14 +-
 tools/libxc/xc_domain_save.c|   4 +-
 tools/libxc/xc_hvm_build_x86.c  |   2 +-
 tools/libxc/xc_mem_access.c |  10 +-
 tools/libxc/xc_mem_event.c  | 178 -
 tools/libxc/xc_mem_paging.c |  38 +-
 tools/libxc/xc_memshr.c |  12 +-
 tools/libxc/xc_private.h|   9 +-
 tools/libxc/xc_vm_event.c   | 162 
 tools/libxc/xg_save_restore.h   |   2 +-
 tools/tests/xen-access/xen-access.c | 187 -
 tools/xenpaging/pagein.c|   2 +-
 tools/xenpaging/xenpaging.c | 150 
 tools/xenpaging/xenpaging.h |   8 +-
 xen/arch/x86/domain.c   |   2 +-
 xen/arch/x86/domctl.c   |   4 +-
 xen/arch/x86/hvm/emulate.c  |   4 +-
 xen/arch/x86/hvm/hvm.c  | 171 +
 xen/arch/x86/hvm/vmx/vmcs.c |   4 +-
 xen/arch/x86/hvm/vmx/vmx.c  |   6 +-
 xen/arch/x86/mm/hap/nested_ept.c|   4 +-
 xen/arch/x86/mm/hap/nested_hap.c|   4 +-
 xen/arch/x86/mm/mem_paging.c|  16 +-
 xen/arch/x86/mm/mem_sharing.c   |  31 +-
 xen/arch/x86/mm/p2m-pod.c   |   4 +-
 xen/arch/x86/mm/p2m-pt.c|   4 +-
 xen/arch/x86/mm/p2m.c   | 139 +++
 xen/arch/x86/x86_64/compat/mm.c |  12 +-
 xen/arch/x86/x86_64/mm.c|  12 +-
 xen/common/Makefile |   2 +-
 xen/common/domain.c |  12 +-
 xen/common/domctl.c |   6 +-
 xen/common/mem_access.c |  24 +-
 xen/common/mem_event.c  | 742 
 xen/common/vm_event.c   | 742 
 xen/drivers/passthrough/pci.c   |   2 +-
 xen/include/asm-arm/p2m.h   |   6 +-
 xen/include/asm-x86/domain.h|   4 +-
 xen/include/asm-x86/hvm/emulate.h   |   2 +-
 xen/include/asm-x86/hvm/hvm.h   |  12 +-
 xen/include/asm-x86/mem_paging.h|   2 +-
 xen/include/asm-x86/p2m.h   |  16 +-
 xen/include/public/domctl.h |  44 +--
 xen/include/public/hvm/params.h |   2 +-
 xen/include/public/mem_event.h  | 134 ---
 xen/include/public/memory.h |   6 +-
 xen/include/public/vm_event.h   | 179 +
 xen/include/xen/mem_access.h|   4 +-
 xen/include/xen/mem_event.h | 143 ---
 xen/include/xen/p2m-common.h|   4 +-
 xen/include/xen/sched.h |  24 +-
 xen/include/xen/vm_event.h  |  87 +
 xen/include/xsm/dummy.h |   6 +-
 xen/include/xsm/xsm.h   |  14 +-
 xen/xsm/dummy.c |   6 +-
 xen/xsm/flask/hooks.c   |  36 +-
 xen/xsm/flask/policy/access_vectors |   2 +-
 59 files changed, 1700 insertions(+), 1762 deletions(-)
 delete mode 100644 tools/libxc/xc_mem_event.c
 create mode 100644 tools/libxc/xc_vm_event.c
 delete mode 100644 xen/common/mem_event.c
 create mode 100644 xen/common/vm_event.c
 delete mode 100644 xen/include/public/mem_event.h
 create mode 100644 xen/include/public/vm_event.h
 delete mode 100644 xen/include/xen/mem_event.h
 create mode 100644 xen/include/xen/vm_event.h

-- 
2.1.1


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


[Xen-devel] [PATCH RFC 6/7] xen/vm_event: Decouple vm_event and mem_access.

2014-11-12 Thread Tamas K Lengyel
The vm_event subsystem has been artifically tied to the presence of mem_access.
While mem_access does depend on vm_event, vm_event is an entirely independent
subsystem that can be used for arbitrary function-offloading to helper apps in
domains. This patch removes the dependency that mem_access needs to be supported
in order to enable vm_event.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
 xen/common/Makefile|  2 +-
 xen/include/xen/vm_event.h | 58 +-
 xen/include/xsm/dummy.h|  2 --
 xen/include/xsm/xsm.h  |  2 --
 xen/xsm/dummy.c|  2 --
 xen/xsm/flask/hooks.c  | 32 +++--
 6 files changed, 15 insertions(+), 83 deletions(-)

diff --git a/xen/common/Makefile b/xen/common/Makefile
index f1b73a3..2ccf0bb 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -52,9 +52,9 @@ obj-y += tmem_xen.o
 obj-y += radix-tree.o
 obj-y += rbtree.o
 obj-y += lzo.o
+obj-y += vm_event.o
 obj-$(HAS_PDX) += pdx.o
 obj-$(HAS_MEM_ACCESS) += mem_access.o
-obj-$(HAS_MEM_ACCESS) += vm_event.o
 
 obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo 
unlz4 earlycpio,$(n).init.o)
 
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index e6e31cd..477ef7e 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -26,8 +26,6 @@
 
 #include xen/sched.h
 
-#ifdef HAS_MEM_ACCESS
-
 /* Clean up on domain destruction */
 void vm_event_cleanup(struct domain *d);
 
@@ -76,61 +74,7 @@ int vm_event_domctl(struct domain *d, 
xen_domctl_vm_event_op_t *mec,
 void vm_event_vcpu_pause(struct vcpu *v);
 void vm_event_vcpu_unpause(struct vcpu *v);
 
-#else
-
-static inline void vm_event_cleanup(struct domain *d) {}
-
-static inline bool_t vm_event_check_ring(struct vm_event_domain *med)
-{
-return 0;
-}
-
-static inline int vm_event_claim_slot(struct domain *d,
-struct vm_event_domain *med)
-{
-return -ENOSYS;
-}
-
-static inline int vm_event_claim_slot_nosleep(struct domain *d,
-struct vm_event_domain *med)
-{
-return -ENOSYS;
-}
-
-static inline
-void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *med)
-{}
-
-static inline
-void vm_event_put_request(struct domain *d, struct vm_event_domain *med,
-vm_event_request_t *req)
-{}
-
-static inline
-int vm_event_get_response(struct domain *d, struct vm_event_domain *med,
-   vm_event_response_t *rsp)
-{
-return -ENOSYS;
-}
-
-static inline int do_vm_event_op(int op, uint32_t domain, void *arg)
-{
-return -ENOSYS;
-}
-
-static inline
-int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *mec,
- XEN_GUEST_HANDLE_PARAM(void) u_domctl)
-{
-return -ENOSYS;
-}
-
-static inline void vm_event_vcpu_pause(struct vcpu *v) {}
-static inline void vm_event_vcpu_unpause(struct vcpu *v) {}
-
-#endif /* HAS_MEM_ACCESS */
-
-#endif /* __MEM_EVENT_H__ */
+#endif /* __VM_EVENT_H__ */
 
 
 /*
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 4227093..50ee929 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -513,7 +513,6 @@ static XSM_INLINE int xsm_hvm_param_nested(XSM_DEFAULT_ARG 
struct domain *d)
 return xsm_default_action(action, current-domain, d);
 }
 
-#ifdef HAS_MEM_ACCESS
 static XSM_INLINE int xsm_vm_event_control(XSM_DEFAULT_ARG struct domain *d, 
int mode, int op)
 {
 XSM_ASSERT_ACTION(XSM_PRIV);
@@ -525,7 +524,6 @@ static XSM_INLINE int xsm_vm_event_op(XSM_DEFAULT_ARG 
struct domain *d, int op)
 XSM_ASSERT_ACTION(XSM_DM_PRIV);
 return xsm_default_action(action, current-domain, d);
 }
-#endif
 
 #ifdef CONFIG_X86
 static XSM_INLINE int xsm_do_mca(XSM_DEFAULT_VOID)
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index cff9d35..61c5acc 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -141,10 +141,8 @@ struct xsm_operations {
 int (*hvm_param_nested) (struct domain *d);
 int (*get_vnumainfo) (struct domain *d);
 
-#ifdef HAS_MEM_ACCESS
 int (*vm_event_control) (struct domain *d, int mode, int op);
 int (*vm_event_op) (struct domain *d, int op);
-#endif
 
 #ifdef CONFIG_X86
 int (*do_mca) (void);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 25fca68..6d12d32 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -118,10 +118,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
 set_to_dummy_if_null(ops, remove_from_physmap);
 set_to_dummy_if_null(ops, map_gmfn_foreign);
 
-#ifdef HAS_MEM_ACCESS
 set_to_dummy_if_null(ops, vm_event_control);
 set_to_dummy_if_null(ops, vm_event_op);
-#endif
 
 #ifdef CONFIG_X86
 set_to_dummy_if_null(ops, do_mca);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d706b1f..1f1b010 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -577,9 +577,7 @@ static int

[Xen-devel] [PATCH RFC 4/7] x86/hvm: rename hvm_memory_event_* functions to hvm_event_*

2014-11-12 Thread Tamas K Lengyel
The function names currently imply that these events are to be delivered via
the memory_event subsystem. However, the naming is confusing as these events
have nothing to do with actual memory events. Simply naming these functions
hvm_event_* more accurately describe their usage.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
 docs/misc/pvh-readme.txt  |  2 +-
 xen/arch/x86/hvm/hvm.c| 50 +--
 xen/arch/x86/hvm/vmx/vmx.c|  6 +++---
 xen/include/asm-x86/hvm/hvm.h | 12 +--
 4 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/docs/misc/pvh-readme.txt b/docs/misc/pvh-readme.txt
index c5b3de4..bbd9dbe 100644
--- a/docs/misc/pvh-readme.txt
+++ b/docs/misc/pvh-readme.txt
@@ -49,7 +49,7 @@ Following remain to be done for PVH:
- AMD port.
- 32bit PVH guest support in both linux and xen. Xen changes are tagged
  32bitfixme.
-   - Add support for monitoring guest behavior. See hvm_memory_event* functions
+   - Add support for monitoring guest behavior. See hvm_event* functions
  in hvm.c
- vcpu hotplug support
- Live migration of PVH guests.
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index b34cdbd..9140a2a 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3230,7 +3230,7 @@ int hvm_set_cr0(unsigned long value)
 hvm_funcs.handle_cd(v, value);
 
 hvm_update_cr(v, 0, value);
-hvm_memory_event_cr0(value, old_value);
+hvm_event_cr0(value, old_value);
 
 if ( (value ^ old_value)  X86_CR0_PG ) {
 if ( !nestedhvm_vmswitch_in_progress(v)  
nestedhvm_vcpu_in_guestmode(v) )
@@ -3271,7 +3271,7 @@ int hvm_set_cr3(unsigned long value)
 old=v-arch.hvm_vcpu.guest_cr[3];
 v-arch.hvm_vcpu.guest_cr[3] = value;
 paging_update_cr3(v);
-hvm_memory_event_cr3(value, old);
+hvm_event_cr3(value, old);
 return X86EMUL_OKAY;
 
  bad_cr3:
@@ -3312,7 +3312,7 @@ int hvm_set_cr4(unsigned long value)
 }
 
 hvm_update_cr(v, 4, value);
-hvm_memory_event_cr4(value, old_cr);
+hvm_event_cr4(value, old_cr);
 
 /*
  * Modifying CR4.{PSE,PAE,PGE,SMEP}, or clearing CR4.PCIDE
@@ -4458,7 +4458,7 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content)
 hvm_cpuid(1, NULL, NULL, NULL, edx);
 mtrr = !!(edx  cpufeat_mask(X86_FEATURE_MTRR));
 
-hvm_memory_event_msr(msr, msr_content);
+hvm_event_msr(msr, msr_content);
 
 switch ( msr )
 {
@@ -6153,7 +6153,7 @@ int hvm_debug_op(struct vcpu *v, int32_t op)
 return rc;
 }
 
-static void hvm_mem_event_fill_regs(mem_event_request_t *req)
+static void hvm_event_fill_regs(mem_event_request_t *req)
 {
 const struct cpu_user_regs *regs = guest_cpu_user_regs();
 const struct vcpu *curr = current;
@@ -6185,7 +6185,7 @@ static void hvm_mem_event_fill_regs(mem_event_request_t 
*req)
 req-x86_regs.cr4 = curr-arch.hvm_vcpu.guest_cr[4];
 }
 
-static int hvm_memory_event_traps(long parameters, mem_event_request_t *req)
+static int hvm_event_traps(long parameters, mem_event_request_t *req)
 {
 int rc;
 struct vcpu *v = current;
@@ -6210,13 +6210,13 @@ static int hvm_memory_event_traps(long parameters, 
mem_event_request_t *req)
 mem_event_vcpu_pause(v);
 }
 
-hvm_mem_event_fill_regs(req);
+hvm_event_fill_regs(req);
 mem_event_put_request(d, d-mem_event-monitor, req);
 
 return 1;
 }
 
-void hvm_memory_event_cr0(unsigned long value, unsigned long old)
+void hvm_event_cr0(unsigned long value, unsigned long old)
 {
 mem_event_request_t req = {
 .reason = MEM_EVENT_REASON_CR0,
@@ -6231,10 +6231,10 @@ void hvm_memory_event_cr0(unsigned long value, unsigned 
long old)
 if ( (parameters  HVMPME_onchangeonly)  (value == old) )
 return;
 
-hvm_memory_event_traps(parameters, req);
+hvm_event_traps(parameters, req);
 }
 
-void hvm_memory_event_cr3(unsigned long value, unsigned long old)
+void hvm_event_cr3(unsigned long value, unsigned long old)
 {
 mem_event_request_t req = {
 .reason = MEM_EVENT_REASON_CR3,
@@ -6249,10 +6249,10 @@ void hvm_memory_event_cr3(unsigned long value, unsigned 
long old)
 if ( (parameters  HVMPME_onchangeonly)  (value == old) )
 return;
 
-hvm_memory_event_traps(parameters, req);
+hvm_event_traps(parameters, req);
 }
 
-void hvm_memory_event_cr4(unsigned long value, unsigned long old)
+void hvm_event_cr4(unsigned long value, unsigned long old)
 {
 mem_event_request_t req = {
 .reason = MEM_EVENT_REASON_CR4,
@@ -6267,10 +6267,10 @@ void hvm_memory_event_cr4(unsigned long value, unsigned 
long old)
 if ( (parameters  HVMPME_onchangeonly)  (value == old) )
 return;
 
-hvm_memory_event_traps(parameters, req);
+hvm_event_traps(parameters, req);
 }
 
-void hvm_memory_event_msr(unsigned long msr, unsigned long value)
+void hvm_event_msr(unsigned long msr, unsigned long value)
 {
 mem_event_request_t req

Re: [Xen-devel] [PATCH RFC 1/7] xen/mem_event: Cleanup of mem_event structures

2014-11-13 Thread Tamas K Lengyel
On Wed, Nov 12, 2014 at 4:58 PM, Andrew Cooper andrew.coop...@citrix.com
wrote:

 On 12/11/14 15:31, Tamas K Lengyel wrote:
  diff --git a/xen/include/public/mem_event.h
 b/xen/include/public/mem_event.h
  index 599f9e8..c0e9394 100644
  --- a/xen/include/public/mem_event.h
  +++ b/xen/include/public/mem_event.h
  @@ -49,15 +49,19 @@
   #define MEM_EVENT_FLAG_EMULATE_NOWRITE (1  6)
 
   /* Reasons for the memory event request */
  -#define MEM_EVENT_REASON_UNKNOWN 0/* typical reason */
  -#define MEM_EVENT_REASON_VIOLATION   1/* access violation, GFN is
 address */
  -#define MEM_EVENT_REASON_CR0 2/* CR0 was hit: gfn is new
 CR0 value, gla is previous */
  -#define MEM_EVENT_REASON_CR3 3/* CR3 was hit: gfn is new
 CR3 value, gla is previous */
  -#define MEM_EVENT_REASON_CR4 4/* CR4 was hit: gfn is new
 CR4 value, gla is previous */
  -#define MEM_EVENT_REASON_INT35/* int3 was hit: gla/gfn are
 RIP */
  -#define MEM_EVENT_REASON_SINGLESTEP  6/* single step was invoked:
 gla/gfn are RIP */
  -#define MEM_EVENT_REASON_MSR 7/* MSR was hit: gfn is MSR
 value, gla is MSR address;
  - does NOT honour
 HVMPME_onchangeonly */
  +typedef enum {
  +MEM_EVENT_REASON_UNKNOWN,  /* Default case */
  +MEM_EVENT_REASON_MEM_ACCESS_VIOLATION, /* Memory access violation */
  +MEM_EVENT_REASON_MEM_SHARING,  /* Memory sharing event */
  +MEM_EVENT_REASON_MEM_PAGING,   /* Memory paging event */
  +MEM_EVENT_REASON_CR0,  /* CR0 was updated */
  +MEM_EVENT_REASON_CR3,  /* CR3 was updated */
  +MEM_EVENT_REASON_CR4,  /* CR4 was updated */
  +MEM_EVENT_REASON_INT3, /* Debug operation executed
 (int3) */
  +MEM_EVENT_REASON_SINGLESTEP,   /* Single-step (MTF) */
  +MEM_EVENT_REASON_MSR,  /* An MSR was updated.
  +* Does NOT honour
 HVMPME_onchangeonly */
  +} mem_event_reason_t;

 Please keep these as defines.  The width of an enum is implementation
 defined, meaning that different compilers are free to interpret the
 width of the above definition differently, which affects the size and
 alignment of mem_event_st below.


OK, that makes sense.

Tamas



 (It is completely wrong that Xen's ABI/API was ever specified using C,
 rather than a document stating actual data structure widths, but that
 horse has long-since bolted)

 ~Andrew


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


Re: [Xen-devel] [PATCH RFC 0/7] xen: Clean-up of mem_event subsystem

2014-11-18 Thread Tamas K Lengyel
On Tue, Nov 18, 2014 at 8:32 AM, Jan Beulich jbeul...@suse.com wrote:

  On 17.11.14 at 18:06, tamas.leng...@zentific.com wrote:
  On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich jbeul...@suse.com wrote:
 
   On 12.11.14 at 16:48, andrew.coop...@citrix.com wrote:
   On 12/11/14 15:31, Tamas K Lengyel wrote:
xen/include/public/domctl.h |  44 +--
xen/include/public/hvm/params.h |   2 +-
xen/include/public/mem_event.h  | 134 ---
xen/include/public/memory.h |   6 +-
xen/include/public/vm_event.h   | 179 +
  
   While in principle I think this series is a very good thing, there is
 a
   problem with editing the pubic header files.
  
   The contents of mem_event.h is not currently hidden behind #ifdef
   __XEN_TOOLS__
  
   As a result, it is strictly speaking part of the VM-visible public
   API/ABI and not permitted to change in a backwards incompatible manor.
  
   Having said that, it is currently only usable by privileged domains,
 so
   there is an argument to be made for declaring that it should have been
   hidden behind __XEN_TOOLS__ in the first place, making it permittable
 to
   change.
 
  I'm not sure I agree - the meaning of tools here would seem quite a
  bit different than e.g. in domctl.h. Looking at patch 1, I can't see how
  an old consumer (remember that for many of these we have at best
  fake consumers in the tree) would deal with the now differently
  arranged data. I don't see any versioning of the interface, and hence
  I can't see how tools would know which of the formats to expect.
 
  The lack of versioning is a real concern which I have aired during the
 4.5
  development process. For example, when we switched from HVMEM_access_* to
  XENMEM_access_* a customer had to do a bunch of manual configure checks
 to
  determine what is supported and what isn't. Furthermore, many of the
  related APIs have changed quite radically between Xen 4.1-4.5, some being
  abandoned midway just to resurface later in a different context. Going
  forward having a clear VM_EVENT_VERSION definition would be very helpful
  and would be the cleanest solution IMHO.

 That's a concern different from mine - source compatibility may be
 acceptable to get broken. Undetectable binary incompatibilities are
 what worry me more.

 Jan


To be fair, I don't think there ever was backwards compatibility
established with the usage of that struct in source or binary form. A quick
glance at git log shows that it had been shuffled around and extended quite
a bit over the years. Going forward it would be best to start with
something that's clean before backwards compatibility is enforced IMHO.

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


Re: [Xen-devel] [v8][PATCH 13/17] xen/mem_access: don't allow accessing reserved device memory

2014-12-18 Thread Tamas K Lengyel
I agree with Julien below, this should probably be put into the p2m layer.
The ARM definition of the function could then simply be an inline
definition that just returns 0.

Tamas

On Tue, Dec 2, 2014 at 9:54 AM, Julien Grall julien.gr...@linaro.org
wrote:

 Hi,

 CC Tamas as he did some work on memaccess for ARM.

 On 01/12/14 09:24, Tiejun Chen wrote:
  We can't expost those reserved device memory in case of mem_access

 s/expost/expose/

  since any access may corrupt device usage.
 
  Signed-off-by: Tiejun Chen tiejun.c...@intel.com
  ---
   xen/common/mem_access.c | 41 +
   1 file changed, 41 insertions(+)
 
  diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
  index 6c2724b..72a807a 100644
  --- a/xen/common/mem_access.c
  +++ b/xen/common/mem_access.c
  @@ -55,6 +55,43 @@ void mem_access_resume(struct domain *d)
   }
   }
 
  +/* We can't expose reserved device memory. */
  +static int mem_access_check_rdm(struct domain *d, uint64_aligned_t
 start,
  +uint32_t nr)
  +{
  +uint32_t i;
  +struct p2m_get_reserved_device_memory pgrdm;

 p2m_get_reserved_device_memory is only defined on x86. This will fail to
 compile on ARM when memaccess is enabled.

  +int rc = 0;
  +
  +if ( !is_hardware_domain(d)  iommu_use_hap_pt(d) )
  +{
  +for ( i = 0; i  nr; i++ )
  +{
  +pgrdm.gfn = start + i;
  +pgrdm.domain = d;
  +rc =
 iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
  +  pgrdm);

 Same here.

 Overall, I'm not sure if it's worth to introduce this code in the common
 part has it doesn't seem useful for ARM.

 In any case, you have to at least stub those bits for ARM.

 Regards,

 --
 Julien Grall

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

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


Re: [Xen-devel] [RFC PATCH V2 1/8] xen/mem_event: Cleanup of mem_event structures

2015-01-22 Thread Tamas K Lengyel
On Thu, Jan 22, 2015 at 1:43 PM, Tim Deegan t...@xen.org wrote:
 Hi,

 At 16:17 +0100 on 18 Jan (1421594274), Tamas K Lengyel wrote:
 From: Razvan Cojocaru rcojoc...@bitdefender.com

 The public mem_event structures used to communicate with helper applications 
 via
 shared rings have been used in different settings. However, the variable 
 names
 within this structure have not reflected this fact, resulting in the reuse of
 variables to mean different things under different scenarios.

 This patch remedies the issue by clearly defining the structure members 
 based on
 the actual context within which the structure is used.

 Signed-off-by: Razvan Cojocaru rcojoc...@bitdefender.com
 Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com

 This looks like a nice improvement.  If everyone who commented about
 making ABI changes is happy with it, I am too.

 It would be nice if you could add some comments to the new struct
 definitions saying what the various fields mean (e.g. when the event
 triggers and what the fields will contain).

Ack, will do!


 One nit in the patch itself:

 @@ -592,13 +592,12 @@ int main(int argc, char *argv[])
  }


 -rsp.gfn = req.gfn;
 -rsp.p2mt = req.p2mt;
 +rsp.mem_access_event.gfn = req.mem_access_event.gfn;

 You're dropping a p2mt update here.  Is that an oversight?
 With the obvious equivalent update inserted,

No, it is not. That field is only used by mem_sharing and mem_paging,
not by mem_access.

Thanks,
Tamas


 Acked-by: Tim Deegan t...@xen.org

 Cheers,

 Tim.

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


Re: [Xen-devel] [RFC PATCH V2 2/8] xen/mem_event: Rename the mem_event ring from 'access' to 'monitor'

2015-01-22 Thread Tamas K Lengyel
On Thu, Jan 22, 2015 at 1:53 PM, Tim Deegan t...@xen.org wrote:
 At 16:17 +0100 on 18 Jan (1421594275), Tamas K Lengyel wrote:
 The name of the ring still implies it is used only for memory accesses,
 which is no longer the case. It is also used to deliver variuos HVM events,
 thus the name monitor is more appropriate in this setting.

 Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com

 Renaming the ring seems good (again assuming everyone is happy about
 making these API changes).  However I think you need to rework the
 public header comment a bit more than just s/access/monitor/.  The
 operation is to set up the event ring but almost all the comments is
 about the access permissions system.  It needs a description that
 would be useful to a developer who didn't already know how all thses
 systems worked. :)

Ack, will describe it a bit better!

Tamas


 Cheers,

 Tim.

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


Re: [Xen-devel] [RFC PATCH V3 10/12] xen: Introduce monitor_op domctl

2015-02-05 Thread Tamas K Lengyel
 +int monitor_domctl(struct xen_domctl_monitor_op *domctl, struct domain *d)
 +{
 +/*
 + * At the moment only HVM domains are supported. However, event delivery
 + * could be extended to PV domains. See comments below.
 + */
 +if ( !is_hvm_domain(d) )
 +return -ENOSYS;
 +
 +if ( domctl-op != XEN_DOMCTL_MONITOR_OP_ENABLE 
 + domctl-op != XEN_DOMCTL_MONITOR_OP_DISABLE )
 +return -EFAULT;
 +
 +switch ( domctl-subop )
 +{
 +case XEN_DOMCTL_MONITOR_SUBOP_MOV_TO_CR0:
 +{
 +/* Note: could be supported on PV domains. */
 +struct mov_to_cr0 *options = d-arch.monitor_options.mov_to_cr0;
 +
 +if ( domctl-op == XEN_DOMCTL_MONITOR_OP_ENABLE )
 +{
 +if ( options-enabled )
 +return -EBUSY;
 +
 +options-enabled = 1;
 +options-sync = domctl-options.mov_to_cr0.sync;
 +options-onchangeonly = domctl-options.mov_to_cr0.onchangeonly;

 Shouldn't you set -enabled last, after a suitable barrier (and with
 the consuming sides using suitable barriers too)? Or are you missing
 a domain_pause() here?

Hm, there wasn't any barrier previously with HVM params so I was not
sure. Would make sense as now we have multiple fields instead of a
single one so its no longer being set atomically. I think
pause/unpause would make the most sense as it is already used in some
of the settings.

...


 --- a/xen/include/public/hvm/params.h
 +++ b/xen/include/public/hvm/params.h
 @@ -162,21 +162,6 @@
   */
  #define HVM_PARAM_ACPI_IOPORTS_LOCATION 19

 -/* Enable blocking memory events, async or sync (pause vcpu until response)
 - * onchangeonly indicates messages only on a change of value */
 -#define HVM_PARAM_MEMORY_EVENT_CR0  20
 -#define HVM_PARAM_MEMORY_EVENT_CR3  21
 -#define HVM_PARAM_MEMORY_EVENT_CR4  22
 -#define HVM_PARAM_MEMORY_EVENT_INT3 23
 -#define HVM_PARAM_MEMORY_EVENT_SINGLE_STEP  25
 -#define HVM_PARAM_MEMORY_EVENT_MSR  30

 I'm not sure if HVM param slots can be re-used. If they can, leaving a
 note that the deleted numbers are available for re-sue would be nice.
 If they can't, leaving a note that they shouldn't be re-used would
 seem mandatory.

 Jan

I'm not sure either if they can be reused, I would assume yes so I'll
make the comment accordingly (unless someone knows more and objects).

All other comments: Ack.

Thanks!
Tamas

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


Re: [Xen-devel] [RFC PATCH V3 02/12] xen/mem_event: Rename the mem_event ring from 'access' to 'monitor'

2015-02-05 Thread Tamas K Lengyel
On Tue, Feb 3, 2015 at 4:37 PM, Jan Beulich jbeul...@suse.com wrote:
 On 29.01.15 at 22:46, tamas.leng...@zentific.com wrote:
 -#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS2
 +#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR2

 While this one looks okay, ...

 -#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE 0
 -#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE1
 -#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE_INTROSPECTION   2
 +#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE 0
 +#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR_DISABLE1
 +#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION   2

 ... I don't think the _DOMCTL and _OP in these are really necessary
 or meaningful. I realize they were this way before, but now that
 you touch them anyway...

 Jan

Good idea!

Thanks,
Tamas

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


Re: [Xen-devel] [RFC PATCH V3 01/12] xen/mem_event: Cleanup of mem_event structures

2015-02-05 Thread Tamas K Lengyel
On Mon, Feb 2, 2015 at 6:19 PM, Ian Campbell ian.campb...@citrix.com wrote:
 On Thu, 2015-01-29 at 22:46 +0100, Tamas K Lengyel wrote:
 From: Razvan Cojocaru rcojoc...@bitdefender.com

 The public mem_event structures used to communicate with helper applications 
 via
 shared rings have been used in different settings. However, the variable 
 names
 within this structure have not reflected this fact, resulting in the reuse of
 variables to mean different things under different scenarios.

 This patch remedies the issue by clearly defining the structure members 
 based on
 the actual context within which the structure is used.

 Signed-off-by: Razvan Cojocaru rcojoc...@bitdefender.com
 Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
 ---
 v3: Add padding to mem_event structures.
 Add version field to mem_event structures and checks for it.

 The addition of versioning is worth mentioning in the commit message
 IMHO.

OK, will do!


 I'm not going to review the tools changes in detail, since I suppose
 they are very much mechanical.

Indeed, no logic changes in this patch.


 -if ( req.gfn  paging-max_pages )
 +if ( req.data.mem_paging.gfn  paging-max_pages )
  {
 -ERROR(Requested gfn %PRIx64 higher than max_pages %x\n, 
 req.gfn, paging-max_pages);
 +ERROR(Requested gfn %PRIx64 higher than max_pages %x\n, 
 req.data.mem_paging.gfn, paging-max_pages);

 If you could wrap some of these lines which have become even more overly
 long here as you change them then that would be much appreciated.

OK!


 +union {
 +struct mem_event_paging_datamem_paging;
 +struct mem_event_sharing_data   mem_sharing;
 +struct mem_event_mem_access_datamem_access;
 +struct mem_event_mov_to_cr_data mov_to_cr;
 +struct mem_event_mov_to_msr_datamov_to_msr;
 +struct mem_event_software_breakpoint_data   software_breakpoint;
 +struct mem_event_singlestep_datasinglestep;
 +} data;

 We typically call these unions u but that's up to the hypervisor guys
 really.

 Ian.


Thanks,
Tamas

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


Re: [Xen-devel] [RFC PATCH V3 01/12] xen/mem_event: Cleanup of mem_event structures

2015-02-05 Thread Tamas K Lengyel
On Tue, Feb 3, 2015 at 10:17 AM, Jan Beulich jbeul...@suse.com wrote:
 On 02.02.15 at 18:19, ian.campb...@citrix.com wrote:
 On Thu, 2015-01-29 at 22:46 +0100, Tamas K Lengyel wrote:
 +union {
 +struct mem_event_paging_datamem_paging;
 +struct mem_event_sharing_data   mem_sharing;
 +struct mem_event_mem_access_datamem_access;
 +struct mem_event_mov_to_cr_data mov_to_cr;
 +struct mem_event_mov_to_msr_datamov_to_msr;
 +struct mem_event_software_breakpoint_data   software_breakpoint;
 +struct mem_event_singlestep_datasinglestep;
 +} data;

 We typically call these unions u but that's up to the hypervisor guys
 really.

 And yes, I agree we should be consistent with things like this.

 Jan

Ack.

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


Re: [Xen-devel] [RFC PATCH V3 05/12] xen: Introduce vm_event

2015-02-06 Thread Tamas K Lengyel
On Mon, Feb 2, 2015 at 8:35 PM, Daniel De Graaf dgde...@tycho.nsa.gov wrote:
 On 01/31/2015 08:24 AM, Tamas K Lengyel wrote:

 On Fri, Jan 30, 2015 at 6:25 PM, Daniel De Graaf dgde...@tycho.nsa.gov
 wrote:

 On 01/29/2015 04:46 PM, Tamas K Lengyel wrote:


 To make it easier to review the renaming process of mem_event -
 vm_event,
 the process is broken into three pieces, of which this patch is the
 first.
 In this patch the vm_event subsystem is introduced and hooked into the
 build
 process, but it is not yet used anywhere.

 Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com



 [...]


 diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
 index f20e89c..d6d403a 100644
 --- a/xen/include/xsm/dummy.h
 +++ b/xen/include/xsm/dummy.h
 @@ -525,6 +525,18 @@ static XSM_INLINE int
 xsm_mem_event_op(XSM_DEFAULT_ARG struct domain *d, int op)
XSM_ASSERT_ACTION(XSM_DM_PRIV);
return xsm_default_action(action, current-domain, d);
}
 +
 +static XSM_INLINE int xsm_vm_event_control(XSM_DEFAULT_ARG struct
 domain
 *d, int mode, int op)
 +{
 +XSM_ASSERT_ACTION(XSM_PRIV);
 +return xsm_default_action(action, current-domain, d);
 +}
 +
 +static XSM_INLINE int xsm_vm_event_op(XSM_DEFAULT_ARG struct domain *d,
 int op)
 +{
 +XSM_ASSERT_ACTION(XSM_DM_PRIV);
 +return xsm_default_action(action, current-domain, d);
 +}
#endif

 [...]


 diff --git a/xen/xsm/flask/policy/access_vectors
 b/xen/xsm/flask/policy/access_vectors
 index 1da9f63..a4241b5 100644
 --- a/xen/xsm/flask/policy/access_vectors
 +++ b/xen/xsm/flask/policy/access_vectors
 @@ -250,6 +250,7 @@ class hvm
hvmctl
# XEN_DOMCTL_set_access_required
mem_event
 +vm_event
# XEN_DOMCTL_mem_sharing_op and XENMEM_sharing_op_{share,add_physmap}
 with:
#  source = the domain making the hypercall
#  target = domain whose memory is being shared


 This implies that device model domains should be allowed to use the
 operations
 covered by xsm_vm_event_op but not those covered by xsm_vm_event_control.
 If this is how the eventual operations are intended to be used, the FLASK
 permissions also need to be split so that a similar distinction can be
 made
 in
 the policy.

 After looking at the later patches in this series, this appears to be a
 flaw
 in
 the existing FLASK hooks that got copied over.  While it is still useful
 to
 fix,
 it  may be better to make the split in a separate patch from the renames.
 Now
 that VM events apply to more than just HVM domains, it may be useful to
 move
 the new permission(s) from class hvm to either domain2 or mmu.

 --
 Daniel De Graaf
 National Security Agency


 Moving it to domain2 would make sense to me. The namings seem to be
 pretty poor so I have a hard time understanding why xsm_vm_event_op
 and xsm_vm_event_control differ when it comes to device model domains.
 The event_op corresponds to memops for access, paging and sharing
 while event_control for the domctl that enables/disables the rings. So
 yes, I think splitting the name for these separating things would make
 sense to clarify what they represent but whether that restriction on
 device model domains was intentional I'm not sure about.

 Tamas


 If the device model stubdom does not use (or plan to use) the memory_op
 hypercall, then there is no reason to allow it to make this hypercall,
 and the XSM check should be changed from XSM_DM_PRIV to XSM_PRIV.  From
 a quick look, this seems to be true, but I would defer to someone who
 has actually used or developed this subsystem.

This subsystem hasn't really seen much use AFAIK and I'm not aware on
anyone using it in device model stubdom, thus this change would be
reasonable.


 As far as the naming, several other hypercalls such as tmem have a
 distinction between use and control that is reflected in the XSM
 policy.  From a quick look at how the hypercalls work, the domctl seems
 to be a toolstack-only feature that is set when building a domain, while
 the mem_event_op hypercall is used by a helper process.

 I think it might be possible to move the helper process to a stub domain
 when creating a very disaggregated system.  In that case, a distinct
 permission for its hypercalls would be useful to let the stub domain
 perform sharing operations without being able to turn sharing on and
 off.  Otherwise the current single permission (moved to domain2) should
 be sufficient.

I would rather keep with the current single permission and split it
only when there is a need for it. In our current model the secondary
(security) control domain pretty much holds equivalent rights to dom0
over a subset of domains, so for us there is no benefit in having such
refined distinction between permissions.



 --
 Daniel De Graaf
 National Security Agency

Thanks,
Tamas

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


Re: [Xen-devel] [RFC PATCH V3 05/12] xen: Introduce vm_event

2015-02-06 Thread Tamas K Lengyel
On Fri, Feb 6, 2015 at 2:58 PM, Andrew Cooper andrew.coop...@citrix.com wrote:
 On 06/02/15 13:54, Tamas K Lengyel wrote:
 Please clarify in the patch description whether this (and perhaps
 other) copied or cloned code is really just a plain copy with some
 renaming, or whether there are any other changes. Reviewing this
 as a non-renaming change isn't time well spent in the former case.
 Ack, this code is identical to mem_event beside the name.

 Using git format-patch/diff -M will make this much more obvious by
 creating a diff which looks something like:

 --- a/xen/common/mem_event.c
 +++ b/xen/common/vm_event.c

 and contains hunks renaming the functions alone.

 ~Andrew

I'll take a look at that, it would certainly simplify things.

Tamas

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


Re: [Xen-devel] [RFC PATCH V3 07/12] xen: Remove mem_event

2015-02-06 Thread Tamas K Lengyel
 Did you look at the resulting patch to see what happened? It didn't
 remove the mem_event stuff, but adjusted it enough to become the
 vm_event one while removing the previously added vm_event part
 again. Another argument against this approach imo.

 Jan

Hm, that is some strange git behavior. I'll reshuffle things in the
next iteration to have most everything in the renaming patch.

Tamas

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


Re: [Xen-devel] [RFC PATCH V3 11/12] xen/vm_event: Decouple vm_event and mem_access.

2015-02-06 Thread Tamas K Lengyel
On Wed, Feb 4, 2015 at 10:47 AM, Jan Beulich jbeul...@suse.com wrote:
 On 29.01.15 at 22:46, tamas.leng...@zentific.com wrote:
 --- a/xen/common/Makefile
 +++ b/xen/common/Makefile
 @@ -52,9 +52,10 @@ obj-y += tmem_xen.o
  obj-y += radix-tree.o
  obj-y += rbtree.o
  obj-y += lzo.o
 +obj-y += vm_event.o
 +obj-y += monitor.o

 Please make the (not) sorting situation worse than it already is - the
 original intention was for entries to be alphabetically sorted here.

I'm just going to sort the list in this patch to have everything in
alphabetic order.


 --- /dev/null
 +++ b/xen/common/monitor.c
 @@ -0,0 +1,64 @@
 +/**
 + * monitor.c
 + *
 + * VM event monitor support.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * 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, write to the Free Software
 + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 + */
 +
 +#include xen/sched.h
 +#include xen/vm_event.h
 +#include xen/mem_access.h
 +
 +void monitor_resume(struct domain *d)
 +{
 +vm_event_response_t rsp;
 +
 +/* Pull all responses off the ring. */
 +while ( vm_event_get_response(d, d-vm_event-monitor, rsp) )
 +{
 +struct vcpu *v;
 +
 +if ( rsp.version != VM_EVENT_INTERFACE_VERSION )
 +continue;
 +
 +#ifndef NDEBUG
 +if ( rsp.flags  VM_EVENT_FLAG_DUMMY )
 +continue;
 +#endif

 This code was unconditional in the original function. Such a change
 needs mentioning in the description.

Ah, yes, the patch that makes this conditional has to be moved up
before this one.


 @@ -49,7 +53,7 @@ int mem_access_send_req(struct domain *d, 
 vm_event_request_t *req)
  return -ENOSYS;
  }

 -static inline void mem_access_resume(struct domain *d) {}
 +static inline void mem_access_resume(struct vcpu *vcpu, vm_event_response_t 
 *rsp) {}

 Long line.

 --- /dev/null
 +++ b/xen/include/xen/monitor.h
 @@ -0,0 +1,38 @@
 +/**
 + * monitor.h
 + *
 + * Monitor event support.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * 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, write to the Free Software
 + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 + */
 +
 +#ifndef _XEN_ASM_MONITOR_H
 +#define _XEN_ASM_MONITOR_H
 +
 +#include public/memory.h

 This can't be enough (nor can I see why it's needed here), or else ...

 +/* Resumes the running of the VCPU, restarting the last instruction */
 +void monitor_resume(struct domain *d);

 ... struct domain may end up being a forward reference (with scope
 restricted to monitor_resume()).

 Jan

I'll revisit the headers needed for this one but it did build fine.

Thanks,
Tamas

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


Re: [Xen-devel] [RFC PATCH V3 12/12] xen/vm_event: Check for VM_EVENT_FLAG_DUMMY only in Debug builds

2015-02-06 Thread Tamas K Lengyel
On Wed, Feb 4, 2015 at 6:59 AM, Tian, Kevin kevin.t...@intel.com wrote:
 From: Tamas K Lengyel [mailto:tamas.leng...@zentific.com]
 Sent: Friday, January 30, 2015 5:47 AM

 The flag is only used for debugging purposes, thus it should be only checked
 for in debug builds of Xen.

 Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
 ---
  xen/arch/x86/mm/mem_sharing.c |  2 ++
  xen/arch/x86/mm/p2m.c |  2 ++
  xen/common/mem_access.c   | 31
 +++
  3 files changed, 35 insertions(+)

 diff --git a/xen/arch/x86/mm/mem_sharing.c
 b/xen/arch/x86/mm/mem_sharing.c
 index c487207..303c2fb 100644
 --- a/xen/arch/x86/mm/mem_sharing.c
 +++ b/xen/arch/x86/mm/mem_sharing.c
 @@ -604,8 +604,10 @@ int mem_sharing_sharing_resume(struct domain *d)
  if ( rsp.version != VM_EVENT_INTERFACE_VERSION )
  continue;

 +#ifndef NDEBUG
  if ( rsp.flags  VM_EVENT_FLAG_DUMMY )
  continue;
 +#endif

  /* Validate the vcpu_id in the response. */
  if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
 diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
 index 3b58700..1d91000 100644
 --- a/xen/arch/x86/mm/p2m.c
 +++ b/xen/arch/x86/mm/p2m.c
 @@ -1305,8 +1305,10 @@ void p2m_mem_paging_resume(struct domain *d)
  if ( rsp.version != VM_EVENT_INTERFACE_VERSION )
  continue;

 +#ifndef NDEBUG
  if ( rsp.flags  VM_EVENT_FLAG_DUMMY )
  continue;
 +#endif

  /* Validate the vcpu_id in the response. */
  if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
 diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
 index 3655165..e0a538f 100644
 --- a/xen/common/mem_access.c
 +++ b/xen/common/mem_access.c
 @@ -30,6 +30,37 @@
  #include asm/p2m.h
  #include xsm/xsm.h

 +void mem_access_resume(struct domain *d)

 so there is no caller of this new function?

This patch seems to got a bit mangled with the previous one so I'll
clean it up. The only thing I intended to have in this patch is the
#ifndef wrapper to be around the DUMMY check. Sorry for the noise.


 +{
 +vm_event_response_t rsp;
 +
 +/* Pull all responses off the ring. */
 +while ( vm_event_get_response(d, d-vm_event-monitor, rsp) )
 +{
 +struct vcpu *v;
 +
 +if ( rsp.version != VM_EVENT_INTERFACE_VERSION )
 +continue;
 +
 +#ifndef NDEBUG
 +if ( rsp.flags  VM_EVENT_FLAG_DUMMY )
 +continue;
 +#endif
 +
 +/* Validate the vcpu_id in the response. */
 +if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
 +continue;
 +
 +v = d-vcpu[rsp.vcpu_id];
 +
 +p2m_vm_event_emulate_check(v, rsp);
 +
 +/* Unpause domain. */
 +if ( rsp.flags  VM_EVENT_FLAG_VCPU_PAUSED )
 +vm_event_vcpu_unpause(v);
 +}
 +}
 +
  int mem_access_memop(unsigned long cmd,

 XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg)
  {
 --
 2.1.4


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


Re: [Xen-devel] [RFC PATCH V3 05/12] xen: Introduce vm_event

2015-02-06 Thread Tamas K Lengyel
On Tue, Feb 3, 2015 at 4:54 PM, Jan Beulich jbeul...@suse.com wrote:
 On 29.01.15 at 22:46, tamas.leng...@zentific.com wrote:
 --- a/docs/misc/xsm-flask.txt
 +++ b/docs/misc/xsm-flask.txt
 @@ -87,6 +87,7 @@ __HYPERVISOR_domctl (xen/include/public/domctl.h)
   * XEN_DOMCTL_set_machine_address_size
   * XEN_DOMCTL_debug_op
   * XEN_DOMCTL_gethvmcontext_partial
 + * XEN_DOMCTL_vm_event_op
   * XEN_DOMCTL_mem_event_op
   * XEN_DOMCTL_mem_sharing_op
   * XEN_DOMCTL_setvcpuextstate

 No - no additions here. You don't define XEN_DOMCTL_vm_event_op
 in this patch anyway. Once you rename the other one, replacing it
 here will be okay.

 --- /dev/null
 +++ b/xen/common/vm_event.c
 @@ -0,0 +1,739 @@

 Please clarify in the patch description whether this (and perhaps
 other) copied or cloned code is really just a plain copy with some
 renaming, or whether there are any other changes. Reviewing this
 as a non-renaming change isn't time well spent in the former case.

Ack, this code is identical to mem_event beside the name.


 --- a/xen/include/public/domctl.h
 +++ b/xen/include/public/domctl.h
 @@ -835,6 +835,84 @@ typedef struct xen_domctl_mem_event_op 
 xen_domctl_mem_event_op_t;
  DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);

  /*
 + * VM event operations
 + */
 +
 +/* XEN_DOMCTL_vm_event_op */
 +
 +/*
 + * Domain memory paging
 + * Page memory in and out.
 + * Domctl interface to set up and tear down the
 + * pager-hypervisor interface. Use XENMEM_paging_op*
 + * to perform per-page operations.
 + *
 + * The XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE domctl returns several
 + * non-standard error codes to indicate why paging could not be enabled:
 + * ENODEV - host lacks HAP support (EPT/NPT) or HAP is disabled in guest
 + * EMLINK - guest has iommu passthrough enabled
 + * EXDEV  - guest has PoD enabled
 + * EBUSY  - guest has or had paging enabled, ring buffer still active
 + */
 +#define XEN_DOMCTL_VM_EVENT_OP_PAGING1
 +
 +#define XEN_DOMCTL_VM_EVENT_OP_PAGING_ENABLE 0
 +#define XEN_DOMCTL_VM_EVENT_OP_PAGING_DISABLE1
 +
 +/*
 + * Monitor permissions.
 + *
 + * As with paging, use the domctl for teardown/setup of the
 + * helper-hypervisor interface.
 + *
 + * There are HVM hypercalls to set the per-page access permissions of every
 + * page in a domain.  When one of these permissions--independent, read,
 + * write, and execute--is violated, the VCPU is paused and a memory event
 + * is sent with what happened.  (See public/vm_event.h) .
 + *
 + * The memory event handler can then resume the VCPU and redo the access
 + * with a XENMEM_access_op_resume hypercall.
 + *
 + * The XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE domctl returns several
 + * non-standard error codes to indicate why access could not be enabled:
 + * EBUSY  - guest has or had access enabled, ring buffer still active
 + */
 +#define XEN_DOMCTL_VM_EVENT_OP_MONITOR2
 +
 +#define XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE 0
 +#define XEN_DOMCTL_VM_EVENT_OP_MONITOR_DISABLE1
 +#define XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION   2
 +
 +/*
 + * Sharing ENOMEM helper.
 + *
 + * As with paging, use the domctl for teardown/setup of the
 + * helper-hypervisor interface.
 + *
 + * If setup, this ring is used to communicate failed allocations
 + * in the unshare path. XENMEM_sharing_op_resume is used to wake up
 + * vcpus that could not unshare.
 + *
 + * Note that shring can be turned on (as per the domctl below)
 + * *without* this ring being setup.
 + */
 +#define XEN_DOMCTL_VM_EVENT_OP_SHARING   3
 +
 +#define XEN_DOMCTL_VM_EVENT_OP_SHARING_ENABLE0
 +#define XEN_DOMCTL_VM_EVENT_OP_SHARING_DISABLE   1
 +
 +/* Use for teardown/setup of helper-hypervisor interface for paging,
 + * access and sharing.*/
 +struct xen_domctl_vm_event_op {
 +uint32_t   op;   /* XEN_DOMCTL_VM_EVENT_OP_*_* */
 +uint32_t   mode; /* XEN_DOMCTL_VM_EVENT_OP_* */
 +
 +uint32_t port;  /* OUT: event channel for ring */
 +};
 +typedef struct xen_domctl_vm_event_op xen_domctl_vm_event_op_t;
 +DEFINE_XEN_GUEST_HANDLE(xen_domctl_vm_event_op_t);

 I doubt it is the best approach to do this via add and remove steps,
 rather than just a single renaming step (where likely much on the
 commentary would remain untouched). Or if staying with that model,
 maybe interleaving the additions with the to be replaced code might
 be a workable approach.

 @@ -216,6 +217,8 @@ struct vcpu

  /* VCPU paused for mem_event replies. */
  atomic_t mem_event_pause_count;
 +/* VCPU paused for vm_event replies. */
 +atomic_t vm_event_pause_count;

 Or, to avoid odd changes like this, don't hook up the new source file(s)
 to the make system yet.

 Jan

The last one I think is the most workable, I'll only hook vm_event
into the build system when it is getting used (next patch in the
series). That avoids a bunch of weird additions we see here.


Re: [Xen-devel] [RFC PATCH V3 12/12] xen/vm_event: Check for VM_EVENT_FLAG_DUMMY only in Debug builds

2015-02-06 Thread Tamas K Lengyel
On Wed, Feb 4, 2015 at 10:49 AM, Jan Beulich jbeul...@suse.com wrote:
 On 29.01.15 at 22:46, tamas.leng...@zentific.com wrote:
 The flag is only used for debugging purposes, thus it should be only checked
 for in debug builds of Xen.

 So this should be where the respective conditional I just complained
 about should get added.


 --- a/xen/common/mem_access.c
 +++ b/xen/common/mem_access.c
 @@ -30,6 +30,37 @@
  #include asm/p2m.h
  #include xsm/xsm.h

 +void mem_access_resume(struct domain *d)
 +{

 Why is this being re-added, and how do things build with the other
 (inline) mem_access_resume() added in an earlier patch?

 Jan

Yes, this patch got a bit mixed up with the previous one.

To answer your question nevertheless, mem_access_resume is redefined
to be only doing mem_access related work. Previously it was
responsible to pulling all the responses off the ring, even if these
were not mem_access related. Now the monitor is pulling the responses
off the ring, and issues mem_access_resume if the response is to a
mem_access request.

Tamas

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


Re: [Xen-devel] [RFC PATCH V3 07/12] xen: Remove mem_event

2015-02-06 Thread Tamas K Lengyel
On Fri, Feb 6, 2015 at 3:18 PM, Jan Beulich jbeul...@suse.com wrote:
 On 06.02.15 at 13:54, tamas.leng...@zentific.com wrote:
  Did you look at the resulting patch to see what happened? It didn't
 remove the mem_event stuff, but adjusted it enough to become the
 vm_event one while removing the previously added vm_event part
 again. Another argument against this approach imo.

 Hm, that is some strange git behavior. I'll reshuffle things in the
 next iteration to have most everything in the renaming patch.

 Considering that Andrew too seems to think that this 3 stage
 approach is undesirable, I think you'd better go the git mv route
 for the next version.

 Jan

Ack, I'll give it a shot. I did that first but hopefully the trick is
in the magic git -M option.

Tamas

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


Re: [Xen-devel] [RFC PATCH V3 11/12] xen/vm_event: Decouple vm_event and mem_access.

2015-02-06 Thread Tamas K Lengyel
On Fri, Feb 6, 2015 at 3:20 PM, Jan Beulich jbeul...@suse.com wrote:
 On 06.02.15 at 14:10, tamas.leng...@zentific.com wrote:
 On Wed, Feb 4, 2015 at 10:47 AM, Jan Beulich jbeul...@suse.com wrote:
 On 29.01.15 at 22:46, tamas.leng...@zentific.com wrote:
 --- a/xen/common/Makefile
 +++ b/xen/common/Makefile
 @@ -52,9 +52,10 @@ obj-y += tmem_xen.o
  obj-y += radix-tree.o
  obj-y += rbtree.o
  obj-y += lzo.o
 +obj-y += vm_event.o
 +obj-y += monitor.o

 Please make the (not) sorting situation worse than it already is - the
 original intention was for entries to be alphabetically sorted here.

 I'm just going to sort the list in this patch to have everything in
 alphabetic order.

 In a prereq patch then you (hopefully) mean?

Does reordering the already out-of-whack list worth its own patch? I
just reordered it as part of this patch that adds to it.


 +#include public/memory.h

 This can't be enough (nor can I see why it's needed here), or else ...

 +/* Resumes the running of the VCPU, restarting the last instruction */
 +void monitor_resume(struct domain *d);

 ... struct domain may end up being a forward reference (with scope
 restricted to monitor_resume()).

 I'll revisit the headers needed for this one but it did build fine.

 Sure - presumably because the including sites included what is needed
 up front.

Probably. Looking at this header all it would need is xen/sched.h for
the definition of struct domain.

 Jan

Thanks,
Tamas

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


Re: [Xen-devel] [RFC PATCH V2 3/8] xen/mem_paging: Convert mem_event_op to mem_paging_op

2015-01-22 Thread Tamas K Lengyel
On Thu, Jan 22, 2015 at 4:09 PM, Jan Beulich jbeul...@suse.com wrote:
 On 18.01.15 at 16:17, tamas.leng...@zentific.com wrote:
 --- a/xen/arch/x86/mm/mem_paging.c
 +++ b/xen/arch/x86/mm/mem_paging.c
 @@ -25,31 +25,31 @@
  #include xen/mem_event.h


 -int mem_paging_memop(struct domain *d, xen_mem_event_op_t *mec)
 +int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *mpc)
  {
  if ( unlikely(!d-mem_event-paging.ring_page) )
  return -ENODEV;

 -switch( mec-op )
 +switch( mpc-op )
  {
  case XENMEM_paging_op_nominate:
  {
 -unsigned long gfn = mec-gfn;
 +unsigned long gfn = mpc-gfn;
  return p2m_mem_paging_nominate(d, gfn);

 If you fiddle with this, please fix obvious style issues - here, blank
 line after declaration(s). Albeit in the particular cases here I wonder
 whether the local variable is really helpful.

Ack.


 --- a/xen/common/mem_event.c
 +++ b/xen/common/mem_event.c
 @@ -474,7 +474,7 @@ int do_mem_event_op(int op, uint32_t domain, void *arg)
  {
  #ifdef HAS_MEM_PAGING
  case XENMEM_paging_op:
 -ret = mem_paging_memop(d, (xen_mem_event_op_t *) arg);
 +ret = mem_paging_memop(d, (xen_mem_paging_op_t *) arg);

 Afaict the cast is useless and should be dropped rather than replaced.

Ack.


 --- a/xen/include/public/memory.h
 +++ b/xen/include/public/memory.h
 @@ -372,7 +372,7 @@ typedef struct xen_pod_target xen_pod_target_t;
  #define XENMEM_paging_op_evict  1
  #define XENMEM_paging_op_prep   2

 -struct xen_mem_event_op {
 +struct xen_mem_paging_op {
  uint8_t op; /* XENMEM_*_op_* */

 Especially this comment makes me think this was originally intended
 for more than just paging. Are we really determined for this to no
 longer be the case? If so, the comment should be updated too.

Ack. The only thing I could imagine is that sharing was intended to be
moved over to use this, but that never happened.

Tamas


 Jan


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


Re: [Xen-devel] [RFC PATCH V2 1/8] xen/mem_event: Cleanup of mem_event structures

2015-01-22 Thread Tamas K Lengyel
On Thu, Jan 22, 2015 at 5:00 PM, Jan Beulich jbeul...@suse.com wrote:
 On 22.01.15 at 16:34, tamas.leng...@zentific.com wrote:
 On Thu, Jan 22, 2015 at 4:00 PM, Jan Beulich jbeul...@suse.com wrote:
 On 18.01.15 at 16:17, tamas.leng...@zentific.com wrote:
 --- a/xen/include/public/mem_event.h
 +++ b/xen/include/public/mem_event.h
 @@ -27,9 +27,15 @@
  #ifndef _XEN_PUBLIC_MEM_EVENT_H
  #define _XEN_PUBLIC_MEM_EVENT_H

 +#if !defined(__XEN__)  !defined(__XEN_TOOLS__)
 +#error vm event operations are intended for use only by Xen or node
 control tools
 +#endif
 +
  #include xen.h
  #include io/ring.h

 +#define MEM_EVENT_INTERFACE_VERSION 0x0001

 This doesn't appear to be used anywhere, and hence isn't useful to
 add here.

 It is intended to be used to establish an API version for backwards
 compatibility. We don't have any backwards compatibility checks at
 this point, but this will change as soon as we extend this interface
 as things go forward in the future.

 But without the caller passing you the version of the ABI it uses,
 how do you want to do such compatibility handling?

True. I was more imagining this flag to be used by the user to
determine (and know) what Xen supports. Currently we have to deduce
that by checking for various functions and structures being defined.
This would just simply that process for the user.


 @@ -48,16 +54,27 @@
   */
  #define MEM_EVENT_FLAG_EMULATE_NOWRITE (1  6)

 -/* Reasons for the memory event request */
 -#define MEM_EVENT_REASON_UNKNOWN 0/* typical reason */
 -#define MEM_EVENT_REASON_VIOLATION   1/* access violation, GFN is
 address */
 -#define MEM_EVENT_REASON_CR0 2/* CR0 was hit: gfn is new CR0
 value, gla is previous */
 -#define MEM_EVENT_REASON_CR3 3/* CR3 was hit: gfn is new CR3
 value, gla is previous */
 -#define MEM_EVENT_REASON_CR4 4/* CR4 was hit: gfn is new CR4
 value, gla is previous */
 -#define MEM_EVENT_REASON_INT35/* int3 was hit: gla/gfn are RIP
 */
 -#define MEM_EVENT_REASON_SINGLESTEP  6/* single step was invoked:
 gla/gfn are RIP */
 -#define MEM_EVENT_REASON_MSR 7/* MSR was hit: gfn is MSR 
 value,
 gla is MSR address;
 - does NOT honour
 HVMPME_onchangeonly */
 +/* Reasons for the vm event request */
 +/* Default case */
 +#define MEM_EVENT_REASON_UNKNOWN 0
 +/* Memory access violation */
 +#define MEM_EVENT_REASON_MEM_ACCESS_VIOLATION1
 +/* Memory sharing event */
 +#define MEM_EVENT_REASON_MEM_SHARING 2
 +/* Memory paging event */
 +#define MEM_EVENT_REASON_MEM_PAGING  3
 +/* CR0 was updated */
 +#define MEM_EVENT_REASON_CR0 4
 +/* CR3 was updated */
 +#define MEM_EVENT_REASON_CR3 5
 +/* CR4 was updated */
 +#define MEM_EVENT_REASON_CR4 6
 +/* Debug operation executed (int3) */
 +#define MEM_EVENT_REASON_INT37
 +/* Single-step (MTF) */
 +#define MEM_EVENT_REASON_SINGLESTEP  8
 +/* An MSR was updated. Does NOT honour HVMPME_onchangeonly */
 +#define MEM_EVENT_REASON_MSR 9

 I see you rename these a second time in patch 5 - can't this renaming
 be reduced to just one?

 I didn't rename anything here, just updated the comments.

 Afaics MEM_EVENT_REASON_VIOLATION became
 MEM_EVENT_REASON_MEM_ACCESS_VIOLATION,
 MEM_EVENT_REASON_MEM_{SHARING,PAGING} got
 introduced, and many other got renumbered. And from a
 trivial perspective - if what you said was true, the diff could
 have retained every other line (as you then would have to
 insert further blanks either).

Ah yes, sorry for the noise. I was only looking at the last couple
defines and missed that we actually changed the others. The renaming
certainly can be done later, but the introduction of the new defines
needs to happen here.


 @@ -97,16 +114,16 @@ struct mem_event_regs_x86 {
  uint32_t _pad;
  };

 -typedef struct mem_event_st {
 -uint32_t flags;
 -uint32_t vcpu_id;
 +struct mem_event_regs {
 +union {
 +struct mem_event_regs_x86 x86;
 +};
 +};

 No non-standard (C89) features in public headers please.

 Elaborate please? I have this union as we will likely have ARM
 registers as well soon. I guess it can wait and be introduced when the
 ARM side catches up.

 But the union has no field name.

I see. I'll just move this union into mem_event_st and name it regs there.


 +struct mem_event_mem_access_data {
  uint64_t gfn;
  uint64_t offset;
  uint64_t gla; /* if gla_valid */
 -
 -uint32_t p2mt;
 -
  uint16_t access_r:1;
  uint16_t access_w:1;
  uint16_t access_x:1;

 I also wonder how well thought through the use of bit fields here is.

 It saves some space on the ring. Maybe a uint8_t is enough.

 The same can be achieved with a flags field and a set of constants.

True. I prefer having the variables directly describing its values
instead of having 

Re: [Xen-devel] [RFC PATCH V2 5/8] xen/mem_event: Rename mem_event to vm_event

2015-01-22 Thread Tamas K Lengyel
On Thu, Jan 22, 2015 at 3:52 PM, Tim Deegan t...@xen.org wrote:
 At 16:17 +0100 on 18 Jan (1421594278), Tamas K Lengyel wrote:
 The mem_event system has originally been used to deliver memory event
 related information to helper programs located in a domain. However,
 the usage of this sub-system have since been expanded to include non-memory
 related events as well, such as register changes, debugging and 
 singlestepping.
 Therefore, renaming the system vm_event more accurately describes the 
 actual
 usage of the subsystem.

 In this patch I also clear up the ambiguities that resulted from the 
 interchanged
 mem_event and mem_access terminology.

 Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com

 This patch is pretty much unreviewable in that it is both renames and
 edits files, but I'm OK with the general intent.  I see Andrew's
 already suggested some git runes to handle the rename better.

Ack, I'll go with Andrew's route: first introducing the vm_event
system in one patch; second moving everything over to the new naming;
third removing the old mem_event files. This will go somewhat against
the Xen convention of introducing code only when it is immediately
used, but for reviewing purposes IMHO it would be cleaner (or just
merge step and 12 into one patch?).

Thanks,
Tamas


 Cheers,

 Tim.

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


Re: [Xen-devel] [RFC PATCH V2 6/8] xen/vm_event: Decouple vm_event and mem_access.

2015-01-22 Thread Tamas K Lengyel
On Thu, Jan 22, 2015 at 3:56 PM, Tim Deegan t...@xen.org wrote:
 At 16:17 +0100 on 18 Jan (1421594279), Tamas K Lengyel wrote:
 The vm_event subsystem has been artifically tied to the presence of 
 mem_access.
 While mem_access does depend on vm_event, vm_event is an entirely independent
 subsystem that can be used for arbitrary function-offloading to helper apps 
 in
 domains. This patch removes the dependency that mem_access needs to be 
 supported
 in order to enable vm_event.

 Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com

 For the x86/mem-event stuff,

 Acked-by: Tim Deegan t...@xen.org

 though you might want to check that it DTRT in an Arm build.

Thanks, good point, will do!

Tamas


 Cheers,

 Tim.

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


Re: [Xen-devel] [RFC PATCH V2 8/8] x86/hvm: factor out vm_event related functions into separate file

2015-01-22 Thread Tamas K Lengyel
On Thu, Jan 22, 2015 at 4:00 PM, Tim Deegan t...@xen.org wrote:
 At 16:18 +0100 on 18 Jan (1421594281), Tamas K Lengyel wrote:
 To avoid growing hvm.c these functions can be stored
 separately.

 Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com

 Assuming this is just code motion, it seems like a good idea to me,
 with one nit:

 --- a/xen/arch/x86/hvm/Makefile
 +++ b/xen/arch/x86/hvm/Makefile
 @@ -22,4 +22,5 @@ obj-y += vlapic.o
  obj-y += vmsi.o
  obj-y += vpic.o
  obj-y += vpt.o
 -obj-y += vpmu.o
 \ No newline at end of file
 +obj-y += vpmu.o
 +obj-y += event.o

 This list is in alphabetical order; please keep it that way.

Noted!

Thanks,
Tamas

 With that fixed,

 Acked-by: Tim Deegan t...@xen.org

 Cheers,

 Tim.

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


Re: [Xen-devel] [RFC PATCH V2 2/8] xen/mem_event: Rename the mem_event ring from 'access' to 'monitor'

2015-01-22 Thread Tamas K Lengyel
On Thu, Jan 22, 2015 at 4:02 PM, Jan Beulich jbeul...@suse.com wrote:
 On 18.01.15 at 16:17, tamas.leng...@zentific.com wrote:
 --- a/xen/include/public/domctl.h
 +++ b/xen/include/public/domctl.h
 @@ -775,7 +775,7 @@ struct xen_domctl_gdbsx_domstatus {
  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE1

  /*
 - * Access permissions.
 + * Monitor permissions.

 permissions?

 Jan

Ack, will do another sweep to make the comments more meaningful and
not just a mere word-replace.

Tamas

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


Re: [Xen-devel] [RFC PATCH V2 1/8] xen/mem_event: Cleanup of mem_event structures

2015-01-22 Thread Tamas K Lengyel
On Thu, Jan 22, 2015 at 4:00 PM, Jan Beulich jbeul...@suse.com wrote:
 On 18.01.15 at 16:17, tamas.leng...@zentific.com wrote:
 --- a/xen/include/Makefile
 +++ b/xen/include/Makefile
 @@ -90,7 +90,7 @@ ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))

  all: headers.chk

 -headers.chk: $(filter-out public/arch-% public/%ctl.h public/xsm/%
 public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) $(public-y)) Makefile
 +headers.chk: $(filter-out public/arch-% public/%ctl.h public/mem_event.h
 public/xsm/% public/%hvm/save.h, $(wildcard public/*.h public/*/*.h)
 $(public-y)) Makefile

 I think you should finally break this already too long line. But of course
 first of all you'll want to explain why the addition is necessary/correct.
 The mere fact that this now becomes a tools-only interface isn't
 enough imo - some of the other headers excluded here would better
 undergo the checking too, just that first they would need cleaning up.

I have to revisit what is actually going on here, I believe I had to
add this to get Xen to build. On a second look not sure why that was.


 --- a/xen/include/public/mem_event.h
 +++ b/xen/include/public/mem_event.h
 @@ -27,9 +27,15 @@
  #ifndef _XEN_PUBLIC_MEM_EVENT_H
  #define _XEN_PUBLIC_MEM_EVENT_H

 +#if !defined(__XEN__)  !defined(__XEN_TOOLS__)
 +#error vm event operations are intended for use only by Xen or node
 control tools
 +#endif
 +
  #include xen.h
  #include io/ring.h

 +#define MEM_EVENT_INTERFACE_VERSION 0x0001

 This doesn't appear to be used anywhere, and hence isn't useful to
 add here.

It is intended to be used to establish an API version for backwards
compatibility. We don't have any backwards compatibility checks at
this point, but this will change as soon as we extend this interface
as things go forward in the future.


 @@ -48,16 +54,27 @@
   */
  #define MEM_EVENT_FLAG_EMULATE_NOWRITE (1  6)

 -/* Reasons for the memory event request */
 -#define MEM_EVENT_REASON_UNKNOWN 0/* typical reason */
 -#define MEM_EVENT_REASON_VIOLATION   1/* access violation, GFN is
 address */
 -#define MEM_EVENT_REASON_CR0 2/* CR0 was hit: gfn is new CR0
 value, gla is previous */
 -#define MEM_EVENT_REASON_CR3 3/* CR3 was hit: gfn is new CR3
 value, gla is previous */
 -#define MEM_EVENT_REASON_CR4 4/* CR4 was hit: gfn is new CR4
 value, gla is previous */
 -#define MEM_EVENT_REASON_INT35/* int3 was hit: gla/gfn are RIP
 */
 -#define MEM_EVENT_REASON_SINGLESTEP  6/* single step was invoked:
 gla/gfn are RIP */
 -#define MEM_EVENT_REASON_MSR 7/* MSR was hit: gfn is MSR value,
 gla is MSR address;
 - does NOT honour 
 HVMPME_onchangeonly */
 +/* Reasons for the vm event request */
 +/* Default case */
 +#define MEM_EVENT_REASON_UNKNOWN 0
 +/* Memory access violation */
 +#define MEM_EVENT_REASON_MEM_ACCESS_VIOLATION1
 +/* Memory sharing event */
 +#define MEM_EVENT_REASON_MEM_SHARING 2
 +/* Memory paging event */
 +#define MEM_EVENT_REASON_MEM_PAGING  3
 +/* CR0 was updated */
 +#define MEM_EVENT_REASON_CR0 4
 +/* CR3 was updated */
 +#define MEM_EVENT_REASON_CR3 5
 +/* CR4 was updated */
 +#define MEM_EVENT_REASON_CR4 6
 +/* Debug operation executed (int3) */
 +#define MEM_EVENT_REASON_INT37
 +/* Single-step (MTF) */
 +#define MEM_EVENT_REASON_SINGLESTEP  8
 +/* An MSR was updated. Does NOT honour HVMPME_onchangeonly */
 +#define MEM_EVENT_REASON_MSR 9

 I see you rename these a second time in patch 5 - can't this renaming
 be reduced to just one?

I didn't rename anything here, just updated the comments.


 @@ -97,16 +114,16 @@ struct mem_event_regs_x86 {
  uint32_t _pad;
  };

 -typedef struct mem_event_st {
 -uint32_t flags;
 -uint32_t vcpu_id;
 +struct mem_event_regs {
 +union {
 +struct mem_event_regs_x86 x86;
 +};
 +};

 No non-standard (C89) features in public headers please.

Elaborate please? I have this union as we will likely have ARM
registers as well soon. I guess it can wait and be introduced when the
ARM side catches up.


 +struct mem_event_mem_access_data {
  uint64_t gfn;
  uint64_t offset;
  uint64_t gla; /* if gla_valid */
 -
 -uint32_t p2mt;
 -
  uint16_t access_r:1;
  uint16_t access_w:1;
  uint16_t access_x:1;

 I also wonder how well thought through the use of bit fields here is.

It saves some space on the ring. Maybe a uint8_t is enough.


 +struct mem_event_int3_data {
 +uint64_t gfn;
 +uint64_t gla;
 +};
 +
 +struct mem_event_singlestep_data {
 +uint64_t gfn;
 +uint64_t gla;
 +};

 I may lack some understanding of the interfaces here, but what do
 gfn and gla have to do with int3 and single-step events?

These contained auxiliary info about the instruction triggering the
event. It is somewhat 

Re: [Xen-devel] [RFC PATCH V2 0/8] xen: Clean-up of mem_event subsystem

2015-01-21 Thread Tamas K Lengyel
 I also wonder whether it might be easier to organise the series along
 the lines of introducing vm_event, move the existing interfaces across,
 then deleting mem_event.  Lets see how easy it is to review in its
 current form first though.

 ~Andrew

Ack, that indeed might be easier to review. I'm OK with going that
route if preferred!

Tamas

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


[Xen-devel] [RFC PATCH V2 0/8] xen: Clean-up of mem_event subsystem

2015-01-18 Thread Tamas K Lengyel
This patch series aims to clean up the mem_event subsystem within Xen. The
original use-case for this system was to allow external helper applications
running in privileged domains to control various memory operations performed
by Xen. Amongs these were paging, sharing and access control. The subsystem
has since been extended to also deliver non-memory related events, namely
various HVM debugging events (INT3, MTF, MOV-TO-CR, MOV-TO-MSR). The structures
and naming of related functions however has not caught up to these new
use-cases, thus leaving many ambigouities in the code.

In this series we convert the mem_event structures to a union of sub-structures
which clearly define the scope of information that is transmitted via the event
delivery mechanism. Afterwards, we clean up the naming of the structures and
related functions to more clearly be in line with their actual operations.

This RFC PATCH series is also available at:
https://github.com/tklengyel/xen/tree/mem_event_cleanup2

Razvan Cojocaru (1):
  xen/mem_event: Cleanup of mem_event structures

Tamas K Lengyel (7):
  xen/mem_event: Rename the mem_event ring from 'access' to 'monitor'
  xen/mem_paging: Convert mem_event_op to mem_paging_op
  x86/hvm: rename hvm_memory_event_* functions to hvm_event_*
  xen/mem_event: Rename mem_event to vm_event
  xen/vm_event: Decouple vm_event and mem_access.
  tools/tests: Clean-up tools/tests/xen-access
  x86/hvm: factor out vm_event related functions into separate file

 docs/misc/pvh-readme.txt|   2 +-
 tools/libxc/Makefile|   2 +-
 tools/libxc/xc_domain_restore.c |  14 +-
 tools/libxc/xc_domain_save.c|   4 +-
 tools/libxc/xc_hvm_build_x86.c  |   2 +-
 tools/libxc/xc_mem_access.c |  10 +-
 tools/libxc/xc_mem_event.c  | 178 -
 tools/libxc/xc_mem_paging.c |  38 +-
 tools/libxc/xc_memshr.c |  12 +-
 tools/libxc/xc_private.h|   9 +-
 tools/libxc/xc_vm_event.c   | 162 
 tools/libxc/xg_save_restore.h   |   2 +-
 tools/tests/xen-access/xen-access.c | 210 --
 tools/xenpaging/pagein.c|   2 +-
 tools/xenpaging/xenpaging.c | 150 
 tools/xenpaging/xenpaging.h |   8 +-
 xen/arch/x86/domain.c   |   2 +-
 xen/arch/x86/domctl.c   |   4 +-
 xen/arch/x86/hvm/Makefile   |   3 +-
 xen/arch/x86/hvm/emulate.c  |   4 +-
 xen/arch/x86/hvm/event.c| 195 ++
 xen/arch/x86/hvm/hvm.c  | 154 +---
 xen/arch/x86/hvm/vmx/vmcs.c |   4 +-
 xen/arch/x86/hvm/vmx/vmx.c  |   7 +-
 xen/arch/x86/mm/hap/nested_ept.c|   4 +-
 xen/arch/x86/mm/hap/nested_hap.c|   4 +-
 xen/arch/x86/mm/mem_paging.c|  16 +-
 xen/arch/x86/mm/mem_sharing.c   |  31 +-
 xen/arch/x86/mm/p2m-pod.c   |   4 +-
 xen/arch/x86/mm/p2m-pt.c|   4 +-
 xen/arch/x86/mm/p2m.c   | 213 ++-
 xen/arch/x86/x86_64/compat/mm.c |  12 +-
 xen/arch/x86/x86_64/mm.c|  13 +-
 xen/common/Makefile |   2 +-
 xen/common/domain.c |  12 +-
 xen/common/domctl.c |   6 +-
 xen/common/mem_access.c |  24 +-
 xen/common/mem_event.c  | 742 
 xen/common/vm_event.c   | 742 
 xen/drivers/passthrough/pci.c   |   2 +-
 xen/include/Makefile|   2 +-
 xen/include/asm-arm/p2m.h   |   6 +-
 xen/include/asm-x86/domain.h|   4 +-
 xen/include/asm-x86/hvm/emulate.h   |   2 +-
 xen/include/asm-x86/hvm/event.h |  40 ++
 xen/include/asm-x86/hvm/hvm.h   |  11 -
 xen/include/asm-x86/mem_paging.h|   2 +-
 xen/include/asm-x86/p2m.h   |  16 +-
 xen/include/public/domctl.h |  44 +--
 xen/include/public/hvm/params.h |   2 +-
 xen/include/public/mem_event.h  | 134 ---
 xen/include/public/memory.h |   6 +-
 xen/include/public/vm_event.h   | 197 ++
 xen/include/xen/mem_access.h|   4 +-
 xen/include/xen/mem_event.h | 143 ---
 xen/include/xen/p2m-common.h|   4 +-
 xen/include/xen/sched.h |  24 +-
 xen/include/xen/vm_event.h  |  87 +
 xen/include/xsm/dummy.h |   6 +-
 xen/include/xsm/xsm.h   |  14 +-
 xen/xsm/dummy.c |   6 +-
 xen/xsm/flask/hooks.c   |  36 +-
 xen/xsm/flask/policy/access_vectors |   2 +-
 63 files changed, 1909 insertions(+), 1892 deletions(-)
 delete mode 100644 tools/libxc/xc_mem_event.c
 create mode 100644 tools/libxc/xc_vm_event.c
 create mode 100644 xen/arch/x86/hvm/event.c
 delete mode 100644 xen/common/mem_event.c
 create mode 100644 xen/common/vm_event.c
 create mode 100644 xen/include/asm-x86/hvm/event.h
 delete mode 100644 xen/include/public/mem_event.h
 create mode 100644 xen/include/public/vm_event.h
 delete mode 100644 xen/include/xen

[Xen-devel] [RFC PATCH V2 8/8] x86/hvm: factor out vm_event related functions into separate file

2015-01-18 Thread Tamas K Lengyel
To avoid growing hvm.c these functions can be stored
separately.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
 xen/arch/x86/hvm/Makefile   |   3 +-
 xen/arch/x86/hvm/event.c| 195 
 xen/arch/x86/hvm/hvm.c  | 163 +
 xen/arch/x86/hvm/vmx/vmx.c  |   1 +
 xen/include/asm-x86/hvm/event.h |  40 +
 xen/include/asm-x86/hvm/hvm.h   |  11 ---
 6 files changed, 239 insertions(+), 174 deletions(-)
 create mode 100644 xen/arch/x86/hvm/event.c
 create mode 100644 xen/include/asm-x86/hvm/event.h

diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index eea..2389923 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -22,4 +22,5 @@ obj-y += vlapic.o
 obj-y += vmsi.o
 obj-y += vpic.o
 obj-y += vpt.o
-obj-y += vpmu.o
\ No newline at end of file
+obj-y += vpmu.o
+obj-y += event.o
diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
new file mode 100644
index 000..96d1748
--- /dev/null
+++ b/xen/arch/x86/hvm/event.c
@@ -0,0 +1,195 @@
+/*
+* event.c: Common hardware virtual machine event abstractions.
+*
+* Copyright (c) 2004, Intel Corporation.
+* Copyright (c) 2005, International Business Machines Corporation.
+* Copyright (c) 2008, Citrix Systems, Inc.
+*
+* This program is free software; you can redistribute it and/or modify it
+* under the terms and conditions of the GNU General Public License,
+* version 2, as published by the Free Software Foundation.
+*
+* This program is distributed in the hope 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, write to the Free Software Foundation, Inc., 59 Temple
+* Place - Suite 330, Boston, MA 02111-1307 USA.
+*/
+
+#include xen/vm_event.h
+#include xen/paging.h
+#include public/vm_event.h
+
+static void hvm_event_fill_regs(vm_event_request_t *req)
+{
+const struct cpu_user_regs *regs = guest_cpu_user_regs();
+const struct vcpu *curr = current;
+
+req-regs.x86.rax = regs-eax;
+req-regs.x86.rcx = regs-ecx;
+req-regs.x86.rdx = regs-edx;
+req-regs.x86.rbx = regs-ebx;
+req-regs.x86.rsp = regs-esp;
+req-regs.x86.rbp = regs-ebp;
+req-regs.x86.rsi = regs-esi;
+req-regs.x86.rdi = regs-edi;
+
+req-regs.x86.r8  = regs-r8;
+req-regs.x86.r9  = regs-r9;
+req-regs.x86.r10 = regs-r10;
+req-regs.x86.r11 = regs-r11;
+req-regs.x86.r12 = regs-r12;
+req-regs.x86.r13 = regs-r13;
+req-regs.x86.r14 = regs-r14;
+req-regs.x86.r15 = regs-r15;
+
+req-regs.x86.rflags = regs-eflags;
+req-regs.x86.rip= regs-eip;
+
+req-regs.x86.msr_efer = curr-arch.hvm_vcpu.guest_efer;
+req-regs.x86.cr0 = curr-arch.hvm_vcpu.guest_cr[0];
+req-regs.x86.cr3 = curr-arch.hvm_vcpu.guest_cr[3];
+req-regs.x86.cr4 = curr-arch.hvm_vcpu.guest_cr[4];
+}
+
+static int hvm_event_traps(long parameters, vm_event_request_t *req)
+{
+int rc;
+struct vcpu *v = current;
+struct domain *d = v-domain;
+
+if ( !(parameters  HVMPME_MODE_MASK) )
+return 0;
+
+rc = vm_event_claim_slot(d, d-vm_event-monitor);
+if ( rc == -ENOSYS )
+{
+/* If there was no ring to handle the event, then
+ * simple continue executing normally. */
+return 1;
+}
+else if ( rc  0 )
+return rc;
+
+if ( (parameters  HVMPME_MODE_MASK) == HVMPME_mode_sync )
+{
+req-flags |= VM_EVENT_FLAG_VCPU_PAUSED;
+vm_event_vcpu_pause(v);
+}
+
+hvm_event_fill_regs(req);
+vm_event_put_request(d, d-vm_event-monitor, req);
+
+return 1;
+}
+
+void hvm_event_cr0(unsigned long value, unsigned long old)
+{
+vm_event_request_t req = {
+.reason = VM_EVENT_REASON_CR0,
+.vcpu_id = current-vcpu_id,
+.cr_event.new_value = value,
+.cr_event.old_value = old
+};
+
+long parameters = current-domain-arch.hvm_domain
+.params[HVM_PARAM_MEMORY_EVENT_CR0];
+
+if ( (parameters  HVMPME_onchangeonly)  (value == old) )
+return;
+
+hvm_event_traps(parameters, req);
+}
+
+void hvm_event_cr3(unsigned long value, unsigned long old)
+{
+vm_event_request_t req = {
+.reason = VM_EVENT_REASON_CR3,
+.vcpu_id = current-vcpu_id,
+.cr_event.new_value = value,
+.cr_event.old_value = old
+};
+
+long parameters = current-domain-arch.hvm_domain
+.params[HVM_PARAM_MEMORY_EVENT_CR3];
+
+if ( (parameters  HVMPME_onchangeonly)  (value == old) )
+return;
+
+hvm_event_traps(parameters, req);
+}
+
+void hvm_event_cr4(unsigned long value, unsigned long old)
+{
+vm_event_request_t req = {
+.reason = VM_EVENT_REASON_CR4

[Xen-devel] [RFC PATCH V2 6/8] xen/vm_event: Decouple vm_event and mem_access.

2015-01-18 Thread Tamas K Lengyel
The vm_event subsystem has been artifically tied to the presence of mem_access.
While mem_access does depend on vm_event, vm_event is an entirely independent
subsystem that can be used for arbitrary function-offloading to helper apps in
domains. This patch removes the dependency that mem_access needs to be supported
in order to enable vm_event.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
 xen/common/Makefile|  2 +-
 xen/include/xen/vm_event.h | 56 --
 xen/include/xsm/dummy.h|  2 --
 xen/include/xsm/xsm.h  |  2 --
 xen/xsm/dummy.c|  2 --
 xen/xsm/flask/hooks.c  | 32 +++---
 6 files changed, 14 insertions(+), 82 deletions(-)

diff --git a/xen/common/Makefile b/xen/common/Makefile
index f1b73a3..2ccf0bb 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -52,9 +52,9 @@ obj-y += tmem_xen.o
 obj-y += radix-tree.o
 obj-y += rbtree.o
 obj-y += lzo.o
+obj-y += vm_event.o
 obj-$(HAS_PDX) += pdx.o
 obj-$(HAS_MEM_ACCESS) += mem_access.o
-obj-$(HAS_MEM_ACCESS) += vm_event.o
 
 obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo 
unlz4 earlycpio,$(n).init.o)
 
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index 988ea42..477ef7e 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -26,8 +26,6 @@
 
 #include xen/sched.h
 
-#ifdef HAS_MEM_ACCESS
-
 /* Clean up on domain destruction */
 void vm_event_cleanup(struct domain *d);
 
@@ -76,60 +74,6 @@ int vm_event_domctl(struct domain *d, 
xen_domctl_vm_event_op_t *mec,
 void vm_event_vcpu_pause(struct vcpu *v);
 void vm_event_vcpu_unpause(struct vcpu *v);
 
-#else
-
-static inline void vm_event_cleanup(struct domain *d) {}
-
-static inline bool_t vm_event_check_ring(struct vm_event_domain *med)
-{
-return 0;
-}
-
-static inline int vm_event_claim_slot(struct domain *d,
-struct vm_event_domain *med)
-{
-return -ENOSYS;
-}
-
-static inline int vm_event_claim_slot_nosleep(struct domain *d,
-struct vm_event_domain *med)
-{
-return -ENOSYS;
-}
-
-static inline
-void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *med)
-{}
-
-static inline
-void vm_event_put_request(struct domain *d, struct vm_event_domain *med,
-vm_event_request_t *req)
-{}
-
-static inline
-int vm_event_get_response(struct domain *d, struct vm_event_domain *med,
-   vm_event_response_t *rsp)
-{
-return -ENOSYS;
-}
-
-static inline int do_vm_event_op(int op, uint32_t domain, void *arg)
-{
-return -ENOSYS;
-}
-
-static inline
-int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *mec,
- XEN_GUEST_HANDLE_PARAM(void) u_domctl)
-{
-return -ENOSYS;
-}
-
-static inline void vm_event_vcpu_pause(struct vcpu *v) {}
-static inline void vm_event_vcpu_unpause(struct vcpu *v) {}
-
-#endif /* HAS_MEM_ACCESS */
-
 #endif /* __VM_EVENT_H__ */
 
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 4227093..50ee929 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -513,7 +513,6 @@ static XSM_INLINE int xsm_hvm_param_nested(XSM_DEFAULT_ARG 
struct domain *d)
 return xsm_default_action(action, current-domain, d);
 }
 
-#ifdef HAS_MEM_ACCESS
 static XSM_INLINE int xsm_vm_event_control(XSM_DEFAULT_ARG struct domain *d, 
int mode, int op)
 {
 XSM_ASSERT_ACTION(XSM_PRIV);
@@ -525,7 +524,6 @@ static XSM_INLINE int xsm_vm_event_op(XSM_DEFAULT_ARG 
struct domain *d, int op)
 XSM_ASSERT_ACTION(XSM_DM_PRIV);
 return xsm_default_action(action, current-domain, d);
 }
-#endif
 
 #ifdef CONFIG_X86
 static XSM_INLINE int xsm_do_mca(XSM_DEFAULT_VOID)
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index cff9d35..61c5acc 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -141,10 +141,8 @@ struct xsm_operations {
 int (*hvm_param_nested) (struct domain *d);
 int (*get_vnumainfo) (struct domain *d);
 
-#ifdef HAS_MEM_ACCESS
 int (*vm_event_control) (struct domain *d, int mode, int op);
 int (*vm_event_op) (struct domain *d, int op);
-#endif
 
 #ifdef CONFIG_X86
 int (*do_mca) (void);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 25fca68..6d12d32 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -118,10 +118,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
 set_to_dummy_if_null(ops, remove_from_physmap);
 set_to_dummy_if_null(ops, map_gmfn_foreign);
 
-#ifdef HAS_MEM_ACCESS
 set_to_dummy_if_null(ops, vm_event_control);
 set_to_dummy_if_null(ops, vm_event_op);
-#endif
 
 #ifdef CONFIG_X86
 set_to_dummy_if_null(ops, do_mca);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index c419543..5008b79 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -577,9 +577,7 @@ static int flask_domctl(struct domain *d, int

[Xen-devel] [RFC PATCH V2 7/8] tools/tests: Clean-up tools/tests/xen-access

2015-01-18 Thread Tamas K Lengyel
The spin-lock implementation in the xen-access test program is implemented
in a fashion that is actually incomplete. The x86 assembly that guarantees that
the lock is held by only one thread lacks the lock; instruction.

However, the spin-lock is not actually necessary in xen-access as it is not
multithreaded. The presence of the faulty implementation of the lock in a non-
mulithreaded environment is unnecessarily complicated for developers who are
trying to follow this code as a guide in implementing their own applications.
Thus, removing it from the code improves the clarity on the behavior of the
system.

Also converting functions that always return 0 to return to void, and making
the teardown function actually return an error code on error.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
 tools/tests/xen-access/xen-access.c | 99 +++--
 1 file changed, 19 insertions(+), 80 deletions(-)

diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index 3538323..80e4de9 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -45,56 +45,6 @@
 #define ERROR(a, b...) fprintf(stderr, a \n, ## b)
 #define PERROR(a, b...) fprintf(stderr, a : %s\n, ## b, strerror(errno))
 
-/* Spinlock and mem event definitions */
-
-#define SPIN_LOCK_UNLOCKED 0
-
-#define ADDR (*(volatile long *) addr)
-/**
- * test_and_set_bit - Set a bit and return its old value
- * @nr: Bit to set
- * @addr: Address to count from
- *
- * This operation is atomic and cannot be reordered.
- * It also implies a memory barrier.
- */
-static inline int test_and_set_bit(int nr, volatile void *addr)
-{
-int oldbit;
-
-asm volatile (
-btsl %2,%1\n\tsbbl %0,%0
-: =r (oldbit), =m (ADDR)
-: Ir (nr), m (ADDR) : memory);
-return oldbit;
-}
-
-typedef int spinlock_t;
-
-static inline void spin_lock(spinlock_t *lock)
-{
-while ( test_and_set_bit(1, lock) );
-}
-
-static inline void spin_lock_init(spinlock_t *lock)
-{
-*lock = SPIN_LOCK_UNLOCKED;
-}
-
-static inline void spin_unlock(spinlock_t *lock)
-{
-*lock = SPIN_LOCK_UNLOCKED;
-}
-
-static inline int spin_trylock(spinlock_t *lock)
-{
-return !test_and_set_bit(1, lock);
-}
-
-#define vm_event_ring_lock_init(_m)  spin_lock_init((_m)-ring_lock)
-#define vm_event_ring_lock(_m)   spin_lock((_m)-ring_lock)
-#define vm_event_ring_unlock(_m) spin_unlock((_m)-ring_lock)
-
 typedef struct vm_event {
 domid_t domain_id;
 xc_evtchn *xce_handle;
@@ -102,7 +52,6 @@ typedef struct vm_event {
 vm_event_back_ring_t back_ring;
 uint32_t evtchn_port;
 void *ring_page;
-spinlock_t ring_lock;
 } vm_event_t;
 
 typedef struct xenaccess {
@@ -180,6 +129,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t 
*xenaccess)
 if ( rc != 0 )
 {
 ERROR(Error tearing down domain xenaccess in xen);
+return rc;
 }
 }
 
@@ -191,6 +141,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t 
*xenaccess)
 if ( rc != 0 )
 {
 ERROR(Error unbinding event port);
+return rc;
 }
 }
 
@@ -201,6 +152,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t 
*xenaccess)
 if ( rc != 0 )
 {
 ERROR(Error closing event channel);
+return rc;
 }
 }
 
@@ -209,6 +161,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t 
*xenaccess)
 if ( rc != 0 )
 {
 ERROR(Error closing connection to xen);
+return rc;
 }
 xenaccess-xc_handle = NULL;
 
@@ -241,9 +194,6 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t 
domain_id)
 /* Set domain id */
 xenaccess-vm_event.domain_id = domain_id;
 
-/* Initialise lock */
-vm_event_ring_lock_init(xenaccess-vm_event);
-
 /* Enable mem_access */
 xenaccess-vm_event.ring_page =
 xc_mem_access_enable(xenaccess-xc_handle,
@@ -314,19 +264,24 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t 
domain_id)
 return xenaccess;
 
  err:
-xenaccess_teardown(xch, xenaccess);
+rc = xenaccess_teardown(xch, xenaccess);
+if ( rc )
+{
+ERROR(Failed to teardown xenaccess structure!\n);
+}
 
  err_iface:
 return NULL;
 }
 
-int get_request(vm_event_t *vm_event, vm_event_request_t *req)
+/*
+ * Note that this function is not thread safe.
+ */
+static void get_request(vm_event_t *vm_event, vm_event_request_t *req)
 {
 vm_event_back_ring_t *back_ring;
 RING_IDX req_cons;
 
-vm_event_ring_lock(vm_event);
-
 back_ring = vm_event-back_ring;
 req_cons = back_ring-req_cons;
 
@@ -337,19 +292,16 @@ int get_request(vm_event_t *vm_event, vm_event_request_t 
*req)
 /* Update ring */
 back_ring-req_cons = req_cons;
 back_ring-sring-req_event = req_cons + 1;
-
-vm_event_ring_unlock(vm_event);
-
-return 0;
 }
 
-static int put_response

Re: [Xen-devel] [PATCH 00/11] Alternate p2m: support multiple copies of host p2m

2015-01-16 Thread Tamas K Lengyel
On Thu, Jan 15, 2015 at 6:31 PM, Ed White edmund.h.wh...@intel.com wrote:
 On 01/15/2015 02:39 AM, Tamas K Lengyel wrote:
 There are ways of avoiding the
 single-step too, although I don't think that falls within the scope
 of this conversation.

 Ed

 I would be very interested in knowing how we can avoid the singlestep
 phase. Are you envisioning using this with a split-TLB? IMHO this is a
 pretty critical component of effectively using the new feature so
 should be within scope of this discussion.


 It's an optimization certainly, but it's not required, and it's not
 a technique we have placed in the public domain. You could try talking
 to us under NDA or figure it out for yourself, but I can't detail
 it here.

 Ed

That's unfortunate. I would have been happy to extend the xen-access
test tool to exercise this feature but contributing code that is known
to be sub-optimal from the beginning just doesn't feel right.

Tamas

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


Re: [Xen-devel] [RFC PATCH V2 8/8] x86/hvm: factor out vm_event related functions into separate file

2015-01-22 Thread Tamas K Lengyel
On Thu, Jan 22, 2015 at 5:25 PM, Jan Beulich jbeul...@suse.com wrote:
 On 18.01.15 at 16:18, tamas.leng...@zentific.com wrote:
 +static int hvm_event_traps(long parameters, vm_event_request_t *req)
 +{
 +int rc;
 +struct vcpu *v = current;
 +struct domain *d = v-domain;

 Unless the intention is to have an exact 1:1 copy of the original,
 please use curr and currd here respectively.

Ack.


 +void hvm_event_cr0(unsigned long value, unsigned long old)
 +{
 +vm_event_request_t req = {
 +.reason = VM_EVENT_REASON_CR0,
 +.vcpu_id = current-vcpu_id,
 +.cr_event.new_value = value,
 +.cr_event.old_value = old
 +};
 +
 +long parameters = current-domain-arch.hvm_domain
 +.params[HVM_PARAM_MEMORY_EVENT_CR0];

 And latch current into a local variable curr here and below.

Ack.


 +void hvm_event_msr(unsigned long msr, unsigned long value)
 +{
 +vm_event_request_t req = {
 +.reason = VM_EVENT_REASON_MSR,
 +.vcpu_id = current-vcpu_id,
 +.msr_event.msr = msr,
 +.msr_event.new_value = value,
 +};

 The .msr_event sub-structure also has an old_value member - how
 come this doesn't get filled (I realize the old code was this way,
 but I now doubt earlier patches are all correct in the regard).

Razvan might have more information on this side as I haven't really
touched MSR events. I vaguely recall some issues with having access to
the old MSR value?


 Jan


Thanks,
Tamas

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


Re: [Xen-devel] [RFC PATCH V2 8/8] x86/hvm: factor out vm_event related functions into separate file

2015-01-22 Thread Tamas K Lengyel
On Thu, Jan 22, 2015 at 5:32 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
 On 18/01/15 15:18, Tamas K Lengyel wrote:
 -void hvm_event_cr0(unsigned long value, unsigned long old)
 -{
 -vm_event_request_t req = {
 -.reason = VM_EVENT_REASON_CR0,
 -.vcpu_id = current-vcpu_id,
 -.cr_event.new_value = value,
 -.cr_event.old_value = old
 -};
 -
 -long parameters = current-domain-arch.hvm_domain
 -.params[HVM_PARAM_MEMORY_EVENT_CR0];

 (I realise this is probably not the best patch, but) As we are redoing
 the API with a hope of including PV and ARM guests, can we remove this
 use of hvm params?  This would probably involve a new setup hypercall
 subop to set up reporting preferences.

 ~Andrew

Ack, that would be certainly a useful addition. We would need to
define some new place to store these preferences for the domain.

Thanks,
Tamas

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


Re: [Xen-devel] [RFC PATCH V2 4/8] x86/hvm: rename hvm_memory_event_* functions to hvm_event_*

2015-01-22 Thread Tamas K Lengyel
On Thu, Jan 22, 2015 at 4:56 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
 On 18/01/15 15:17, Tamas K Lengyel wrote:
 The function names currently imply that these events are to be delivered via
 the memory_event subsystem. However, the naming is confusing as these events
 have nothing to do with actual memory events. Simply naming these functions
 hvm_event_* more accurately describe their usage.

 Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
 ---
  docs/misc/pvh-readme.txt  |  2 +-
  xen/arch/x86/hvm/hvm.c| 50 
 +--
  xen/arch/x86/hvm/vmx/vmx.c|  6 +++---
  xen/include/asm-x86/hvm/hvm.h | 12 +--
  4 files changed, 35 insertions(+), 35 deletions(-)

 diff --git a/docs/misc/pvh-readme.txt b/docs/misc/pvh-readme.txt
 index c5b3de4..bbd9dbe 100644
 --- a/docs/misc/pvh-readme.txt
 +++ b/docs/misc/pvh-readme.txt
 @@ -49,7 +49,7 @@ Following remain to be done for PVH:
 - AMD port.
 - 32bit PVH guest support in both linux and xen. Xen changes are tagged
   32bitfixme.
 -   - Add support for monitoring guest behavior. See hvm_memory_event* 
 functions
 +   - Add support for monitoring guest behavior. See hvm_event* functions
   in hvm.c
 - vcpu hotplug support
 - Live migration of PVH guests.
 diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
 index f936d51..1968865 100644
 --- a/xen/arch/x86/hvm/hvm.c
 +++ b/xen/arch/x86/hvm/hvm.c
 @@ -3229,7 +3229,7 @@ int hvm_set_cr0(unsigned long value)
  hvm_funcs.handle_cd(v, value);

  hvm_update_cr(v, 0, value);
 -hvm_memory_event_cr0(value, old_value);
 +hvm_event_cr0(value, old_value);

 I feel that if we are naming these things consistently, vm_event_$FOO
 would be better than hvm_event_$FOO.  A while ago there was interest
 in getting bits of the mem_event infrastructure working for PV guests,
 and the vm_event infrastructure is not inherently hvm specific.

 ~Andrew

Surely.

Thanks,
Tamas

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


Re: [Xen-devel] [PATCH V4 01/13] xen/mem_event: Cleanup of mem_event structures

2015-02-10 Thread Tamas K Lengyel
On Tue, Feb 10, 2015 at 5:17 PM, Jan Beulich jbeul...@suse.com wrote:
 Tamas K Lengyel tamas.leng...@zentific.com 02/10/15 2:51 PM 
 On Tue, Feb 10, 2015 at 1:52 PM, Jan Beulich jbeul...@suse.com wrote:
 On 09.02.15 at 19:53, tamas.leng...@zentific.com wrote:
 @@ -598,6 +600,12 @@ int mem_sharing_sharing_resume(struct domain *d)
  {
  struct vcpu *v;

 +if ( rsp.version != MEM_EVENT_INTERFACE_VERSION )
 +{
 +gdprintk(XENLOG_WARNING, mem_event interface version 
 mismatch!\n);

 Why gdprintk()?

Is that only for debug cases?

 I'm intending to propose compiling out alll dprintk() and gdprintk() instance 
 in
 non-debug builds. Right now they're preferable when the message is so terse
 that identifying its origin without file name and line number is difficult. 
 Clearly
 any non-debug messages shouldn't be of such poor quality.

I willwrap it into #ifndef NDEBUG as it is really only for debugging.


 @@ -1310,18 +1322,19 @@ void p2m_mem_paging_resume(struct domain *d)
  /* Fix p2m entry if the page was not dropped */
  if ( !(rsp.flags  MEM_EVENT_FLAG_DROP_PAGE) )
  {
 -gfn_lock(p2m, rsp.gfn, 0);
 -mfn = p2m-get_entry(p2m, rsp.gfn, p2mt, a, 0, NULL);
 +uint64_t gfn = rsp.u.mem_access.gfn;
 +gfn_lock(p2m, gfn, 0);

 Blank line between declarations and statements. Also - why uint64_t
 instead of just unsigned long?

The type of mem_access.gfn is uint64_t so its that for consistency.

 And the type most functions taking a gfn expect is unsigned long.

 Jan

Well, we need to have it as uint64_t in the shared public struct
definition so that the width of it is explicit. Unsigned long may be
32-bit depending on the compiler so it is going to be casted
somewhere. Whether it is preferred to be casted when assigned to a
local variable or when passed to the function is just a style question
- I'm fine with either.

Tamas

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


Re: [Xen-devel] [PATCH V4 01/13] xen/mem_event: Cleanup of mem_event structures

2015-02-10 Thread Tamas K Lengyel
On Tue, Feb 10, 2015 at 6:39 PM, Jan Beulich jbeul...@suse.com wrote:
 Tamas K Lengyel tamas.leng...@zentific.com 02/10/15 5:38 PM 
On Tue, Feb 10, 2015 at 5:17 PM, Jan Beulich jbeul...@suse.com wrote:
 Tamas K Lengyel tamas.leng...@zentific.com 02/10/15 2:51 PM 
 On Tue, Feb 10, 2015 at 1:52 PM, Jan Beulich jbeul...@suse.com wrote:
 On 09.02.15 at 19:53, tamas.leng...@zentific.com wrote:
 @@ -598,6 +600,12 @@ int mem_sharing_sharing_resume(struct domain *d)
  {
  struct vcpu *v;

 +if ( rsp.version != MEM_EVENT_INTERFACE_VERSION )
 +{
 +gdprintk(XENLOG_WARNING, mem_event interface version 
 mismatch!\n);

 Why gdprintk()?

Is that only for debug cases?

 I'm intending to propose compiling out alll dprintk() and gdprintk() 
 instance in
 non-debug builds. Right now they're preferable when the message is so terse
 that identifying its origin without file name and line number is difficult. 
 Clearly
 any non-debug messages shouldn't be of such poor quality.

I willwrap it into #ifndef NDEBUG as it is really only for debugging.

 That'll make the code even uglier, and won't address the question I 
 originally asked.

I just reused the function since I've seen it being used for printing
warnings. What would be the preffered print function to be used here?


 @@ -1310,18 +1322,19 @@ void p2m_mem_paging_resume(struct domain *d)
  /* Fix p2m entry if the page was not dropped */
  if ( !(rsp.flags  MEM_EVENT_FLAG_DROP_PAGE) )
  {
 -gfn_lock(p2m, rsp.gfn, 0);
 -mfn = p2m-get_entry(p2m, rsp.gfn, p2mt, a, 0, NULL);
 +uint64_t gfn = rsp.u.mem_access.gfn;
 +gfn_lock(p2m, gfn, 0);

 Blank line between declarations and statements. Also - why uint64_t
 instead of just unsigned long?

The type of mem_access.gfn is uint64_t so its that for consistency.

 And the type most functions taking a gfn expect is unsigned long.

Well, we need to have it as uint64_t in the shared public struct
definition so that the width of it is explicit. Unsigned long may be
32-bit depending on the compiler so it is going to be casted
somewhere.

 That's understood.

 Whether it is preferred to be casted when assigned to a
local variable or when passed to the function is just a style question
- I'm fine with either.

 As much as gfn function parameters are usually unsigned long, local
 variables are too iirc. So please follow suit.

Ack.


 Jan


Thanks,
Tamas

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


[Xen-devel] [PATCH V6 10/13] xen/vm_event: Decouple vm_event and mem_access.

2015-02-17 Thread Tamas K Lengyel
The vm_event subsystem has been artifically tied to the presence of mem_access.
While mem_access does depend on vm_event, vm_event is an entirely independent
subsystem that can be used for arbitrary function-offloading to helper apps in
domains. This patch removes the dependency that mem_access needs to be supported
in order to enable vm_event.

A new vm_event_resume function is introduced which pulls all responses off from
given ring and delegates handling to appropriate helper functions (if
necessary). By default, vm_event_resume just pulls the response from the ring
and unpauses the corresponding vCPU. This approach reduces code duplication
and present a single point of entry for the entire vm_event subsystem's
response handling mechanism.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
---
v4: Consolidate resume routines into vm_event_resume
Style fixes
Sort xen/common/Makefile to be alphabetical
v3: Move ring processing out from mem_access.c to monitor.c in common
---
 xen/arch/x86/mm/mem_sharing.c   | 32 ++---
 xen/arch/x86/mm/p2m.c   | 62 
 xen/common/Makefile | 18 +-
 xen/common/mem_access.c | 31 +---
 xen/common/vm_event.c   | 72 +++--
 xen/include/asm-x86/mem_sharing.h   |  1 -
 xen/include/asm-x86/p2m.h   |  2 +-
 xen/include/xen/mem_access.h| 14 ++--
 xen/include/xen/vm_event.h  | 58 ++
 xen/include/xsm/dummy.h |  2 --
 xen/include/xsm/xsm.h   |  4 ---
 xen/xsm/dummy.c |  2 --
 xen/xsm/flask/hooks.c   | 36 ---
 xen/xsm/flask/policy/access_vectors |  8 ++---
 14 files changed, 128 insertions(+), 214 deletions(-)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index e6572af..4959407 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -591,35 +591,6 @@ unsigned int mem_sharing_get_nr_shared_mfns(void)
 return (unsigned int)atomic_read(nr_shared_mfns);
 }
 
-int mem_sharing_sharing_resume(struct domain *d)
-{
-vm_event_response_t rsp;
-
-/* Get all requests off the ring */
-while ( vm_event_get_response(d, d-vm_event-share, rsp) )
-{
-struct vcpu *v;
-
-if ( rsp.version != VM_EVENT_INTERFACE_VERSION )
-{
-printk(XENLOG_G_WARNING vm_event interface version mismatch\n);
-continue;
-}
-
-/* Validate the vcpu_id in the response. */
-if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
-continue;
-
-v = d-vcpu[rsp.vcpu_id];
-
-/* Unpause domain/vcpu */
-if ( rsp.flags  VM_EVENT_FLAG_VCPU_PAUSED )
-vm_event_vcpu_unpause(v);
-}
-
-return 0;
-}
-
 /* Functions that change a page's type and ownership */
 static int page_make_sharable(struct domain *d, 
struct page_info *page, 
@@ -1470,7 +1441,8 @@ int mem_sharing_memop(struct domain *d, 
xen_mem_sharing_op_t *mec)
 {
 if ( !mem_sharing_enabled(d) )
 return -EINVAL;
-rc = mem_sharing_sharing_resume(d);
+
+vm_event_resume(d, d-vm_event-share);
 }
 break;
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 4032c62..6403172 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1279,13 +1279,13 @@ int p2m_mem_paging_prep(struct domain *d, unsigned long 
gfn, uint64_t buffer)
 }
 
 /**
- * p2m_mem_paging_resume - Resume guest gfn and vcpus
+ * p2m_mem_paging_resume - Resume guest gfn
  * @d: guest domain
- * @gfn: guest page in paging state
+ * @rsp: vm_event response received
+ *
+ * p2m_mem_paging_resume() will forward the p2mt of a gfn to ram_rw. It is
+ * called by the pager.
  *
- * p2m_mem_paging_resume() will forward the p2mt of a gfn to ram_rw and all
- * waiting vcpus will be unpaused again. It is called by the pager.
- * 
  * The gfn was previously either evicted and populated, or nominated and
  * populated. If the page was evicted the p2mt will be p2m_ram_paging_in. If
  * the page was just nominated the p2mt will be p2m_ram_paging_in_start because
@@ -1293,51 +1293,33 @@ int p2m_mem_paging_prep(struct domain *d, unsigned long 
gfn, uint64_t buffer)
  *
  * If the gfn was dropped the vcpu needs to be unpaused.
  */
-void p2m_mem_paging_resume(struct domain *d)
+
+void p2m_mem_paging_resume(struct domain *d, vm_event_response_t *rsp)
 {
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
-vm_event_response_t rsp;
 p2m_type_t p2mt;
 p2m_access_t a;
 mfn_t mfn;
 
-/* Pull all responses off the ring */
-while( vm_event_get_response(d, d-vm_event-paging, rsp) )
+/* Fix p2m entry if the page was not dropped */
+if ( !(rsp-u.mem_paging.flags

[Xen-devel] [PATCH V6 06/13] tools/tests: Clean-up tools/tests/xen-access

2015-02-17 Thread Tamas K Lengyel
The spin-lock implementation in the xen-access test program is implemented
in a fashion that is actually incomplete. The x86 assembly that guarantees that
the lock is held by only one thread lacks the lock; instruction.

However, the spin-lock is not actually necessary in xen-access as it is not
multithreaded. The presence of the faulty implementation of the lock in a non-
multithreaded environment is unnecessarily complicated for developers who are
trying to follow this code as a guide in implementing their own applications.
Thus, removing it from the code improves the clarity on the behavior of the
system.

Also converting functions that always return 0 to return to void, and making
the teardown function actually return an error code on error.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
v5: Process all requests on the ring before notifying Xen
No need to notify Xen twice
---
 tools/tests/xen-access/xen-access.c | 131 +---
 1 file changed, 30 insertions(+), 101 deletions(-)

diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index 9e913e4..d667bf5 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -45,56 +45,6 @@
 #define ERROR(a, b...) fprintf(stderr, a \n, ## b)
 #define PERROR(a, b...) fprintf(stderr, a : %s\n, ## b, strerror(errno))
 
-/* Spinlock and mem event definitions */
-
-#define SPIN_LOCK_UNLOCKED 0
-
-#define ADDR (*(volatile long *) addr)
-/**
- * test_and_set_bit - Set a bit and return its old value
- * @nr: Bit to set
- * @addr: Address to count from
- *
- * This operation is atomic and cannot be reordered.
- * It also implies a memory barrier.
- */
-static inline int test_and_set_bit(int nr, volatile void *addr)
-{
-int oldbit;
-
-asm volatile (
-btsl %2,%1\n\tsbbl %0,%0
-: =r (oldbit), =m (ADDR)
-: Ir (nr), m (ADDR) : memory);
-return oldbit;
-}
-
-typedef int spinlock_t;
-
-static inline void spin_lock(spinlock_t *lock)
-{
-while ( test_and_set_bit(1, lock) );
-}
-
-static inline void spin_lock_init(spinlock_t *lock)
-{
-*lock = SPIN_LOCK_UNLOCKED;
-}
-
-static inline void spin_unlock(spinlock_t *lock)
-{
-*lock = SPIN_LOCK_UNLOCKED;
-}
-
-static inline int spin_trylock(spinlock_t *lock)
-{
-return !test_and_set_bit(1, lock);
-}
-
-#define vm_event_ring_lock_init(_m)  spin_lock_init((_m)-ring_lock)
-#define vm_event_ring_lock(_m)   spin_lock((_m)-ring_lock)
-#define vm_event_ring_unlock(_m) spin_unlock((_m)-ring_lock)
-
 typedef struct vm_event {
 domid_t domain_id;
 xc_evtchn *xce_handle;
@@ -102,7 +52,6 @@ typedef struct vm_event {
 vm_event_back_ring_t back_ring;
 uint32_t evtchn_port;
 void *ring_page;
-spinlock_t ring_lock;
 } vm_event_t;
 
 typedef struct xenaccess {
@@ -180,6 +129,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t 
*xenaccess)
 if ( rc != 0 )
 {
 ERROR(Error tearing down domain xenaccess in xen);
+return rc;
 }
 }
 
@@ -191,6 +141,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t 
*xenaccess)
 if ( rc != 0 )
 {
 ERROR(Error unbinding event port);
+return rc;
 }
 }
 
@@ -201,6 +152,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t 
*xenaccess)
 if ( rc != 0 )
 {
 ERROR(Error closing event channel);
+return rc;
 }
 }
 
@@ -209,6 +161,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t 
*xenaccess)
 if ( rc != 0 )
 {
 ERROR(Error closing connection to xen);
+return rc;
 }
 xenaccess-xc_handle = NULL;
 
@@ -241,9 +194,6 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t 
domain_id)
 /* Set domain id */
 xenaccess-vm_event.domain_id = domain_id;
 
-/* Initialise lock */
-vm_event_ring_lock_init(xenaccess-vm_event);
-
 /* Enable mem_access */
 xenaccess-vm_event.ring_page =
 xc_mem_access_enable(xenaccess-xc_handle,
@@ -314,19 +264,24 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t 
domain_id)
 return xenaccess;
 
  err:
-xenaccess_teardown(xch, xenaccess);
+rc = xenaccess_teardown(xch, xenaccess);
+if ( rc )
+{
+ERROR(Failed to teardown xenaccess structure!\n);
+}
 
  err_iface:
 return NULL;
 }
 
-int get_request(vm_event_t *vm_event, vm_event_request_t *req)
+/*
+ * Note that this function is not thread safe.
+ */
+static void get_request(vm_event_t *vm_event, vm_event_request_t *req)
 {
 vm_event_back_ring_t *back_ring;
 RING_IDX req_cons;
 
-vm_event_ring_lock(vm_event);
-
 back_ring = vm_event-back_ring;
 req_cons = back_ring-req_cons;
 
@@ -337,19 +292,16 @@ int get_request(vm_event_t *vm_event, vm_event_request_t 
*req)
 /* Update ring */
 back_ring-req_cons

[Xen-devel] [PATCH V6 01/13] xen/mem_event: Cleanup of mem_event structures

2015-02-17 Thread Tamas K Lengyel
The public mem_event structures used to communicate with helper applications via
shared rings have been used in different settings. However, the variable names
within this structure have not reflected this fact, resulting in the reuse of
variables to mean different things under different scenarios.

This patch remedies the issue by clearly defining the structure members based on
the actual context within which the structure is used.

Signed-off-by: Razvan Cojocaru rcojoc...@bitdefender.com
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
v6: Keep gfn's uint64_t and use unsigned long in Xen
Keep the mem_access flags as a bitfield and definitions for consistency
Pass hvm params to hvm_event_cr instead of switching
v5: Style fixes
Convert gfn to uint32_t and define mem_access flags bits as we can now save
space on the ring this way
Split non-mem_event flags into access/paging flags
v4: Attach mem_event version to each outgoing request directly in mem_event.
v3: Add padding to mem_event structures.
Add version field to mem_event structures and checks for it.
---
 tools/tests/xen-access/xen-access.c |  43 +
 tools/xenpaging/xenpaging.c |  49 ++-
 xen/arch/x86/hvm/hvm.c  | 162 +-
 xen/arch/x86/mm/mem_sharing.c   |  16 +++-
 xen/arch/x86/mm/p2m.c   | 163 +++---
 xen/common/mem_access.c |   6 ++
 xen/common/mem_event.c  |   2 +
 xen/include/public/mem_event.h  | 171 +++-
 8 files changed, 377 insertions(+), 235 deletions(-)

diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index 6cb382d..98becc3 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -551,13 +551,21 @@ int main(int argc, char *argv[])
 continue;
 }
 
+if ( req.version != MEM_EVENT_INTERFACE_VERSION )
+{
+ERROR(Error: mem_event interface version mismatch!\n);
+interrupted = -1;
+continue;
+}
+
 memset( rsp, 0, sizeof (rsp) );
+rsp.version = MEM_EVENT_INTERFACE_VERSION;
 rsp.vcpu_id = req.vcpu_id;
 rsp.flags = req.flags;
 
 switch (req.reason) {
-case MEM_EVENT_REASON_VIOLATION:
-rc = xc_get_mem_access(xch, domain_id, req.gfn, access);
+case MEM_EVENT_REASON_MEM_ACCESS:
+rc = xc_get_mem_access(xch, domain_id, req.u.mem_access.gfn, 
access);
 if (rc  0)
 {
 ERROR(Error %d getting mem_access event\n, rc);
@@ -567,21 +575,21 @@ int main(int argc, char *argv[])
 
 printf(PAGE ACCESS: %c%c%c for GFN %PRIx64 (offset %06
PRIx64) gla %016PRIx64 (valid: %c; fault in gpt: %c; 
fault with gla: %c) (vcpu %u)\n,
-   req.access_r ? 'r' : '-',
-   req.access_w ? 'w' : '-',
-   req.access_x ? 'x' : '-',
-   req.gfn,
-   req.offset,
-   req.gla,
-   req.gla_valid ? 'y' : 'n',
-   req.fault_in_gpt ? 'y' : 'n',
-   req.fault_with_gla ? 'y': 'n',
+   (req.u.mem_access.flags  MEM_ACCESS_R) ? 'r' : '-',
+   (req.u.mem_access.flags  MEM_ACCESS_W) ? 'w' : '-',
+   (req.u.mem_access.flags  MEM_ACCESS_X) ? 'x' : '-',
+   req.u.mem_access.gfn,
+   req.u.mem_access.offset,
+   req.u.mem_access.gla,
+   (req.u.mem_access.flags  MEM_ACCESS_GLA_VALID) ? 'y' : 
'n',
+   (req.u.mem_access.flags  MEM_ACCESS_FAULT_IN_GPT) ? 
'y' : 'n',
+   (req.u.mem_access.flags  MEM_ACCESS_FAULT_WITH_GLA) ? 
'y': 'n',
req.vcpu_id);
 
 if ( default_access != after_first_access )
 {
 rc = xc_set_mem_access(xch, domain_id, after_first_access,
-   req.gfn, 1);
+   req.u.mem_access.gfn, 1);
 if (rc  0)
 {
 ERROR(Error %d setting gfn to access_type %d\n, rc,
@@ -592,13 +600,12 @@ int main(int argc, char *argv[])
 }
 
 
-rsp.gfn = req.gfn;
-rsp.p2mt = req.p2mt;
+rsp.u.mem_access.gfn = req.u.mem_access.gfn;
 break;
-case MEM_EVENT_REASON_INT3:
-printf(INT3: rip=%016PRIx64, gfn=%PRIx64 (vcpu %d)\n, 
-   req.gla, 
-   req.gfn,
+case MEM_EVENT_REASON_SOFTWARE_BREAKPOINT

[Xen-devel] [PATCH V6 09/13] xen/vm_event: Deprecate VM_EVENT_FLAG_DUMMY flag

2015-02-17 Thread Tamas K Lengyel
There are no use-cases for this flag.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
 xen/arch/x86/mm/mem_sharing.c | 3 ---
 xen/arch/x86/mm/p2m.c | 3 ---
 xen/common/mem_access.c   | 3 ---
 xen/include/public/vm_event.h | 1 -
 4 files changed, 10 deletions(-)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 4e5477a..e6572af 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -606,9 +606,6 @@ int mem_sharing_sharing_resume(struct domain *d)
 continue;
 }
 
-if ( rsp.flags  VM_EVENT_FLAG_DUMMY )
-continue;
-
 /* Validate the vcpu_id in the response. */
 if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
 continue;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 1d3356a..4032c62 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1312,9 +1312,6 @@ void p2m_mem_paging_resume(struct domain *d)
 continue;
 }
 
-if ( rsp.flags  VM_EVENT_FLAG_DUMMY )
-continue;
-
 /* Validate the vcpu_id in the response. */
 if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
 continue;
diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
index f925ac7..7ed8a4e 100644
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -44,9 +44,6 @@ void mem_access_resume(struct domain *d)
 continue;
 }
 
-if ( rsp.flags  VM_EVENT_FLAG_DUMMY )
-continue;
-
 /* Validate the vcpu_id in the response. */
 if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
 continue;
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index 71f1878..5b835a7 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -47,7 +47,6 @@
 #define VM_EVENT_FLAG_VCPU_PAUSED (1  0)
 /* Flags to aid debugging mem_event */
 #define VM_EVENT_FLAG_FOREIGN (1  1)
-#define VM_EVENT_FLAG_DUMMY   (1  2)
 
 /*
  * Reasons for the vm event request
-- 
2.1.4


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


[Xen-devel] [PATCH V6 03/13] xen/mem_paging: Convert mem_event_op to mem_paging_op and cleanup

2015-02-17 Thread Tamas K Lengyel
The only use-case of the mem_event_op structure had been in mem_paging,
thus renaming the structure mem_paging_op and relocating its associated
functions clarifies its actual usage.

As part of this fix-up we also convert the gfn's in the toolstack to be
explicitely 64-bit wide and clean the code a bit.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Tim Deegan t...@xen.org
Acked-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Jan Beulich jbeul...@suse.com
---
v6: Make gfn's explicitily 64-bit in the toolstack
v5: Style fixes
v4: Style fixes
v3: Style fixes
---
 tools/libxc/xc_mem_event.c   | 16 
 tools/libxc/xc_mem_paging.c  | 56 +++-
 tools/libxc/xc_private.h |  3 ---
 xen/arch/x86/mm/mem_paging.c | 32 ++-
 xen/arch/x86/x86_64/compat/mm.c  | 10 ---
 xen/arch/x86/x86_64/mm.c |  8 +++---
 xen/common/mem_event.c   |  4 +--
 xen/include/asm-x86/mem_paging.h |  5 +++-
 xen/include/public/memory.h  |  9 +++
 9 files changed, 66 insertions(+), 77 deletions(-)

diff --git a/tools/libxc/xc_mem_event.c b/tools/libxc/xc_mem_event.c
index 4bb120d..487fcee 100644
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -40,22 +40,6 @@ int xc_mem_event_control(xc_interface *xch, domid_t 
domain_id, unsigned int op,
 return rc;
 }
 
-int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
-unsigned int op, unsigned int mode,
-uint64_t gfn, void *buffer)
-{
-xen_mem_event_op_t meo;
-
-memset(meo, 0, sizeof(meo));
-
-meo.op  = op;
-meo.domain  = domain_id;
-meo.gfn = gfn;
-meo.buffer  = (unsigned long) buffer;
-
-return do_memory_op(xch, mode, meo, sizeof(meo));
-}
-
 void *xc_mem_event_enable(xc_interface *xch, domid_t domain_id, int param,
   uint32_t *port, int enable_introspection)
 {
diff --git a/tools/libxc/xc_mem_paging.c b/tools/libxc/xc_mem_paging.c
index 5194423..32c4703 100644
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -23,6 +23,20 @@
 
 #include xc_private.h
 
+static int xc_mem_paging_memop(xc_interface *xch, domid_t domain_id,
+   unsigned int op, uint64_t gfn, void *buffer)
+{
+xen_mem_paging_op_t mpo;
+
+memset(mpo, 0, sizeof(mpo));
+
+mpo.op  = op;
+mpo.domain  = domain_id;
+mpo.gfn = gfn;
+mpo.buffer  = (unsigned long) buffer;
+
+return do_memory_op(xch, XENMEM_paging_op, mpo, sizeof(mpo));
+}
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
  uint32_t *port)
@@ -32,7 +46,7 @@ int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
 errno = EINVAL;
 return -1;
 }
-
+
 return xc_mem_event_control(xch, domain_id,
 XEN_MEM_EVENT_PAGING_ENABLE,
 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
@@ -47,32 +61,29 @@ int xc_mem_paging_disable(xc_interface *xch, domid_t 
domain_id)
 NULL);
 }
 
-int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, unsigned long 
gfn)
+int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, uint64_t gfn)
 {
-return xc_mem_event_memop(xch, domain_id,
-XENMEM_paging_op_nominate,
-XENMEM_paging_op,
-gfn, NULL);
+return xc_mem_paging_memop(xch, domain_id,
+   XENMEM_paging_op_nominate,
+   gfn, NULL);
 }
 
-int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long 
gfn)
+int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, uint64_t gfn)
 {
-return xc_mem_event_memop(xch, domain_id,
-XENMEM_paging_op_evict,
-XENMEM_paging_op,
-gfn, NULL);
+return xc_mem_paging_memop(xch, domain_id,
+   XENMEM_paging_op_evict,
+   gfn, NULL);
 }
 
-int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn)
+int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, uint64_t gfn)
 {
-return xc_mem_event_memop(xch, domain_id,
-XENMEM_paging_op_prep,
-XENMEM_paging_op,
-gfn, NULL);
+return xc_mem_paging_memop(xch, domain_id,
+   XENMEM_paging_op_prep,
+   gfn, NULL);
 }
 
-int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
-unsigned long gfn, void *buffer)
+int xc_mem_paging_load(xc_interface *xch, domid_t domain_id,
+   uint64_t gfn, void *buffer)
 {
 int rc, old_errno;
 
@@ -86,11

[Xen-devel] [PATCH V6 11/13] xen/vm_event: Relocate memop checks

2015-02-17 Thread Tamas K Lengyel
The memop handler function for paging/sharing responsible for calling XSM
doesn't really have anything to do with vm_event, thus in this patch we
relocate it into mem_paging_memop and mem_sharing_memop. This has already
been the approach in mem_access_memop, so in this patch we just make it
consistent.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Reviewed-by: Andrew Cooper andrew.coop...@citrix.com
---
v6: Don't pass superfluous cmd to the memops.
Unlock rcu's in sharing/paging
Style fixes
---
 xen/arch/x86/mm/mem_paging.c  |  44 +++---
 xen/arch/x86/mm/mem_sharing.c | 125 +-
 xen/arch/x86/x86_64/compat/mm.c   |  26 +---
 xen/arch/x86/x86_64/mm.c  |  24 +---
 xen/common/vm_event.c |  43 -
 xen/include/asm-x86/mem_paging.h  |   2 +-
 xen/include/asm-x86/mem_sharing.h |   3 +-
 xen/include/xen/vm_event.h|   1 -
 8 files changed, 127 insertions(+), 141 deletions(-)

diff --git a/xen/arch/x86/mm/mem_paging.c b/xen/arch/x86/mm/mem_paging.c
index e63d8c1..cbdee99 100644
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -22,34 +22,60 @@
 
 
 #include asm/p2m.h
-#include xen/vm_event.h
+#include xen/guest_access.h
+#include xsm/xsm.h
 
-
-int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *mpo)
+int mem_paging_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_paging_op_t) arg)
 {
-int rc = -ENODEV;
-if ( unlikely(!d-vm_event-paging.ring_page) )
+int rc;
+xen_mem_paging_op_t mpo;
+struct domain *d;
+bool_t copyback = 0;
+
+rc = -EFAULT;
+if ( copy_from_guest(mpo, arg, 1) )
 return rc;
 
-switch( mpo-op )
+rc = rcu_lock_live_remote_domain_by_id(mpo.domain, d);
+if ( rc )
+goto out;
+
+rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_paging_op);
+if ( rc )
+goto out;
+
+rc = -ENODEV;
+if ( unlikely(!d-vm_event-paging.ring_page) )
+goto out;
+
+switch( mpo.op )
 {
 case XENMEM_paging_op_nominate:
-rc = p2m_mem_paging_nominate(d, mpo-gfn);
+rc = p2m_mem_paging_nominate(d, mpo.gfn);
 break;
 
 case XENMEM_paging_op_evict:
-rc = p2m_mem_paging_evict(d, mpo-gfn);
+rc = p2m_mem_paging_evict(d, mpo.gfn);
 break;
 
 case XENMEM_paging_op_prep:
-rc = p2m_mem_paging_prep(d, mpo-gfn, mpo-buffer);
+{
+rc = p2m_mem_paging_prep(d, mpo.gfn, mpo.buffer);
+if ( !rc )
+copyback = 1;
 break;
+}
 
 default:
 rc = -ENOSYS;
 break;
 }
 
+if ( copyback  __copy_to_guest(arg, mpo, 1) )
+rc = -EFAULT;
+
+out:
+rcu_unlock_domain(d);
 return rc;
 }
 
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 4959407..2d49bc4 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -28,6 +28,7 @@
 #include xen/grant_table.h
 #include xen/sched.h
 #include xen/rcupdate.h
+#include xen/guest_access.h
 #include xen/vm_event.h
 #include asm/page.h
 #include asm/string.h
@@ -1293,39 +1294,66 @@ int relinquish_shared_pages(struct domain *d)
 return rc;
 }
 
-int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
+int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
 {
-int rc = 0;
+int rc;
+xen_mem_sharing_op_t mso;
+struct domain *d;
+
+rc = -EFAULT;
+if ( copy_from_guest(mso, arg, 1) )
+return rc;
+
+if ( mso.op == XENMEM_sharing_op_audit )
+return mem_sharing_audit();
+
+rc = rcu_lock_live_remote_domain_by_id(mso.domain, d);
+if ( rc )
+return rc;
 
 /* Only HAP is supported */
+rc = -ENODEV;
 if ( !hap_enabled(d) || !d-arch.hvm_domain.mem_sharing_enabled )
- return -ENODEV;
+ rc = -ENODEV;
 
-switch(mec-op)
+rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_sharing_op);
+if ( rc )
+goto out;
+
+rc = -ENODEV;
+if ( unlikely(!d-vm_event-share.ring_page) )
+goto out;
+
+switch ( mso.op )
 {
 case XENMEM_sharing_op_nominate_gfn:
 {
-unsigned long gfn = mec-u.nominate.u.gfn;
+unsigned long gfn = mso.u.nominate.u.gfn;
 shr_handle_t handle;
+
+rc = -EINVAL;
 if ( !mem_sharing_enabled(d) )
-return -EINVAL;
+goto out;
+
 rc = mem_sharing_nominate_page(d, gfn, 0, handle);
-mec-u.nominate.handle = handle;
+mso.u.nominate.handle = handle;
 }
 break;
 
 case XENMEM_sharing_op_nominate_gref:
 {
-grant_ref_t gref = mec-u.nominate.u.grant_ref;
+grant_ref_t gref = mso.u.nominate.u.grant_ref;
 unsigned long gfn;
 shr_handle_t handle;
 
+rc = -EINVAL;
 if ( !mem_sharing_enabled(d) )
-return -EINVAL

[Xen-devel] [PATCH V6 05/13] xen/vm_event: Style fixes

2015-02-17 Thread Tamas K Lengyel
Fix style issues left over from the renaming to vm_event and other minor
alignment issues.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
 xen/common/vm_event.c  | 36 +++-
 xen/include/xen/vm_event.h | 18 +-
 2 files changed, 20 insertions(+), 34 deletions(-)

diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 195739e..a185539 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -568,9 +568,6 @@ int vm_event_domctl(struct domain *d, 
xen_domctl_vm_event_op_t *vec,
 switch( vec-op )
 {
 case XEN_VM_EVENT_PAGING_ENABLE:
-{
-struct p2m_domain *p2m = p2m_get_hostp2m(d);
-
 rc = -EOPNOTSUPP;
 /* pvh fixme: p2m_is_foreign types need addressing */
 if ( is_pvh_vcpu(current) || is_pvh_domain(hardware_domain) )
@@ -588,21 +585,18 @@ int vm_event_domctl(struct domain *d, 
xen_domctl_vm_event_op_t *vec,
 
 rc = -EXDEV;
 /* Disallow paging in a PoD guest */
-if ( p2m-pod.entry_count )
+if ( p2m_get_hostp2m(d)-pod.entry_count )
 break;
 
 rc = vm_event_enable(d, vec, ved, _VPF_mem_paging,
  HVM_PARAM_PAGING_RING_PFN,
  mem_paging_notification);
-}
-break;
+break;
 
 case XEN_VM_EVENT_PAGING_DISABLE:
-{
 if ( ved-ring_page )
 rc = vm_event_disable(d, ved);
-}
-break;
+break;
 
 default:
 rc = -ENOSYS;
@@ -622,31 +616,27 @@ int vm_event_domctl(struct domain *d, 
xen_domctl_vm_event_op_t *vec,
 {
 case XEN_VM_EVENT_MONITOR_ENABLE:
 case XEN_VM_EVENT_MONITOR_ENABLE_INTROSPECTION:
-{
 rc = -ENODEV;
 if ( !p2m_vm_event_sanity_check(d) )
 break;
 
 rc = vm_event_enable(d, vec, ved, _VPF_mem_access,
-HVM_PARAM_MONITOR_RING_PFN,
-mem_access_notification);
+ HVM_PARAM_MONITOR_RING_PFN,
+ mem_access_notification);
 
 if ( vec-op == XEN_VM_EVENT_MONITOR_ENABLE_INTROSPECTION
   !rc )
 p2m_setup_introspection(d);
 
-}
-break;
+break;
 
 case XEN_VM_EVENT_MONITOR_DISABLE:
-{
 if ( ved-ring_page )
 {
 rc = vm_event_disable(d, ved);
 d-arch.hvm_domain.introspection_enabled = 0;
 }
-}
-break;
+break;
 
 default:
 rc = -ENOSYS;
@@ -665,7 +655,6 @@ int vm_event_domctl(struct domain *d, 
xen_domctl_vm_event_op_t *vec,
 switch( vec-op )
 {
 case XEN_VM_EVENT_SHARING_ENABLE:
-{
 rc = -EOPNOTSUPP;
 /* pvh fixme: p2m_is_foreign types need addressing */
 if ( is_pvh_vcpu(current) || is_pvh_domain(hardware_domain) )
@@ -677,17 +666,14 @@ int vm_event_domctl(struct domain *d, 
xen_domctl_vm_event_op_t *vec,
 break;
 
 rc = vm_event_enable(d, vec, ved, _VPF_mem_sharing,
-HVM_PARAM_SHARING_RING_PFN,
-mem_sharing_notification);
-}
-break;
+ HVM_PARAM_SHARING_RING_PFN,
+ mem_sharing_notification);
+break;
 
 case XEN_VM_EVENT_SHARING_DISABLE:
-{
 if ( ved-ring_page )
 rc = vm_event_disable(d, ved);
-}
-break;
+break;
 
 default:
 rc = -ENOSYS;
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index 188ee16..206efb0 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -48,15 +48,15 @@ bool_t vm_event_check_ring(struct vm_event_domain *ved);
  * succeed.
  */
 int __vm_event_claim_slot(struct domain *d, struct vm_event_domain *ved,
-bool_t allow_sleep);
+  bool_t allow_sleep);
 static inline int vm_event_claim_slot(struct domain *d,
-struct vm_event_domain *ved)
+  struct vm_event_domain *ved)
 {
 return __vm_event_claim_slot(d, ved, 1);
 }
 
 static inline int vm_event_claim_slot_nosleep(struct domain *d,
-struct vm_event_domain *ved)
+  struct vm_event_domain *ved)
 {
 return __vm_event_claim_slot(d, ved, 0);
 }
@@ -64,10 +64,10 @@ static inline int vm_event_claim_slot_nosleep(struct domain 
*d,
 void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *ved);
 
 void vm_event_put_request(struct

[Xen-devel] [PATCH V6 12/13] xen/xsm: Split vm_event_op into three separate labels

2015-02-17 Thread Tamas K Lengyel
The XSM label vm_event_op has been used to control the three memops
controlling mem_access, mem_paging and mem_sharing. While these systems
rely on vm_event, these are not vm_event operations themselves. Thus,
in this patch we introduce three separate labels for each of these memops.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
Reviewed-by: Andrew Cooper andrew.coop...@citrix.com
---
 xen/arch/x86/mm/mem_paging.c|  2 +-
 xen/arch/x86/mm/mem_sharing.c   |  2 +-
 xen/common/mem_access.c |  2 +-
 xen/include/xsm/dummy.h | 20 +++-
 xen/include/xsm/xsm.h   | 33 ++---
 xen/xsm/dummy.c | 13 -
 xen/xsm/flask/hooks.c   | 33 ++---
 xen/xsm/flask/policy/access_vectors |  6 ++
 8 files changed, 100 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/mm/mem_paging.c b/xen/arch/x86/mm/mem_paging.c
index cbdee99..0fa2abd 100644
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -40,7 +40,7 @@ int 
mem_paging_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_paging_op_t) arg)
 if ( rc )
 goto out;
 
-rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_paging_op);
+rc = xsm_mem_paging(XSM_DM_PRIV, d);
 if ( rc )
 goto out;
 
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 2d49bc4..d56ecf9 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1316,7 +1316,7 @@ int 
mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
 if ( !hap_enabled(d) || !d-arch.hvm_domain.mem_sharing_enabled )
  rc = -ENODEV;
 
-rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_sharing_op);
+rc = xsm_mem_sharing(XSM_DM_PRIV, d);
 if ( rc )
 goto out;
 
diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
index 511c8c5..aa00513 100644
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -48,7 +48,7 @@ int mem_access_memop(unsigned long cmd,
 if ( !p2m_mem_access_sanity_check(d) )
 goto out;
 
-rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_access_op);
+rc = xsm_mem_access(XSM_DM_PRIV, d);
 if ( rc )
 goto out;
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 50ee929..16967ed 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -519,11 +519,29 @@ static XSM_INLINE int 
xsm_vm_event_control(XSM_DEFAULT_ARG struct domain *d, int
 return xsm_default_action(action, current-domain, d);
 }
 
-static XSM_INLINE int xsm_vm_event_op(XSM_DEFAULT_ARG struct domain *d, int op)
+#ifdef HAS_MEM_ACCESS
+static XSM_INLINE int xsm_mem_access(XSM_DEFAULT_ARG struct domain *d)
 {
 XSM_ASSERT_ACTION(XSM_DM_PRIV);
 return xsm_default_action(action, current-domain, d);
 }
+#endif
+
+#ifdef HAS_MEM_PAGING
+static XSM_INLINE int xsm_mem_paging(XSM_DEFAULT_ARG struct domain *d)
+{
+XSM_ASSERT_ACTION(XSM_DM_PRIV);
+return xsm_default_action(action, current-domain, d);
+}
+#endif
+
+#ifdef HAS_MEM_SHARING
+static XSM_INLINE int xsm_mem_sharing(XSM_DEFAULT_ARG struct domain *d)
+{
+XSM_ASSERT_ACTION(XSM_DM_PRIV);
+return xsm_default_action(action, current-domain, d);
+}
+#endif
 
 #ifdef CONFIG_X86
 static XSM_INLINE int xsm_do_mca(XSM_DEFAULT_VOID)
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index d56a68f..2a88d84 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -142,7 +142,18 @@ struct xsm_operations {
 int (*get_vnumainfo) (struct domain *d);
 
 int (*vm_event_control) (struct domain *d, int mode, int op);
-int (*vm_event_op) (struct domain *d, int op);
+
+#ifdef HAS_MEM_ACCESS
+int (*mem_access) (struct domain *d);
+#endif
+
+#ifdef HAS_MEM_PAGING
+int (*mem_paging) (struct domain *d);
+#endif
+
+#ifdef HAS_MEM_SHARING
+int (*mem_sharing) (struct domain *d);
+#endif
 
 #ifdef CONFIG_X86
 int (*do_mca) (void);
@@ -546,10 +557,26 @@ static inline int xsm_vm_event_control (xsm_default_t 
def, struct domain *d, int
 return xsm_ops-vm_event_control(d, mode, op);
 }
 
-static inline int xsm_vm_event_op (xsm_default_t def, struct domain *d, int op)
+#ifdef HAS_MEM_ACCESS
+static inline int xsm_mem_access (xsm_default_t def, struct domain *d)
 {
-return xsm_ops-vm_event_op(d, op);
+return xsm_ops-mem_access(d);
 }
+#endif
+
+#ifdef HAS_MEM_PAGING
+static inline int xsm_mem_paging (xsm_default_t def, struct domain *d)
+{
+return xsm_ops-mem_paging(d);
+}
+#endif
+
+#ifdef HAS_MEM_SHARING
+static inline int xsm_mem_sharing (xsm_default_t def, struct domain *d)
+{
+return xsm_ops-mem_sharing(d);
+}
+#endif
 
 #ifdef CONFIG_X86
 static inline int xsm_do_mca(xsm_default_t def)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 6d12d32..3ddb4f6 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -119,7 +119,18 @@ void

[Xen-devel] [PATCH V6 07/13] x86/hvm: factor out and rename vm_event related functions

2015-02-17 Thread Tamas K Lengyel
To avoid growing hvm.c these functions can be stored separately. Minor style
changes are applied to the logic in the file.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Kevin Tian kevin.t...@intel.com
---
v6: Style fixes
v5: Style fixes
Fix hvm_event_msr input types to match the incoming variables
v4: Style fixes
v3: Style fixes and removing unused fields from msr events.
---
 MAINTAINERS |   1 +
 xen/arch/x86/hvm/Makefile   |   3 +-
 xen/arch/x86/hvm/event.c| 184 
 xen/arch/x86/hvm/hvm.c  | 152 ++---
 xen/arch/x86/hvm/vmx/vmx.c  |   7 +-
 xen/include/asm-x86/hvm/event.h |  40 +
 xen/include/asm-x86/hvm/hvm.h   |  11 ---
 7 files changed, 236 insertions(+), 162 deletions(-)
 create mode 100644 xen/arch/x86/hvm/event.c
 create mode 100644 xen/include/asm-x86/hvm/event.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 3d09d15..1e1b6f9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -366,6 +366,7 @@ M:  Tim Deegan t...@xen.org
 S: Supported
 F: xen/common/vm_event.c
 F: xen/common/mem_access.c
+F: xen/arch/x86/hvm/event.c
 
 XENTRACE
 M: George Dunlap george.dun...@eu.citrix.com
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index eea..69af47f 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -3,6 +3,7 @@ subdir-y += vmx
 
 obj-y += asid.o
 obj-y += emulate.o
+obj-y += event.o
 obj-y += hpet.o
 obj-y += hvm.o
 obj-y += i8254.o
@@ -22,4 +23,4 @@ obj-y += vlapic.o
 obj-y += vmsi.o
 obj-y += vpic.o
 obj-y += vpt.o
-obj-y += vpmu.o
\ No newline at end of file
+obj-y += vpmu.o
diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
new file mode 100644
index 000..dfb0ab7
--- /dev/null
+++ b/xen/arch/x86/hvm/event.c
@@ -0,0 +1,184 @@
+/*
+* event.c: Common hardware virtual machine event abstractions.
+*
+* Copyright (c) 2004, Intel Corporation.
+* Copyright (c) 2005, International Business Machines Corporation.
+* Copyright (c) 2008, Citrix Systems, Inc.
+*
+* This program is free software; you can redistribute it and/or modify it
+* under the terms and conditions of the GNU General Public License,
+* version 2, as published by the Free Software Foundation.
+*
+* This program is distributed in the hope 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, write to the Free Software Foundation, Inc., 59 Temple
+* Place - Suite 330, Boston, MA 02111-1307 USA.
+*/
+
+#include xen/vm_event.h
+#include xen/paging.h
+#include public/vm_event.h
+
+static void hvm_event_fill_regs(vm_event_request_t *req)
+{
+const struct cpu_user_regs *regs = guest_cpu_user_regs();
+const struct vcpu *curr = current;
+
+req-regs.x86.rax = regs-eax;
+req-regs.x86.rcx = regs-ecx;
+req-regs.x86.rdx = regs-edx;
+req-regs.x86.rbx = regs-ebx;
+req-regs.x86.rsp = regs-esp;
+req-regs.x86.rbp = regs-ebp;
+req-regs.x86.rsi = regs-esi;
+req-regs.x86.rdi = regs-edi;
+
+req-regs.x86.r8  = regs-r8;
+req-regs.x86.r9  = regs-r9;
+req-regs.x86.r10 = regs-r10;
+req-regs.x86.r11 = regs-r11;
+req-regs.x86.r12 = regs-r12;
+req-regs.x86.r13 = regs-r13;
+req-regs.x86.r14 = regs-r14;
+req-regs.x86.r15 = regs-r15;
+
+req-regs.x86.rflags = regs-eflags;
+req-regs.x86.rip= regs-eip;
+
+req-regs.x86.msr_efer = curr-arch.hvm_vcpu.guest_efer;
+req-regs.x86.cr0 = curr-arch.hvm_vcpu.guest_cr[0];
+req-regs.x86.cr3 = curr-arch.hvm_vcpu.guest_cr[3];
+req-regs.x86.cr4 = curr-arch.hvm_vcpu.guest_cr[4];
+}
+
+static int hvm_event_traps(uint64_t parameters, vm_event_request_t *req)
+{
+int rc;
+struct vcpu *curr = current;
+struct domain *currd = curr-domain;
+
+if ( !(parameters  HVMPME_MODE_MASK) )
+return 0;
+
+rc = vm_event_claim_slot(currd, currd-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 1;
+default:
+return rc;
+};
+
+if ( (parameters  HVMPME_MODE_MASK) == HVMPME_mode_sync )
+{
+req-flags |= VM_EVENT_FLAG_VCPU_PAUSED;
+vm_event_vcpu_pause(curr);
+}
+
+hvm_event_fill_regs(req);
+vm_event_put_request(currd, currd-vm_event-monitor, req);
+
+return 1;
+}
+
+static void hvm_event_cr(uint32_t reason, unsigned long value,
+ unsigned long old, uint64_t parameters)
+{
+vm_event_request_t req = {
+.reason = reason,
+.vcpu_id = current-vcpu_id,
+.u.mov_to_cr.new_value = value

[Xen-devel] [PATCH V6 04/13] xen: Rename mem_event to vm_event

2015-02-17 Thread Tamas K Lengyel
In this patch we mechanically rename mem_event to vm_event. This patch
introduces no logic changes to the code. Using the name vm_event better
describes the intended use of this subsystem, which is not limited to memory
events. It can be used for off-loading the decision making logic into helper
applications when encountering various events during a VM's execution.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
Acked-by: Jan Beulich jbeul...@suse.com
Acked-by: Wei Liu wei.l...@citrix.com
---
v5: Rebased on master
v4: Using git -M option for patch to improve readability
Note that in include/xen/vm_event.h the style problems are fixed in a later
 patch in the series so that git can keep track of the relocation here.
---
 MAINTAINERS|   4 +-
 docs/misc/xsm-flask.txt|   2 +-
 tools/libxc/Makefile   |   2 +-
 tools/libxc/xc_mem_access.c|  16 +-
 tools/libxc/xc_mem_paging.c|  16 +-
 tools/libxc/xc_memshr.c|  18 +-
 tools/libxc/xc_private.h   |  12 +-
 tools/libxc/{xc_mem_event.c = xc_vm_event.c}  |  40 +--
 tools/tests/xen-access/xen-access.c| 110 
 tools/xenpaging/pagein.c   |   2 +-
 tools/xenpaging/xenpaging.c| 112 
 tools/xenpaging/xenpaging.h|   8 +-
 xen/arch/x86/domain.c  |   2 +-
 xen/arch/x86/domctl.c  |   4 +-
 xen/arch/x86/hvm/emulate.c |   4 +-
 xen/arch/x86/hvm/hvm.c |  40 +--
 xen/arch/x86/hvm/vmx/vmcs.c|   4 +-
 xen/arch/x86/mm/hap/nested_ept.c   |   4 +-
 xen/arch/x86/mm/hap/nested_hap.c   |   4 +-
 xen/arch/x86/mm/mem_paging.c   |   4 +-
 xen/arch/x86/mm/mem_sharing.c  |  32 +--
 xen/arch/x86/mm/p2m-pod.c  |   4 +-
 xen/arch/x86/mm/p2m-pt.c   |   4 +-
 xen/arch/x86/mm/p2m.c  |  86 +++
 xen/arch/x86/x86_64/compat/mm.c|   6 +-
 xen/arch/x86/x86_64/mm.c   |   6 +-
 xen/common/Makefile|   2 +-
 xen/common/domain.c|  12 +-
 xen/common/domctl.c|   8 +-
 xen/common/mem_access.c|  26 +-
 xen/common/{mem_event.c = vm_event.c} | 338 -
 xen/drivers/passthrough/pci.c  |   2 +-
 xen/include/asm-arm/p2m.h  |   4 +-
 xen/include/asm-x86/domain.h   |   4 +-
 xen/include/asm-x86/p2m.h  |  10 +-
 xen/include/public/domctl.h|  46 ++--
 xen/include/public/{mem_event.h = vm_event.h} |  84 +++---
 xen/include/xen/mem_access.h   |   4 +-
 xen/include/xen/p2m-common.h   |   4 +-
 xen/include/xen/sched.h|  26 +-
 xen/include/xen/{mem_event.h = vm_event.h}|  74 +++---
 xen/include/xsm/dummy.h|   4 +-
 xen/include/xsm/xsm.h  |  12 +-
 xen/xsm/dummy.c|   4 +-
 xen/xsm/flask/hooks.c  |  16 +-
 xen/xsm/flask/policy/access_vectors|   2 +-
 46 files changed, 613 insertions(+), 615 deletions(-)
 rename tools/libxc/{xc_mem_event.c = xc_vm_event.c} (79%)
 rename xen/common/{mem_event.c = vm_event.c} (59%)
 rename xen/include/public/{mem_event.h = vm_event.h} (72%)
 rename xen/include/xen/{mem_event.h = vm_event.h} (50%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3bbac9e..3d09d15 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -361,10 +361,10 @@ F:xen/arch/x86/mm/mem_sharing.c
 F: xen/arch/x86/mm/mem_paging.c
 F: tools/memshr
 
-MEMORY EVENT AND ACCESS
+VM EVENT AND MEM ACCESS
 M: Tim Deegan t...@xen.org
 S: Supported
-F: xen/common/mem_event.c
+F: xen/common/vm_event.c
 F: xen/common/mem_access.c
 
 XENTRACE
diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 9559028..13ce498 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -87,7 +87,7 @@ __HYPERVISOR_domctl (xen/include/public/domctl.h)
  * XEN_DOMCTL_set_machine_address_size
  * XEN_DOMCTL_debug_op
  * XEN_DOMCTL_gethvmcontext_partial
- * XEN_DOMCTL_mem_event_op
+ * XEN_DOMCTL_vm_event_op
  * XEN_DOMCTL_mem_sharing_op
  * XEN_DOMCTL_setvcpuextstate
  * XEN_DOMCTL_getvcpuextstate
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 6fa88c7..22ba2a1 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -31,7 +31,7 @@ CTRL_SRCS-y   += xc_pm.c
 CTRL_SRCS-y   += xc_cpu_hotplug.c
 CTRL_SRCS-y   += xc_resume.c
 CTRL_SRCS-y   += xc_tmem.c
-CTRL_SRCS-y   += xc_mem_event.c
+CTRL_SRCS-y

[Xen-devel] [PATCH V6 08/13] xen: Introduce monitor_op domctl

2015-02-17 Thread Tamas K Lengyel
In preparation for allowing for introspecting ARM and PV domains the old
control interface via the hvm_op hypercall is retired. A new control mechanism
is introduced via the domctl hypercall: monitor_op.

This patch aims to establish a base API on which future applications can build
on.

Suggested-by: Andrew Cooper andrew.coop...@citrix.com
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Kevin Tian kevin.t...@intel.com
Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
---
v6: Convert monitor control fields to bool_t both in Xen and in libxc
Make monitor_domctl more compact by abstracting common patterns
Deprecated HVM params remain but throw error both in Xen and in libxc
Style fixes
Add another field to arch.domain that determines if mem_access emulation
is enabled and corresponding mem_access memops to enable/disable it
Add XSM check to monitor_domctl
v5: p2m_vm_event_sanity_check is moved into the monitor_op handler
v4: Style fixes
Only defining struct mov_to_cr and struct debug_event in asm-x86/domain.h
Add pause/unpause domain wrapper when enabled a monitor option.
---
 MAINTAINERS |   1 +
 tools/libxc/Makefile|   1 +
 tools/libxc/include/xenctrl.h   |  27 +
 tools/libxc/xc_domain.c |  28 -
 tools/libxc/xc_mem_access.c |  33 --
 tools/libxc/xc_monitor.c| 115 +
 tools/libxc/xc_private.h|   2 +-
 tools/libxc/xc_vm_event.c   |   7 +-
 tools/tests/xen-access/xen-access.c |  30 +++---
 xen/arch/x86/Makefile   |   1 +
 xen/arch/x86/hvm/emulate.c  |   2 +-
 xen/arch/x86/hvm/event.c|  58 ++-
 xen/arch/x86/hvm/hvm.c  |  33 +-
 xen/arch/x86/hvm/vmx/vmcs.c |   7 +-
 xen/arch/x86/hvm/vmx/vmx.c  |   2 +-
 xen/arch/x86/mm/p2m.c   |   9 --
 xen/arch/x86/monitor.c  | 200 
 xen/common/domctl.c |   9 ++
 xen/common/mem_access.c |   8 ++
 xen/common/vm_event.c   |  11 --
 xen/include/asm-arm/monitor.h   |  35 +++
 xen/include/asm-arm/p2m.h   |  18 +++-
 xen/include/asm-x86/domain.h|  37 ++-
 xen/include/asm-x86/hvm/domain.h|   1 -
 xen/include/asm-x86/monitor.h   |  31 ++
 xen/include/asm-x86/p2m.h   |  34 --
 xen/include/public/domctl.h |  48 -
 xen/include/public/hvm/params.h |   9 +-
 xen/include/public/memory.h |   2 +
 xen/include/public/vm_event.h   |   2 +-
 xen/xsm/flask/hooks.c   |   3 +
 xen/xsm/flask/policy/access_vectors |   2 +
 32 files changed, 665 insertions(+), 141 deletions(-)
 create mode 100644 tools/libxc/xc_monitor.c
 create mode 100644 xen/arch/x86/monitor.c
 create mode 100644 xen/include/asm-arm/monitor.h
 create mode 100644 xen/include/asm-x86/monitor.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 1e1b6f9..3ebbc5e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -367,6 +367,7 @@ S:  Supported
 F: xen/common/vm_event.c
 F: xen/common/mem_access.c
 F: xen/arch/x86/hvm/event.c
+F: xen/arch/x86/monitor.c
 
 XENTRACE
 M: George Dunlap george.dun...@eu.citrix.com
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 22ba2a1..8b609cf 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -32,6 +32,7 @@ CTRL_SRCS-y   += xc_cpu_hotplug.c
 CTRL_SRCS-y   += xc_resume.c
 CTRL_SRCS-y   += xc_tmem.c
 CTRL_SRCS-y   += xc_vm_event.c
+CTRL_SRCS-y   += xc_monitor.c
 CTRL_SRCS-y   += xc_mem_paging.c
 CTRL_SRCS-y   += xc_mem_access.c
 CTRL_SRCS-y   += xc_memshr.c
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 790db53..4d9c610 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -34,6 +34,7 @@
 #include stddef.h
 #include stdint.h
 #include stdio.h
+#include stdbool.h
 #include xen/xen.h
 #include xen/domctl.h
 #include xen/physdev.h
@@ -2307,6 +2308,32 @@ int xc_set_mem_access(xc_interface *xch, domid_t 
domain_id,
 int xc_get_mem_access(xc_interface *xch, domid_t domain_id,
   uint64_t pfn, xenmem_access_t *access);
 
+/*
+ * Instructions causing a mem_access violation can be emulated by Xen
+ * to progress the execution without having to relax the mem_access
+ * permissions.
+ * This feature has to be first enabled, then in the vm_event
+ * response to a mem_access event it can indicated if the instruction
+ * should be emulated.
+ */
+int xc_mem_access_enable_emulate(xc_interface *xch, domid_t domain_id);
+int xc_mem_access_disable_emulate(xc_interface *xch, domid_t domain_id);
+
+/***
+ * Monitor control operations.
+ */
+int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t domain_id, bool enable,
+  bool sync, bool onchangeonly);
+int

[Xen-devel] [PATCH V6 02/13] xen/mem_event: Cleanup mem_event names in rings, functions and domctls

2015-02-17 Thread Tamas K Lengyel
The name of one of the mem_event rings still implies it is used only
for memory accesses, which is no longer the case. It is also used to
deliver various HVM events, thus the name monitor is more appropriate
in this setting.

Couple functions incorrectly labeled as part of mem_event is also renamed
to reflect that they belong to mem_access.

The mem_event subop definitions are also shortened to be more meaningful.

The tool side changes are only mechanical renaming to match these new names.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Jan Beulich jbeul...@suse.com
---
v6: Rename p2m_mem_event_emulate_check to p2m_mem_access_emulate_check
Rename hvm_mem_event_emulate_one to hvm_mem_access_emulate_one
v5: Style fixes
v4: Shorted mem_event domctl subops.
v3: Style and comment fixes.
---
 tools/libxc/xc_domain_restore.c   | 14 ++---
 tools/libxc/xc_domain_save.c  |  4 ++--
 tools/libxc/xc_hvm_build_x86.c|  2 +-
 tools/libxc/xc_mem_access.c   |  8 
 tools/libxc/xc_mem_event.c| 12 +--
 tools/libxc/xc_mem_paging.c   |  4 ++--
 tools/libxc/xc_memshr.c   |  4 ++--
 tools/libxc/xg_save_restore.h |  2 +-
 xen/arch/x86/hvm/emulate.c|  2 +-
 xen/arch/x86/hvm/hvm.c|  4 ++--
 xen/arch/x86/hvm/vmx/vmcs.c   |  2 +-
 xen/arch/x86/mm/p2m.c | 10 -
 xen/common/mem_access.c   | 10 -
 xen/common/mem_event.c| 37 +
 xen/include/asm-arm/p2m.h |  6 +++---
 xen/include/asm-x86/hvm/emulate.h |  2 +-
 xen/include/asm-x86/p2m.h |  4 ++--
 xen/include/public/domctl.h   | 43 +++
 xen/include/public/hvm/params.h   |  2 +-
 xen/include/xen/sched.h   |  4 ++--
 20 files changed, 93 insertions(+), 83 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index a382701..2ab9f46 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -734,7 +734,7 @@ typedef struct {
 uint64_t vcpumap[XC_SR_MAX_VCPUS/64];
 uint64_t identpt;
 uint64_t paging_ring_pfn;
-uint64_t access_ring_pfn;
+uint64_t monitor_ring_pfn;
 uint64_t sharing_ring_pfn;
 uint64_t vm86_tss;
 uint64_t console_pfn;
@@ -828,15 +828,15 @@ static int pagebuf_get_one(xc_interface *xch, struct 
restore_ctx *ctx,
 // DPRINTF(paging ring pfn address: %llx\n, buf-paging_ring_pfn);
 return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
-case XC_SAVE_ID_HVM_ACCESS_RING_PFN:
+case XC_SAVE_ID_HVM_MONITOR_RING_PFN:
 /* Skip padding 4 bytes then read the mem access ring location. */
-if ( RDEXACT(fd, buf-access_ring_pfn, sizeof(uint32_t)) ||
- RDEXACT(fd, buf-access_ring_pfn, sizeof(uint64_t)) )
+if ( RDEXACT(fd, buf-monitor_ring_pfn, sizeof(uint32_t)) ||
+ RDEXACT(fd, buf-monitor_ring_pfn, sizeof(uint64_t)) )
 {
 PERROR(error read the access ring pfn);
 return -1;
 }
-// DPRINTF(access ring pfn address: %llx\n, buf-access_ring_pfn);
+// DPRINTF(monitor ring pfn address: %llx\n, buf-monitor_ring_pfn);
 return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
 case XC_SAVE_ID_HVM_SHARING_RING_PFN:
@@ -1660,8 +1660,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, 
uint32_t dom,
 xc_hvm_param_set(xch, dom, HVM_PARAM_IDENT_PT, 
pagebuf.identpt);
 if ( pagebuf.paging_ring_pfn )
 xc_hvm_param_set(xch, dom, HVM_PARAM_PAGING_RING_PFN, 
pagebuf.paging_ring_pfn);
-if ( pagebuf.access_ring_pfn )
-xc_hvm_param_set(xch, dom, HVM_PARAM_ACCESS_RING_PFN, 
pagebuf.access_ring_pfn);
+if ( pagebuf.monitor_ring_pfn )
+xc_hvm_param_set(xch, dom, HVM_PARAM_MONITOR_RING_PFN, 
pagebuf.monitor_ring_pfn);
 if ( pagebuf.sharing_ring_pfn )
 xc_hvm_param_set(xch, dom, HVM_PARAM_SHARING_RING_PFN, 
pagebuf.sharing_ring_pfn);
 if ( pagebuf.vm86_tss )
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index 254fdb3..949ef64 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1664,9 +1664,9 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t 
dom, uint32_t max_iter
 goto out;
 }
 
-chunk.id = XC_SAVE_ID_HVM_ACCESS_RING_PFN;
+chunk.id = XC_SAVE_ID_HVM_MONITOR_RING_PFN;
 chunk.data = 0;
-xc_hvm_param_get(xch, dom, HVM_PARAM_ACCESS_RING_PFN, chunk.data);
+xc_hvm_param_get(xch, dom, HVM_PARAM_MONITOR_RING_PFN, chunk.data);
 
 if ( (chunk.data != 0) 
  wrexact(io_fd, chunk, sizeof(chunk)) )
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index c81a25b..30a929d 100644
--- a/tools/libxc/xc_hvm_build_x86.c

[Xen-devel] [PATCH V6 13/13] xen/vm_event: Add RESUME option to vm_event_op domctl

2015-02-17 Thread Tamas K Lengyel
Thus far mem_access and mem_sharing memops had been able to signal
to Xen to start pulling responses off the corresponding rings. In this patch
we retire these memops and add them to the option to the vm_event_op domctl.

The vm_event_op domctl suboptions are the same for each ring thus we
consolidate them into XEN_VM_EVENT_ENABLE/DISABLE/RESUME.

As part of this patch in libxc we also rename the mem_access_enable/disable
functions to monitor_enable/disable and move them into xc_monitor.c.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Wei Liu wei.l...@citrix.com
---
v6: Style fixes
---
 tools/libxc/include/xenctrl.h   | 22 +++---
 tools/libxc/xc_mem_access.c | 25 -
 tools/libxc/xc_mem_paging.c | 12 ++--
 tools/libxc/xc_memshr.c | 15 ++-
 tools/libxc/xc_monitor.c| 22 ++
 tools/libxc/xc_vm_event.c   |  6 +++---
 tools/tests/xen-access/xen-access.c | 10 +-
 xen/arch/x86/mm/mem_sharing.c   | 12 
 xen/common/mem_access.c |  9 -
 xen/common/vm_event.c   | 33 +++--
 xen/include/public/domctl.h | 32 +++-
 xen/include/public/memory.h | 20 +---
 12 files changed, 108 insertions(+), 110 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 4d9c610..45651c8 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2270,6 +2270,7 @@ int xc_tmem_restore_extra(xc_interface *xch, int dom, int 
fd);
  */
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id);
+int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id);
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id,
unsigned long gfn);
 int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long 
gfn);
@@ -2283,17 +2284,6 @@ int xc_mem_paging_load(xc_interface *xch, domid_t 
domain_id,
  */
 
 /*
- * Enables mem_access and returns the mapped ring page.
- * Will return NULL on error.
- * Caller has to unmap this page when done.
- */
-void *xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t 
*port);
-void *xc_mem_access_enable_introspection(xc_interface *xch, domid_t domain_id,
- uint32_t *port);
-int xc_mem_access_disable(xc_interface *xch, domid_t domain_id);
-int xc_mem_access_resume(xc_interface *xch, domid_t domain_id);
-
-/*
  * Set a range of memory to a specific access.
  * Allowed types are XENMEM_access_default, XENMEM_access_n, any combination of
  * XENMEM_access_ + (rwx), and XENMEM_access_rx2rw
@@ -2321,7 +2311,17 @@ int xc_mem_access_disable_emulate(xc_interface *xch, 
domid_t domain_id);
 
 /***
  * Monitor control operations.
+ *
+ * Enables the VM event monitor ring and returns the mapped ring page.
+ * This ring is used to deliver mem_access events, as well a set of additional
+ * events that can be enabled with the xc_monitor_* functions.
+ *
+ * Will return NULL on error.
+ * Caller has to unmap this page when done.
  */
+void *xc_monitor_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
+int xc_monitor_disable(xc_interface *xch, domid_t domain_id);
+int xc_monitor_resume(xc_interface *xch, domid_t domain_id);
 int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t domain_id, bool enable,
   bool sync, bool onchangeonly);
 int xc_monitor_mov_to_cr3(xc_interface *xch, domid_t domain_id, bool enable,
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index f27bc44..5cfa611 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -24,31 +24,6 @@
 #include xc_private.h
 #include xen/memory.h
 
-void *xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t 
*port)
-{
-return xc_vm_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
-  port);
-}
-
-int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
-{
-return xc_vm_event_control(xch, domain_id,
-   XEN_VM_EVENT_MONITOR_DISABLE,
-   XEN_DOMCTL_VM_EVENT_OP_MONITOR,
-   NULL);
-}
-
-int xc_mem_access_resume(xc_interface *xch, domid_t domain_id)
-{
-xen_mem_access_op_t mao =
-{
-.op= XENMEM_access_op_resume,
-.domid = domain_id
-};
-
-return do_memory_op(xch, XENMEM_access_op, mao, sizeof(mao));
-}
-
 int xc_set_mem_access(xc_interface *xch,
   domid_t domain_id,
   xenmem_access_t access,
diff --git a/tools/libxc/xc_mem_paging.c b/tools/libxc/xc_mem_paging.c
index 9c311d9..4aa48d6 100644
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc

[Xen-devel] [PATCH V6 00/13] xen: Clean-up of mem_event subsystem

2015-02-17 Thread Tamas K Lengyel
This patch series aims to clean up the mem_event subsystem within Xen. The
original use-case for this system was to allow external helper applications
running in privileged domains to control various memory operations performed
by Xen. Amongs these were paging, sharing and access control. The subsystem
has since been extended to also deliver non-memory related events, namely
various HVM debugging events (INT3, MTF, MOV-TO-CR, MOV-TO-MSR). The structures
and naming of related functions however has not caught up to these new
use-cases, thus leaving many ambiguities in the code. Furthermore, future
use-cases envisioned for this subsystem include PV domains and ARM domains,
thus there is a need to establish a common base to build on.

In this series we convert the mem_event system to vm_event in which we clearly
define the scope of information that is transmitted via the event
delivery mechanism. Afterwards, we clean up the naming of the structures and
related functions to more clearly be in line with their actual operations.
Finally, the control of monitor events is moved to a new domctl, monitor_op.

Each patch in the series has been build-tested on x86 and ARM, both with
and without XSM enabled.

This PATCH series is also available at:
https://github.com/tklengyel/xen/tree/mem_event_cleanup6

Tamas K Lengyel (13):
  xen/mem_event: Cleanup of mem_event structures
  xen/mem_event: Cleanup mem_event names in rings, functions and domctls
  xen/mem_paging: Convert mem_event_op to mem_paging_op and cleanup
  xen: Rename mem_event to vm_event
  xen/vm_event: Style fixes
  tools/tests: Clean-up tools/tests/xen-access
  x86/hvm: factor out and rename vm_event related functions
  xen: Introduce monitor_op domctl
  xen/vm_event: Deprecate VM_EVENT_FLAG_DUMMY flag
  xen/vm_event: Decouple vm_event and mem_access.
  xen/vm_event: Relocate memop checks
  xen/xsm: Split vm_event_op into three separate labels
  xen/vm_event: Add RESUME option to vm_event_op domctl

 MAINTAINERS   |   6 +-
 docs/misc/xsm-flask.txt   |   2 +-
 tools/libxc/Makefile  |   3 +-
 tools/libxc/include/xenctrl.h |  49 ++-
 tools/libxc/xc_domain.c   |  28 +-
 tools/libxc/xc_domain_restore.c   |  14 +-
 tools/libxc/xc_domain_save.c  |   4 +-
 tools/libxc/xc_hvm_build_x86.c|   2 +-
 tools/libxc/xc_mem_access.c   |  56 ++-
 tools/libxc/xc_mem_paging.c   |  80 ++--
 tools/libxc/xc_memshr.c   |  29 +-
 tools/libxc/xc_monitor.c  | 137 +++
 tools/libxc/xc_private.h  |  15 +-
 tools/libxc/{xc_mem_event.c = xc_vm_event.c} |  59 +--
 tools/libxc/xg_save_restore.h |   2 +-
 tools/tests/xen-access/xen-access.c   | 264 +
 tools/xenpaging/pagein.c  |   2 +-
 tools/xenpaging/xenpaging.c   | 155 
 tools/xenpaging/xenpaging.h   |   8 +-
 xen/arch/x86/Makefile |   1 +
 xen/arch/x86/domain.c |   2 +-
 xen/arch/x86/domctl.c |   4 +-
 xen/arch/x86/hvm/Makefile |   3 +-
 xen/arch/x86/hvm/emulate.c|   8 +-
 xen/arch/x86/hvm/event.c  | 190 ++
 xen/arch/x86/hvm/hvm.c| 187 +-
 xen/arch/x86/hvm/vmx/vmcs.c   |  11 +-
 xen/arch/x86/hvm/vmx/vmx.c|   9 +-
 xen/arch/x86/mm/hap/nested_ept.c  |   4 +-
 xen/arch/x86/mm/hap/nested_hap.c  |   4 +-
 xen/arch/x86/mm/mem_paging.c  |  60 ++-
 xen/arch/x86/mm/mem_sharing.c | 180 -
 xen/arch/x86/mm/p2m-pod.c |   4 +-
 xen/arch/x86/mm/p2m-pt.c  |   4 +-
 xen/arch/x86/mm/p2m.c | 271 +++---
 xen/arch/x86/monitor.c| 200 ++
 xen/arch/x86/x86_64/compat/mm.c   |  24 +-
 xen/arch/x86/x86_64/mm.c  |  24 +-
 xen/common/Makefile   |  18 +-
 xen/common/domain.c   |  12 +-
 xen/common/domctl.c   |  17 +-
 xen/common/mem_access.c   |  55 +--
 xen/common/{mem_event.c = vm_event.c}| 512 +-
 xen/drivers/passthrough/pci.c |   2 +-
 xen/include/asm-arm/monitor.h |  35 ++
 xen/include/asm-arm/p2m.h |  22 +-
 xen/include/asm-x86/domain.h  |  41 ++-
 xen/include/asm-x86/hvm/domain.h  |   1 -
 xen/include/asm-x86/hvm/emulate.h |   2 +-
 xen/include/asm-x86/hvm/event.h   |  40 ++
 xen/include/asm-x86/hvm/hvm.h |  11 -
 xen/include/asm-x86/mem_paging.h  |   5 +-
 xen

Re: [Xen-devel] [PATCH V5 07/12] xen: Introduce monitor_op domctl

2015-02-17 Thread Tamas K Lengyel
On Tue, Feb 17, 2015 at 7:20 PM, Tamas K Lengyel
tamas.leng...@zentific.com wrote:
 On Tue, Feb 17, 2015 at 3:02 PM, Jan Beulich jbeul...@suse.com wrote:
 On 13.02.15 at 17:33, tamas.leng...@zentific.com wrote:
 --- a/xen/arch/x86/hvm/emulate.c
 +++ b/xen/arch/x86/hvm/emulate.c
 @@ -411,7 +411,8 @@ static int hvmemul_virtual_to_linear(
   * being triggered for repeated writes to a whole page.
   */
  *reps = min_t(unsigned long, *reps,
 -  
 unlikely(current-domain-arch.hvm_domain.introspection_enabled)
 +  unlikely(current-domain-arch
 +.monitor_options.mov_to_msr.extended_capture)
 ? 1 : 4096);

 This makes no sense (especially not to a reader in a year or two):
 There's no connection between mov-to-msr and the repeat count
 capping done here. Please wrap this in a suitably named is_...() or
 has_...() or introspection_enabled() helper, with a comment at its
 definition site making the connection explicit.

 It took me a while to understand what introspection_enabled actually
 represents and all it really does at the moment is enabling the
 interception of an extended set of MSRs. If something, that is a bad
 variable name. Since in this series introspection_enabled is
 removed, here I just updated the variable to the one that holds the
 same information. I don't actually know what the code here does as I
 didn't touch it. If this indeed has no connection to mov-to-msr, it
 should have its own option field with its own name actually describing
 what it does. Maybe Razvan has some more information on what is going
 on here and if another variable needs to be introduced that was just
 latched onto introspection_enabled.

So I looked into this a bit more and this is being used when a
mem_event response to a mem_access event has the emulation flag set.
So this is an extra option that was latched onto
introspection_enabled, thus we will need an extra field to determine
if this particular feature is enabled or not.

Now I understand why Razvan was wondering about umbrella options
going forward. IMHO this highlights the problem with umbrella options
- it becomes really hard to understand what the option actually does.
Especially without proper documentation.

Tamas

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


Re: [Xen-devel] [PATCH V6 04/13] xen: Rename mem_event to vm_event

2015-02-18 Thread Tamas K Lengyel
On Wed, Feb 18, 2015 at 4:55 PM, Tamas K Lengyel
tamas.leng...@zentific.com wrote:
 On Wed, Feb 18, 2015 at 2:35 PM, Jan Beulich jbeul...@suse.com wrote:
 On 18.02.15 at 13:21, tamas.k.leng...@gmail.com wrote:
 On Wed Feb 18 2015 10:46:02 AM CET, Jan Beulich jbeul...@suse.com wrote:

On 18.02.15 at 01:11, tamas.leng...@zentific.com wrote:
  diff --git a/xen/common/mem_event.c b/xen/common/vm_event.c
  similarity index 59%
  rename from xen/common/mem_event.c
  rename to xen/common/vm_event.c

 Looking at this already quite huge delta I can't really see why
 adjusting white space at once would make it much worse. In any
 case better than leaving white space damage behind.

 I did that in the first version of the patch and the feedback I got was that
 it is unreviewable that way.

 Not really - in the first version of the patch the old file gets removed
 as a whole, and the new file added. Same in v2 afaics, where indeed
 you got such a comment.

 Jan

 I would rather prefer it all being done in one patch but unfortunately
 git can't keep track of the code movement that way. I'm not aware of
 any option to git to achieve all this in one patch.

 Tamas

So apparently this is possible if I relax the default 50% similarity
index -M looks for. I'll merge the white-space fixing part into this
patch in v7.

Thanks,
Tamas

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


Re: [Xen-devel] [PATCH V5 09/12] xen/vm_event: Decouple vm_event and mem_access.

2015-02-17 Thread Tamas K Lengyel
On Tue, Feb 17, 2015 at 7:34 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
 On 17/02/15 18:30, Tamas K Lengyel wrote:
 All these whitespace changes here and further down don't really
 belong in this patch - please again get this right when adding the
 code.
 Same issue I mentioned in the other patch: git -M can't track the
 files if indentation is fixed as part of the renaming process. As I
 end up touching all the files that have with minor style issues like
 this in the series as a result of the renaming, I fix them as I go
 along. If that stretches the rules, I will need to add a whole new
 separate patch just for indentation fixing.

 Separating the two is best for review.

 One patch which git diff -M says is identical for moving the file, and
 one patch which git diff -w says is identical for whitespace fixes.

 It makes it trivial to confirm that there is no functional change involved.

 ~Andrew

Alright, that makes sense, will do so.

Thanks,
Tamas

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


Re: [Xen-devel] [PATCH V5 07/12] xen: Introduce monitor_op domctl

2015-02-17 Thread Tamas K Lengyel
,
 -mem_access_notification);
 -
 -if ( vec-op == XEN_VM_EVENT_MONITOR_ENABLE_INTROSPECTION
 -  !rc )
 -p2m_setup_introspection(d);
 -
 -}
 -break;
 + HVM_PARAM_MONITOR_RING_PFN,
 + mem_access_notification);

 I don't see what changes for these two lines. If it's indentation, it
 should be done right when the code gets added.

Indentation can't be fixed in the code addition as it breaks git -M.
It reverts to the old format where it just removes the whole file and
adds the new one. I think its a waste to add a whole new separate
patch just to fix indentations so I just fix it here.

 +break;

 This indentation change should not be necessary - the braces you
 remove here shouldn't get added in the first place when the new
 file gets introduced. Same further down.

See my previous comment.


 --- /dev/null
 +++ b/xen/include/asm-arm/monitor.h
 @@ -0,0 +1,13 @@
 +#ifndef __ASM_ARM_MONITOR_H__
 +#define __ASM_ARM_MONITOR_H__
 +
 +#include xen/config.h

 This is pointless and should be dropped (I seem to recall having made
 the same statement before on an earlier version - please apply such
 to all of the patches in a series).

Ack.


 +#include public/domctl.h
 +
 +static inline
 +int monitor_domctl(struct xen_domctl_monitor_op *op, struct domain *d)

 The includes above are insufficient for the types used, or you should
 forward declare _both_ structs and not have any includes.

Just including sched.h additionally should be enough IMHO.


 --- a/xen/include/asm-x86/domain.h
 +++ b/xen/include/asm-x86/domain.h
 @@ -241,6 +241,24 @@ struct time_scale {
  u32 mul_frac;
  };

 +//
 +/*monitor event options */
 +//
 +struct mov_to_cr {
 +uint8_t enabled;
 +uint8_t sync;
 +uint8_t onchangeonly;
 +};
 +
 +struct mov_to_msr {
 +uint8_t enabled;
 +uint8_t extended_capture;
 +};
 +
 +struct debug_event {
 +uint8_t enabled;
 +};

 These are all internal structures - is there anything wrong with using
 bitfields here?

The use if bitfields is not good performance-wise AFAIK. Would there
be any benefit that would offset that?


 --- /dev/null
 +++ b/xen/include/asm-x86/monitor.h
 @@ -0,0 +1,30 @@
 +/*
 + * include/asm-x86/monitor.h
 + *
 + * Architecture-specific monitor_op domctl handler.
 + *
 + * Copyright (c) 2015 Tamas K Lengyel (ta...@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, write to the
 + * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
 + * Boston, MA 021110-1307, USA.
 + */
 +
 +#ifndef __ASM_X86_MONITOR_H__
 +#define __ASM_X86_MONITOR_H__
 +
 +#include public/domctl.h
 +
 +int monitor_domctl(struct xen_domctl_monitor_op *op, struct domain *d);

 Same as for the ARM variant.

Ack.


 Jan

Thanks,
Tamas

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


Re: [Xen-devel] [PATCH V5 12/12] xen/vm_event: Add RESUME option to vm_event_op domctl

2015-02-17 Thread Tamas K Lengyel
On Tue, Feb 17, 2015 at 3:31 PM, Jan Beulich jbeul...@suse.com wrote:
 On 13.02.15 at 17:33, tamas.leng...@zentific.com wrote:
 @@ -611,13 +611,22 @@ int vm_event_domctl(struct domain *d, 
 xen_domctl_vm_event_op_t *vec,
  }
  break;

 -case XEN_VM_EVENT_PAGING_DISABLE:
 +case XEN_VM_EVENT_DISABLE:
  {
  if ( ved-ring_page )
  rc = vm_event_disable(d, ved);
  }
  break;

 +case XEN_VM_EVENT_RESUME:
 +{
 +if ( ved-ring_page )
 +vm_event_resume(d, ved);
 +else
 +rc = -ENODEV;
 +}
 +break;

 Stray braces again.

Ack.


 I also find it confusing that the same set of changes repeats three
 times here - is that an indication of a problem with an earlier patch?

No it's not. There are three rings vm_event can use, thus three rings
that can be resumed.


 Jan


Thanks,
Tamas

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


Re: [Xen-devel] [PATCH V5 07/12] xen: Introduce monitor_op domctl

2015-02-17 Thread Tamas K Lengyel
On Tue, Feb 17, 2015 at 7:37 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
 On 17/02/15 18:20, Tamas K Lengyel wrote:
 +//
 +/*monitor event options */
 +//
 +struct mov_to_cr {
 +uint8_t enabled;
 +uint8_t sync;
 +uint8_t onchangeonly;
 +};
 +
 +struct mov_to_msr {
 +uint8_t enabled;
 +uint8_t extended_capture;
 +};
 +
 +struct debug_event {
 +uint8_t enabled;
 +};
 These are all internal structures - is there anything wrong with using
 bitfields here?
 The use if bitfields is not good performance-wise AFAIK. Would there
 be any benefit that would offset that?

 struct vcpu lives in a 4k page.  We avoid needlessly bloating it.

 However bitfields will not work with my suggestion as you cannot
 construct a pointer to 'enabled' if enabled is a bit.

 ~Andrew

That too.. I would rather keep these as bool_t's if possible.

Thanks,
Tamas

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


Re: [Xen-devel] [PATCH V5 10/12] xen/vm_event: Relocate memop checks

2015-02-17 Thread Tamas K Lengyel
On Tue, Feb 17, 2015 at 3:25 PM, Jan Beulich jbeul...@suse.com wrote:
 On 13.02.15 at 17:33, tamas.leng...@zentific.com wrote:
 -int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *mpo)
 +int mem_paging_memop(unsigned long cmd,
 + XEN_GUEST_HANDLE_PARAM(xen_mem_paging_op_t) arg)
  {
 -int rc = -ENODEV;
 +int rc;
 +xen_mem_paging_op_t mpo;
 +struct domain *d;
 +
 +rc = -EFAULT;
 +if ( copy_from_guest(mpo, arg, 1) )
 +return rc;

 Please don't make things more complicated than they need to be:
 You only use the -EFAULT once here, so no reason to assign it to
 rc up front.

This return will be a goto out; where the rcu is getting unlocked as well.


 +
 +rc = rcu_lock_live_remote_domain_by_id(mpo.domain, d);
 +if ( rc )
 +return rc;
 +
 +rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_paging_op);
 +if ( rc )

 There's an RCU lock you take right before this, which you now fail
 to drop here and below.

Ack.


 +return rc;
 +
 +rc = -ENODEV;
  if ( unlikely(!d-vm_event-paging.ring_page) )
  return rc;

 Same comment as for the -EFAULT above.

Same as above, will be a goto out.


 Jan

Thanks,
Tamas

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


Re: [Xen-devel] [PATCH V5 09/12] xen/vm_event: Decouple vm_event and mem_access.

2015-02-17 Thread Tamas K Lengyel
On Tue, Feb 17, 2015 at 3:17 PM, Jan Beulich jbeul...@suse.com wrote:
 On 13.02.15 at 17:33, tamas.leng...@zentific.com wrote:
 @@ -1293,56 +1293,30 @@ int p2m_mem_paging_prep(struct domain *d, unsigned 
 long gfn, uint64_t buffer)
   *
   * If the gfn was dropped the vcpu needs to be unpaused.
   */
 -void p2m_mem_paging_resume(struct domain *d)
 +
 +void p2m_mem_paging_resume(struct domain *d, vm_event_response_t *rsp)
  {
  struct p2m_domain *p2m = p2m_get_hostp2m(d);
 -vm_event_response_t rsp;
  p2m_type_t p2mt;
  p2m_access_t a;
  mfn_t mfn;

 -/* Pull all responses off the ring */
 -while( vm_event_get_response(d, d-vm_event-paging, rsp) )
 +/* Fix p2m entry if the page was not dropped */
 +if ( !(rsp-u.mem_paging.flags  MEM_PAGING_DROP_PAGE) )
  {
 -struct vcpu *v;
 -
 -if ( rsp.version != VM_EVENT_INTERFACE_VERSION )
 -{
 -printk(XENLOG_G_WARNING vm_event interface version 
 mismatch\n);
 -continue;
 -}
 -
 -#ifndef NDEBUG
 -if ( rsp.flags  VM_EVENT_FLAG_DUMMY )
 -continue;
 -#endif
 -
 -/* Validate the vcpu_id in the response. */
 -if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
 -continue;
 -
 -v = d-vcpu[rsp.vcpu_id];
 -
 -/* Fix p2m entry if the page was not dropped */
 -if ( !(rsp.u.mem_paging.flags  MEM_PAGING_DROP_PAGE) )
 +unsigned long gfn = rsp-u.mem_access.gfn;
 +gfn_lock(p2m, gfn, 0);

 Once again - blank line between declarations and statements please.

 +mfn = p2m-get_entry(p2m, gfn, p2mt, a, 0, NULL);
 +/* Allow only pages which were prepared properly, or pages which
 + * were nominated but not evicted */

 Coding style.

 @@ -48,15 +46,15 @@ bool_t vm_event_check_ring(struct vm_event_domain *med);
   * succeed.
   */
  int __vm_event_claim_slot(struct domain *d, struct vm_event_domain *med,
 -bool_t allow_sleep);
 +  bool_t allow_sleep);
  static inline int vm_event_claim_slot(struct domain *d,
 -struct vm_event_domain *med)
 +  struct vm_event_domain *med)
  {
  return __vm_event_claim_slot(d, med, 1);
  }

  static inline int vm_event_claim_slot_nosleep(struct domain *d,
 -struct vm_event_domain *med)
 +  struct vm_event_domain *med)

 All these whitespace changes here and further down don't really
 belong in this patch - please again get this right when adding the
 code.

Same issue I mentioned in the other patch: git -M can't track the
files if indentation is fixed as part of the renaming process. As I
end up touching all the files that have with minor style issues like
this in the series as a result of the renaming, I fix them as I go
along. If that stretches the rules, I will need to add a whole new
separate patch just for indentation fixing.


 Jan

Thanks,
Tamas

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


Re: [Xen-devel] EPT question - XENMEM_get_access_op

2015-02-20 Thread Tamas K Lengyel
On Fri, Feb 20, 2015 at 3:21 PM, Balbir Singh bsinghar...@gmail.com wrote:
 [snip]
 On Fri, Feb 20, 2015 at 5:21 PM, Jan Beulich jbeul...@suse.com wrote:
 Thanks Jan! Is there a way for a memevents channel consumer to get
 access to the L1 (OS Page tables).

 Hardly.

 I presume we'll need to walk the
 page tables, I suspect the current access_op is broken without it and
 may not be returning anything meaningful in most of the cases

 It's not broken in any way, you just seem to have wrong expectations.


 Probably, because I am interested in the final protection as seen by
 an application or kernel and I'm trying to find a way to get that
 information. For me the effective permission set is of interest.

 Balbir

You can get the guest pagetable permissions via LibVMI:
http://libvmi.com/api/#func_vmi_pagetable_lookup_extended

Cheers,
Tamas

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


Re: [Xen-devel] [PATCH V6 04/13] xen: Rename mem_event to vm_event

2015-02-18 Thread Tamas K Lengyel
On Wed Feb 18 2015 10:46:02 AM CET, Jan Beulich jbeul...@suse.com wrote:

On 18.02.15 at 01:11, tamas.leng...@zentific.com wrote:
  diff --git a/xen/common/mem_event.c b/xen/common/vm_event.c
  similarity index 59%
  rename from xen/common/mem_event.c
  rename to xen/common/vm_event.c
 
 Looking at this already quite huge delta I can't really see why
 adjusting white space at once would make it much worse. In any
 case better than leaving white space damage behind.
 
 Jan

I did that in the first version of the patch and the feedback I got was that it 
is unreviewable that way.

Tamas

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


Re: [Xen-devel] [PATCH V5 06/12] x86/hvm: factor out and rename vm_event related functions

2015-02-18 Thread Tamas K Lengyel
On Wed Feb 18 2015 10:07:29 AM CET, Jan Beulich jbeul...@suse.com wrote:

On 17.02.15 at 18:37, tamas.leng...@zentific.com wrote:
  On Tue, Feb 17, 2015 at 12:56 PM, Jan Beulich jbeul...@suse.com
  wrote:
  On 13.02.15 at 17:33, tamas.leng...@zentific.com wrote:
+static void hvm_event_cr(uint32_t reason, unsigned long value,
+                                                               
unsigned long old)
+{
+       vm_event_request_t req = {
+               .reason = reason,
+               .vcpu_id = current-vcpu_id,
+               .u.mov_to_cr.new_value = value,
+               .u.mov_to_cr.old_value = old
+       };
+       uint64_t parameters = 0;
+
+       switch(reason)
   
   Coding style. Also I continue to think using switch() here rather
   than having the caller pass both VM_EVENT_* and HVM_PARAM_* is ugly/
   inefficient (even if the compiler may be able to sort this out for
   you).
  
  It's getting retired in the series so there isn't much point in
  tweaking it here.
 
 I realized that looking at later patches in this series, but then you
 could similarly argue that the other requested adjustments are
 unnecessary. But please always keep in mind that series may get
 applied partially. And of course ideally a series wouldn't introduce
 code just for a later patch to delete it again - i.e. if you already
 find you want/need to do that, then please accept that coding
 style remarks are still being made and considered relevant.
 
 Jan

I do consider coding style issues relevant. Here we were talking about 
optimizing a method that is being retired in the series anyway but it is your 
call. In v6 I already made the changes you requested. 

Tamas

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


Re: [Xen-devel] [PATCH V5 10/12] xen/vm_event: Relocate memop checks

2015-02-18 Thread Tamas K Lengyel
On Wed Feb 18 2015 10:29:40 AM CET, Jan Beulich jbeul...@suse.com wrote:

On 17.02.15 at 19:47, tamas.leng...@zentific.com wrote:
  On Tue, Feb 17, 2015 at 3:25 PM, Jan Beulich jbeul...@suse.com wrote:
  On 13.02.15 at 17:33, tamas.leng...@zentific.com wrote:
-int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *mpo)
+int mem_paging_memop(unsigned long cmd,
+                                         
XEN_GUEST_HANDLE_PARAM(xen_mem_paging_op_t)
arg) {
-       int rc = -ENODEV;
+       int rc;
+       xen_mem_paging_op_t mpo;
+       struct domain *d;
+
+       rc = -EFAULT;
+       if ( copy_from_guest(mpo, arg, 1) )
+               return rc;
   
   Please don't make things more complicated than they need to be:
   You only use the -EFAULT once here, so no reason to assign it to
   rc up front.
  
  This return will be a goto out; where the rcu is getting unlocked as
  well.
 
 How that? You didn't take the RCU lock yet (which is even visible
 from the rest of the hunk above).
 
 Jan

Sorry, was just replying mechanically as most returns here turn into goto outs. 
Ack.

Tamas


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


Re: [Xen-devel] [PATCH V6 04/13] xen: Rename mem_event to vm_event

2015-02-18 Thread Tamas K Lengyel
On Wed, Feb 18, 2015 at 2:35 PM, Jan Beulich jbeul...@suse.com wrote:
 On 18.02.15 at 13:21, tamas.k.leng...@gmail.com wrote:
 On Wed Feb 18 2015 10:46:02 AM CET, Jan Beulich jbeul...@suse.com wrote:

On 18.02.15 at 01:11, tamas.leng...@zentific.com wrote:
  diff --git a/xen/common/mem_event.c b/xen/common/vm_event.c
  similarity index 59%
  rename from xen/common/mem_event.c
  rename to xen/common/vm_event.c

 Looking at this already quite huge delta I can't really see why
 adjusting white space at once would make it much worse. In any
 case better than leaving white space damage behind.

 I did that in the first version of the patch and the feedback I got was that
 it is unreviewable that way.

 Not really - in the first version of the patch the old file gets removed
 as a whole, and the new file added. Same in v2 afaics, where indeed
 you got such a comment.

 Jan

I would rather prefer it all being done in one patch but unfortunately
git can't keep track of the code movement that way. I'm not aware of
any option to git to achieve all this in one patch.

Tamas

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


Re: [Xen-devel] [PATCH V5 12/12] xen/vm_event: Add RESUME option to vm_event_op domctl

2015-02-18 Thread Tamas K Lengyel
On Wed Feb 18 2015 10:31:06 AM CET, Jan Beulich jbeul...@suse.com wrote:

On 17.02.15 at 19:32, tamas.leng...@zentific.com wrote:
  On Tue, Feb 17, 2015 at 3:31 PM, Jan Beulich jbeul...@suse.com wrote:
  On 13.02.15 at 17:33, tamas.leng...@zentific.com wrote:
@@ -611,13 +611,22 @@ int vm_event_domctl(struct domain *d, 
  xen_domctl_vm_event_op_t *vec,
}
break;

-               case XEN_VM_EVENT_PAGING_DISABLE:
+               case XEN_VM_EVENT_DISABLE:
{
if ( ved-ring_page )
rc = vm_event_disable(d, ved);
}
break;

+               case XEN_VM_EVENT_RESUME:
+               {
+                       if ( ved-ring_page )
+                               vm_event_resume(d, ved);
+                       else
+                               rc = -ENODEV;
+               }
+               break;
   
   Stray braces again.
  
  Ack.
  
   
   I also find it confusing that the same set of changes repeats three
   times here - is that an indication of a problem with an earlier
   patch?
  
  No it's not. There are three rings vm_event can use, thus three rings
  that can be resumed.
 
 But if the code ends up being almost identical, this loudly calls for
 consolidation into e.g. a helper function.
 
 Jan

That could be done but considering we are talking about only couple lines of 
code, I'm not sure that would improve readability by much.

I think the question I raised earlier, whether we need the resume option to the 
domctl to begin with is what needs discussion. IMHO the event channel method is 
enough so maybe I'll just turn this patch into deprecating the resume options 
in the memops.

Thanks,
Tamas

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


Re: [Xen-devel] [RFC PATCH V2 1/8] xen/mem_event: Cleanup of mem_event structures

2015-01-29 Thread Tamas K Lengyel
On Thu, Jan 29, 2015 at 1:02 PM, Jan Beulich jbeul...@suse.com wrote:
 On 29.01.15 at 12:54, tamas.leng...@zentific.com wrote:
 On Thu, Jan 22, 2015 at 4:34 PM, Tamas K Lengyel
 tamas.leng...@zentific.com wrote:
 On Thu, Jan 22, 2015 at 4:00 PM, Jan Beulich jbeul...@suse.com wrote:
 On 18.01.15 at 16:17, tamas.leng...@zentific.com wrote:
 --- a/xen/include/Makefile
 +++ b/xen/include/Makefile
 @@ -90,7 +90,7 @@ ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))

  all: headers.chk

 -headers.chk: $(filter-out public/arch-% public/%ctl.h public/xsm/%
 public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) $(public-y)) 
 Makefile
 +headers.chk: $(filter-out public/arch-% public/%ctl.h public/mem_event.h
 public/xsm/% public/%hvm/save.h, $(wildcard public/*.h public/*/*.h)
 $(public-y)) Makefile

 I think you should finally break this already too long line. But of course
 first of all you'll want to explain why the addition is necessary/correct.
 The mere fact that this now becomes a tools-only interface isn't
 enough imo - some of the other headers excluded here would better
 undergo the checking too, just that first they would need cleaning up.

 I have to revisit what is actually going on here, I believe I had to
 add this to get Xen to build. On a second look not sure why that was.

 So I double checked and the addition here is correct, without
 excluding the header, the compilation fails at #if !defined(__XEN__)
  !defined(__XEN_TOOLS__) in mem_event.h.

 Hardly at that line. I'm afraid I won't be convinced without you
 explaining what fails why, and why that can't be dealt with.

 So I'll break the line but
 cleaning up/checking the other headers IMHO is out of scope for this
 series.

 Of course, no-one asked you to do this (and even less so in this series).

 Jan

The reason why compilation fails is because the new preprocessor check
in mem_event.j #if !defined(__XEN__)  !defined(__XEN_TOOLS__) is not
happy and I get the error message #error vm event operations are
intended for use only by Xen or node control tools. This is a new
addition into the mem_event.h thus the build without this
pre-processor check works just fine. All other headers within
include/public that have similar preprocessor checks are already
excluded in this line, thus my impression was this is the correct way
to get the build to progress. Of course if I missed something please
let me know, I don't honestly fully comprehend the build process here.

Thanks,
Tamas

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


Re: [Xen-devel] [RFC PATCH V2 1/8] xen/mem_event: Cleanup of mem_event structures

2015-01-29 Thread Tamas K Lengyel
On Thu, Jan 29, 2015 at 1:09 PM, Tamas K Lengyel
tamas.leng...@zentific.com wrote:
 On Thu, Jan 29, 2015 at 1:02 PM, Jan Beulich jbeul...@suse.com wrote:
 On 29.01.15 at 12:54, tamas.leng...@zentific.com wrote:
 On Thu, Jan 22, 2015 at 4:34 PM, Tamas K Lengyel
 tamas.leng...@zentific.com wrote:
 On Thu, Jan 22, 2015 at 4:00 PM, Jan Beulich jbeul...@suse.com wrote:
 On 18.01.15 at 16:17, tamas.leng...@zentific.com wrote:
 --- a/xen/include/Makefile
 +++ b/xen/include/Makefile
 @@ -90,7 +90,7 @@ ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))

  all: headers.chk

 -headers.chk: $(filter-out public/arch-% public/%ctl.h public/xsm/%
 public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) $(public-y)) 
 Makefile
 +headers.chk: $(filter-out public/arch-% public/%ctl.h public/mem_event.h
 public/xsm/% public/%hvm/save.h, $(wildcard public/*.h public/*/*.h)
 $(public-y)) Makefile

 I think you should finally break this already too long line. But of course
 first of all you'll want to explain why the addition is necessary/correct.
 The mere fact that this now becomes a tools-only interface isn't
 enough imo - some of the other headers excluded here would better
 undergo the checking too, just that first they would need cleaning up.

 I have to revisit what is actually going on here, I believe I had to
 add this to get Xen to build. On a second look not sure why that was.

 So I double checked and the addition here is correct, without
 excluding the header, the compilation fails at #if !defined(__XEN__)
  !defined(__XEN_TOOLS__) in mem_event.h.

 Hardly at that line. I'm afraid I won't be convinced without you
 explaining what fails why, and why that can't be dealt with.

 So I'll break the line but
 cleaning up/checking the other headers IMHO is out of scope for this
 series.

 Of course, no-one asked you to do this (and even less so in this series).

 Jan

 The reason why compilation fails is because the new preprocessor check
 in mem_event.j #if !defined(__XEN__)  !defined(__XEN_TOOLS__) is not
 happy and I get the error message #error vm event operations are
 intended for use only by Xen or node control tools. This is a new
 addition into the mem_event.h thus the build without this
 pre-processor check works just fine. All other headers within
 include/public that have similar preprocessor checks are already
 excluded in this line, thus my impression was this is the correct way
 to get the build to progress. Of course if I missed something please
 let me know, I don't honestly fully comprehend the build process here.

 Thanks,
 Tamas

Here is the full error message I get when the header is not filtered-out here:

for i in public/vcpu.h public/kexec.h public/dom0_ops.h public/nmi.h
public/xencomm.h public/gcov.h public/elfnote.h public/xenoprof.h
public/sched.h public/version.h public/mem_event.h public/memory.h
public/xen.h public/features.h public/callback.h public/grant_table.h
public/xen-compat.h public/physdev.h public/platform.h public/tmem.h
public/trace.h public/event_channel.h public/io/xs_wire.h
public/io/kbdif.h public/io/protocols.h public/io/ring.h
public/io/fsif.h public/io/blkif.h public/io/console.h
public/io/tpmif.h public/io/fbif.h public/io/xenbus.h
public/io/netif.h public/io/pciif.h public/io/usbif.h
public/io/libxenvchan.h public/io/vscsiif.h public/hvm/pvdrivers.h
public/hvm/e820.h public/hvm/hvm_xs_strings.h public/hvm/hvm_op.h
public/hvm/hvm_info_table.h public/hvm/ioreq.h public/hvm/params.h; do
gcc -ansi -include stdint.h -Wall -W -Werror -S -o /dev/null -x c $i
|| exit 1; echo $i; done headers.chk.new
public/mem_event.h:31:2: error: #error vm event operations are
intended for use only by Xen or node control tools
 #error vm event operations are intended for use only by Xen or node
control tools
  ^
Makefile:94: recipe for target 'headers.chk' failed
make[3]: *** [headers.chk] Error 1

Tamas

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


Re: [Xen-devel] [RFC PATCH V3 05/12] xen: Introduce vm_event

2015-01-31 Thread Tamas K Lengyel
On Fri, Jan 30, 2015 at 6:25 PM, Daniel De Graaf dgde...@tycho.nsa.gov wrote:
 On 01/29/2015 04:46 PM, Tamas K Lengyel wrote:

 To make it easier to review the renaming process of mem_event - vm_event,
 the process is broken into three pieces, of which this patch is the first.
 In this patch the vm_event subsystem is introduced and hooked into the
 build
 process, but it is not yet used anywhere.

 Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com


 [...]

 diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
 index f20e89c..d6d403a 100644
 --- a/xen/include/xsm/dummy.h
 +++ b/xen/include/xsm/dummy.h
 @@ -525,6 +525,18 @@ static XSM_INLINE int
 xsm_mem_event_op(XSM_DEFAULT_ARG struct domain *d, int op)
   XSM_ASSERT_ACTION(XSM_DM_PRIV);
   return xsm_default_action(action, current-domain, d);
   }
 +
 +static XSM_INLINE int xsm_vm_event_control(XSM_DEFAULT_ARG struct domain
 *d, int mode, int op)
 +{
 +XSM_ASSERT_ACTION(XSM_PRIV);
 +return xsm_default_action(action, current-domain, d);
 +}
 +
 +static XSM_INLINE int xsm_vm_event_op(XSM_DEFAULT_ARG struct domain *d,
 int op)
 +{
 +XSM_ASSERT_ACTION(XSM_DM_PRIV);
 +return xsm_default_action(action, current-domain, d);
 +}
   #endif

 [...]

 diff --git a/xen/xsm/flask/policy/access_vectors
 b/xen/xsm/flask/policy/access_vectors
 index 1da9f63..a4241b5 100644
 --- a/xen/xsm/flask/policy/access_vectors
 +++ b/xen/xsm/flask/policy/access_vectors
 @@ -250,6 +250,7 @@ class hvm
   hvmctl
   # XEN_DOMCTL_set_access_required
   mem_event
 +vm_event
   # XEN_DOMCTL_mem_sharing_op and XENMEM_sharing_op_{share,add_physmap}
 with:
   #  source = the domain making the hypercall
   #  target = domain whose memory is being shared


 This implies that device model domains should be allowed to use the
 operations
 covered by xsm_vm_event_op but not those covered by xsm_vm_event_control.
 If this is how the eventual operations are intended to be used, the FLASK
 permissions also need to be split so that a similar distinction can be made
 in
 the policy.

 After looking at the later patches in this series, this appears to be a flaw
 in
 the existing FLASK hooks that got copied over.  While it is still useful to
 fix,
 it  may be better to make the split in a separate patch from the renames.
 Now
 that VM events apply to more than just HVM domains, it may be useful to move
 the new permission(s) from class hvm to either domain2 or mmu.

 --
 Daniel De Graaf
 National Security Agency

Moving it to domain2 would make sense to me. The namings seem to be
pretty poor so I have a hard time understanding why xsm_vm_event_op
and xsm_vm_event_control differ when it comes to device model domains.
The event_op corresponds to memops for access, paging and sharing
while event_control for the domctl that enables/disables the rings. So
yes, I think splitting the name for these separating things would make
sense to clarify what they represent but whether that restriction on
device model domains was intentional I'm not sure about.

Tamas

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


Re: [Xen-devel] [RFC PATCH V2 1/8] xen/mem_event: Cleanup of mem_event structures

2015-01-23 Thread Tamas K Lengyel
On Fri, Jan 23, 2015 at 10:00 AM, Jan Beulich jbeul...@suse.com wrote:
 (re-adding xen-devel)

 On 22.01.15 at 17:54, tamas.leng...@zentific.com wrote:
 On Thu, Jan 22, 2015 at 5:34 PM, Jan Beulich jbeul...@suse.com wrote:
 On 22.01.15 at 17:23, tamas.leng...@zentific.com wrote:
 Wouldn't making the
 struct packed just take care of it automatically?

 How would you envision to do that without using compiler
 extensions?

 My understanding of making the struct packed is that there is simply
 no alignment and padding. Thus, it would look the same on 32-bit and
 64-bit as the size of each member is explicitly the same on each
 architecture. Am I missing something here?

 But isn't that exactly what I suggested by adding explicit padding?
 If not, please give an example.

 Jan

Ack, I was thinking of using  __attribute__((packed)) but I see your
point now that that's a gcc extensions. So we are going to have to do
it by hand as you said.

Tamas

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


Re: [Xen-devel] [RFC PATCH V2 8/8] x86/hvm: factor out vm_event related functions into separate file

2015-01-23 Thread Tamas K Lengyel
On Fri, Jan 23, 2015 at 10:03 AM, Jan Beulich jbeul...@suse.com wrote:
 On 23.01.15 at 09:56, rcojoc...@bitdefender.com wrote:
 On 01/22/2015 06:42 PM, Tamas K Lengyel wrote:
 On Thu, Jan 22, 2015 at 5:25 PM, Jan Beulich jbeul...@suse.com wrote:
 On 18.01.15 at 16:18, tamas.leng...@zentific.com wrote:
 +void hvm_event_msr(unsigned long msr, unsigned long value)
 +{
 +vm_event_request_t req = {
 +.reason = VM_EVENT_REASON_MSR,
 +.vcpu_id = current-vcpu_id,
 +.msr_event.msr = msr,
 +.msr_event.new_value = value,
 +};

 The .msr_event sub-structure also has an old_value member - how
 come this doesn't get filled (I realize the old code was this way,
 but I now doubt earlier patches are all correct in the regard).

 Razvan might have more information on this side as I haven't really
 touched MSR events. I vaguely recall some issues with having access to
 the old MSR value?

 Indeed, getting the previous value would be a bit involved. Please see
 xen/arch/x86/hvm/hvm.c, specifically hvm_msr_write_intercept(). At first
 glance, you'd have to call hvm_msr_read_intercept() to get the previous
 value, or create some sort of cache for previous values for all MSRs,
 updated by hvm_msr_write_intercept().

 Since this has not had any real value for my use-case, and since my code
 has only needed to keep track of a handful of MSRs, I took the route of
 caching previous values for them in the userspace application.

 This is, of course, not to say that it can't be done at the HV level,
 just that (at least IMHO) the HV-level costs have outweighed the benefits.

 In which case the respective interface structure field should have a
 comment attached saying that it currently doesn't hold what the field
 name promises (and, without having checked whether this may already
 be the case, it should be made hold a deterministic value, e.g. zero).

 Jan

Ack, I'll remove it as we don't need unused struct members to pollute
the landscape.

Tamas

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


Re: [Xen-devel] [PATCH 00/11] Alternate p2m: support multiple copies of host p2m

2015-01-13 Thread Tamas K Lengyel
On Mon, Jan 12, 2015 at 7:31 PM, Ed White edmund.h.wh...@intel.com wrote:
 On 01/12/2015 10:00 AM, Ian Jackson wrote:
 Ed White writes (Re: [PATCH 00/11] Alternate p2m: support multiple copies 
 of host p2m):
 The hypercalls are all there. My testing is all done in a Windows
 domU with the tests running inside that domain, so I couldn't use
 tools support even if I had it.

 To support this code in-tree, I think we will need Open Source code
 for exercising it, surely ?


 I'm hoping that, as Andrew says, there will be people interested
 in using these capabilities, and that some of them will be prepared
 to help fill in the gaps. That's why I wanted to send the series to
 the list very early in the 4.6 development cycle.

 If that doesn't turn out to be the case, I'll see if I can find some
 help internally, but I have neither the bandwidth nor the expertise
 to do everything myself.

 Ed

Hi Ed,
we are certainly very interested in this feature so thanks for posting
this series!

I also see a usecase for multiple copies of host p2m by enabling
better performance for monitoring with the existing memaccess API.
Currently the problem is that if a memaccess violation occurs on one
vcpu, the memaccess settings need to be cleared, then re-applied again
after the operation has passed (usually done via singlestepping). With
multiple vCPUs there is a potential racecondition here, unless all
other vCPUs are paused while the memaccess settings are cleared. With
multiple copies of the host p2m, we could easily just swap in a table
for the violating vCPU where the permissions are clear, without
affecting any of the other vCPUs. This could be exercised by extending
the xen-access test tool!

Is this something you think would be within scope for the envisioned
use-case for this series?

Tamas

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


Re: [Xen-devel] [PATCH 00/11] Alternate p2m: support multiple copies of host p2m

2015-01-14 Thread Tamas K Lengyel
On Wed, Jan 14, 2015 at 12:09 PM, Jan Beulich jbeul...@suse.com wrote:
 On 14.01.15 at 11:31, tamas.leng...@zentific.com wrote:
 On Wed, Jan 14, 2015 at 8:04 AM, Jan Beulich jbeul...@suse.com wrote:
 Ed White edmund.h.wh...@intel.com 01/13/15 10:32 PM 
On 01/13/2015 12:45 PM, Andrew Cooper wrote:
 On 13/01/15 20:02, Ed White wrote:
 The set of mfn's is the same, but I do allow gfn-mfn mappings to be
 modified under certain circumstances. One use of this is to point the
 same VA to different physical pages (with different access permissions)
 in different p2m's to hide memory changes.

 What is the practical use of being able to play paging tricks like this
 behind a VMs back?

I'm restricted in how much detail I can go into on a public mailing list,
but imagine that you want a data read to see one thing and an instruction
fetch to see something else.

 How would that work? There can only be one P2M in use at a time, and that's
 used for both translations. Or are you saying at least one of the two 
 accesses
 would be emulated nevertheless?

 I can see it working by having data fetch access to a page trapped via
 mem_access, while instruction fetch is not.

 Understood, but how do you then carry out the data access? The
 question I raised was whether that would then involve emulation.

 Jan

At the mem_access trap point you can swap in an altp2m where the
gfn-mfn mapping is the one where the breakpoints are hidden,
singlestep, then swap the original p2m back. While this approach still
has some overhead because of the use of singlestepping, it is going to
be faster then what you currently have to do, which is removing all
breakpoints, singlestep, then put breakpoints back. Now it would just
be a matter of swapping a single pointer.

Tamas

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


Re: [Xen-devel] [PATCH 00/11] Alternate p2m: support multiple copies of host p2m

2015-01-14 Thread Tamas K Lengyel
On Wed, Jan 14, 2015 at 8:04 AM, Jan Beulich jbeul...@suse.com wrote:
 Ed White edmund.h.wh...@intel.com 01/13/15 10:32 PM 
On 01/13/2015 12:45 PM, Andrew Cooper wrote:
 On 13/01/15 20:02, Ed White wrote:
 The set of mfn's is the same, but I do allow gfn-mfn mappings to be
 modified under certain circumstances. One use of this is to point the
 same VA to different physical pages (with different access permissions)
 in different p2m's to hide memory changes.

 What is the practical use of being able to play paging tricks like this
 behind a VMs back?

I'm restricted in how much detail I can go into on a public mailing list,
but imagine that you want a data read to see one thing and an instruction
fetch to see something else.

 How would that work? There can only be one P2M in use at a time, and that's
 used for both translations. Or are you saying at least one of the two accesses
 would be emulated nevertheless?

 Jan

I can see it working by having data fetch access to a page trapped via
mem_access, while instruction fetch is not. This would be very handy
when doing stealthy debugging where the presence of breakpoints should
be hidden from the guest. With this technique it is possible to
present a copy of the page to the data fetch that has no breakpoints
in it, as done for example in this paper:
http://friends.cs.purdue.edu/pubs/ACSAC13.pdf.

Tamas

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


Re: [Xen-devel] [RFC PATCH V3 10/12] xen: Introduce monitor_op domctl

2015-02-09 Thread Tamas K Lengyel
 --- a/xen/include/public/hvm/params.h
 +++ b/xen/include/public/hvm/params.h
 @@ -162,21 +162,6 @@
   */
  #define HVM_PARAM_ACPI_IOPORTS_LOCATION 19

 -/* Enable blocking memory events, async or sync (pause vcpu until response)
 - * onchangeonly indicates messages only on a change of value */
 -#define HVM_PARAM_MEMORY_EVENT_CR0  20
 -#define HVM_PARAM_MEMORY_EVENT_CR3  21
 -#define HVM_PARAM_MEMORY_EVENT_CR4  22
 -#define HVM_PARAM_MEMORY_EVENT_INT3 23
 -#define HVM_PARAM_MEMORY_EVENT_SINGLE_STEP  25
 -#define HVM_PARAM_MEMORY_EVENT_MSR  30

 I'm not sure if HVM param slots can be re-used. If they can, leaving a
 note that the deleted numbers are available for re-sue would be nice.
 If they can't, leaving a note that they shouldn't be re-used would
 seem mandatory.

 Jan

 I'm not sure either if they can be reused, I would assume yes so I'll
 make the comment accordingly (unless someone knows more and objects).

 All other comments: Ack.

 Thanks!
 Tamas

On a second look there seems to be a handful of HVM params that are
already undefined, so they don't seem to get recycled.

Tamas

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


[Xen-devel] [PATCH V4 12/13] xen/xsm: Split vm_event_op into three separate labels

2015-02-09 Thread Tamas K Lengyel
The XSM label vm_event_op has been used to control the three memops
controlling mem_access, mem_paging and mem_sharing. While these systems
rely on vm_event, these are not vm_event operations themselves. Thus,
in this patch we introduce three separate labels for each of these memops.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
 xen/arch/x86/mm/mem_paging.c|  2 +-
 xen/arch/x86/mm/mem_sharing.c   |  2 +-
 xen/common/mem_access.c |  2 +-
 xen/include/xsm/dummy.h | 20 +++-
 xen/include/xsm/xsm.h   | 33 ++---
 xen/xsm/dummy.c | 13 -
 xen/xsm/flask/hooks.c   | 33 ++---
 xen/xsm/flask/policy/access_vectors |  6 ++
 8 files changed, 100 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/mm/mem_paging.c b/xen/arch/x86/mm/mem_paging.c
index 9d2cc4c..0856c23 100644
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -40,7 +40,7 @@ int mem_paging_memop(unsigned long cmd,
 if ( rc )
 return rc;
 
-rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_paging_op);
+rc = xsm_mem_paging(XSM_DM_PRIV, d);
 if ( rc )
 return rc;
 
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 612ed89..e3ebc05 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1316,7 +1316,7 @@ int mem_sharing_memop(unsigned long cmd,
 if ( !hap_enabled(d) || !d-arch.hvm_domain.mem_sharing_enabled )
  return -ENODEV;
 
-rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_sharing_op);
+rc = xsm_mem_sharing(XSM_DM_PRIV, d);
 if ( rc )
 return rc;
 
diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
index a54fe6e..426f766 100644
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -48,7 +48,7 @@ int mem_access_memop(unsigned long cmd,
 if ( !p2m_mem_access_sanity_check(d) )
 goto out;
 
-rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_access_op);
+rc = xsm_mem_access(XSM_DM_PRIV, d);
 if ( rc )
 goto out;
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 50ee929..16967ed 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -519,11 +519,29 @@ static XSM_INLINE int 
xsm_vm_event_control(XSM_DEFAULT_ARG struct domain *d, int
 return xsm_default_action(action, current-domain, d);
 }
 
-static XSM_INLINE int xsm_vm_event_op(XSM_DEFAULT_ARG struct domain *d, int op)
+#ifdef HAS_MEM_ACCESS
+static XSM_INLINE int xsm_mem_access(XSM_DEFAULT_ARG struct domain *d)
 {
 XSM_ASSERT_ACTION(XSM_DM_PRIV);
 return xsm_default_action(action, current-domain, d);
 }
+#endif
+
+#ifdef HAS_MEM_PAGING
+static XSM_INLINE int xsm_mem_paging(XSM_DEFAULT_ARG struct domain *d)
+{
+XSM_ASSERT_ACTION(XSM_DM_PRIV);
+return xsm_default_action(action, current-domain, d);
+}
+#endif
+
+#ifdef HAS_MEM_SHARING
+static XSM_INLINE int xsm_mem_sharing(XSM_DEFAULT_ARG struct domain *d)
+{
+XSM_ASSERT_ACTION(XSM_DM_PRIV);
+return xsm_default_action(action, current-domain, d);
+}
+#endif
 
 #ifdef CONFIG_X86
 static XSM_INLINE int xsm_do_mca(XSM_DEFAULT_VOID)
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index d56a68f..2a88d84 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -142,7 +142,18 @@ struct xsm_operations {
 int (*get_vnumainfo) (struct domain *d);
 
 int (*vm_event_control) (struct domain *d, int mode, int op);
-int (*vm_event_op) (struct domain *d, int op);
+
+#ifdef HAS_MEM_ACCESS
+int (*mem_access) (struct domain *d);
+#endif
+
+#ifdef HAS_MEM_PAGING
+int (*mem_paging) (struct domain *d);
+#endif
+
+#ifdef HAS_MEM_SHARING
+int (*mem_sharing) (struct domain *d);
+#endif
 
 #ifdef CONFIG_X86
 int (*do_mca) (void);
@@ -546,10 +557,26 @@ static inline int xsm_vm_event_control (xsm_default_t 
def, struct domain *d, int
 return xsm_ops-vm_event_control(d, mode, op);
 }
 
-static inline int xsm_vm_event_op (xsm_default_t def, struct domain *d, int op)
+#ifdef HAS_MEM_ACCESS
+static inline int xsm_mem_access (xsm_default_t def, struct domain *d)
 {
-return xsm_ops-vm_event_op(d, op);
+return xsm_ops-mem_access(d);
 }
+#endif
+
+#ifdef HAS_MEM_PAGING
+static inline int xsm_mem_paging (xsm_default_t def, struct domain *d)
+{
+return xsm_ops-mem_paging(d);
+}
+#endif
+
+#ifdef HAS_MEM_SHARING
+static inline int xsm_mem_sharing (xsm_default_t def, struct domain *d)
+{
+return xsm_ops-mem_sharing(d);
+}
+#endif
 
 #ifdef CONFIG_X86
 static inline int xsm_do_mca(xsm_default_t def)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 6d12d32..3ddb4f6 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -119,7 +119,18 @@ void xsm_fixup_ops (struct xsm_operations *ops)
 set_to_dummy_if_null(ops, map_gmfn_foreign);
 
 set_to_dummy_if_null(ops, vm_event_control);
-set_to_dummy_if_null

[Xen-devel] [PATCH V4 13/13] xen/vm_event: Add RESUME option to vm_event_op domctl

2015-02-09 Thread Tamas K Lengyel
Thus far mem_access and mem_sharing memops had been able to signal
to Xen to start pulling responses off the corresponding rings. In this patch
we retire these memops and add them to the option to the vm_event_op domctl.

The vm_event_op domctl suboptions are the same for each ring thus we
consolidate them into XEN_VM_EVENT_ENABLE/DISABLE/RESUME.

As part of this patch in libxc we also rename the mem_access_enable/disable
functions to monitor_enable/disable and move them into xc_monitor.c.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
 tools/libxc/include/xenctrl.h   | 22 ++---
 tools/libxc/xc_mem_access.c | 25 
 tools/libxc/xc_mem_paging.c | 12 ++--
 tools/libxc/xc_memshr.c | 15 ++
 tools/libxc/xc_monitor.c| 22 +
 tools/libxc/xc_vm_event.c   |  6 +++---
 tools/tests/xen-access/xen-access.c | 12 ++--
 xen/arch/x86/mm/mem_sharing.c   |  9 -
 xen/common/mem_access.c |  9 -
 xen/common/vm_event.c   | 39 +++--
 xen/include/public/domctl.h | 32 ++
 xen/include/public/memory.h | 16 +++
 12 files changed, 113 insertions(+), 106 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 3324132..3042e98 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2269,6 +2269,7 @@ int xc_tmem_restore_extra(xc_interface *xch, int dom, int 
fd);
  */
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id);
+int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id);
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id,
unsigned long gfn);
 int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long 
gfn);
@@ -2282,17 +2283,6 @@ int xc_mem_paging_load(xc_interface *xch, domid_t 
domain_id,
  */
 
 /*
- * Enables mem_access and returns the mapped ring page.
- * Will return NULL on error.
- * Caller has to unmap this page when done.
- */
-void *xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t 
*port);
-void *xc_mem_access_enable_introspection(xc_interface *xch, domid_t domain_id,
- uint32_t *port);
-int xc_mem_access_disable(xc_interface *xch, domid_t domain_id);
-int xc_mem_access_resume(xc_interface *xch, domid_t domain_id);
-
-/*
  * Set a range of memory to a specific access.
  * Allowed types are XENMEM_access_default, XENMEM_access_n, any combination of
  * XENMEM_access_ + (rwx), and XENMEM_access_rx2rw
@@ -2309,7 +2299,17 @@ int xc_get_mem_access(xc_interface *xch, domid_t 
domain_id,
 
 /***
  * Monitor control operations.
+ *
+ * Enables the VM event monitor ring and returns the mapped ring page.
+ * This ring is used to deliver mem_access events, as well a set of additional
+ * events that can be enabled with the xc_monitor_* functions.
+ *
+ * Will return NULL on error.
+ * Caller has to unmap this page when done.
  */
+void *xc_monitor_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
+int xc_monitor_disable(xc_interface *xch, domid_t domain_id);
+int xc_monitor_resume(xc_interface *xch, domid_t domain_id);
 int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t domain_id,
   unsigned int op, unsigned int sync,
   unsigned int onchangeonly);
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index 37e776c..7050692 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -24,31 +24,6 @@
 #include xc_private.h
 #include xen/memory.h
 
-void *xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t 
*port)
-{
-return xc_vm_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
-  port);
-}
-
-int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
-{
-return xc_vm_event_control(xch, domain_id,
-   XEN_VM_EVENT_MONITOR_DISABLE,
-   XEN_DOMCTL_VM_EVENT_OP_MONITOR,
-   NULL);
-}
-
-int xc_mem_access_resume(xc_interface *xch, domid_t domain_id)
-{
-xen_mem_access_op_t mao =
-{
-.op= XENMEM_access_op_resume,
-.domid = domain_id
-};
-
-return do_memory_op(xch, XENMEM_access_op, mao, sizeof(mao));
-}
-
 int xc_set_mem_access(xc_interface *xch,
   domid_t domain_id,
   xenmem_access_t access,
diff --git a/tools/libxc/xc_mem_paging.c b/tools/libxc/xc_mem_paging.c
index b635a4d..9e64190 100644
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -48,7 +48,7 @@ int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
 }
 
 return

[Xen-devel] [PATCH V4 05/13] xen: Rename mem_event to vm_event

2015-02-09 Thread Tamas K Lengyel
In this patch we mechanically rename mem_event to vm_event. This patch
introduces no logic changes to the code. Using the name vm_event better
describes the intended use of this subsystem, which is not limited to memory
events. It can be used for off-loading the decision making logic into helper
applications when encountering various events during a VM's execution.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
v4: Using git -M option for patch to improve readability
Note that in include/xen/vm_event.h the style problems are fixed in a later
 patch in the series so that git can keep track of the relocation here.
---
 MAINTAINERS|   4 +-
 docs/misc/xsm-flask.txt|   2 +-
 tools/libxc/Makefile   |   2 +-
 tools/libxc/xc_mem_access.c|  16 +-
 tools/libxc/xc_mem_paging.c|  18 +-
 tools/libxc/xc_memshr.c|  18 +-
 tools/libxc/xc_private.h   |  12 +-
 tools/libxc/{xc_mem_event.c = xc_vm_event.c}  |  40 +--
 tools/tests/xen-access/xen-access.c| 110 
 tools/xenpaging/pagein.c   |   2 +-
 tools/xenpaging/xenpaging.c| 118 -
 tools/xenpaging/xenpaging.h|   8 +-
 xen/arch/x86/domain.c  |   2 +-
 xen/arch/x86/domctl.c  |   4 +-
 xen/arch/x86/hvm/emulate.c |   6 +-
 xen/arch/x86/hvm/hvm.c |  46 ++--
 xen/arch/x86/hvm/vmx/vmcs.c|   4 +-
 xen/arch/x86/mm/hap/nested_ept.c   |   4 +-
 xen/arch/x86/mm/hap/nested_hap.c   |   4 +-
 xen/arch/x86/mm/mem_paging.c   |   4 +-
 xen/arch/x86/mm/mem_sharing.c  |  32 +--
 xen/arch/x86/mm/p2m-pod.c  |   4 +-
 xen/arch/x86/mm/p2m-pt.c   |   4 +-
 xen/arch/x86/mm/p2m.c  |  99 
 xen/arch/x86/x86_64/compat/mm.c|   6 +-
 xen/arch/x86/x86_64/mm.c   |   6 +-
 xen/common/Makefile|   2 +-
 xen/common/domain.c|  12 +-
 xen/common/domctl.c|   8 +-
 xen/common/mem_access.c|  28 +--
 xen/common/{mem_event.c = vm_event.c} | 336 -
 xen/drivers/passthrough/pci.c  |   2 +-
 xen/include/asm-arm/p2m.h  |   6 +-
 xen/include/asm-x86/domain.h   |   4 +-
 xen/include/asm-x86/hvm/emulate.h  |   2 +-
 xen/include/asm-x86/p2m.h  |   8 +-
 xen/include/public/domctl.h|  46 ++--
 xen/include/public/{mem_event.h = vm_event.h} |  90 +++
 xen/include/xen/mem_access.h   |   4 +-
 xen/include/xen/p2m-common.h   |   4 +-
 xen/include/xen/sched.h|  26 +-
 xen/include/xen/{mem_event.h = vm_event.h}|  74 +++---
 xen/include/xsm/dummy.h|   4 +-
 xen/include/xsm/xsm.h  |  12 +-
 xen/xsm/dummy.c|   4 +-
 xen/xsm/flask/hooks.c  |  16 +-
 xen/xsm/flask/policy/access_vectors|   2 +-
 47 files changed, 632 insertions(+), 633 deletions(-)
 rename tools/libxc/{xc_mem_event.c = xc_vm_event.c} (79%)
 rename xen/common/{mem_event.c = vm_event.c} (59%)
 rename xen/include/public/{mem_event.h = vm_event.h} (61%)
 rename xen/include/xen/{mem_event.h = vm_event.h} (50%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3bbac9e..3d09d15 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -361,10 +361,10 @@ F:xen/arch/x86/mm/mem_sharing.c
 F: xen/arch/x86/mm/mem_paging.c
 F: tools/memshr
 
-MEMORY EVENT AND ACCESS
+VM EVENT AND MEM ACCESS
 M: Tim Deegan t...@xen.org
 S: Supported
-F: xen/common/mem_event.c
+F: xen/common/vm_event.c
 F: xen/common/mem_access.c
 
 XENTRACE
diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 9559028..13ce498 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -87,7 +87,7 @@ __HYPERVISOR_domctl (xen/include/public/domctl.h)
  * XEN_DOMCTL_set_machine_address_size
  * XEN_DOMCTL_debug_op
  * XEN_DOMCTL_gethvmcontext_partial
- * XEN_DOMCTL_mem_event_op
+ * XEN_DOMCTL_vm_event_op
  * XEN_DOMCTL_mem_sharing_op
  * XEN_DOMCTL_setvcpuextstate
  * XEN_DOMCTL_getvcpuextstate
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 6fa88c7..22ba2a1 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -31,7 +31,7 @@ CTRL_SRCS-y   += xc_pm.c
 CTRL_SRCS-y   += xc_cpu_hotplug.c
 CTRL_SRCS-y   += xc_resume.c
 CTRL_SRCS-y   += xc_tmem.c
-CTRL_SRCS-y   += xc_mem_event.c
+CTRL_SRCS-y   += xc_vm_event.c
 CTRL_SRCS-y   += xc_mem_paging.c
 CTRL_SRCS-y

[Xen-devel] [PATCH V4 08/13] xen: Introduce monitor_op domctl

2015-02-09 Thread Tamas K Lengyel
In preparation for allowing for introspecting ARM and PV domains the old
control interface via the hvm_op hypercall is retired. A new control mechanism
is introduced via the domctl hypercall: monitor_op.

This patch aims to establish a base API on which future applications can build
on.

Suggested-by: Andrew Cooper andrew.coop...@citrix.com
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Kevin Tian kevin.t...@intel.com
---
v4: Style fixes
Only defining struct mov_to_cr and struct debug_event in asm-x86/domain.h
Add pause/unpause domain wrapper when enabled a monitor option.
---
 tools/libxc/Makefile|   1 +
 tools/libxc/include/xenctrl.h   |  19 
 tools/libxc/xc_mem_access.c |   9 +-
 tools/libxc/xc_monitor.c| 118 +
 tools/libxc/xc_private.h|   2 +-
 tools/libxc/xc_vm_event.c   |   7 +-
 tools/tests/xen-access/xen-access.c |  14 +--
 xen/arch/x86/Makefile   |   1 +
 xen/arch/x86/hvm/emulate.c  |   3 +-
 xen/arch/x86/hvm/event.c|  69 ++--
 xen/arch/x86/hvm/hvm.c  |  38 +--
 xen/arch/x86/hvm/vmx/vmcs.c |   6 +-
 xen/arch/x86/hvm/vmx/vmx.c  |   2 +-
 xen/arch/x86/mm/p2m.c   |   9 --
 xen/arch/x86/monitor.c  | 204 
 xen/common/domctl.c |   9 ++
 xen/common/vm_event.c   |  19 +---
 xen/include/asm-arm/monitor.h   |  13 +++
 xen/include/asm-x86/domain.h|  28 +
 xen/include/asm-x86/hvm/domain.h|   1 -
 xen/include/asm-x86/monitor.h   |   8 ++
 xen/include/public/domctl.h |  50 -
 xen/include/public/hvm/params.h |  15 ---
 xen/include/public/vm_event.h   |   2 +-
 xen/xsm/flask/hooks.c   |   3 +
 xen/xsm/flask/policy/access_vectors |   2 +
 26 files changed, 510 insertions(+), 142 deletions(-)
 create mode 100644 tools/libxc/xc_monitor.c
 create mode 100644 xen/arch/x86/monitor.c
 create mode 100644 xen/include/asm-arm/monitor.h
 create mode 100644 xen/include/asm-x86/monitor.h

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 22ba2a1..8b609cf 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -32,6 +32,7 @@ CTRL_SRCS-y   += xc_cpu_hotplug.c
 CTRL_SRCS-y   += xc_resume.c
 CTRL_SRCS-y   += xc_tmem.c
 CTRL_SRCS-y   += xc_vm_event.c
+CTRL_SRCS-y   += xc_monitor.c
 CTRL_SRCS-y   += xc_mem_paging.c
 CTRL_SRCS-y   += xc_mem_access.c
 CTRL_SRCS-y   += xc_memshr.c
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 790db53..3324132 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2308,6 +2308,25 @@ int xc_get_mem_access(xc_interface *xch, domid_t 
domain_id,
   uint64_t pfn, xenmem_access_t *access);
 
 /***
+ * Monitor control operations.
+ */
+int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t domain_id,
+  unsigned int op, unsigned int sync,
+  unsigned int onchangeonly);
+int xc_monitor_mov_to_cr3(xc_interface *xch, domid_t domain_id,
+  unsigned int op, unsigned int sync,
+  unsigned int onchangeonly);
+int xc_monitor_mov_to_cr4(xc_interface *xch, domid_t domain_id,
+  unsigned int op, unsigned int sync,
+  unsigned int onchangeonly);
+int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id,
+  unsigned int op, unsigned int extended_capture);
+int xc_monitor_singlestep(xc_interface *xch, domid_t domain_id,
+  unsigned int op);
+int xc_monitor_software_breakpoint(xc_interface *xch, domid_t domain_id,
+   unsigned int op);
+
+/***
  * Memory sharing operations.
  *
  * Unles otherwise noted, these calls return 0 on succes, -1 and errno on
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index 0a3f0e6..37e776c 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -27,14 +27,7 @@
 void *xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t 
*port)
 {
 return xc_vm_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
-  port, 0);
-}
-
-void *xc_mem_access_enable_introspection(xc_interface *xch, domid_t domain_id,
- uint32_t *port)
-{
-return xc_vm_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
-  port, 1);
+  port);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
new file mode 100644
index 000..9e807d1
--- /dev/null
+++ b/tools/libxc/xc_monitor.c
@@ -0,0 +1,118

[Xen-devel] [PATCH V4 10/13] xen/vm_event: Decouple vm_event and mem_access.

2015-02-09 Thread Tamas K Lengyel
The vm_event subsystem has been artifically tied to the presence of mem_access.
While mem_access does depend on vm_event, vm_event is an entirely independent
subsystem that can be used for arbitrary function-offloading to helper apps in
domains. This patch removes the dependency that mem_access needs to be supported
in order to enable vm_event.

A new vm_event_resume function is introduced which pulls all responses off from
given ring and delegates handling to appropriate helper functions (if
necessary). By default, vm_event_resume just pulls the response from the ring
and unpauses the corresponding vCPU. This approach reduces code duplication
and present a single point of entry for the entire vm_event subsystem's
response handling mechanism.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
v4: Consolidate resume routines into vm_event_resume
Style fixes
Sort xen/common/Makefile to be alphabetical
v3: Move ring processing out from mem_access.c to monitor.c in common
---
 xen/arch/x86/mm/mem_sharing.c   | 37 +-
 xen/arch/x86/mm/p2m.c   | 66 ++-
 xen/common/Makefile | 18 -
 xen/common/mem_access.c | 36 +
 xen/common/vm_event.c   | 77 +++--
 xen/include/asm-x86/mem_sharing.h   |  1 -
 xen/include/asm-x86/p2m.h   |  2 +-
 xen/include/xen/mem_access.h| 14 +--
 xen/include/xen/vm_event.h  | 70 -
 xen/include/xsm/dummy.h |  2 -
 xen/include/xsm/xsm.h   |  4 --
 xen/xsm/dummy.c |  2 -
 xen/xsm/flask/hooks.c   | 36 -
 xen/xsm/flask/policy/access_vectors |  8 ++--
 14 files changed, 137 insertions(+), 236 deletions(-)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 0731261..4959407 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -591,40 +591,6 @@ unsigned int mem_sharing_get_nr_shared_mfns(void)
 return (unsigned int)atomic_read(nr_shared_mfns);
 }
 
-int mem_sharing_sharing_resume(struct domain *d)
-{
-vm_event_response_t rsp;
-
-/* Get all requests off the ring */
-while ( vm_event_get_response(d, d-vm_event-share, rsp) )
-{
-struct vcpu *v;
-
-if ( rsp.version != VM_EVENT_INTERFACE_VERSION )
-{
-gdprintk(XENLOG_WARNING, vm_event interface version mismatch!\n);
-continue;
-}
-
-#ifndef NDEBUG
-if ( rsp.flags  VM_EVENT_FLAG_DUMMY )
-continue;
-#endif
-
-/* Validate the vcpu_id in the response. */
-if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
-continue;
-
-v = d-vcpu[rsp.vcpu_id];
-
-/* Unpause domain/vcpu */
-if ( rsp.flags  VM_EVENT_FLAG_VCPU_PAUSED )
-vm_event_vcpu_unpause(v);
-}
-
-return 0;
-}
-
 /* Functions that change a page's type and ownership */
 static int page_make_sharable(struct domain *d, 
struct page_info *page, 
@@ -1475,7 +1441,8 @@ int mem_sharing_memop(struct domain *d, 
xen_mem_sharing_op_t *mec)
 {
 if ( !mem_sharing_enabled(d) )
 return -EINVAL;
-rc = mem_sharing_sharing_resume(d);
+
+vm_event_resume(d, d-vm_event-share);
 }
 break;
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 13a567d..5ccaede 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1277,13 +1277,13 @@ int p2m_mem_paging_prep(struct domain *d, unsigned long 
gfn, uint64_t buffer)
 }
 
 /**
- * p2m_mem_paging_resume - Resume guest gfn and vcpus
+ * p2m_mem_paging_resume - Resume guest gfn
  * @d: guest domain
- * @gfn: guest page in paging state
+ * @rsp: vm_event response received
+ *
+ * p2m_mem_paging_resume() will forward the p2mt of a gfn to ram_rw. It is
+ * called by the pager.
  *
- * p2m_mem_paging_resume() will forward the p2mt of a gfn to ram_rw and all
- * waiting vcpus will be unpaused again. It is called by the pager.
- * 
  * The gfn was previously either evicted and populated, or nominated and
  * populated. If the page was evicted the p2mt will be p2m_ram_paging_in. If
  * the page was just nominated the p2mt will be p2m_ram_paging_in_start because
@@ -1291,56 +1291,30 @@ int p2m_mem_paging_prep(struct domain *d, unsigned long 
gfn, uint64_t buffer)
  *
  * If the gfn was dropped the vcpu needs to be unpaused.
  */
-void p2m_mem_paging_resume(struct domain *d)
+
+void p2m_mem_paging_resume(struct domain *d, vm_event_response_t *rsp)
 {
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
-vm_event_response_t rsp;
 p2m_type_t p2mt;
 p2m_access_t a;
 mfn_t mfn;
 
-/* Pull all responses off the ring */
-while( vm_event_get_response(d, d-vm_event-paging, rsp) )
+/* Fix p2m entry if the page was not dropped

[Xen-devel] [PATCH V4 02/13] xen/mem_event: Cleanup mem_event ring names and domctls

2015-02-09 Thread Tamas K Lengyel
The name of one of the mem_event rings still implies it is used only
for memory accesses, which is no longer the case. It is also used to
deliver various HVM events, thus the name monitor is more appropriate
in this setting.

The mem_event subop definitions are also shortened to be more meaningful.

The tool side changes are only mechanical renaming to match these new names.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
v4: Shorted mem_event domctl subops.
v3: Style and comment fixes.
---
 tools/libxc/xc_domain_restore.c | 14 +++---
 tools/libxc/xc_domain_save.c|  4 ++--
 tools/libxc/xc_hvm_build_x86.c  |  2 +-
 tools/libxc/xc_mem_access.c |  8 
 tools/libxc/xc_mem_event.c  | 12 ++--
 tools/libxc/xc_mem_paging.c |  4 ++--
 tools/libxc/xc_memshr.c |  4 ++--
 tools/libxc/xg_save_restore.h   |  2 +-
 xen/arch/x86/hvm/hvm.c  |  4 ++--
 xen/arch/x86/hvm/vmx/vmcs.c |  2 +-
 xen/arch/x86/mm/p2m.c   |  2 +-
 xen/common/mem_access.c |  8 
 xen/common/mem_event.c  | 30 ++--
 xen/include/public/domctl.h | 43 -
 xen/include/public/hvm/params.h |  2 +-
 xen/include/xen/sched.h |  4 ++--
 16 files changed, 76 insertions(+), 69 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index a382701..2ab9f46 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -734,7 +734,7 @@ typedef struct {
 uint64_t vcpumap[XC_SR_MAX_VCPUS/64];
 uint64_t identpt;
 uint64_t paging_ring_pfn;
-uint64_t access_ring_pfn;
+uint64_t monitor_ring_pfn;
 uint64_t sharing_ring_pfn;
 uint64_t vm86_tss;
 uint64_t console_pfn;
@@ -828,15 +828,15 @@ static int pagebuf_get_one(xc_interface *xch, struct 
restore_ctx *ctx,
 // DPRINTF(paging ring pfn address: %llx\n, buf-paging_ring_pfn);
 return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
-case XC_SAVE_ID_HVM_ACCESS_RING_PFN:
+case XC_SAVE_ID_HVM_MONITOR_RING_PFN:
 /* Skip padding 4 bytes then read the mem access ring location. */
-if ( RDEXACT(fd, buf-access_ring_pfn, sizeof(uint32_t)) ||
- RDEXACT(fd, buf-access_ring_pfn, sizeof(uint64_t)) )
+if ( RDEXACT(fd, buf-monitor_ring_pfn, sizeof(uint32_t)) ||
+ RDEXACT(fd, buf-monitor_ring_pfn, sizeof(uint64_t)) )
 {
 PERROR(error read the access ring pfn);
 return -1;
 }
-// DPRINTF(access ring pfn address: %llx\n, buf-access_ring_pfn);
+// DPRINTF(monitor ring pfn address: %llx\n, buf-monitor_ring_pfn);
 return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
 case XC_SAVE_ID_HVM_SHARING_RING_PFN:
@@ -1660,8 +1660,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, 
uint32_t dom,
 xc_hvm_param_set(xch, dom, HVM_PARAM_IDENT_PT, 
pagebuf.identpt);
 if ( pagebuf.paging_ring_pfn )
 xc_hvm_param_set(xch, dom, HVM_PARAM_PAGING_RING_PFN, 
pagebuf.paging_ring_pfn);
-if ( pagebuf.access_ring_pfn )
-xc_hvm_param_set(xch, dom, HVM_PARAM_ACCESS_RING_PFN, 
pagebuf.access_ring_pfn);
+if ( pagebuf.monitor_ring_pfn )
+xc_hvm_param_set(xch, dom, HVM_PARAM_MONITOR_RING_PFN, 
pagebuf.monitor_ring_pfn);
 if ( pagebuf.sharing_ring_pfn )
 xc_hvm_param_set(xch, dom, HVM_PARAM_SHARING_RING_PFN, 
pagebuf.sharing_ring_pfn);
 if ( pagebuf.vm86_tss )
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index 254fdb3..949ef64 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1664,9 +1664,9 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t 
dom, uint32_t max_iter
 goto out;
 }
 
-chunk.id = XC_SAVE_ID_HVM_ACCESS_RING_PFN;
+chunk.id = XC_SAVE_ID_HVM_MONITOR_RING_PFN;
 chunk.data = 0;
-xc_hvm_param_get(xch, dom, HVM_PARAM_ACCESS_RING_PFN, chunk.data);
+xc_hvm_param_get(xch, dom, HVM_PARAM_MONITOR_RING_PFN, chunk.data);
 
 if ( (chunk.data != 0) 
  wrexact(io_fd, chunk, sizeof(chunk)) )
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index c81a25b..30a929d 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -497,7 +497,7 @@ static int setup_guest(xc_interface *xch,
  special_pfn(SPECIALPAGE_CONSOLE));
 xc_hvm_param_set(xch, dom, HVM_PARAM_PAGING_RING_PFN,
  special_pfn(SPECIALPAGE_PAGING));
-xc_hvm_param_set(xch, dom, HVM_PARAM_ACCESS_RING_PFN,
+xc_hvm_param_set(xch, dom, HVM_PARAM_MONITOR_RING_PFN,
  special_pfn(SPECIALPAGE_ACCESS));
 xc_hvm_param_set(xch, dom, HVM_PARAM_SHARING_RING_PFN

[Xen-devel] [PATCH V4 01/13] xen/mem_event: Cleanup of mem_event structures

2015-02-09 Thread Tamas K Lengyel
From: Razvan Cojocaru rcojoc...@bitdefender.com

The public mem_event structures used to communicate with helper applications via
shared rings have been used in different settings. However, the variable names
within this structure have not reflected this fact, resulting in the reuse of
variables to mean different things under different scenarios.

This patch remedies the issue by clearly defining the structure members based on
the actual context within which the structure is used.

Signed-off-by: Razvan Cojocaru rcojoc...@bitdefender.com
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
v4: Attach mem_event version to each outgoing request directly in mem_event.
v3: Add padding to mem_event structures.
Add version field to mem_event structures and checks for it.
---
 tools/tests/xen-access/xen-access.c |  43 +
 tools/xenpaging/xenpaging.c |  40 
 xen/arch/x86/hvm/hvm.c  | 177 +++-
 xen/arch/x86/mm/mem_sharing.c   |  16 +++-
 xen/arch/x86/mm/p2m.c   | 143 -
 xen/common/mem_access.c |   6 ++
 xen/common/mem_event.c  |   2 +
 xen/include/public/mem_event.h  | 108 +-
 8 files changed, 325 insertions(+), 210 deletions(-)

diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index 6cb382d..dd21d3b 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -551,13 +551,21 @@ int main(int argc, char *argv[])
 continue;
 }
 
+if ( req.version != MEM_EVENT_INTERFACE_VERSION )
+{
+ERROR(Error: mem_event interface version mismatch!\n);
+interrupted = -1;
+continue;
+}
+
 memset( rsp, 0, sizeof (rsp) );
+rsp.version = MEM_EVENT_INTERFACE_VERSION;
 rsp.vcpu_id = req.vcpu_id;
 rsp.flags = req.flags;
 
 switch (req.reason) {
-case MEM_EVENT_REASON_VIOLATION:
-rc = xc_get_mem_access(xch, domain_id, req.gfn, access);
+case MEM_EVENT_REASON_MEM_ACCESS:
+rc = xc_get_mem_access(xch, domain_id, req.u.mem_access.gfn, 
access);
 if (rc  0)
 {
 ERROR(Error %d getting mem_access event\n, rc);
@@ -567,21 +575,21 @@ int main(int argc, char *argv[])
 
 printf(PAGE ACCESS: %c%c%c for GFN %PRIx64 (offset %06
PRIx64) gla %016PRIx64 (valid: %c; fault in gpt: %c; 
fault with gla: %c) (vcpu %u)\n,
-   req.access_r ? 'r' : '-',
-   req.access_w ? 'w' : '-',
-   req.access_x ? 'x' : '-',
-   req.gfn,
-   req.offset,
-   req.gla,
-   req.gla_valid ? 'y' : 'n',
-   req.fault_in_gpt ? 'y' : 'n',
-   req.fault_with_gla ? 'y': 'n',
+   req.u.mem_access.access_r ? 'r' : '-',
+   req.u.mem_access.access_w ? 'w' : '-',
+   req.u.mem_access.access_x ? 'x' : '-',
+   req.u.mem_access.gfn,
+   req.u.mem_access.offset,
+   req.u.mem_access.gla,
+   req.u.mem_access.gla_valid ? 'y' : 'n',
+   req.u.mem_access.fault_in_gpt ? 'y' : 'n',
+   req.u.mem_access.fault_with_gla ? 'y': 'n',
req.vcpu_id);
 
 if ( default_access != after_first_access )
 {
 rc = xc_set_mem_access(xch, domain_id, after_first_access,
-   req.gfn, 1);
+   req.u.mem_access.gfn, 1);
 if (rc  0)
 {
 ERROR(Error %d setting gfn to access_type %d\n, rc,
@@ -592,13 +600,12 @@ int main(int argc, char *argv[])
 }
 
 
-rsp.gfn = req.gfn;
-rsp.p2mt = req.p2mt;
+rsp.u.mem_access.gfn = req.u.mem_access.gfn;
 break;
-case MEM_EVENT_REASON_INT3:
-printf(INT3: rip=%016PRIx64, gfn=%PRIx64 (vcpu %d)\n, 
-   req.gla, 
-   req.gfn,
+case MEM_EVENT_REASON_SOFTWARE_BREAKPOINT:
+printf(INT3: rip=%016PRIx64, gfn=%PRIx64 (vcpu %d)\n,
+   req.regs.x86.rip,
+   req.u.software_breakpoint.gfn,
req.vcpu_id);
 
 /* Reinject */
diff --git a/tools/xenpaging/xenpaging.c b/tools/xenpaging/xenpaging.c
index 82c1ee4..c71ee06 100644
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -684,9 +684,9 @@ static int

[Xen-devel] [PATCH V4 09/13] xen/vm_event: Check for VM_EVENT_FLAG_DUMMY only in Debug builds

2015-02-09 Thread Tamas K Lengyel
The flag is only used for debugging purposes, thus it should be only checked
for in debug builds of Xen.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
 xen/arch/x86/mm/mem_sharing.c | 2 ++
 xen/arch/x86/mm/p2m.c | 2 ++
 xen/common/mem_access.c   | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 9d796e7..0731261 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -606,8 +606,10 @@ int mem_sharing_sharing_resume(struct domain *d)
 continue;
 }
 
+#ifndef NDEBUG
 if ( rsp.flags  VM_EVENT_FLAG_DUMMY )
 continue;
+#endif
 
 /* Validate the vcpu_id in the response. */
 if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 38defdf..13a567d 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1310,8 +1310,10 @@ void p2m_mem_paging_resume(struct domain *d)
 continue;
 }
 
+#ifndef NDEBUG
 if ( rsp.flags  VM_EVENT_FLAG_DUMMY )
 continue;
+#endif
 
 /* Validate the vcpu_id in the response. */
 if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
index f77f134..15dcbf0 100644
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -44,8 +44,10 @@ void mem_access_resume(struct domain *d)
 continue;
 }
 
+#ifndef NDEBUG
 if ( rsp.flags  VM_EVENT_FLAG_DUMMY )
 continue;
+#endif
 
 /* Validate the vcpu_id in the response. */
 if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
-- 
2.1.4


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


[Xen-devel] [PATCH V4 00/13] xen: Clean-up of mem_event subsystem

2015-02-09 Thread Tamas K Lengyel
This patch series aims to clean up the mem_event subsystem within Xen. The
original use-case for this system was to allow external helper applications
running in privileged domains to control various memory operations performed
by Xen. Amongs these were paging, sharing and access control. The subsystem
has since been extended to also deliver non-memory related events, namely
various HVM debugging events (INT3, MTF, MOV-TO-CR, MOV-TO-MSR). The structures
and naming of related functions however has not caught up to these new
use-cases, thus leaving many ambiguities in the code. Furthermore, future
use-cases envisioned for this subsystem include PV domains and ARM domains,
thus there is a need to establish a common base to build on.

In this series we convert the mem_event system to vm_event in which we clearly
define the scope of information that is transmitted via the event
delivery mechanism. Afterwards, we clean up the naming of the structures and
related functions to more clearly be in line with their actual operations.
Finally, the control of monitor events is moved to a new domctl, monitor_op.

Each patch in the series has been build-tested on x86 and ARM, both with
and without XSM enabled.

This PATCH series is also available at:
https://github.com/tklengyel/xen/tree/mem_event_cleanup4

Razvan Cojocaru (1):
  xen/mem_event: Cleanup of mem_event structures

Tamas K Lengyel (12):
  xen/mem_event: Cleanup mem_event ring names and domctls
  xen/mem_paging: Convert mem_event_op to mem_paging_op
  xen/mem_access: Merge mem_event sanity check into mem_access check
  xen: Rename mem_event to vm_event
  tools/tests: Clean-up tools/tests/xen-access
  x86/hvm: factor out and rename vm_event related functions
  xen: Introduce monitor_op domctl
  xen/vm_event: Check for VM_EVENT_FLAG_DUMMY only in Debug builds
  xen/vm_event: Decouple vm_event and mem_access.
  xen/vm_event: Relocate memop checks
  xen/xsm: Split vm_event_op into three separate labels
  xen/vm_event: Add RESUME option to vm_event_op domctl

 MAINTAINERS   |   4 +-
 docs/misc/xsm-flask.txt   |   2 +-
 tools/libxc/Makefile  |   3 +-
 tools/libxc/include/xenctrl.h |  41 ++-
 tools/libxc/xc_domain_restore.c   |  14 +-
 tools/libxc/xc_domain_save.c  |   4 +-
 tools/libxc/xc_hvm_build_x86.c|   2 +-
 tools/libxc/xc_mem_access.c   |  32 --
 tools/libxc/xc_mem_paging.c   |  52 ++-
 tools/libxc/xc_memshr.c   |  29 +-
 tools/libxc/xc_monitor.c  | 140 
 tools/libxc/xc_private.h  |  15 +-
 tools/libxc/{xc_mem_event.c = xc_vm_event.c} |  59 ++-
 tools/libxc/xg_save_restore.h |   2 +-
 tools/tests/xen-access/xen-access.c   | 226 +---
 tools/xenpaging/pagein.c  |   2 +-
 tools/xenpaging/xenpaging.c   | 154 
 tools/xenpaging/xenpaging.h   |   8 +-
 xen/arch/x86/Makefile |   1 +
 xen/arch/x86/domain.c |   2 +-
 xen/arch/x86/domctl.c |   4 +-
 xen/arch/x86/hvm/Makefile |   3 +-
 xen/arch/x86/hvm/emulate.c|   9 +-
 xen/arch/x86/hvm/event.c  | 190 ++
 xen/arch/x86/hvm/hvm.c| 192 +-
 xen/arch/x86/hvm/vmx/vmcs.c   |  10 +-
 xen/arch/x86/hvm/vmx/vmx.c|   9 +-
 xen/arch/x86/mm/hap/nested_ept.c  |   4 +-
 xen/arch/x86/mm/hap/nested_hap.c  |   4 +-
 xen/arch/x86/mm/mem_paging.c  |  46 ++-
 xen/arch/x86/mm/mem_sharing.c | 136 ---
 xen/arch/x86/mm/p2m-pod.c |   4 +-
 xen/arch/x86/mm/p2m-pt.c  |   4 +-
 xen/arch/x86/mm/p2m.c | 259 +++---
 xen/arch/x86/monitor.c| 204 +++
 xen/arch/x86/x86_64/compat/mm.c   |  26 +-
 xen/arch/x86/x86_64/mm.c  |  26 +-
 xen/common/Makefile   |  18 +-
 xen/common/domain.c   |  12 +-
 xen/common/domctl.c   |  17 +-
 xen/common/mem_access.c   |  47 +--
 xen/common/{mem_event.c = vm_event.c}| 492 ++
 xen/drivers/passthrough/pci.c |   2 +-
 xen/include/asm-arm/monitor.h |  13 +
 xen/include/asm-arm/p2m.h |   6 +-
 xen/include/asm-x86/domain.h  |  32 +-
 xen/include/asm-x86/hvm/domain.h  |   1 -
 xen/include/asm-x86/hvm/emulate.h |   2 +-
 xen/include/asm-x86/hvm/event.h   |  40 +++
 xen/include/asm-x86/hvm/hvm.h |  11 -
 xen/include/asm-x86/mem_paging.h  |   7 +-
 xen/include/asm

[Xen-devel] [PATCH V4 11/13] xen/vm_event: Relocate memop checks

2015-02-09 Thread Tamas K Lengyel
The memop handler function for paging/sharing responsible for calling XSM
doesn't really have anything to do with vm_event, thus in this patch we
relocate it into mem_paging_memop and mem_sharing_memop. This has already
been the approach in mem_access_memop, so in this patch we just make it
consistent.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
 xen/arch/x86/mm/mem_paging.c  | 42 --
 xen/arch/x86/mm/mem_sharing.c | 76 ++-
 xen/arch/x86/x86_64/compat/mm.c   | 28 +++
 xen/arch/x86/x86_64/mm.c  | 26 +++---
 xen/common/vm_event.c | 43 --
 xen/include/asm-x86/mem_paging.h  |  7 +++-
 xen/include/asm-x86/mem_sharing.h |  4 +--
 xen/include/xen/vm_event.h|  1 -
 8 files changed, 101 insertions(+), 126 deletions(-)

diff --git a/xen/arch/x86/mm/mem_paging.c b/xen/arch/x86/mm/mem_paging.c
index 68b7fcc..9d2cc4c 100644
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -21,40 +21,62 @@
  */
 
 
+#include xen/guest_access.h
 #include asm/p2m.h
-#include xen/vm_event.h
+#include xsm/xsm.h
 
-
-int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *mpc)
+int mem_paging_memop(unsigned long cmd,
+ XEN_GUEST_HANDLE_PARAM(xen_mem_paging_op_t) arg)
 {
+int rc;
+xen_mem_paging_op_t mpo;
+struct domain *d;
+
+rc = -EFAULT;
+if ( copy_from_guest(mpo, arg, 1) )
+return rc;
+
+rc = rcu_lock_live_remote_domain_by_id(mpo.domain, d);
+if ( rc )
+return rc;
+
+rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_paging_op);
+if ( rc )
+return rc;
+
+rc = -ENODEV;
 if ( unlikely(!d-vm_event-paging.ring_page) )
-return -ENODEV;
+return rc;
 
-switch( mpc-op )
+switch( mpo.op )
 {
 case XENMEM_paging_op_nominate:
 {
-return p2m_mem_paging_nominate(d, mpc-gfn);
+rc = p2m_mem_paging_nominate(d, mpo.gfn);
 }
 break;
 
 case XENMEM_paging_op_evict:
 {
-return p2m_mem_paging_evict(d, mpc-gfn);
+rc = p2m_mem_paging_evict(d, mpo.gfn);
 }
 break;
 
 case XENMEM_paging_op_prep:
 {
-unsigned long gfn = mpc-gfn;
-return p2m_mem_paging_prep(d, gfn, mpc-buffer);
+rc = p2m_mem_paging_prep(d, mpo.gfn, mpo.buffer);
 }
 break;
 
 default:
-return -ENOSYS;
+rc = -ENOSYS;
 break;
 }
+
+if ( !rc  __copy_to_guest(arg, mpo, 1) )
+rc = -EFAULT;
+
+return rc;
 }
 
 
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 4959407..612ed89 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -28,6 +28,7 @@
 #include xen/grant_table.h
 #include xen/sched.h
 #include xen/rcupdate.h
+#include xen/guest_access.h
 #include xen/vm_event.h
 #include asm/page.h
 #include asm/string.h
@@ -1293,30 +1294,52 @@ int relinquish_shared_pages(struct domain *d)
 return rc;
 }
 
-int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
+int mem_sharing_memop(unsigned long cmd,
+  XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
 {
-int rc = 0;
+int rc;
+xen_mem_sharing_op_t mso;
+struct domain *d;
+
+rc = -EFAULT;
+if ( copy_from_guest(mso, arg, 1) )
+return rc;
+
+if ( mso.op == XENMEM_sharing_op_audit )
+return mem_sharing_audit();
+
+rc = rcu_lock_live_remote_domain_by_id(mso.domain, d);
+if ( rc )
+return rc;
 
 /* Only HAP is supported */
 if ( !hap_enabled(d) || !d-arch.hvm_domain.mem_sharing_enabled )
  return -ENODEV;
 
-switch(mec-op)
+rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_sharing_op);
+if ( rc )
+return rc;
+
+rc = -ENODEV;
+if ( unlikely(!d-vm_event-share.ring_page) )
+return rc;
+
+switch(mso.op)
 {
 case XENMEM_sharing_op_nominate_gfn:
 {
-unsigned long gfn = mec-u.nominate.u.gfn;
+unsigned long gfn = mso.u.nominate.u.gfn;
 shr_handle_t handle;
 if ( !mem_sharing_enabled(d) )
 return -EINVAL;
 rc = mem_sharing_nominate_page(d, gfn, 0, handle);
-mec-u.nominate.handle = handle;
+mso.u.nominate.handle = handle;
 }
 break;
 
 case XENMEM_sharing_op_nominate_gref:
 {
-grant_ref_t gref = mec-u.nominate.u.grant_ref;
+grant_ref_t gref = mso.u.nominate.u.grant_ref;
 unsigned long gfn;
 shr_handle_t handle;
 
@@ -1325,7 +1348,7 @@ int mem_sharing_memop(struct domain *d, 
xen_mem_sharing_op_t *mec)
 if ( mem_sharing_gref_to_gfn(d, gref, gfn)  0 )
 return -EINVAL;
 rc = mem_sharing_nominate_page(d, gfn, 3, handle);
-mec-u.nominate.handle = handle;
+mso.u.nominate.handle = handle

[Xen-devel] [PATCH V4 06/13] tools/tests: Clean-up tools/tests/xen-access

2015-02-09 Thread Tamas K Lengyel
The spin-lock implementation in the xen-access test program is implemented
in a fashion that is actually incomplete. The x86 assembly that guarantees that
the lock is held by only one thread lacks the lock; instruction.

However, the spin-lock is not actually necessary in xen-access as it is not
multithreaded. The presence of the faulty implementation of the lock in a non-
multithreaded environment is unnecessarily complicated for developers who are
trying to follow this code as a guide in implementing their own applications.
Thus, removing it from the code improves the clarity on the behavior of the
system.

Also converting functions that always return 0 to return to void, and making
the teardown function actually return an error code on error.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
 tools/tests/xen-access/xen-access.c | 99 +++--
 1 file changed, 19 insertions(+), 80 deletions(-)

diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index 0a22a31..fe1589e 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -45,56 +45,6 @@
 #define ERROR(a, b...) fprintf(stderr, a \n, ## b)
 #define PERROR(a, b...) fprintf(stderr, a : %s\n, ## b, strerror(errno))
 
-/* Spinlock and mem event definitions */
-
-#define SPIN_LOCK_UNLOCKED 0
-
-#define ADDR (*(volatile long *) addr)
-/**
- * test_and_set_bit - Set a bit and return its old value
- * @nr: Bit to set
- * @addr: Address to count from
- *
- * This operation is atomic and cannot be reordered.
- * It also implies a memory barrier.
- */
-static inline int test_and_set_bit(int nr, volatile void *addr)
-{
-int oldbit;
-
-asm volatile (
-btsl %2,%1\n\tsbbl %0,%0
-: =r (oldbit), =m (ADDR)
-: Ir (nr), m (ADDR) : memory);
-return oldbit;
-}
-
-typedef int spinlock_t;
-
-static inline void spin_lock(spinlock_t *lock)
-{
-while ( test_and_set_bit(1, lock) );
-}
-
-static inline void spin_lock_init(spinlock_t *lock)
-{
-*lock = SPIN_LOCK_UNLOCKED;
-}
-
-static inline void spin_unlock(spinlock_t *lock)
-{
-*lock = SPIN_LOCK_UNLOCKED;
-}
-
-static inline int spin_trylock(spinlock_t *lock)
-{
-return !test_and_set_bit(1, lock);
-}
-
-#define vm_event_ring_lock_init(_m)  spin_lock_init((_m)-ring_lock)
-#define vm_event_ring_lock(_m)   spin_lock((_m)-ring_lock)
-#define vm_event_ring_unlock(_m) spin_unlock((_m)-ring_lock)
-
 typedef struct vm_event {
 domid_t domain_id;
 xc_evtchn *xce_handle;
@@ -102,7 +52,6 @@ typedef struct vm_event {
 vm_event_back_ring_t back_ring;
 uint32_t evtchn_port;
 void *ring_page;
-spinlock_t ring_lock;
 } vm_event_t;
 
 typedef struct xenaccess {
@@ -180,6 +129,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t 
*xenaccess)
 if ( rc != 0 )
 {
 ERROR(Error tearing down domain xenaccess in xen);
+return rc;
 }
 }
 
@@ -191,6 +141,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t 
*xenaccess)
 if ( rc != 0 )
 {
 ERROR(Error unbinding event port);
+return rc;
 }
 }
 
@@ -201,6 +152,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t 
*xenaccess)
 if ( rc != 0 )
 {
 ERROR(Error closing event channel);
+return rc;
 }
 }
 
@@ -209,6 +161,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t 
*xenaccess)
 if ( rc != 0 )
 {
 ERROR(Error closing connection to xen);
+return rc;
 }
 xenaccess-xc_handle = NULL;
 
@@ -241,9 +194,6 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t 
domain_id)
 /* Set domain id */
 xenaccess-vm_event.domain_id = domain_id;
 
-/* Initialise lock */
-vm_event_ring_lock_init(xenaccess-vm_event);
-
 /* Enable mem_access */
 xenaccess-vm_event.ring_page =
 xc_mem_access_enable(xenaccess-xc_handle,
@@ -314,19 +264,24 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t 
domain_id)
 return xenaccess;
 
  err:
-xenaccess_teardown(xch, xenaccess);
+rc = xenaccess_teardown(xch, xenaccess);
+if ( rc )
+{
+ERROR(Failed to teardown xenaccess structure!\n);
+}
 
  err_iface:
 return NULL;
 }
 
-int get_request(vm_event_t *vm_event, vm_event_request_t *req)
+/*
+ * Note that this function is not thread safe.
+ */
+static void get_request(vm_event_t *vm_event, vm_event_request_t *req)
 {
 vm_event_back_ring_t *back_ring;
 RING_IDX req_cons;
 
-vm_event_ring_lock(vm_event);
-
 back_ring = vm_event-back_ring;
 req_cons = back_ring-req_cons;
 
@@ -337,19 +292,16 @@ int get_request(vm_event_t *vm_event, vm_event_request_t 
*req)
 /* Update ring */
 back_ring-req_cons = req_cons;
 back_ring-sring-req_event = req_cons + 1;
-
-vm_event_ring_unlock(vm_event

[Xen-devel] [PATCH V4 04/13] xen/mem_access: Merge mem_event sanity check into mem_access check

2015-02-09 Thread Tamas K Lengyel
The current sanity check when enabling mem_event is only applicable
to mem_access.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
 xen/common/mem_event.c  | 4 
 xen/include/asm-x86/p2m.h   | 8 +---
 xen/include/public/domctl.h | 1 -
 3 files changed, 1 insertion(+), 12 deletions(-)

diff --git a/xen/common/mem_event.c b/xen/common/mem_event.c
index 8a9119f..3ed6abc 100644
--- a/xen/common/mem_event.c
+++ b/xen/common/mem_event.c
@@ -621,10 +621,6 @@ int mem_event_domctl(struct domain *d, 
xen_domctl_mem_event_op_t *mec,
 case XEN_MEM_EVENT_MONITOR_ENABLE:
 case XEN_MEM_EVENT_MONITOR_ENABLE_INTROSPECTION:
 {
-rc = -ENODEV;
-if ( !p2m_mem_event_sanity_check(d) )
-break;
-
 rc = mem_event_enable(d, mec, med, _VPF_mem_access,
 HVM_PARAM_MONITOR_RING_PFN,
 mem_access_notification);
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index e86e26f..20accc6 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -600,16 +600,10 @@ void p2m_mem_event_emulate_check(struct vcpu *v,
 /* Enable arch specific introspection options (such as MSR interception). */
 void p2m_setup_introspection(struct domain *d);
 
-/* Sanity check for mem_event hardware support */
-static inline bool_t p2m_mem_event_sanity_check(struct domain *d)
-{
-return hap_enabled(d)  cpu_has_vmx;
-}
-
 /* Sanity check for mem_access hardware support */
 static inline bool_t p2m_mem_access_sanity_check(struct domain *d)
 {
-return is_hvm_domain(d);
+return is_hvm_domain(d)  hap_enabled(d)  cpu_has_vmx;
 }
 
 /* 
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 034cec7..3b4c2e2 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -796,7 +796,6 @@ struct xen_domctl_gdbsx_domstatus {
  *
  * The XEN_MEM_EVENT_MONITOR_ENABLE* domctls return several
  * non-standard error codes to indicate why access could not be enabled:
- * ENODEV - host lacks HAP support (EPT/NPT) or HAP is disabled in guest
  * EBUSY  - guest has or had access enabled, ring buffer still active
  *
  */
-- 
2.1.4


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


Re: [Xen-devel] [PATCH V4 01/13] xen/mem_event: Cleanup of mem_event structures

2015-02-10 Thread Tamas K Lengyel
On Tue, Feb 10, 2015 at 1:52 PM, Jan Beulich jbeul...@suse.com wrote:
 On 09.02.15 at 19:53, tamas.leng...@zentific.com wrote:
 +static void hvm_memory_event_cr(uint32_t reason, unsigned long value,
 +unsigned long old)
 +{
 +mem_event_request_t req = {
 +.reason = reason,
 +.vcpu_id = current-vcpu_id,
 +.u.mov_to_cr.new_value = value,
 +.u.mov_to_cr.old_value = old
 +};
 +
 +uint64_t parameters = 0 ;
 +switch(reason)

 Blank line between declarations and statements please. And no blank
 before a semicolon.

Ack


 +{
 +case MEM_EVENT_REASON_MOV_TO_CR0:
 +parameters = current-domain-arch.hvm_domain
 +  .params[HVM_PARAM_MEMORY_EVENT_CR0];
 +break;
 +case MEM_EVENT_REASON_MOV_TO_CR3:
 +parameters = current-domain-arch.hvm_domain
 +  .params[HVM_PARAM_MEMORY_EVENT_CR3];
 +break;
 +case MEM_EVENT_REASON_MOV_TO_CR4:
 +parameters = current-domain-arch.hvm_domain
 +  .params[HVM_PARAM_MEMORY_EVENT_CR4];
 +break;
 +};

 I think you should bail in the default case; perhaps add an
 ASSERT_UNREACHABLE(). And with that I think readability (and
 maybe even generated code) would benefit if you just latched
 the index into .params[].

Simply initializing parameters to be 0 is enough IMHO. The only
callers of this function already explicitly choose one of these cases.
Furthermore, hvm params are retired later in the series anyway so
there wouldn't really be much benefit in tweaking this here.


 @@ -598,6 +600,12 @@ int mem_sharing_sharing_resume(struct domain *d)
  {
  struct vcpu *v;

 +if ( rsp.version != MEM_EVENT_INTERFACE_VERSION )
 +{
 +gdprintk(XENLOG_WARNING, mem_event interface version 
 mismatch!\n);

 Why gdprintk()?

Is that only for debug cases?


 @@ -1310,18 +1322,19 @@ void p2m_mem_paging_resume(struct domain *d)
  /* Fix p2m entry if the page was not dropped */
  if ( !(rsp.flags  MEM_EVENT_FLAG_DROP_PAGE) )
  {
 -gfn_lock(p2m, rsp.gfn, 0);
 -mfn = p2m-get_entry(p2m, rsp.gfn, p2mt, a, 0, NULL);
 +uint64_t gfn = rsp.u.mem_access.gfn;
 +gfn_lock(p2m, gfn, 0);

 Blank line between declarations and statements. Also - why uint64_t
 instead of just unsigned long?

The type of mem_access.gfn is uint64_t so its that for consistency.


 +/* Reasons for the vm event request */
 +/* Default case */
 +#define MEM_EVENT_REASON_UNKNOWN 0
 +/* Memory access violation */
 +#define MEM_EVENT_REASON_MEM_ACCESS  1
 +/* Memory sharing event */
 +#define MEM_EVENT_REASON_MEM_SHARING 2
 +/* Memory paging event */
 +#define MEM_EVENT_REASON_MEM_PAGING  3
 +/* CR0 was updated */
 +#define MEM_EVENT_REASON_MOV_TO_CR0  4
 +/* CR3 was updated */
 +#define MEM_EVENT_REASON_MOV_TO_CR3  5
 +/* CR4 was updated */
 +#define MEM_EVENT_REASON_MOV_TO_CR4  6
 +/* An MSR was updated. Does NOT honour HVMPME_onchangeonly */
 +#define MEM_EVENT_REASON_MOV_TO_MSR  7
 +/* Debug operation executed (int3) */

 If you absolutely want to mention architecture specific things in a
 generic header, please make this an example (i.e. insert e.g.
 above).

Ack.


 +#define MEM_EVENT_REASON_SOFTWARE_BREAKPOINT 8
 +/* Single-step (MTF) */

 Same here then (this one is even VT-x specific).

 @@ -97,31 +112,74 @@ struct mem_event_regs_x86 {
  uint32_t _pad;
  };

 -typedef struct mem_event_st {
 -uint32_t flags;
 -uint32_t vcpu_id;
 -
 +struct mem_event_mem_access_data {

 Do you really need all these _data tags?

Not really, no.


 Jan


Thanks,
Tamas

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


[Xen-devel] [PATCH V5 01/12] xen/mem_event: Cleanup of mem_event structures

2015-02-13 Thread Tamas K Lengyel
The public mem_event structures used to communicate with helper applications via
shared rings have been used in different settings. However, the variable names
within this structure have not reflected this fact, resulting in the reuse of
variables to mean different things under different scenarios.

This patch remedies the issue by clearly defining the structure members based on
the actual context within which the structure is used.

Signed-off-by: Razvan Cojocaru rcojoc...@bitdefender.com
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
v5: Style fixes
Convert gfn to uint32_t and define mem_access flags bits as we can now save
space on the ring this way
Split non-mem_event flags into access/paging flags
v4: Attach mem_event version to each outgoing request directly in mem_event.
v3: Add padding to mem_event structures.
Add version field to mem_event structures and checks for it.
---
 tools/libxc/xc_mem_event.c  |   2 +-
 tools/libxc/xc_private.h|   2 +-
 tools/tests/xen-access/xen-access.c |  45 +
 tools/xenpaging/xenpaging.c |  51 ++-
 xen/arch/x86/hvm/hvm.c  | 177 +++-
 xen/arch/x86/mm/mem_sharing.c   |  16 +++-
 xen/arch/x86/mm/p2m.c   | 163 ++---
 xen/common/mem_access.c |   6 ++
 xen/common/mem_event.c  |   2 +
 xen/include/public/mem_event.h  | 173 ++-
 xen/include/public/memory.h |  11 ++-
 11 files changed, 401 insertions(+), 247 deletions(-)

diff --git a/tools/libxc/xc_mem_event.c b/tools/libxc/xc_mem_event.c
index 8c0be4e..1b5f7c3 100644
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -42,7 +42,7 @@ int xc_mem_event_control(xc_interface *xch, domid_t 
domain_id, unsigned int op,
 
 int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
 unsigned int op, unsigned int mode,
-uint64_t gfn, void *buffer)
+uint32_t gfn, void *buffer)
 {
 xen_mem_event_op_t meo;
 
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 45b8644..bc021b8 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -427,7 +427,7 @@ int xc_mem_event_control(xc_interface *xch, domid_t 
domain_id, unsigned int op,
  unsigned int mode, uint32_t *port);
 int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
 unsigned int op, unsigned int mode,
-uint64_t gfn, void *buffer);
+uint32_t gfn, void *buffer);
 /*
  * Enables mem_event and returns the mapped ring page indicated by param.
  * param can be HVM_PARAM_PAGING/ACCESS/SHARING_RING_PFN
diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index 6cb382d..68f05db 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -551,13 +551,21 @@ int main(int argc, char *argv[])
 continue;
 }
 
+if ( req.version != MEM_EVENT_INTERFACE_VERSION )
+{
+ERROR(Error: mem_event interface version mismatch!\n);
+interrupted = -1;
+continue;
+}
+
 memset( rsp, 0, sizeof (rsp) );
+rsp.version = MEM_EVENT_INTERFACE_VERSION;
 rsp.vcpu_id = req.vcpu_id;
 rsp.flags = req.flags;
 
 switch (req.reason) {
-case MEM_EVENT_REASON_VIOLATION:
-rc = xc_get_mem_access(xch, domain_id, req.gfn, access);
+case MEM_EVENT_REASON_MEM_ACCESS:
+rc = xc_get_mem_access(xch, domain_id, req.u.mem_access.gfn, 
access);
 if (rc  0)
 {
 ERROR(Error %d getting mem_access event\n, rc);
@@ -565,23 +573,23 @@ int main(int argc, char *argv[])
 continue;
 }
 
-printf(PAGE ACCESS: %c%c%c for GFN %PRIx64 (offset %06
+printf(PAGE ACCESS: %c%c%c for GFN %PRIx32 (offset %06
PRIx64) gla %016PRIx64 (valid: %c; fault in gpt: %c; 
fault with gla: %c) (vcpu %u)\n,
-   req.access_r ? 'r' : '-',
-   req.access_w ? 'w' : '-',
-   req.access_x ? 'x' : '-',
-   req.gfn,
-   req.offset,
-   req.gla,
-   req.gla_valid ? 'y' : 'n',
-   req.fault_in_gpt ? 'y' : 'n',
-   req.fault_with_gla ? 'y': 'n',
+   (req.u.mem_access.flags  MEM_ACCESS_R) ? 'r' : '-',
+   (req.u.mem_access.flags  MEM_ACCESS_W) ? 'w' : '-',
+   (req.u.mem_access.flags  MEM_ACCESS_X) ? 'x' : '-',
+   req.u.mem_access.gfn

[Xen-devel] [PATCH V5 09/12] xen/vm_event: Decouple vm_event and mem_access.

2015-02-13 Thread Tamas K Lengyel
The vm_event subsystem has been artifically tied to the presence of mem_access.
While mem_access does depend on vm_event, vm_event is an entirely independent
subsystem that can be used for arbitrary function-offloading to helper apps in
domains. This patch removes the dependency that mem_access needs to be supported
in order to enable vm_event.

A new vm_event_resume function is introduced which pulls all responses off from
given ring and delegates handling to appropriate helper functions (if
necessary). By default, vm_event_resume just pulls the response from the ring
and unpauses the corresponding vCPU. This approach reduces code duplication
and present a single point of entry for the entire vm_event subsystem's
response handling mechanism.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
---
v4: Consolidate resume routines into vm_event_resume
Style fixes
Sort xen/common/Makefile to be alphabetical
v3: Move ring processing out from mem_access.c to monitor.c in common
---
 xen/arch/x86/mm/mem_sharing.c   | 37 +-
 xen/arch/x86/mm/p2m.c   | 66 ++-
 xen/common/Makefile | 18 -
 xen/common/mem_access.c | 36 +
 xen/common/vm_event.c   | 77 +++--
 xen/include/asm-x86/mem_sharing.h   |  1 -
 xen/include/asm-x86/p2m.h   |  2 +-
 xen/include/xen/mem_access.h| 14 +--
 xen/include/xen/vm_event.h  | 70 -
 xen/include/xsm/dummy.h |  2 -
 xen/include/xsm/xsm.h   |  4 --
 xen/xsm/dummy.c |  2 -
 xen/xsm/flask/hooks.c   | 36 -
 xen/xsm/flask/policy/access_vectors |  8 ++--
 14 files changed, 137 insertions(+), 236 deletions(-)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 0459544..4959407 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -591,40 +591,6 @@ unsigned int mem_sharing_get_nr_shared_mfns(void)
 return (unsigned int)atomic_read(nr_shared_mfns);
 }
 
-int mem_sharing_sharing_resume(struct domain *d)
-{
-vm_event_response_t rsp;
-
-/* Get all requests off the ring */
-while ( vm_event_get_response(d, d-vm_event-share, rsp) )
-{
-struct vcpu *v;
-
-if ( rsp.version != VM_EVENT_INTERFACE_VERSION )
-{
-printk(XENLOG_G_WARNING vm_event interface version mismatch\n);
-continue;
-}
-
-#ifndef NDEBUG
-if ( rsp.flags  VM_EVENT_FLAG_DUMMY )
-continue;
-#endif
-
-/* Validate the vcpu_id in the response. */
-if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
-continue;
-
-v = d-vcpu[rsp.vcpu_id];
-
-/* Unpause domain/vcpu */
-if ( rsp.flags  VM_EVENT_FLAG_VCPU_PAUSED )
-vm_event_vcpu_unpause(v);
-}
-
-return 0;
-}
-
 /* Functions that change a page's type and ownership */
 static int page_make_sharable(struct domain *d, 
struct page_info *page, 
@@ -1475,7 +1441,8 @@ int mem_sharing_memop(struct domain *d, 
xen_mem_sharing_op_t *mec)
 {
 if ( !mem_sharing_enabled(d) )
 return -EINVAL;
-rc = mem_sharing_sharing_resume(d);
+
+vm_event_resume(d, d-vm_event-share);
 }
 break;
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 68d57d7..dab1da1 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1279,13 +1279,13 @@ int p2m_mem_paging_prep(struct domain *d, unsigned long 
gfn, uint64_t buffer)
 }
 
 /**
- * p2m_mem_paging_resume - Resume guest gfn and vcpus
+ * p2m_mem_paging_resume - Resume guest gfn
  * @d: guest domain
- * @gfn: guest page in paging state
+ * @rsp: vm_event response received
+ *
+ * p2m_mem_paging_resume() will forward the p2mt of a gfn to ram_rw. It is
+ * called by the pager.
  *
- * p2m_mem_paging_resume() will forward the p2mt of a gfn to ram_rw and all
- * waiting vcpus will be unpaused again. It is called by the pager.
- * 
  * The gfn was previously either evicted and populated, or nominated and
  * populated. If the page was evicted the p2mt will be p2m_ram_paging_in. If
  * the page was just nominated the p2mt will be p2m_ram_paging_in_start because
@@ -1293,56 +1293,30 @@ int p2m_mem_paging_prep(struct domain *d, unsigned long 
gfn, uint64_t buffer)
  *
  * If the gfn was dropped the vcpu needs to be unpaused.
  */
-void p2m_mem_paging_resume(struct domain *d)
+
+void p2m_mem_paging_resume(struct domain *d, vm_event_response_t *rsp)
 {
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
-vm_event_response_t rsp;
 p2m_type_t p2mt;
 p2m_access_t a;
 mfn_t mfn;
 
-/* Pull all responses off the ring */
-while( vm_event_get_response(d, d-vm_event-paging, rsp

[Xen-devel] [PATCH V5 03/12] xen/mem_paging: Convert mem_event_op to mem_paging_op

2015-02-13 Thread Tamas K Lengyel
The only use-case of the mem_event_op structure had been in mem_paging,
thus renaming the structure mem_paging_op and relocating its associated
functions clarifies its actual usage.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Tim Deegan t...@xen.org
Acked-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Jan Beulich jbeul...@suse.com
---
v5: Style fixes
v4: Style fixes
v3: Style fixes
---
 tools/libxc/xc_mem_event.c   | 16 
 tools/libxc/xc_mem_paging.c  | 26 ++
 tools/libxc/xc_private.h |  3 ---
 xen/arch/x86/mm/mem_paging.c | 32 +---
 xen/arch/x86/x86_64/compat/mm.c  | 10 ++
 xen/arch/x86/x86_64/mm.c |  8 
 xen/common/mem_event.c   |  4 ++--
 xen/include/asm-x86/mem_paging.h |  2 +-
 xen/include/public/memory.h  |  9 -
 9 files changed, 48 insertions(+), 62 deletions(-)

diff --git a/tools/libxc/xc_mem_event.c b/tools/libxc/xc_mem_event.c
index ee25cdd..487fcee 100644
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -40,22 +40,6 @@ int xc_mem_event_control(xc_interface *xch, domid_t 
domain_id, unsigned int op,
 return rc;
 }
 
-int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
-unsigned int op, unsigned int mode,
-uint32_t gfn, void *buffer)
-{
-xen_mem_event_op_t meo;
-
-memset(meo, 0, sizeof(meo));
-
-meo.op  = op;
-meo.domain  = domain_id;
-meo.gfn = gfn;
-meo.buffer  = (unsigned long) buffer;
-
-return do_memory_op(xch, mode, meo, sizeof(meo));
-}
-
 void *xc_mem_event_enable(xc_interface *xch, domid_t domain_id, int param,
   uint32_t *port, int enable_introspection)
 {
diff --git a/tools/libxc/xc_mem_paging.c b/tools/libxc/xc_mem_paging.c
index 5194423..049aff4 100644
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -23,6 +23,20 @@
 
 #include xc_private.h
 
+static int xc_mem_paging_memop(xc_interface *xch, domid_t domain_id,
+   unsigned int op, uint32_t gfn, void *buffer)
+{
+xen_mem_paging_op_t mpo;
+
+memset(mpo, 0, sizeof(mpo));
+
+mpo.op  = op;
+mpo.domain  = domain_id;
+mpo.gfn = gfn;
+mpo.buffer  = (unsigned long) buffer;
+
+return do_memory_op(xch, XENMEM_paging_op, mpo, sizeof(mpo));
+}
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
  uint32_t *port)
@@ -49,25 +63,22 @@ int xc_mem_paging_disable(xc_interface *xch, domid_t 
domain_id)
 
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, unsigned long 
gfn)
 {
-return xc_mem_event_memop(xch, domain_id,
+return xc_mem_paging_memop(xch, domain_id,
 XENMEM_paging_op_nominate,
-XENMEM_paging_op,
 gfn, NULL);
 }
 
 int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long 
gfn)
 {
-return xc_mem_event_memop(xch, domain_id,
+return xc_mem_paging_memop(xch, domain_id,
 XENMEM_paging_op_evict,
-XENMEM_paging_op,
 gfn, NULL);
 }
 
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-return xc_mem_event_memop(xch, domain_id,
+return xc_mem_paging_memop(xch, domain_id,
 XENMEM_paging_op_prep,
-XENMEM_paging_op,
 gfn, NULL);
 }
 
@@ -87,9 +98,8 @@ int xc_mem_paging_load(xc_interface *xch, domid_t domain_id,
 if ( mlock(buffer, XC_PAGE_SIZE) )
 return -1;
 
-rc = xc_mem_event_memop(xch, domain_id,
+rc = xc_mem_paging_memop(xch, domain_id,
 XENMEM_paging_op_prep,
-XENMEM_paging_op,
 gfn, buffer);
 
 old_errno = errno;
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index bc021b8..f1f601c 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -425,9 +425,6 @@ int xc_ffs64(uint64_t x);
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
  unsigned int mode, uint32_t *port);
-int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
-unsigned int op, unsigned int mode,
-uint32_t gfn, void *buffer);
 /*
  * Enables mem_event and returns the mapped ring page indicated by param.
  * param can be HVM_PARAM_PAGING/ACCESS/SHARING_RING_PFN
diff --git a/xen/arch/x86/mm/mem_paging.c b/xen/arch/x86/mm/mem_paging.c
index 65f6a3d..87a7b72 100644
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -25,38 +25,32 @@
 #include xen/mem_event.h
 
 
-int mem_paging_memop(struct domain *d

[Xen-devel] [PATCH V5 00/12] xen: Clean-up of mem_event subsystem

2015-02-13 Thread Tamas K Lengyel
This patch series aims to clean up the mem_event subsystem within Xen. The
original use-case for this system was to allow external helper applications
running in privileged domains to control various memory operations performed
by Xen. Amongs these were paging, sharing and access control. The subsystem
has since been extended to also deliver non-memory related events, namely
various HVM debugging events (INT3, MTF, MOV-TO-CR, MOV-TO-MSR). The structures
and naming of related functions however has not caught up to these new
use-cases, thus leaving many ambiguities in the code. Furthermore, future
use-cases envisioned for this subsystem include PV domains and ARM domains,
thus there is a need to establish a common base to build on.

In this series we convert the mem_event system to vm_event in which we clearly
define the scope of information that is transmitted via the event
delivery mechanism. Afterwards, we clean up the naming of the structures and
related functions to more clearly be in line with their actual operations.
Finally, the control of monitor events is moved to a new domctl, monitor_op.

Each patch in the series has been build-tested on x86 and ARM, both with
and without XSM enabled.

This PATCH series is also available at:
https://github.com/tklengyel/xen/tree/mem_event_cleanup5

Tamas K Lengyel (12):
  xen/mem_event: Cleanup of mem_event structures
  xen/mem_event: Cleanup mem_event ring names and domctls
  xen/mem_paging: Convert mem_event_op to mem_paging_op
  xen: Rename mem_event to vm_event
  tools/tests: Clean-up tools/tests/xen-access
  x86/hvm: factor out and rename vm_event related functions
  xen: Introduce monitor_op domctl
  xen/vm_event: Check for VM_EVENT_FLAG_DUMMY only in Debug builds
  xen/vm_event: Decouple vm_event and mem_access.
  xen/vm_event: Relocate memop checks
  xen/xsm: Split vm_event_op into three separate labels
  xen/vm_event: Add RESUME option to vm_event_op domctl

 MAINTAINERS   |   4 +-
 docs/misc/xsm-flask.txt   |   2 +-
 tools/libxc/Makefile  |   3 +-
 tools/libxc/include/xenctrl.h |  41 ++-
 tools/libxc/xc_domain_restore.c   |  14 +-
 tools/libxc/xc_domain_save.c  |   4 +-
 tools/libxc/xc_hvm_build_x86.c|   2 +-
 tools/libxc/xc_mem_access.c   |  32 --
 tools/libxc/xc_mem_paging.c   |  52 ++-
 tools/libxc/xc_memshr.c   |  29 +-
 tools/libxc/xc_monitor.c  | 140 
 tools/libxc/xc_private.h  |  15 +-
 tools/libxc/{xc_mem_event.c = xc_vm_event.c} |  59 ++-
 tools/libxc/xg_save_restore.h |   2 +-
 tools/tests/xen-access/xen-access.c   | 252 +
 tools/xenpaging/pagein.c  |   2 +-
 tools/xenpaging/xenpaging.c   | 157 
 tools/xenpaging/xenpaging.h   |   8 +-
 xen/arch/x86/Makefile |   1 +
 xen/arch/x86/domain.c |   2 +-
 xen/arch/x86/domctl.c |   4 +-
 xen/arch/x86/hvm/Makefile |   3 +-
 xen/arch/x86/hvm/emulate.c|   9 +-
 xen/arch/x86/hvm/event.c  | 190 ++
 xen/arch/x86/hvm/hvm.c| 192 +-
 xen/arch/x86/hvm/vmx/vmcs.c   |  10 +-
 xen/arch/x86/hvm/vmx/vmx.c|   9 +-
 xen/arch/x86/mm/hap/nested_ept.c  |   4 +-
 xen/arch/x86/mm/hap/nested_hap.c  |   4 +-
 xen/arch/x86/mm/mem_paging.c  |  58 +--
 xen/arch/x86/mm/mem_sharing.c | 136 ---
 xen/arch/x86/mm/p2m-pod.c |   4 +-
 xen/arch/x86/mm/p2m-pt.c  |   4 +-
 xen/arch/x86/mm/p2m.c | 269 +++---
 xen/arch/x86/monitor.c| 210 +++
 xen/arch/x86/x86_64/compat/mm.c   |  26 +-
 xen/arch/x86/x86_64/mm.c  |  26 +-
 xen/common/Makefile   |  18 +-
 xen/common/domain.c   |  12 +-
 xen/common/domctl.c   |  17 +-
 xen/common/mem_access.c   |  47 +--
 xen/common/{mem_event.c = vm_event.c}| 495 ++
 xen/drivers/passthrough/pci.c |   2 +-
 xen/include/asm-arm/monitor.h |  13 +
 xen/include/asm-arm/p2m.h |   6 +-
 xen/include/asm-x86/domain.h  |  32 +-
 xen/include/asm-x86/hvm/domain.h  |   1 -
 xen/include/asm-x86/hvm/emulate.h |   2 +-
 xen/include/asm-x86/hvm/event.h   |  40 +++
 xen/include/asm-x86/hvm/hvm.h |  11 -
 xen/include/asm-x86/mem_paging.h  |   7 +-
 xen/include/asm-x86/mem_sharing.h |   5 +-
 xen/include/asm-x86/monitor.h |  30

[Xen-devel] [PATCH V5 02/12] xen/mem_event: Cleanup mem_event ring names and domctls

2015-02-13 Thread Tamas K Lengyel
The name of one of the mem_event rings still implies it is used only
for memory accesses, which is no longer the case. It is also used to
deliver various HVM events, thus the name monitor is more appropriate
in this setting.

The mem_event subop definitions are also shortened to be more meaningful.

The tool side changes are only mechanical renaming to match these new names.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Jan Beulich jbeul...@suse.com
---
v5: Style fixes
v4: Shorted mem_event domctl subops.
v3: Style and comment fixes.
---
 tools/libxc/xc_domain_restore.c | 14 +++---
 tools/libxc/xc_domain_save.c|  4 ++--
 tools/libxc/xc_hvm_build_x86.c  |  2 +-
 tools/libxc/xc_mem_access.c |  8 
 tools/libxc/xc_mem_event.c  | 12 ++--
 tools/libxc/xc_mem_paging.c |  4 ++--
 tools/libxc/xc_memshr.c |  4 ++--
 tools/libxc/xg_save_restore.h   |  2 +-
 xen/arch/x86/hvm/hvm.c  |  4 ++--
 xen/arch/x86/hvm/vmx/vmcs.c |  2 +-
 xen/arch/x86/mm/p2m.c   |  2 +-
 xen/common/mem_access.c |  8 
 xen/common/mem_event.c  | 37 +++
 xen/include/public/domctl.h | 43 -
 xen/include/public/hvm/params.h |  2 +-
 xen/include/xen/sched.h |  4 ++--
 16 files changed, 81 insertions(+), 71 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index a382701..2ab9f46 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -734,7 +734,7 @@ typedef struct {
 uint64_t vcpumap[XC_SR_MAX_VCPUS/64];
 uint64_t identpt;
 uint64_t paging_ring_pfn;
-uint64_t access_ring_pfn;
+uint64_t monitor_ring_pfn;
 uint64_t sharing_ring_pfn;
 uint64_t vm86_tss;
 uint64_t console_pfn;
@@ -828,15 +828,15 @@ static int pagebuf_get_one(xc_interface *xch, struct 
restore_ctx *ctx,
 // DPRINTF(paging ring pfn address: %llx\n, buf-paging_ring_pfn);
 return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
-case XC_SAVE_ID_HVM_ACCESS_RING_PFN:
+case XC_SAVE_ID_HVM_MONITOR_RING_PFN:
 /* Skip padding 4 bytes then read the mem access ring location. */
-if ( RDEXACT(fd, buf-access_ring_pfn, sizeof(uint32_t)) ||
- RDEXACT(fd, buf-access_ring_pfn, sizeof(uint64_t)) )
+if ( RDEXACT(fd, buf-monitor_ring_pfn, sizeof(uint32_t)) ||
+ RDEXACT(fd, buf-monitor_ring_pfn, sizeof(uint64_t)) )
 {
 PERROR(error read the access ring pfn);
 return -1;
 }
-// DPRINTF(access ring pfn address: %llx\n, buf-access_ring_pfn);
+// DPRINTF(monitor ring pfn address: %llx\n, buf-monitor_ring_pfn);
 return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
 case XC_SAVE_ID_HVM_SHARING_RING_PFN:
@@ -1660,8 +1660,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, 
uint32_t dom,
 xc_hvm_param_set(xch, dom, HVM_PARAM_IDENT_PT, 
pagebuf.identpt);
 if ( pagebuf.paging_ring_pfn )
 xc_hvm_param_set(xch, dom, HVM_PARAM_PAGING_RING_PFN, 
pagebuf.paging_ring_pfn);
-if ( pagebuf.access_ring_pfn )
-xc_hvm_param_set(xch, dom, HVM_PARAM_ACCESS_RING_PFN, 
pagebuf.access_ring_pfn);
+if ( pagebuf.monitor_ring_pfn )
+xc_hvm_param_set(xch, dom, HVM_PARAM_MONITOR_RING_PFN, 
pagebuf.monitor_ring_pfn);
 if ( pagebuf.sharing_ring_pfn )
 xc_hvm_param_set(xch, dom, HVM_PARAM_SHARING_RING_PFN, 
pagebuf.sharing_ring_pfn);
 if ( pagebuf.vm86_tss )
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index 254fdb3..949ef64 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1664,9 +1664,9 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t 
dom, uint32_t max_iter
 goto out;
 }
 
-chunk.id = XC_SAVE_ID_HVM_ACCESS_RING_PFN;
+chunk.id = XC_SAVE_ID_HVM_MONITOR_RING_PFN;
 chunk.data = 0;
-xc_hvm_param_get(xch, dom, HVM_PARAM_ACCESS_RING_PFN, chunk.data);
+xc_hvm_param_get(xch, dom, HVM_PARAM_MONITOR_RING_PFN, chunk.data);
 
 if ( (chunk.data != 0) 
  wrexact(io_fd, chunk, sizeof(chunk)) )
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index c81a25b..30a929d 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -497,7 +497,7 @@ static int setup_guest(xc_interface *xch,
  special_pfn(SPECIALPAGE_CONSOLE));
 xc_hvm_param_set(xch, dom, HVM_PARAM_PAGING_RING_PFN,
  special_pfn(SPECIALPAGE_PAGING));
-xc_hvm_param_set(xch, dom, HVM_PARAM_ACCESS_RING_PFN,
+xc_hvm_param_set(xch, dom, HVM_PARAM_MONITOR_RING_PFN,
  special_pfn(SPECIALPAGE_ACCESS));
 xc_hvm_param_set

[Xen-devel] [PATCH V5 07/12] xen: Introduce monitor_op domctl

2015-02-13 Thread Tamas K Lengyel
In preparation for allowing for introspecting ARM and PV domains the old
control interface via the hvm_op hypercall is retired. A new control mechanism
is introduced via the domctl hypercall: monitor_op.

This patch aims to establish a base API on which future applications can build
on.

Suggested-by: Andrew Cooper andrew.coop...@citrix.com
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Kevin Tian kevin.t...@intel.com
Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
---
v5: p2m_vm_event_sanity_check is moved into the monitor_op handler
v4: Style fixes
Only defining struct mov_to_cr and struct debug_event in asm-x86/domain.h
Add pause/unpause domain wrapper when enabled a monitor option.
---
 tools/libxc/Makefile|   1 +
 tools/libxc/include/xenctrl.h   |  19 
 tools/libxc/xc_mem_access.c |   9 +-
 tools/libxc/xc_monitor.c| 118 
 tools/libxc/xc_private.h|   2 +-
 tools/libxc/xc_vm_event.c   |   7 +-
 tools/tests/xen-access/xen-access.c |  14 +--
 xen/arch/x86/Makefile   |   1 +
 xen/arch/x86/hvm/emulate.c  |   3 +-
 xen/arch/x86/hvm/event.c|  69 ++--
 xen/arch/x86/hvm/hvm.c  |  38 +--
 xen/arch/x86/hvm/vmx/vmcs.c |   6 +-
 xen/arch/x86/hvm/vmx/vmx.c  |   2 +-
 xen/arch/x86/mm/p2m.c   |   9 --
 xen/arch/x86/monitor.c  | 210 
 xen/common/domctl.c |   9 ++
 xen/common/vm_event.c   |  23 +---
 xen/include/asm-arm/monitor.h   |  13 +++
 xen/include/asm-x86/domain.h|  28 +
 xen/include/asm-x86/hvm/domain.h|   1 -
 xen/include/asm-x86/monitor.h   |  30 ++
 xen/include/asm-x86/p2m.h   |   8 +-
 xen/include/public/domctl.h |  50 -
 xen/include/public/hvm/params.h |  15 ---
 xen/include/public/vm_event.h   |   2 +-
 xen/xsm/flask/hooks.c   |   3 +
 xen/xsm/flask/policy/access_vectors |   2 +
 27 files changed, 539 insertions(+), 153 deletions(-)
 create mode 100644 tools/libxc/xc_monitor.c
 create mode 100644 xen/arch/x86/monitor.c
 create mode 100644 xen/include/asm-arm/monitor.h
 create mode 100644 xen/include/asm-x86/monitor.h

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 22ba2a1..8b609cf 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -32,6 +32,7 @@ CTRL_SRCS-y   += xc_cpu_hotplug.c
 CTRL_SRCS-y   += xc_resume.c
 CTRL_SRCS-y   += xc_tmem.c
 CTRL_SRCS-y   += xc_vm_event.c
+CTRL_SRCS-y   += xc_monitor.c
 CTRL_SRCS-y   += xc_mem_paging.c
 CTRL_SRCS-y   += xc_mem_access.c
 CTRL_SRCS-y   += xc_memshr.c
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 790db53..3324132 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2308,6 +2308,25 @@ int xc_get_mem_access(xc_interface *xch, domid_t 
domain_id,
   uint64_t pfn, xenmem_access_t *access);
 
 /***
+ * Monitor control operations.
+ */
+int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t domain_id,
+  unsigned int op, unsigned int sync,
+  unsigned int onchangeonly);
+int xc_monitor_mov_to_cr3(xc_interface *xch, domid_t domain_id,
+  unsigned int op, unsigned int sync,
+  unsigned int onchangeonly);
+int xc_monitor_mov_to_cr4(xc_interface *xch, domid_t domain_id,
+  unsigned int op, unsigned int sync,
+  unsigned int onchangeonly);
+int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id,
+  unsigned int op, unsigned int extended_capture);
+int xc_monitor_singlestep(xc_interface *xch, domid_t domain_id,
+  unsigned int op);
+int xc_monitor_software_breakpoint(xc_interface *xch, domid_t domain_id,
+   unsigned int op);
+
+/***
  * Memory sharing operations.
  *
  * Unles otherwise noted, these calls return 0 on succes, -1 and errno on
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index 0a3f0e6..37e776c 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -27,14 +27,7 @@
 void *xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t 
*port)
 {
 return xc_vm_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
-  port, 0);
-}
-
-void *xc_mem_access_enable_introspection(xc_interface *xch, domid_t domain_id,
- uint32_t *port)
-{
-return xc_vm_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
-  port, 1);
+  port);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
diff --git a/tools/libxc

[Xen-devel] [PATCH V5 08/12] xen/vm_event: Check for VM_EVENT_FLAG_DUMMY only in Debug builds

2015-02-13 Thread Tamas K Lengyel
The flag is only used for debugging purposes, thus it should be only checked
for in debug builds of Xen.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
 xen/arch/x86/mm/mem_sharing.c | 2 ++
 xen/arch/x86/mm/p2m.c | 2 ++
 xen/common/mem_access.c   | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 4e5477a..0459544 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -606,8 +606,10 @@ int mem_sharing_sharing_resume(struct domain *d)
 continue;
 }
 
+#ifndef NDEBUG
 if ( rsp.flags  VM_EVENT_FLAG_DUMMY )
 continue;
+#endif
 
 /* Validate the vcpu_id in the response. */
 if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 5ce852e..68d57d7 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1312,8 +1312,10 @@ void p2m_mem_paging_resume(struct domain *d)
 continue;
 }
 
+#ifndef NDEBUG
 if ( rsp.flags  VM_EVENT_FLAG_DUMMY )
 continue;
+#endif
 
 /* Validate the vcpu_id in the response. */
 if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
index a6d82d1..63f2b52 100644
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -44,8 +44,10 @@ void mem_access_resume(struct domain *d)
 continue;
 }
 
+#ifndef NDEBUG
 if ( rsp.flags  VM_EVENT_FLAG_DUMMY )
 continue;
+#endif
 
 /* Validate the vcpu_id in the response. */
 if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
-- 
2.1.4


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


[Xen-devel] [PATCH V5 06/12] x86/hvm: factor out and rename vm_event related functions

2015-02-13 Thread Tamas K Lengyel
To avoid growing hvm.c these functions can be stored separately. Minor style
changes are applied to the logic in the file.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Kevin Tian kevin.t...@intel.com
---
v5: Style fixes
Fix hvm_event_msr input types to match the incoming variables
v4: Style fixes
v3: Style fixes and removing unused fields from msr events.
---
 xen/arch/x86/hvm/Makefile   |   3 +-
 xen/arch/x86/hvm/event.c| 195 
 xen/arch/x86/hvm/hvm.c  | 163 ++---
 xen/arch/x86/hvm/vmx/vmx.c  |   7 +-
 xen/include/asm-x86/hvm/event.h |  40 +
 xen/include/asm-x86/hvm/hvm.h   |  11 ---
 6 files changed, 246 insertions(+), 173 deletions(-)
 create mode 100644 xen/arch/x86/hvm/event.c
 create mode 100644 xen/include/asm-x86/hvm/event.h

diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index eea..69af47f 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -3,6 +3,7 @@ subdir-y += vmx
 
 obj-y += asid.o
 obj-y += emulate.o
+obj-y += event.o
 obj-y += hpet.o
 obj-y += hvm.o
 obj-y += i8254.o
@@ -22,4 +23,4 @@ obj-y += vlapic.o
 obj-y += vmsi.o
 obj-y += vpic.o
 obj-y += vpt.o
-obj-y += vpmu.o
\ No newline at end of file
+obj-y += vpmu.o
diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
new file mode 100644
index 000..3fdd28e
--- /dev/null
+++ b/xen/arch/x86/hvm/event.c
@@ -0,0 +1,195 @@
+/*
+* event.c: Common hardware virtual machine event abstractions.
+*
+* Copyright (c) 2004, Intel Corporation.
+* Copyright (c) 2005, International Business Machines Corporation.
+* Copyright (c) 2008, Citrix Systems, Inc.
+*
+* This program is free software; you can redistribute it and/or modify it
+* under the terms and conditions of the GNU General Public License,
+* version 2, as published by the Free Software Foundation.
+*
+* This program is distributed in the hope 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, write to the Free Software Foundation, Inc., 59 Temple
+* Place - Suite 330, Boston, MA 02111-1307 USA.
+*/
+
+#include xen/vm_event.h
+#include xen/paging.h
+#include public/vm_event.h
+
+static void hvm_event_fill_regs(vm_event_request_t *req)
+{
+const struct cpu_user_regs *regs = guest_cpu_user_regs();
+const struct vcpu *curr = current;
+
+req-regs.x86.rax = regs-eax;
+req-regs.x86.rcx = regs-ecx;
+req-regs.x86.rdx = regs-edx;
+req-regs.x86.rbx = regs-ebx;
+req-regs.x86.rsp = regs-esp;
+req-regs.x86.rbp = regs-ebp;
+req-regs.x86.rsi = regs-esi;
+req-regs.x86.rdi = regs-edi;
+
+req-regs.x86.r8  = regs-r8;
+req-regs.x86.r9  = regs-r9;
+req-regs.x86.r10 = regs-r10;
+req-regs.x86.r11 = regs-r11;
+req-regs.x86.r12 = regs-r12;
+req-regs.x86.r13 = regs-r13;
+req-regs.x86.r14 = regs-r14;
+req-regs.x86.r15 = regs-r15;
+
+req-regs.x86.rflags = regs-eflags;
+req-regs.x86.rip= regs-eip;
+
+req-regs.x86.msr_efer = curr-arch.hvm_vcpu.guest_efer;
+req-regs.x86.cr0 = curr-arch.hvm_vcpu.guest_cr[0];
+req-regs.x86.cr3 = curr-arch.hvm_vcpu.guest_cr[3];
+req-regs.x86.cr4 = curr-arch.hvm_vcpu.guest_cr[4];
+}
+
+static int hvm_event_traps(uint64_t parameters, vm_event_request_t *req)
+{
+int rc;
+struct vcpu *curr = current;
+struct domain *currd = curr-domain;
+
+if ( !(parameters  HVMPME_MODE_MASK) )
+return 0;
+
+rc = vm_event_claim_slot(currd, currd-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 1;
+default:
+return rc;
+};
+
+if ( (parameters  HVMPME_MODE_MASK) == HVMPME_mode_sync )
+{
+req-flags |= VM_EVENT_FLAG_VCPU_PAUSED;
+vm_event_vcpu_pause(curr);
+}
+
+hvm_event_fill_regs(req);
+vm_event_put_request(currd, currd-vm_event-monitor, req);
+
+return 1;
+}
+
+static void hvm_event_cr(uint32_t reason, unsigned long value,
+unsigned long old)
+{
+vm_event_request_t req = {
+.reason = reason,
+.vcpu_id = current-vcpu_id,
+.u.mov_to_cr.new_value = value,
+.u.mov_to_cr.old_value = old
+};
+uint64_t parameters = 0;
+
+switch(reason)
+{
+case VM_EVENT_REASON_MOV_TO_CR0:
+parameters = current-domain-arch.hvm_domain
+  .params[HVM_PARAM_MEMORY_EVENT_CR0];
+break;
+case VM_EVENT_REASON_MOV_TO_CR3:
+parameters = current-domain-arch.hvm_domain
+  .params

[Xen-devel] [PATCH V5 12/12] xen/vm_event: Add RESUME option to vm_event_op domctl

2015-02-13 Thread Tamas K Lengyel
Thus far mem_access and mem_sharing memops had been able to signal
to Xen to start pulling responses off the corresponding rings. In this patch
we retire these memops and add them to the option to the vm_event_op domctl.

The vm_event_op domctl suboptions are the same for each ring thus we
consolidate them into XEN_VM_EVENT_ENABLE/DISABLE/RESUME.

As part of this patch in libxc we also rename the mem_access_enable/disable
functions to monitor_enable/disable and move them into xc_monitor.c.

Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Wei Liu wei.l...@citrix.com
---
 tools/libxc/include/xenctrl.h   | 22 ++---
 tools/libxc/xc_mem_access.c | 25 
 tools/libxc/xc_mem_paging.c | 12 ++--
 tools/libxc/xc_memshr.c | 15 ++
 tools/libxc/xc_monitor.c| 22 +
 tools/libxc/xc_vm_event.c   |  6 +++---
 tools/tests/xen-access/xen-access.c | 10 +-
 xen/arch/x86/mm/mem_sharing.c   |  9 -
 xen/common/mem_access.c |  9 -
 xen/common/vm_event.c   | 39 +++--
 xen/include/public/domctl.h | 32 ++
 xen/include/public/memory.h | 16 +++
 12 files changed, 112 insertions(+), 105 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 3324132..3042e98 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2269,6 +2269,7 @@ int xc_tmem_restore_extra(xc_interface *xch, int dom, int 
fd);
  */
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id);
+int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id);
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id,
unsigned long gfn);
 int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long 
gfn);
@@ -2282,17 +2283,6 @@ int xc_mem_paging_load(xc_interface *xch, domid_t 
domain_id,
  */
 
 /*
- * Enables mem_access and returns the mapped ring page.
- * Will return NULL on error.
- * Caller has to unmap this page when done.
- */
-void *xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t 
*port);
-void *xc_mem_access_enable_introspection(xc_interface *xch, domid_t domain_id,
- uint32_t *port);
-int xc_mem_access_disable(xc_interface *xch, domid_t domain_id);
-int xc_mem_access_resume(xc_interface *xch, domid_t domain_id);
-
-/*
  * Set a range of memory to a specific access.
  * Allowed types are XENMEM_access_default, XENMEM_access_n, any combination of
  * XENMEM_access_ + (rwx), and XENMEM_access_rx2rw
@@ -2309,7 +2299,17 @@ int xc_get_mem_access(xc_interface *xch, domid_t 
domain_id,
 
 /***
  * Monitor control operations.
+ *
+ * Enables the VM event monitor ring and returns the mapped ring page.
+ * This ring is used to deliver mem_access events, as well a set of additional
+ * events that can be enabled with the xc_monitor_* functions.
+ *
+ * Will return NULL on error.
+ * Caller has to unmap this page when done.
  */
+void *xc_monitor_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
+int xc_monitor_disable(xc_interface *xch, domid_t domain_id);
+int xc_monitor_resume(xc_interface *xch, domid_t domain_id);
 int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t domain_id,
   unsigned int op, unsigned int sync,
   unsigned int onchangeonly);
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index 37e776c..7050692 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -24,31 +24,6 @@
 #include xc_private.h
 #include xen/memory.h
 
-void *xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t 
*port)
-{
-return xc_vm_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
-  port);
-}
-
-int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
-{
-return xc_vm_event_control(xch, domain_id,
-   XEN_VM_EVENT_MONITOR_DISABLE,
-   XEN_DOMCTL_VM_EVENT_OP_MONITOR,
-   NULL);
-}
-
-int xc_mem_access_resume(xc_interface *xch, domid_t domain_id)
-{
-xen_mem_access_op_t mao =
-{
-.op= XENMEM_access_op_resume,
-.domid = domain_id
-};
-
-return do_memory_op(xch, XENMEM_access_op, mao, sizeof(mao));
-}
-
 int xc_set_mem_access(xc_interface *xch,
   domid_t domain_id,
   xenmem_access_t access,
diff --git a/tools/libxc/xc_mem_paging.c b/tools/libxc/xc_mem_paging.c
index 083ab60..76e0c05 100644
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -48,7 +48,7 @@ int xc_mem_paging_enable(xc_interface *xch

  1   2   3   4   5   6   7   8   9   10   >