* [PATCH 0/7] vm-event: Implement ARM support for control-register writes
@ 2016-06-16 14:04 Corneliu ZUZU
2016-06-16 14:06 ` [PATCH 1/7] minor (formatting) fixes Corneliu ZUZU
` (6 more replies)
0 siblings, 7 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-16 14:04 UTC (permalink / raw)
To: xen-devel
Cc: Kevin Tian, Stefano Stabellini, Jan Beulich, Razvan Cojocaru,
George Dunlap, Andrew Cooper, Julien Grall, Paul Durrant,
Tamas K Lengyel, Jun Nakajima
Add ARM support for control-register write vm-events.
Patch-series summary:
1. [minor] small (formatting & other) fixes
2. [minor] fix an issue w/ VM_EVENT_FLAG_DENY
3+4. [major] introduce a new vm-event function (vm_event_vcpu_enter) that
gets executed just before a vCPU is (re)entered and move some
x86 code there
5. [minor] conceptual change of x86 monitor_write_data structure
6. [major] move hvm_event_cr->common vm_event_monitor_cr
7. [major] actual implementation, use HCR.TVM bit to monitor SCTLR, TTBR0,
TTBR1 and TTBCR writes
Corneliu ZUZU (7):
minor (formatting) fixes
vm-event: VM_EVENT_FLAG_DENY requires VM_EVENT_FLAG_VCPU_PAUSED
vm-event: introduce vm_event_vcpu_enter
vm-event/x86: use vm_event_vcpu_enter properly
x86: replace monitor_write_data.do_write with enum
vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr
vm-event/arm: implement support for control-register write vm-events
MAINTAINERS | 1 +
xen/arch/arm/Makefile | 1 +
xen/arch/arm/domain.c | 6 +-
xen/arch/arm/traps.c | 129 +++++++++++++++++++-
xen/arch/arm/vm_event.c | 112 ++++++++++++++++++
xen/arch/x86/hvm/emulate.c | 2 +-
xen/arch/x86/hvm/event.c | 32 +----
xen/arch/x86/hvm/hvm.c | 83 ++++---------
xen/arch/x86/hvm/vmx/vmx.c | 16 +--
xen/arch/x86/mm/p2m.c | 1 -
xen/arch/x86/monitor.c | 46 --------
xen/arch/x86/vm_event.c | 134 ++++++++++++++++-----
xen/common/monitor.c | 41 ++++++-
xen/common/vm_event.c | 30 ++++-
xen/include/asm-arm/domain.h | 30 +++++
xen/include/asm-arm/traps.h | 253 ++++++++++++++++++++++++++++++++++++++++
xen/include/asm-arm/vm_event.h | 32 +++--
xen/include/asm-x86/domain.h | 20 ++--
xen/include/asm-x86/hvm/event.h | 15 +--
xen/include/asm-x86/monitor.h | 5 -
xen/include/asm-x86/vm_event.h | 6 +-
xen/include/public/vm_event.h | 45 ++++---
xen/include/xen/monitor.h | 2 +
xen/include/xen/vm_event.h | 24 +++-
24 files changed, 828 insertions(+), 238 deletions(-)
create mode 100644 xen/arch/arm/vm_event.c
create mode 100644 xen/include/asm-arm/traps.h
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* [PATCH 1/7] minor (formatting) fixes
2016-06-16 14:04 [PATCH 0/7] vm-event: Implement ARM support for control-register writes Corneliu ZUZU
@ 2016-06-16 14:06 ` Corneliu ZUZU
2016-06-16 14:24 ` Jan Beulich
2016-06-16 16:02 ` Tamas K Lengyel
2016-06-16 14:07 ` [PATCH 2/7] vm-event: VM_EVENT_FLAG_DENY requires VM_EVENT_FLAG_VCPU_PAUSED Corneliu ZUZU
` (5 subsequent siblings)
6 siblings, 2 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-16 14:06 UTC (permalink / raw)
To: xen-devel
Cc: Stefano Stabellini, Razvan Cojocaru, Andrew Cooper, Julien Grall,
Tamas K Lengyel, Jan Beulich
Minor fixes:
- fix 80-columns formatting in some places
- remove some empty lines
- remove some unused includes
- add 2 comments
Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
---
xen/arch/arm/domain.c | 1 -
xen/arch/arm/traps.c | 1 -
xen/arch/x86/hvm/event.c | 1 +
xen/common/monitor.c | 1 -
xen/include/asm-arm/vm_event.h | 12 ++++++------
xen/include/asm-x86/hvm/event.h | 2 --
xen/include/asm-x86/monitor.h | 3 ---
xen/include/asm-x86/vm_event.h | 3 +++
xen/include/public/vm_event.h | 36 ++++++++++++++++++------------------
xen/include/xen/vm_event.h | 1 -
10 files changed, 28 insertions(+), 33 deletions(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1365b4a..d31f821 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -274,7 +274,6 @@ static void continue_new_vcpu(struct vcpu *prev)
else
/* check_wakeup_from_wait(); */
reset_stack_and_jump(return_to_new_vcpu64);
-
}
void context_switch(struct vcpu *prev, struct vcpu *next)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index aa3e3c2..7fa2ae5 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -439,7 +439,6 @@ static void inject_abt32_exception(struct cpu_user_regs *regs,
far |= addr << 32;
WRITE_SYSREG(far, FAR_EL1);
WRITE_SYSREG(fsr, IFSR32_EL2);
-
#endif
}
else
diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
index 56c5514..9c51890 100644
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/event.c
@@ -23,6 +23,7 @@
#include <xen/vm_event.h>
#include <asm/hvm/event.h>
+#include <asm/paging.h>
#include <asm/monitor.h>
#include <asm/vm_event.h>
#include <public/vm_event.h>
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index d950a7c..b30857a 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -22,7 +22,6 @@
#include <xen/monitor.h>
#include <xen/sched.h>
#include <xsm/xsm.h>
-#include <public/domctl.h>
#include <asm/monitor.h>
#include <asm/vm_event.h>
diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index 014d9ba..05c3027 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -23,21 +23,18 @@
#include <xen/vm_event.h>
#include <public/domctl.h>
-static inline
-int vm_event_init_domain(struct domain *d)
+static inline int vm_event_init_domain(struct domain *d)
{
/* Nothing to do. */
return 0;
}
-static inline
-void vm_event_cleanup_domain(struct domain *d)
+static inline void vm_event_cleanup_domain(struct domain *d)
{
memset(&d->monitor, 0, sizeof(d->monitor));
}
-static inline
-void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
+static inline void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
{
/* Not supported on ARM. */
}
@@ -59,6 +56,9 @@ static inline void vm_event_fill_regs(vm_event_request_t *req)
/* Not supported on ARM. */
}
+/*
+ * Monitor vm-events.
+ */
static inline uint32_t vm_event_monitor_get_capabilities(struct domain *d)
{
uint32_t capabilities = 0;
diff --git a/xen/include/asm-x86/hvm/event.h b/xen/include/asm-x86/hvm/event.h
index 03f7fee..504bd66 100644
--- a/xen/include/asm-x86/hvm/event.h
+++ b/xen/include/asm-x86/hvm/event.h
@@ -19,8 +19,6 @@
#ifndef __ASM_X86_HVM_EVENT_H__
#define __ASM_X86_HVM_EVENT_H__
-#include <xen/sched.h>
-#include <xen/paging.h>
#include <public/vm_event.h>
enum hvm_event_breakpoint_type
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index d367099..7a662f9 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -23,9 +23,6 @@
#define __ASM_X86_MONITOR_H__
#include <xen/sched.h>
-#include <public/domctl.h>
-#include <asm/cpufeature.h>
-#include <asm/hvm/hvm.h>
#define monitor_ctrlreg_bitmask(ctrlreg_index) (1U << (ctrlreg_index))
diff --git a/xen/include/asm-x86/vm_event.h b/xen/include/asm-x86/vm_event.h
index 0470240..df8e98d 100644
--- a/xen/include/asm-x86/vm_event.h
+++ b/xen/include/asm-x86/vm_event.h
@@ -44,6 +44,9 @@ void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp);
void vm_event_fill_regs(vm_event_request_t *req);
+/*
+ * Monitor vm-events.
+ */
static inline uint32_t vm_event_monitor_get_capabilities(struct domain *d)
{
uint32_t capabilities = 0;
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index 9270d52..586f43b 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -74,19 +74,19 @@
* VM_EVENT_FLAG_SET_EMUL_READ_DATA are set, only the latter will be honored).
*/
#define VM_EVENT_FLAG_SET_EMUL_READ_DATA (1 << 5)
- /*
- * Deny completion of the operation that triggered the event.
- * Currently only useful for MSR, CR0, CR3 and CR4 write events.
- */
+/*
+ * Deny completion of the operation that triggered the event.
+ * Currently only useful for MSR and control-register write events.
+ */
#define VM_EVENT_FLAG_DENY (1 << 6)
/*
* This flag can be set in a request or a response
*
- * On a request, indicates that the event occurred in the alternate p2m specified by
- * the altp2m_idx request field.
+ * On a request, indicates that the event occurred in the alternate p2m
+ * specified by the altp2m_idx request field.
*
- * On a response, indicates that the VCPU should resume in the alternate p2m specified
- * by the altp2m_idx response field if possible.
+ * On a response, indicates that the VCPU should resume in the alternate p2m
+ * specified by the altp2m_idx response field if possible.
*/
#define VM_EVENT_FLAG_ALTERNATE_P2M (1 << 7)
/*
@@ -177,16 +177,16 @@ struct vm_event_regs_x86 {
* FAULT_WITH_GLA: If the violation was triggered by accessing gla
* FAULT_IN_GPT: If the violation was triggered during translating gla
*/
-#define MEM_ACCESS_R (1 << 0)
-#define MEM_ACCESS_W (1 << 1)
-#define MEM_ACCESS_X (1 << 2)
-#define MEM_ACCESS_RWX (MEM_ACCESS_R | MEM_ACCESS_W | MEM_ACCESS_X)
-#define MEM_ACCESS_RW (MEM_ACCESS_R | MEM_ACCESS_W)
-#define MEM_ACCESS_RX (MEM_ACCESS_R | MEM_ACCESS_X)
-#define MEM_ACCESS_WX (MEM_ACCESS_W | MEM_ACCESS_X)
-#define MEM_ACCESS_GLA_VALID (1 << 3)
-#define MEM_ACCESS_FAULT_WITH_GLA (1 << 4)
-#define MEM_ACCESS_FAULT_IN_GPT (1 << 5)
+#define MEM_ACCESS_R (1 << 0)
+#define MEM_ACCESS_W (1 << 1)
+#define MEM_ACCESS_X (1 << 2)
+#define MEM_ACCESS_RWX (MEM_ACCESS_R | MEM_ACCESS_W | MEM_ACCESS_X)
+#define MEM_ACCESS_RW (MEM_ACCESS_R | MEM_ACCESS_W)
+#define MEM_ACCESS_RX (MEM_ACCESS_R | MEM_ACCESS_X)
+#define MEM_ACCESS_WX (MEM_ACCESS_W | MEM_ACCESS_X)
+#define MEM_ACCESS_GLA_VALID (1 << 3)
+#define MEM_ACCESS_FAULT_WITH_GLA (1 << 4)
+#define MEM_ACCESS_FAULT_IN_GPT (1 << 5)
struct vm_event_mem_access {
uint64_t gfn;
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index beda9fe..a10ee40 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -85,7 +85,6 @@ void vm_event_monitor_guest_request(void);
#endif /* __VM_EVENT_H__ */
-
/*
* Local variables:
* mode: C
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 73+ messages in thread
* [PATCH 2/7] vm-event: VM_EVENT_FLAG_DENY requires VM_EVENT_FLAG_VCPU_PAUSED
2016-06-16 14:04 [PATCH 0/7] vm-event: Implement ARM support for control-register writes Corneliu ZUZU
2016-06-16 14:06 ` [PATCH 1/7] minor (formatting) fixes Corneliu ZUZU
@ 2016-06-16 14:07 ` Corneliu ZUZU
2016-06-16 16:11 ` Tamas K Lengyel
2016-06-16 14:08 ` [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter Corneliu ZUZU
` (4 subsequent siblings)
6 siblings, 1 reply; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-16 14:07 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Tamas K Lengyel, Jan Beulich, Razvan Cojocaru
For VM_EVENT_FLAG_DENY to work, the vcpu must be paused (sync = 1) until the
vm-event is handled. A vm-event response having VM_EVENT_FLAG_DENY flag set
should also set the VM_EVENT_FLAG_VCPU_PAUSED flag. Enforce that in
vm_event_register_write_resume().
Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
---
xen/arch/x86/vm_event.c | 3 ++-
xen/include/public/vm_event.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 5635603..75647c4 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -70,7 +70,8 @@ void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t *rsp)
{
- if ( rsp->flags & VM_EVENT_FLAG_DENY )
+ if ( (rsp->flags & VM_EVENT_FLAG_DENY) &&
+ (rsp->flags & VM_EVENT_FLAG_VCPU_PAUSED) )
{
struct monitor_write_data *w = &v->arch.vm_event->write_data;
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index 586f43b..8f94e20 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -77,6 +77,7 @@
/*
* Deny completion of the operation that triggered the event.
* Currently only useful for MSR and control-register write events.
+ * Requires the vCPU to be paused already (synchronous events only).
*/
#define VM_EVENT_FLAG_DENY (1 << 6)
/*
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 73+ messages in thread
* [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter
2016-06-16 14:04 [PATCH 0/7] vm-event: Implement ARM support for control-register writes Corneliu ZUZU
2016-06-16 14:06 ` [PATCH 1/7] minor (formatting) fixes Corneliu ZUZU
2016-06-16 14:07 ` [PATCH 2/7] vm-event: VM_EVENT_FLAG_DENY requires VM_EVENT_FLAG_VCPU_PAUSED Corneliu ZUZU
@ 2016-06-16 14:08 ` Corneliu ZUZU
2016-06-16 14:51 ` Jan Beulich
` (2 more replies)
2016-06-16 14:09 ` [PATCH 4/7] vm-event/x86: use vm_event_vcpu_enter properly Corneliu ZUZU
` (3 subsequent siblings)
6 siblings, 3 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-16 14:08 UTC (permalink / raw)
To: xen-devel
Cc: Kevin Tian, Stefano Stabellini, Jan Beulich, Razvan Cojocaru,
George Dunlap, Andrew Cooper, Julien Grall, Paul Durrant,
Tamas K Lengyel, Jun Nakajima
In an effort to improve on the vm-event interface, we introduce a new function
called vm_event_vcpu_enter. Its significance is that of a "final touch" vCPU
function - i.e. it should be called by implementing architectures just before
re-entering vCPUs.
On X86 for example, it is called on the scheduling tail (hvm_do_resume) and just
before reentering the guest world after a hypervisor trap (vmx_vmenter_helper).
Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
---
xen/arch/arm/domain.c | 5 ++++-
xen/arch/arm/traps.c | 2 ++
xen/arch/x86/hvm/emulate.c | 2 +-
xen/arch/x86/hvm/event.c | 1 -
xen/arch/x86/hvm/hvm.c | 3 ++-
xen/arch/x86/hvm/vmx/vmx.c | 4 ++++
xen/arch/x86/mm/p2m.c | 1 -
xen/arch/x86/vm_event.c | 4 +---
xen/common/monitor.c | 2 +-
xen/common/vm_event.c | 1 -
xen/include/asm-arm/vm_event.h | 6 +++++-
xen/include/asm-x86/vm_event.h | 6 +++++-
xen/include/xen/vm_event.h | 15 +++++++++++++++
13 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d31f821..ba248c8 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -19,6 +19,7 @@
#include <xen/errno.h>
#include <xen/bitops.h>
#include <xen/grant_table.h>
+#include <xen/vm_event.h>
#include <asm/current.h>
#include <asm/event.h>
@@ -251,6 +252,8 @@ static void schedule_tail(struct vcpu *prev)
ctxt_switch_to(current);
+ vm_event_vcpu_enter(current);
+
local_irq_enable();
context_saved(prev);
@@ -296,7 +299,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
void continue_running(struct vcpu *same)
{
- /* Nothing to do */
+ vm_event_vcpu_enter(same);
}
void sync_local_execstate(void)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 7fa2ae5..8c50685 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -32,6 +32,7 @@
#include <xen/domain_page.h>
#include <xen/perfc.h>
#include <xen/virtual_region.h>
+#include <xen/vm_event.h>
#include <public/sched.h>
#include <public/xen.h>
#include <asm/debugger.h>
@@ -2662,6 +2663,7 @@ asmlinkage void leave_hypervisor_tail(void)
{
local_irq_disable();
if (!softirq_pending(smp_processor_id())) {
+ vm_event_vcpu_enter(current);
gic_inject();
return;
}
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 266ed89..9b2872a 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -15,6 +15,7 @@
#include <xen/sched.h>
#include <xen/paging.h>
#include <xen/trace.h>
+#include <xen/vm_event.h>
#include <asm/event.h>
#include <asm/xstate.h>
#include <asm/hvm/emulate.h>
@@ -23,7 +24,6 @@
#include <asm/hvm/trace.h>
#include <asm/hvm/support.h>
#include <asm/hvm/svm/svm.h>
-#include <asm/vm_event.h>
static void hvmtrace_io_assist(const ioreq_t *p)
{
diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
index 9c51890..26165b4 100644
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/event.c
@@ -25,7 +25,6 @@
#include <asm/hvm/event.h>
#include <asm/paging.h>
#include <asm/monitor.h>
-#include <asm/vm_event.h>
#include <public/vm_event.h>
bool_t hvm_event_cr(unsigned int index, unsigned long value, unsigned long old)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 78db903..770bb50 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -65,7 +65,6 @@
#include <asm/altp2m.h>
#include <asm/mtrr.h>
#include <asm/apic.h>
-#include <asm/vm_event.h>
#include <public/sched.h>
#include <public/hvm/ioreq.h>
#include <public/version.h>
@@ -509,6 +508,8 @@ void hvm_do_resume(struct vcpu *v)
}
}
+ vm_event_vcpu_enter(v);
+
/* Inject pending hw/sw trap */
if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
{
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 670d7dc..b43b94a 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -25,6 +25,7 @@
#include <xen/domain_page.h>
#include <xen/hypercall.h>
#include <xen/perfc.h>
+#include <xen/vm_event.h>
#include <asm/current.h>
#include <asm/io.h>
#include <asm/iocap.h>
@@ -3874,6 +3875,9 @@ void vmx_vmenter_helper(const struct cpu_user_regs *regs)
}
out:
+ if ( guest_mode(regs) )
+ vm_event_vcpu_enter(curr);
+
HVMTRACE_ND(VMENTRY, 0, 1/*cycles*/, 0, 0, 0, 0, 0, 0, 0);
__vmwrite(GUEST_RIP, regs->rip);
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 89462b2..9d37b12 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -36,7 +36,6 @@
#include <asm/hvm/nestedhvm.h>
#include <asm/altp2m.h>
#include <asm/hvm/svm/amd-iommu-proto.h>
-#include <asm/vm_event.h>
#include <xsm/xsm.h>
#include "mm-locks.h"
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 75647c4..f7eb24a 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -18,9 +18,7 @@
* License along with this program; If not, see <http://www.gnu.org/licenses/>.
*/
-#include <xen/sched.h>
-#include <asm/hvm/hvm.h>
-#include <asm/vm_event.h>
+#include <xen/vm_event.h>
/* Implicitly serialized by the domctl lock. */
int vm_event_init_domain(struct domain *d)
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index b30857a..c46df5a 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -22,8 +22,8 @@
#include <xen/monitor.h>
#include <xen/sched.h>
#include <xsm/xsm.h>
+#include <xen/vm_event.h>
#include <asm/monitor.h>
-#include <asm/vm_event.h>
int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
{
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 2906407..15152ba 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -27,7 +27,6 @@
#include <xen/mem_access.h>
#include <asm/p2m.h>
#include <asm/altp2m.h>
-#include <asm/vm_event.h>
#include <xsm/xsm.h>
/* for public/io/ring.h macros */
diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index 05c3027..4e5a272 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -20,7 +20,6 @@
#define __ASM_ARM_VM_EVENT_H__
#include <xen/sched.h>
-#include <xen/vm_event.h>
#include <public/domctl.h>
static inline int vm_event_init_domain(struct domain *d)
@@ -56,6 +55,11 @@ static inline void vm_event_fill_regs(vm_event_request_t *req)
/* Not supported on ARM. */
}
+static inline void arch_vm_event_vcpu_enter(struct vcpu *v)
+{
+ /* Nothing to do. */
+}
+
/*
* Monitor vm-events.
*/
diff --git a/xen/include/asm-x86/vm_event.h b/xen/include/asm-x86/vm_event.h
index df8e98d..6fb3b58 100644
--- a/xen/include/asm-x86/vm_event.h
+++ b/xen/include/asm-x86/vm_event.h
@@ -20,7 +20,6 @@
#define __ASM_X86_VM_EVENT_H__
#include <xen/sched.h>
-#include <xen/vm_event.h>
/*
* Should we emulate the next matching instruction on VCPU resume
@@ -44,6 +43,11 @@ void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp);
void vm_event_fill_regs(vm_event_request_t *req);
+static inline void arch_vm_event_vcpu_enter(struct vcpu *v)
+{
+ /* Nothing to do. */
+}
+
/*
* Monitor vm-events.
*/
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index a10ee40..f124143 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -24,6 +24,7 @@
#define __VM_EVENT_H__
#include <xen/sched.h>
+#include <asm/vm_event.h>
#include <public/vm_event.h>
/* Clean up on domain destruction */
@@ -72,6 +73,20 @@ void vm_event_resume(struct domain *d, struct vm_event_domain *ved);
int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *vec,
XEN_GUEST_HANDLE_PARAM(void) u_domctl);
+/*
+ * "Final touch" vCPU function, should be called just before re-entering vCPUs,
+ * e.g. on x86 it is called by hvm_do_resume (scheduling tail) and
+ * vmx_vmenter_helper (before VMRESUME or VMLAUNCH).
+ */
+static inline void vm_event_vcpu_enter(struct vcpu *v)
+{
+ /* don't track idle vcpus, they're not subject to the vm-event subsystem */
+ if ( is_idle_vcpu(v) )
+ return;
+
+ arch_vm_event_vcpu_enter(v);
+}
+
void vm_event_vcpu_pause(struct vcpu *v);
void vm_event_vcpu_unpause(struct vcpu *v);
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 73+ messages in thread
* [PATCH 4/7] vm-event/x86: use vm_event_vcpu_enter properly
2016-06-16 14:04 [PATCH 0/7] vm-event: Implement ARM support for control-register writes Corneliu ZUZU
` (2 preceding siblings ...)
2016-06-16 14:08 ` [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter Corneliu ZUZU
@ 2016-06-16 14:09 ` Corneliu ZUZU
2016-06-16 15:00 ` Jan Beulich
2016-06-16 16:27 ` Tamas K Lengyel
2016-06-16 14:10 ` [PATCH 5/7] x86: replace monitor_write_data.do_write with enum Corneliu ZUZU
` (2 subsequent siblings)
6 siblings, 2 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-16 14:09 UTC (permalink / raw)
To: xen-devel
Cc: Kevin Tian, Tamas K Lengyel, Jan Beulich, Razvan Cojocaru,
Andrew Cooper, Jun Nakajima
After introducing vm_event_vcpu_enter, it makes sense to move the following
code there:
- handling of monitor_write_data from hvm_do_resume
- enabling/disabling CPU_BASED_CR3_LOAD_EXITING from vmx_update_guest_cr(v, 0)
Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
---
xen/arch/x86/hvm/hvm.c | 62 +++++--------------------
xen/arch/x86/hvm/vmx/vmx.c | 12 ++---
xen/arch/x86/monitor.c | 9 ----
xen/arch/x86/vm_event.c | 102 +++++++++++++++++++++++++++++++++++++++++
xen/include/asm-x86/vm_event.h | 5 +-
5 files changed, 119 insertions(+), 71 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 770bb50..2f48846 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -462,52 +462,6 @@ void hvm_do_resume(struct vcpu *v)
if ( !handle_hvm_io_completion(v) )
return;
- if ( unlikely(v->arch.vm_event) )
- {
- struct monitor_write_data *w = &v->arch.vm_event->write_data;
-
- if ( v->arch.vm_event->emulate_flags )
- {
- enum emul_kind kind = EMUL_KIND_NORMAL;
-
- if ( v->arch.vm_event->emulate_flags &
- VM_EVENT_FLAG_SET_EMUL_READ_DATA )
- kind = EMUL_KIND_SET_CONTEXT;
- else if ( v->arch.vm_event->emulate_flags &
- VM_EVENT_FLAG_EMULATE_NOWRITE )
- kind = EMUL_KIND_NOWRITE;
-
- hvm_mem_access_emulate_one(kind, TRAP_invalid_op,
- HVM_DELIVER_NO_ERROR_CODE);
-
- v->arch.vm_event->emulate_flags = 0;
- }
-
- if ( w->do_write.msr )
- {
- hvm_msr_write_intercept(w->msr, w->value, 0);
- w->do_write.msr = 0;
- }
-
- if ( w->do_write.cr0 )
- {
- hvm_set_cr0(w->cr0, 0);
- w->do_write.cr0 = 0;
- }
-
- if ( w->do_write.cr4 )
- {
- hvm_set_cr4(w->cr4, 0);
- w->do_write.cr4 = 0;
- }
-
- if ( w->do_write.cr3 )
- {
- hvm_set_cr3(w->cr3, 0);
- w->do_write.cr3 = 0;
- }
- }
-
vm_event_vcpu_enter(v);
/* Inject pending hw/sw trap */
@@ -2199,7 +2153,9 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
if ( hvm_event_crX(CR0, value, old_value) )
{
- /* The actual write will occur in hvm_do_resume(), if permitted. */
+ /* The actual write will occur in vcpu_enter_write_data(), if
+ * permitted.
+ */
v->arch.vm_event->write_data.do_write.cr0 = 1;
v->arch.vm_event->write_data.cr0 = value;
@@ -2301,7 +2257,9 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
if ( hvm_event_crX(CR3, value, old) )
{
- /* The actual write will occur in hvm_do_resume(), if permitted. */
+ /* The actual write will occur in vcpu_enter_write_data(), if
+ * permitted.
+ */
v->arch.vm_event->write_data.do_write.cr3 = 1;
v->arch.vm_event->write_data.cr3 = value;
@@ -2381,7 +2339,9 @@ int hvm_set_cr4(unsigned long value, bool_t may_defer)
if ( hvm_event_crX(CR4, value, old_cr) )
{
- /* The actual write will occur in hvm_do_resume(), if permitted. */
+ /* The actual write will occur in vcpu_enter_write_data(), if
+ * permitted.
+ */
v->arch.vm_event->write_data.do_write.cr4 = 1;
v->arch.vm_event->write_data.cr4 = value;
@@ -3761,7 +3721,9 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t msr_content,
{
ASSERT(v->arch.vm_event);
- /* The actual write will occur in hvm_do_resume() (if permitted). */
+ /* The actual write will occur in vcpu_enter_write_data(), if
+ * permitted.
+ */
v->arch.vm_event->write_data.do_write.msr = 1;
v->arch.vm_event->write_data.msr = msr;
v->arch.vm_event->write_data.value = msr_content;
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b43b94a..8b76ef9 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -35,7 +35,6 @@
#include <asm/guest_access.h>
#include <asm/debugreg.h>
#include <asm/msr.h>
-#include <asm/paging.h>
#include <asm/p2m.h>
#include <asm/mem_sharing.h>
#include <asm/hvm/emulate.h>
@@ -58,7 +57,6 @@
#include <asm/hvm/nestedhvm.h>
#include <asm/altp2m.h>
#include <asm/event.h>
-#include <asm/monitor.h>
#include <public/arch-x86/cpuid.h>
static bool_t __initdata opt_force_ept;
@@ -1432,18 +1430,16 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned int cr)
if ( paging_mode_hap(v->domain) )
{
/* Manage GUEST_CR3 when CR0.PE=0. */
+ uint32_t old_ctls = v->arch.hvm_vmx.exec_control;
uint32_t cr3_ctls = (CPU_BASED_CR3_LOAD_EXITING |
CPU_BASED_CR3_STORE_EXITING);
+
v->arch.hvm_vmx.exec_control &= ~cr3_ctls;
if ( !hvm_paging_enabled(v) && !vmx_unrestricted_guest(v) )
v->arch.hvm_vmx.exec_control |= cr3_ctls;
- /* Trap CR3 updates if CR3 memory events are enabled. */
- if ( v->domain->arch.monitor.write_ctrlreg_enabled &
- monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
- v->arch.hvm_vmx.exec_control |= CPU_BASED_CR3_LOAD_EXITING;
-
- vmx_update_cpu_exec_control(v);
+ if ( old_ctls != v->arch.hvm_vmx.exec_control )
+ vmx_update_cpu_exec_control(v);
}
if ( !nestedhvm_vcpu_in_guestmode(v) )
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 1fec412..1e5445f 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -20,7 +20,6 @@
*/
#include <asm/monitor.h>
-#include <public/vm_event.h>
int arch_monitor_domctl_event(struct domain *d,
struct xen_domctl_monitor_op *mop)
@@ -62,14 +61,6 @@ int arch_monitor_domctl_event(struct domain *d,
else
ad->monitor.write_ctrlreg_enabled &= ~ctrlreg_bitmask;
- if ( VM_EVENT_X86_CR3 == mop->u.mov_to_cr.index )
- {
- struct vcpu *v;
- /* Latches new CR3 mask through CR0 code. */
- for_each_vcpu ( d, v )
- hvm_update_guest_cr(v, 0);
- }
-
domain_unpause(d);
break;
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index f7eb24a..94b50fc 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -19,6 +19,9 @@
*/
#include <xen/vm_event.h>
+#include <asm/monitor.h>
+#include <asm/paging.h>
+#include <asm/hvm/vmx/vmx.h>
/* Implicitly serialized by the domctl lock. */
int vm_event_init_domain(struct domain *d)
@@ -179,6 +182,105 @@ void vm_event_fill_regs(vm_event_request_t *req)
req->data.regs.x86.cs_arbytes = seg.attr.bytes;
}
+static inline void vcpu_enter_write_data(struct vcpu *v)
+{
+ struct monitor_write_data *w;
+
+ if ( likely(!v->arch.vm_event) )
+ return;
+
+ w = &v->arch.vm_event->write_data;
+
+ if ( unlikely(v->arch.vm_event->emulate_flags) )
+ {
+ enum emul_kind kind = EMUL_KIND_NORMAL;
+
+ if ( v->arch.vm_event->emulate_flags &
+ VM_EVENT_FLAG_SET_EMUL_READ_DATA )
+ kind = EMUL_KIND_SET_CONTEXT;
+ else if ( v->arch.vm_event->emulate_flags &
+ VM_EVENT_FLAG_EMULATE_NOWRITE )
+ kind = EMUL_KIND_NOWRITE;
+
+ hvm_mem_access_emulate_one(kind, TRAP_invalid_op,
+ HVM_DELIVER_NO_ERROR_CODE);
+
+ v->arch.vm_event->emulate_flags = 0;
+ }
+
+ if ( w->do_write.msr )
+ {
+ hvm_msr_write_intercept(w->msr, w->value, 0);
+ w->do_write.msr = 0;
+ }
+
+ if ( w->do_write.cr0 )
+ {
+ hvm_set_cr0(w->cr0, 0);
+ w->do_write.cr0 = 0;
+ }
+
+ if ( w->do_write.cr4 )
+ {
+ hvm_set_cr4(w->cr4, 0);
+ w->do_write.cr4 = 0;
+ }
+
+ if ( w->do_write.cr3 )
+ {
+ hvm_set_cr3(w->cr3, 0);
+ w->do_write.cr3 = 0;
+ }
+}
+
+static inline void vcpu_enter_adjust_traps(struct vcpu *v)
+{
+ struct domain *d = v->domain;
+ struct arch_vmx_struct *avmx = &v->arch.hvm_vmx;
+ bool_t cr3_ldexit, cr3_vmevent;
+ unsigned int cr3_bitmask;
+
+ /* Adjust CR3 load-exiting (for monitor vm-events). */
+
+ cr3_bitmask = monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3);
+ cr3_vmevent = !!(d->arch.monitor.write_ctrlreg_enabled & cr3_bitmask);
+ cr3_ldexit = !!(avmx->exec_control & CPU_BASED_CR3_LOAD_EXITING);
+
+ if ( likely(cr3_vmevent == cr3_ldexit) )
+ return;
+
+ if ( !paging_mode_hap(d) )
+ {
+ /* non-hap domains trap CR3 writes unconditionally */
+ ASSERT(cr3_ldexit);
+ return;
+ }
+
+ /*
+ * If CR0.PE=0, CR3 load exiting must remain enabled.
+ * See vmx_update_guest_cr code motion for cr = 0.
+ */
+ if ( cr3_ldexit && !hvm_paging_enabled(v) && !vmx_unrestricted_guest(v) )
+ return;
+
+ if ( cr3_vmevent )
+ avmx->exec_control |= CPU_BASED_CR3_LOAD_EXITING;
+ else
+ avmx->exec_control &= ~CPU_BASED_CR3_LOAD_EXITING;
+
+ vmx_vmcs_enter(v);
+ vmx_update_cpu_exec_control(v);
+ vmx_vmcs_exit(v);
+}
+
+void arch_vm_event_vcpu_enter(struct vcpu *v)
+{
+ /* vmx only */
+ ASSERT( cpu_has_vmx );
+ vcpu_enter_write_data(v);
+ vcpu_enter_adjust_traps(v);
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/include/asm-x86/vm_event.h b/xen/include/asm-x86/vm_event.h
index 6fb3b58..c4b5def 100644
--- a/xen/include/asm-x86/vm_event.h
+++ b/xen/include/asm-x86/vm_event.h
@@ -43,10 +43,7 @@ void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp);
void vm_event_fill_regs(vm_event_request_t *req);
-static inline void arch_vm_event_vcpu_enter(struct vcpu *v)
-{
- /* Nothing to do. */
-}
+void arch_vm_event_vcpu_enter(struct vcpu *v);
/*
* Monitor vm-events.
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 73+ messages in thread
* [PATCH 5/7] x86: replace monitor_write_data.do_write with enum
2016-06-16 14:04 [PATCH 0/7] vm-event: Implement ARM support for control-register writes Corneliu ZUZU
` (3 preceding siblings ...)
2016-06-16 14:09 ` [PATCH 4/7] vm-event/x86: use vm_event_vcpu_enter properly Corneliu ZUZU
@ 2016-06-16 14:10 ` Corneliu ZUZU
2016-06-16 14:12 ` [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr Corneliu ZUZU
2016-06-16 14:13 ` [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events Corneliu ZUZU
6 siblings, 0 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-16 14:10 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Tamas K Lengyel, Razvan Cojocaru, Jan Beulich
After trapping a control-register write vm-event and -until- deciding if that
write is to be permitted or not (VM_EVENT_FLAG_DENY) and doing the actual write,
there cannot and should not be another trapped control-register write event.
That is: currently -only one- of the fields of monitor_write_data.do_write can
be true at any given moment and therefore it would be more appropriate to
replace those fields with an enum value.
Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
---
xen/arch/x86/hvm/hvm.c | 18 ++++++++-----
xen/arch/x86/vm_event.c | 63 ++++++++++++++------------------------------
xen/include/asm-x86/domain.h | 20 +++++++-------
3 files changed, 41 insertions(+), 60 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 2f48846..4596662 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2156,8 +2156,9 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
/* The actual write will occur in vcpu_enter_write_data(), if
* permitted.
*/
- v->arch.vm_event->write_data.do_write.cr0 = 1;
- v->arch.vm_event->write_data.cr0 = value;
+ ASSERT(MWS_NOWRITE == v->arch.vm_event->write_data.status);
+ v->arch.vm_event->write_data.status = MWS_CR0;
+ v->arch.vm_event->write_data.value = value;
return X86EMUL_OKAY;
}
@@ -2260,8 +2261,9 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
/* The actual write will occur in vcpu_enter_write_data(), if
* permitted.
*/
- v->arch.vm_event->write_data.do_write.cr3 = 1;
- v->arch.vm_event->write_data.cr3 = value;
+ ASSERT(MWS_NOWRITE == v->arch.vm_event->write_data.status);
+ v->arch.vm_event->write_data.status = MWS_CR3;
+ v->arch.vm_event->write_data.value = value;
return X86EMUL_OKAY;
}
@@ -2342,8 +2344,9 @@ int hvm_set_cr4(unsigned long value, bool_t may_defer)
/* The actual write will occur in vcpu_enter_write_data(), if
* permitted.
*/
- v->arch.vm_event->write_data.do_write.cr4 = 1;
- v->arch.vm_event->write_data.cr4 = value;
+ ASSERT(MWS_NOWRITE == v->arch.vm_event->write_data.status);
+ v->arch.vm_event->write_data.status = MWS_CR4;
+ v->arch.vm_event->write_data.value = value;
return X86EMUL_OKAY;
}
@@ -3724,7 +3727,8 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t msr_content,
/* The actual write will occur in vcpu_enter_write_data(), if
* permitted.
*/
- v->arch.vm_event->write_data.do_write.msr = 1;
+ ASSERT(MWS_NOWRITE == v->arch.vm_event->write_data.status);
+ v->arch.vm_event->write_data.status = MWS_MSR;
v->arch.vm_event->write_data.msr = msr;
v->arch.vm_event->write_data.value = msr_content;
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 94b50fc..94342d5 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -74,30 +74,8 @@ void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t *rsp)
if ( (rsp->flags & VM_EVENT_FLAG_DENY) &&
(rsp->flags & VM_EVENT_FLAG_VCPU_PAUSED) )
{
- struct monitor_write_data *w = &v->arch.vm_event->write_data;
-
- ASSERT(w);
-
- switch ( rsp->reason )
- {
- case VM_EVENT_REASON_MOV_TO_MSR:
- w->do_write.msr = 0;
- break;
- case VM_EVENT_REASON_WRITE_CTRLREG:
- switch ( rsp->u.write_ctrlreg.index )
- {
- case VM_EVENT_X86_CR0:
- w->do_write.cr0 = 0;
- break;
- case VM_EVENT_X86_CR3:
- w->do_write.cr3 = 0;
- break;
- case VM_EVENT_X86_CR4:
- w->do_write.cr4 = 0;
- break;
- }
- break;
- }
+ ASSERT(v->arch.vm_event);
+ v->arch.vm_event->write_data.status = MWS_NOWRITE;
}
}
@@ -208,29 +186,28 @@ static inline void vcpu_enter_write_data(struct vcpu *v)
v->arch.vm_event->emulate_flags = 0;
}
- if ( w->do_write.msr )
- {
- hvm_msr_write_intercept(w->msr, w->value, 0);
- w->do_write.msr = 0;
- }
-
- if ( w->do_write.cr0 )
- {
- hvm_set_cr0(w->cr0, 0);
- w->do_write.cr0 = 0;
- }
+ if ( likely(MWS_NOWRITE == w->status) )
+ return;
- if ( w->do_write.cr4 )
+ switch ( w->status )
{
- hvm_set_cr4(w->cr4, 0);
- w->do_write.cr4 = 0;
+ case MWS_MSR:
+ hvm_msr_write_intercept(w->msr, w->value, 0);
+ break;
+ case MWS_CR0:
+ hvm_set_cr0(w->value, 0);
+ break;
+ case MWS_CR3:
+ hvm_set_cr3(w->value, 0);
+ break;
+ case MWS_CR4:
+ hvm_set_cr4(w->value, 0);
+ break;
+ default:
+ break;
}
- if ( w->do_write.cr3 )
- {
- hvm_set_cr3(w->cr3, 0);
- w->do_write.cr3 = 0;
- }
+ w->status = MWS_NOWRITE;
}
static inline void vcpu_enter_adjust_traps(struct vcpu *v)
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 783fa4f..0ed2761 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -259,19 +259,19 @@ struct pv_domain
struct cpuidmasks *cpuidmasks;
};
-struct monitor_write_data {
- struct {
- unsigned int msr : 1;
- unsigned int cr0 : 1;
- unsigned int cr3 : 1;
- unsigned int cr4 : 1;
- } do_write;
+enum monitor_write_status
+{
+ MWS_NOWRITE = 0,
+ MWS_MSR,
+ MWS_CR0,
+ MWS_CR3,
+ MWS_CR4,
+};
+struct monitor_write_data {
+ enum monitor_write_status status;
uint32_t msr;
uint64_t value;
- uint64_t cr0;
- uint64_t cr3;
- uint64_t cr4;
};
struct arch_domain
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 73+ messages in thread
* [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr
2016-06-16 14:04 [PATCH 0/7] vm-event: Implement ARM support for control-register writes Corneliu ZUZU
` (4 preceding siblings ...)
2016-06-16 14:10 ` [PATCH 5/7] x86: replace monitor_write_data.do_write with enum Corneliu ZUZU
@ 2016-06-16 14:12 ` Corneliu ZUZU
2016-06-16 15:16 ` Jan Beulich
2016-06-16 16:55 ` Tamas K Lengyel
2016-06-16 14:13 ` [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events Corneliu ZUZU
6 siblings, 2 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-16 14:12 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Tamas K Lengyel, Razvan Cojocaru, Jan Beulich
Prepare for ARM implementation of control-register write vm-events by moving
X86-specific hvm_event_cr to the common-side.
Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
---
xen/arch/x86/hvm/event.c | 30 ------------------------------
xen/arch/x86/hvm/hvm.c | 2 +-
xen/arch/x86/monitor.c | 37 -------------------------------------
xen/arch/x86/vm_event.c | 2 +-
xen/common/monitor.c | 40 ++++++++++++++++++++++++++++++++++++++++
xen/common/vm_event.c | 31 +++++++++++++++++++++++++++++++
xen/include/asm-x86/hvm/event.h | 13 ++++---------
xen/include/asm-x86/monitor.h | 2 --
xen/include/xen/monitor.h | 4 ++++
xen/include/xen/vm_event.h | 10 ++++++++++
10 files changed, 91 insertions(+), 80 deletions(-)
diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
index 26165b4..e8175e4 100644
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/event.c
@@ -21,38 +21,8 @@
* this program; If not, see <http://www.gnu.org/licenses/>.
*/
-#include <xen/vm_event.h>
#include <asm/hvm/event.h>
#include <asm/paging.h>
-#include <asm/monitor.h>
-#include <public/vm_event.h>
-
-bool_t hvm_event_cr(unsigned int index, unsigned long value, unsigned long old)
-{
- struct vcpu *curr = current;
- struct arch_domain *ad = &curr->domain->arch;
- unsigned int ctrlreg_bitmask = monitor_ctrlreg_bitmask(index);
-
- if ( (ad->monitor.write_ctrlreg_enabled & ctrlreg_bitmask) &&
- (!(ad->monitor.write_ctrlreg_onchangeonly & ctrlreg_bitmask) ||
- value != old) )
- {
- bool_t sync = !!(ad->monitor.write_ctrlreg_sync & ctrlreg_bitmask);
-
- vm_event_request_t req = {
- .reason = VM_EVENT_REASON_WRITE_CTRLREG,
- .vcpu_id = curr->vcpu_id,
- .u.write_ctrlreg.index = index,
- .u.write_ctrlreg.new_value = value,
- .u.write_ctrlreg.old_value = old
- };
-
- vm_event_monitor_traps(curr, sync, &req);
- return 1;
- }
-
- return 0;
-}
void hvm_event_msr(unsigned int msr, uint64_t value)
{
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 4596662..26f8625 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -37,6 +37,7 @@
#include <xen/mem_access.h>
#include <xen/rangeset.h>
#include <xen/vm_event.h>
+#include <xen/monitor.h>
#include <asm/shadow.h>
#include <asm/hap.h>
#include <asm/current.h>
@@ -52,7 +53,6 @@
#include <asm/traps.h>
#include <asm/mc146818rtc.h>
#include <asm/mce.h>
-#include <asm/monitor.h>
#include <asm/hvm/hvm.h>
#include <asm/hvm/vpt.h>
#include <asm/hvm/support.h>
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 1e5445f..264f0fc 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -29,43 +29,6 @@ int arch_monitor_domctl_event(struct domain *d,
switch ( mop->event )
{
- case XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG:
- {
- unsigned int ctrlreg_bitmask;
- bool_t old_status;
-
- /* sanity check: avoid left-shift undefined behavior */
- if ( unlikely(mop->u.mov_to_cr.index > 31) )
- return -EINVAL;
-
- ctrlreg_bitmask = monitor_ctrlreg_bitmask(mop->u.mov_to_cr.index);
- old_status = !!(ad->monitor.write_ctrlreg_enabled & ctrlreg_bitmask);
-
- if ( unlikely(old_status == requested_status) )
- return -EEXIST;
-
- domain_pause(d);
-
- if ( mop->u.mov_to_cr.sync )
- ad->monitor.write_ctrlreg_sync |= ctrlreg_bitmask;
- else
- ad->monitor.write_ctrlreg_sync &= ~ctrlreg_bitmask;
-
- if ( mop->u.mov_to_cr.onchangeonly )
- ad->monitor.write_ctrlreg_onchangeonly |= ctrlreg_bitmask;
- else
- ad->monitor.write_ctrlreg_onchangeonly &= ~ctrlreg_bitmask;
-
- if ( requested_status )
- ad->monitor.write_ctrlreg_enabled |= ctrlreg_bitmask;
- else
- ad->monitor.write_ctrlreg_enabled &= ~ctrlreg_bitmask;
-
- domain_unpause(d);
-
- break;
- }
-
case XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR:
{
bool_t old_status = ad->monitor.mov_to_msr_enabled;
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 94342d5..aa65840 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -19,7 +19,7 @@
*/
#include <xen/vm_event.h>
-#include <asm/monitor.h>
+#include <xen/monitor.h>
#include <asm/paging.h>
#include <asm/hvm/vmx/vmx.h>
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index c46df5a..2366bae 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -62,6 +62,46 @@ int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
switch ( mop->event )
{
+#if CONFIG_X86
+ case XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG:
+ {
+ struct arch_domain *ad = &d->arch;
+ unsigned int ctrlreg_bitmask;
+ bool_t old_status;
+
+ /* sanity check: avoid left-shift undefined behavior */
+ if ( unlikely(mop->u.mov_to_cr.index > 31) )
+ return -EINVAL;
+
+ ctrlreg_bitmask = monitor_ctrlreg_bitmask(mop->u.mov_to_cr.index);
+ old_status = !!(ad->monitor.write_ctrlreg_enabled & ctrlreg_bitmask);
+
+ if ( unlikely(old_status == requested_status) )
+ return -EEXIST;
+
+ domain_pause(d);
+
+ if ( mop->u.mov_to_cr.sync )
+ ad->monitor.write_ctrlreg_sync |= ctrlreg_bitmask;
+ else
+ ad->monitor.write_ctrlreg_sync &= ~ctrlreg_bitmask;
+
+ if ( mop->u.mov_to_cr.onchangeonly )
+ ad->monitor.write_ctrlreg_onchangeonly |= ctrlreg_bitmask;
+ else
+ ad->monitor.write_ctrlreg_onchangeonly &= ~ctrlreg_bitmask;
+
+ if ( requested_status )
+ ad->monitor.write_ctrlreg_enabled |= ctrlreg_bitmask;
+ else
+ ad->monitor.write_ctrlreg_enabled &= ~ctrlreg_bitmask;
+
+ domain_unpause(d);
+
+ break;
+ }
+#endif
+
case XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST:
{
bool_t old_status = d->monitor.guest_request_enabled;
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 15152ba..53dc048 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -25,6 +25,7 @@
#include <xen/wait.h>
#include <xen/vm_event.h>
#include <xen/mem_access.h>
+#include <xen/monitor.h>
#include <asm/p2m.h>
#include <asm/altp2m.h>
#include <xsm/xsm.h>
@@ -823,6 +824,36 @@ int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
return 1;
}
+#if CONFIG_X86
+bool_t vm_event_monitor_cr(unsigned int index, unsigned long value,
+ unsigned long old)
+{
+ struct vcpu *curr = current;
+ struct arch_domain *ad = &curr->domain->arch;
+ unsigned int ctrlreg_bitmask = monitor_ctrlreg_bitmask(index);
+
+ if ( (ad->monitor.write_ctrlreg_enabled & ctrlreg_bitmask) &&
+ (!(ad->monitor.write_ctrlreg_onchangeonly & ctrlreg_bitmask) ||
+ value != old) )
+ {
+ bool_t sync = !!(ad->monitor.write_ctrlreg_sync & ctrlreg_bitmask);
+
+ vm_event_request_t req = {
+ .reason = VM_EVENT_REASON_WRITE_CTRLREG,
+ .vcpu_id = curr->vcpu_id,
+ .u.write_ctrlreg.index = index,
+ .u.write_ctrlreg.new_value = value,
+ .u.write_ctrlreg.old_value = old
+ };
+
+ vm_event_monitor_traps(curr, sync, &req);
+ return 1;
+ }
+
+ return 0;
+}
+#endif
+
void vm_event_monitor_guest_request(void)
{
struct vcpu *curr = current;
diff --git a/xen/include/asm-x86/hvm/event.h b/xen/include/asm-x86/hvm/event.h
index 504bd66..7fb9d96 100644
--- a/xen/include/asm-x86/hvm/event.h
+++ b/xen/include/asm-x86/hvm/event.h
@@ -19,6 +19,7 @@
#ifndef __ASM_X86_HVM_EVENT_H__
#define __ASM_X86_HVM_EVENT_H__
+#include <xen/vm_event.h>
#include <public/vm_event.h>
enum hvm_event_breakpoint_type
@@ -27,19 +28,13 @@ enum hvm_event_breakpoint_type
HVM_EVENT_SINGLESTEP_BREAKPOINT,
};
-/*
- * Called for current VCPU on crX/MSR changes by guest.
- * The event might not fire if the client has subscribed to it in onchangeonly
- * mode, hence the bool_t return type for control register write events.
- */
-bool_t hvm_event_cr(unsigned int index, unsigned long value,
- unsigned long old);
-#define hvm_event_crX(cr, new, old) \
- hvm_event_cr(VM_EVENT_X86_##cr, new, old)
void hvm_event_msr(unsigned int msr, uint64_t value);
int hvm_event_breakpoint(unsigned long rip,
enum hvm_event_breakpoint_type type);
+#define hvm_event_crX(cr, new, old) \
+ vm_event_monitor_cr(VM_EVENT_X86_##cr, new, old)
+
#endif /* __ASM_X86_HVM_EVENT_H__ */
/*
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index 7a662f9..99538b9 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -24,8 +24,6 @@
#include <xen/sched.h>
-#define monitor_ctrlreg_bitmask(ctrlreg_index) (1U << (ctrlreg_index))
-
static inline
int arch_monitor_domctl_op(struct domain *d, struct xen_domctl_monitor_op *mop)
{
diff --git a/xen/include/xen/monitor.h b/xen/include/xen/monitor.h
index 7015e6d..422fd93 100644
--- a/xen/include/xen/monitor.h
+++ b/xen/include/xen/monitor.h
@@ -25,6 +25,10 @@
struct domain;
struct xen_domctl_monitor_op;
+#if CONFIG_X86
+#define monitor_ctrlreg_bitmask(ctrlreg_index) (1U << (ctrlreg_index))
+#endif
+
int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *op);
#endif /* __XEN_MONITOR_H__ */
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index f124143..71ae84a 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -96,6 +96,16 @@ void vm_event_vcpu_unpause(struct vcpu *v);
int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
vm_event_request_t *req);
+#if CONFIG_X86
+/*
+ * Called for the current vCPU on control-register changes by guest.
+ * The event might not fire if the client has subscribed to it in onchangeonly
+ * mode, hence the bool_t return type for control register write events.
+ */
+bool_t vm_event_monitor_cr(unsigned int index, unsigned long value,
+ unsigned long old);
+#endif
+
void vm_event_monitor_guest_request(void);
#endif /* __VM_EVENT_H__ */
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 73+ messages in thread
* [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-16 14:04 [PATCH 0/7] vm-event: Implement ARM support for control-register writes Corneliu ZUZU
` (5 preceding siblings ...)
2016-06-16 14:12 ` [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr Corneliu ZUZU
@ 2016-06-16 14:13 ` Corneliu ZUZU
2016-06-16 14:26 ` Julien Grall
2016-06-16 16:49 ` Julien Grall
6 siblings, 2 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-16 14:13 UTC (permalink / raw)
To: xen-devel
Cc: Julien Grall, Stefano Stabellini, Tamas K Lengyel, Razvan Cojocaru
Add ARM support for control-register write monitoring through the vm-events
subsystem.
Chosen ARM system control-registers that can be monitored are:
- VM_EVENT_ARM_SCTLR: AArch32 SCTLR, AArch64 SCTLR_EL1
- VM_EVENT_ARM_TTBR{0,1}: AArch32 TTBR{0,1}, AArch64 TTBR{0,1}_EL1
- VM_EVENT_ARM_TTBCR: AArch32 TTBCR, AArch64 TCR_EL1
Trapping of write operations of these registers was attained by setting the
HCR_EL2.TVM / HCR.TVM bit.
Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
---
MAINTAINERS | 1 +
xen/arch/arm/Makefile | 1 +
xen/arch/arm/traps.c | 126 +++++++++++++++++++-
xen/arch/arm/vm_event.c | 112 ++++++++++++++++++
xen/common/monitor.c | 2 -
xen/common/vm_event.c | 2 -
xen/include/asm-arm/domain.h | 30 +++++
xen/include/asm-arm/traps.h | 253 +++++++++++++++++++++++++++++++++++++++++
xen/include/asm-arm/vm_event.h | 22 +++-
xen/include/public/vm_event.h | 8 +-
xen/include/xen/monitor.h | 2 -
xen/include/xen/vm_event.h | 2 -
12 files changed, 543 insertions(+), 18 deletions(-)
create mode 100644 xen/arch/arm/vm_event.c
create mode 100644 xen/include/asm-arm/traps.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 9a224d4..634f359 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -402,6 +402,7 @@ M: Tamas K Lengyel <tamas@tklengyel.com>
S: Supported
F: xen/common/mem_access.c
F: xen/*/vm_event.c
+F: xen/arch/*/vm_event.c
F: xen/*/monitor.c
F: xen/include/*/mem_access.h
F: xen/include/*/monitor.h
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9e38da3..390df0a 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -40,6 +40,7 @@ obj-y += device.o
obj-y += decode.o
obj-y += processor.o
obj-y += smc.o
+obj-y += vm_event.o
obj-$(CONFIG_LIVEPATCH) += livepatch.o
#obj-bin-y += ....o
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 8c50685..af61ac3 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -43,6 +43,7 @@
#include <asm/mmio.h>
#include <asm/cpufeature.h>
#include <asm/flushtlb.h>
+#include <asm/traps.h>
#include "decode.h"
#include "vtimer.h"
@@ -124,7 +125,12 @@ void init_traps(void)
WRITE_SYSREG((HCPTR_CP_MASK & ~(HCPTR_CP(10) | HCPTR_CP(11))) | HCPTR_TTA,
CPTR_EL2);
- /* Setup hypervisor traps */
+ /* Setup hypervisor traps
+ *
+ * Note: HCR_TVM bit is also set for system-register write monitoring
+ * purposes (see vm_event_monitor_cr), but (for performance reasons) that's
+ * done selectively (see vcpu_enter_adjust_traps).
+ */
WRITE_SYSREG(HCR_PTW|HCR_BSU_INNER|HCR_AMO|HCR_IMO|HCR_FMO|HCR_VM|
HCR_TWE|HCR_TWI|HCR_TSC|HCR_TAC|HCR_SWIO|HCR_TIDCP|HCR_FB,
HCR_EL2);
@@ -1720,6 +1726,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
const struct hsr_cp32 cp32 = hsr.cp32;
int regidx = cp32.reg;
struct vcpu *v = current;
+ register_t r = get_user_reg(regs, regidx);
if ( !check_conditional_instr(regs, hsr) )
{
@@ -1730,6 +1737,61 @@ static void do_cp15_32(struct cpu_user_regs *regs,
switch ( hsr.bits & HSR_CP32_REGS_MASK )
{
/*
+ * HCR_EL2.TVM / HCR.TVM
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.13
+ * ARMv8 (DDI 0487A.e): D1-1569 Table D1-34
+ */
+ case HSR_CPREG32(SCTLR):
+ TVM_EMUL_VMEVT(v, regs, hsr, r, SCTLR);
+ break;
+ case HSR_CPREG32(TTBR0_32):
+ TVM_EMUL_VMEVT(v, regs, hsr, r, TTBR0_32);
+ break;
+ case HSR_CPREG32(TTBR1_32):
+ TVM_EMUL_VMEVT(v, regs, hsr, r, TTBR1_32);
+ break;
+ case HSR_CPREG32(TTBCR):
+ TVM_EMUL_VMEVT(v, regs, hsr, r, TTBCR);
+ break;
+ case HSR_CPREG32(DACR):
+ TVM_EMUL(regs, hsr, r, DACR);
+ break;
+ case HSR_CPREG32(DFSR):
+ TVM_EMUL(regs, hsr, r, DFSR);
+ break;
+ case HSR_CPREG32(IFSR):
+ TVM_EMUL(regs, hsr, r, IFSR);
+ break;
+ case HSR_CPREG32(DFAR):
+ TVM_EMUL(regs, hsr, r, DFAR);
+ break;
+ case HSR_CPREG32(IFAR):
+ TVM_EMUL(regs, hsr, r, IFAR);
+ break;
+ case HSR_CPREG32(ADFSR):
+ TVM_EMUL(regs, hsr, r, ADFSR);
+ break;
+ case HSR_CPREG32(AIFSR):
+ TVM_EMUL(regs, hsr, r, AIFSR);
+ break;
+ case HSR_CPREG32(MAIR0):
+ TVM_EMUL(regs, hsr, r, MAIR0);
+ break;
+ case HSR_CPREG32(MAIR1):
+ TVM_EMUL(regs, hsr, r, MAIR1);
+ break;
+ case HSR_CPREG32(AMAIR0):
+ TVM_EMUL(regs, hsr, r, AMAIR0);
+ break;
+ case HSR_CPREG32(AMAIR1):
+ TVM_EMUL(regs, hsr, r, AMAIR1);
+ break;
+ case HSR_CPREG32(CONTEXTIDR):
+ TVM_EMUL(regs, hsr, r, CONTEXTIDR);
+ break;
+
+ /*
* !CNTHCTL_EL2.EL1PCEN / !CNTHCTL.PL1PCEN
*
* ARMv7 (DDI 0406C.b): B4.1.22
@@ -1853,6 +1915,13 @@ static void do_cp15_32(struct cpu_user_regs *regs,
static void do_cp15_64(struct cpu_user_regs *regs,
const union hsr hsr)
{
+ struct vcpu *v = current;
+ const struct hsr_cp64 cp64 = hsr.cp64;
+ sysreg64_t r = {
+ .low32 = (uint32_t) get_user_reg(regs, cp64.reg1),
+ .high32 = (uint32_t) get_user_reg(regs, cp64.reg2)
+ };
+
if ( !check_conditional_instr(regs, hsr) )
{
advance_pc(regs, hsr);
@@ -1862,6 +1931,19 @@ static void do_cp15_64(struct cpu_user_regs *regs,
switch ( hsr.bits & HSR_CP64_REGS_MASK )
{
/*
+ * HCR_EL2.TVM / HCR.TVM
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.13
+ * ARMv8 (DDI 0487A.e): D1-1569 Table D1-34
+ */
+ case HSR_CPREG64(TTBR0):
+ TVM_EMUL_VMEVT(v, regs, hsr, r.val64, TTBR0_64);
+ break;
+ case HSR_CPREG64(TTBR1):
+ TVM_EMUL_VMEVT(v, regs, hsr, r.val64, TTBR1_64);
+ break;
+
+ /*
* !CNTHCTL_EL2.EL1PCEN / !CNTHCTL.PL1PCEN
*
* ARMv7 (DDI 0406C.b): B4.1.22
@@ -1891,8 +1973,6 @@ static void do_cp15_64(struct cpu_user_regs *regs,
*/
default:
{
- const struct hsr_cp64 cp64 = hsr.cp64;
-
gdprintk(XENLOG_ERR,
"%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
cp64.read ? "mrrc" : "mcrr",
@@ -2128,10 +2208,50 @@ static void do_sysreg(struct cpu_user_regs *regs,
{
int regidx = hsr.sysreg.reg;
struct vcpu *v = current;
+ register_t r = get_user_reg(regs, regidx);
switch ( hsr.bits & HSR_SYSREG_REGS_MASK )
{
/*
+ * HCR_EL2.TVM
+ *
+ * ARMv8 (DDI 0487A.e): D1-1569 Table D1-34
+ */
+ case HSR_SYSREG_SCTLR_EL1:
+ TVM_EMUL_VMEVT(v, regs, hsr, r, SCTLR_EL1);
+ break;
+ case HSR_SYSREG_TTBR0_EL1:
+ TVM_EMUL_VMEVT(v, regs, hsr, r, TTBR0_EL1);
+ break;
+ case HSR_SYSREG_TTBR1_EL1:
+ TVM_EMUL_VMEVT(v, regs, hsr, r, TTBR1_EL1);
+ break;
+ case HSR_SYSREG_TCR_EL1:
+ TVM_EMUL_VMEVT(v, regs, hsr, r, TCR_EL1);
+ break;
+ case HSR_SYSREG_ESR_EL1:
+ TVM_EMUL(regs, hsr, r, ESR_EL1);
+ break;
+ case HSR_SYSREG_FAR_EL1:
+ TVM_EMUL(regs, hsr, r, FAR_EL1);
+ break;
+ case HSR_SYSREG_AFSR0_EL1:
+ TVM_EMUL(regs, hsr, r, AFSR0_EL1);
+ break;
+ case HSR_SYSREG_AFSR1_EL1:
+ TVM_EMUL(regs, hsr, r, AFSR1_EL1);
+ break;
+ case HSR_SYSREG_MAIR_EL1:
+ TVM_EMUL(regs, hsr, r, MAIR_EL1);
+ break;
+ case HSR_SYSREG_AMAIR_EL1:
+ TVM_EMUL(regs, hsr, r, AMAIR_EL1);
+ break;
+ case HSR_SYSREG_CONTEXTIDR_EL1:
+ TVM_EMUL(regs, hsr, r, CONTEXTIDR_EL1);
+ break;
+
+ /*
* HCR_EL2.TACR
*
* ARMv8 (DDI 0487A.d): D7.2.1
diff --git a/xen/arch/arm/vm_event.c b/xen/arch/arm/vm_event.c
new file mode 100644
index 0000000..3f23fec
--- /dev/null
+++ b/xen/arch/arm/vm_event.c
@@ -0,0 +1,112 @@
+/*
+ * arch/arm/vm_event.c
+ *
+ * Architecture-specific vm_event handling routines
+ *
+ * Copyright (c) 2016, Bitdefender S.R.L.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <xen/vm_event.h>
+#include <asm/traps.h>
+
+#if CONFIG_ARM_64
+
+#define MWSINF_SCTLR 32,SCTLR_EL1
+#define MWSINF_TTBR0 64,TTBR0_EL1
+#define MWSINF_TTBR1 64,TTBR1_EL1
+#define MWSINF_TTBCR 64,TCR_EL1
+
+#elif CONFIG_ARM_32
+
+#define MWSINF_SCTLR 32,SCTLR
+#define MWSINF_TTBR0 64,TTBR0
+#define MWSINF_TTBR1 64,TTBR1
+#define MWSINF_TTBR0_32 32,TTBR0_32
+#define MWSINF_TTBR1_32 32,TTBR1_32
+#define MWSINF_TTBCR 32,TTBCR
+
+#endif
+
+#define MWS_EMUL_(val, sz, r...) WRITE_SYSREG##sz((uint##sz##_t) (val), r)
+#define MWS_EMUL(r) CALL_MACRO(MWS_EMUL_, w->value, MWSINF_##r)
+
+static inline void vcpu_enter_write_data(struct vcpu *v)
+{
+ struct monitor_write_data *w = &v->arch.vm_event.write_data;
+
+ if ( likely(MWS_NOWRITE == w->status) )
+ return;
+
+ switch ( w->status )
+ {
+ case MWS_SCTLR:
+ MWS_EMUL(SCTLR);
+ break;
+ case MWS_TTBR0:
+ MWS_EMUL(TTBR0);
+ break;
+ case MWS_TTBR1:
+ MWS_EMUL(TTBR1);
+ break;
+#if CONFIG_ARM_32
+ case MWS_TTBR0_32:
+ MWS_EMUL(TTBR0_32);
+ break;
+ case MWS_TTBR1_32:
+ MWS_EMUL(TTBR1_32);
+ break;
+#endif
+ case MWS_TTBCR:
+ MWS_EMUL(TTBCR);
+ break;
+ default:
+ break;
+ }
+
+ w->status = MWS_NOWRITE;
+}
+
+static inline void vcpu_enter_adjust_traps(struct vcpu *v)
+{
+ register_t old_hcr, hcr;
+
+ hcr = (old_hcr = READ_SYSREG(HCR_EL2));
+
+ if ( unlikely(0 != v->domain->arch.monitor.write_ctrlreg_enabled) )
+ hcr |= HCR_TVM;
+ else
+ hcr &= ~HCR_TVM;
+
+ if ( unlikely(hcr != old_hcr) )
+ {
+ WRITE_SYSREG(hcr, HCR_EL2);
+ isb();
+ }
+}
+
+void arch_vm_event_vcpu_enter(struct vcpu *v)
+{
+ vcpu_enter_write_data(v);
+ vcpu_enter_adjust_traps(v);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index 2366bae..c35a717 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -62,7 +62,6 @@ int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
switch ( mop->event )
{
-#if CONFIG_X86
case XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG:
{
struct arch_domain *ad = &d->arch;
@@ -100,7 +99,6 @@ int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
break;
}
-#endif
case XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST:
{
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 53dc048..e0f999e 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -824,7 +824,6 @@ int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
return 1;
}
-#if CONFIG_X86
bool_t vm_event_monitor_cr(unsigned int index, unsigned long value,
unsigned long old)
{
@@ -852,7 +851,6 @@ bool_t vm_event_monitor_cr(unsigned int index, unsigned long value,
return 0;
}
-#endif
void vm_event_monitor_guest_request(void)
{
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 370cdeb..83f0952 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -40,6 +40,26 @@ struct vtimer {
uint64_t cval;
};
+enum monitor_write_status
+{
+ MWS_NOWRITE = 0,
+ MWS_SCTLR,
+ MWS_TTBR0,
+ MWS_TTBR1,
+ MWS_TTBR0_32,
+ MWS_TTBR1_32,
+ MWS_TTBCR,
+};
+
+struct monitor_write_data {
+ enum monitor_write_status status;
+ uint64_t value;
+};
+
+struct arch_vm_event {
+ struct monitor_write_data write_data;
+};
+
struct arch_domain
{
#ifdef CONFIG_ARM_64
@@ -127,6 +147,14 @@ struct arch_domain
paddr_t efi_acpi_gpa;
paddr_t efi_acpi_len;
#endif
+
+ /* Arch-specific monitor options */
+ struct {
+ unsigned int write_ctrlreg_enabled : 4;
+ unsigned int write_ctrlreg_sync : 4;
+ unsigned int write_ctrlreg_onchangeonly : 4;
+ } monitor;
+
} __cacheline_aligned;
struct arch_vcpu
@@ -258,6 +286,8 @@ struct arch_vcpu
struct vtimer phys_timer;
struct vtimer virt_timer;
bool_t vtimer_initialized;
+
+ struct arch_vm_event vm_event;
} __cacheline_aligned;
void vcpu_show_execution_state(struct vcpu *);
diff --git a/xen/include/asm-arm/traps.h b/xen/include/asm-arm/traps.h
new file mode 100644
index 0000000..9e246a7
--- /dev/null
+++ b/xen/include/asm-arm/traps.h
@@ -0,0 +1,253 @@
+/*
+ * include/asm-arm/traps.h
+ *
+ * ARM Trap handlers
+ *
+ * Copyright (c) 2016, Bitdefender S.R.L.
+ *
+ * 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ASM_ARM_TRAPS_H__
+#define __ASM_ARM_TRAPS_H__
+
+#include <xen/vm_event.h>
+#include <asm/regs.h>
+#include <public/vm_event.h>
+
+/* used to force expansion of args before calling macro */
+#define CALL_MACRO(macro, args...) macro(args)
+
+/* used for easy manipulation of low/high 32-bits of 64-bit system registers */
+typedef union {
+ uint64_t val64;
+ struct {
+ uint32_t low32;
+ uint32_t high32;
+ };
+} sysreg64_t;
+
+#if CONFIG_ARM_64
+
+/*
+ * Emulation of system-register trapped writes that do not cause
+ * VM_EVENT_REASON_WRITE_CTRLREG monitor vm-events.
+ * Such writes are collaterally trapped due to setting the HCR_EL2.TVM bit.
+ *
+ * Regarding aarch32 domains, note that from Xen's perspective system-registers
+ * of such domains are architecturally-mapped to aarch64 registers in one of
+ * three ways:
+ * - low 32-bits mapping (e.g. aarch32 DFAR -> aarch64 FAR_EL1[31:0])
+ * - high 32-bits mapping (e.g. aarch32 IFAR -> aarch64 FAR_EL1[63:32])
+ * - full mapping (e.g. aarch32 SCTLR -> aarch64 SCTLR_EL1)
+ *
+ * Hence we define 2 macro variants:
+ * - TVM_EMUL_SZ variant, for full mappings
+ * - TVM_EMUL_LH variant, for low/high 32-bits mappings
+ */
+#define TVM_EMUL_SZ(regs, hsr, val, sz, r...) \
+{ \
+ if ( psr_mode_is_user(regs) ) \
+ return inject_undef_exception(regs, hsr); \
+ WRITE_SYSREG##sz((uint##sz##_t) (val), r); \
+}
+#define TVM_EMUL_LH(regs, hsr, val, l_or_h, r...) \
+{ \
+ sysreg64_t _new; \
+ if ( psr_mode_is_user(regs) ) \
+ return inject_undef_exception(regs, hsr); \
+ _new.val64 = READ_SYSREG64(r); \
+ _new.l_or_h = (uint32_t) (val); \
+ WRITE_SYSREG64(_new.val64, r); \
+}
+
+/*
+ * Emulation of system-register writes that cause VM_EVENT_REASON_WRITE_CTRLREG
+ * monitor vm-events.
+ * SZ/LH variants, reasoning is the same as above.
+ */
+#define TVM_EMUL_SZ_VMEVT(v, regs, hsr, val, cridx, mws, sz, r) \
+{ \
+ unsigned long _old; \
+ if ( psr_mode_is_user(regs) ) \
+ return inject_undef_exception(regs, hsr); \
+ ASSERT(MWS_NOWRITE == (v)->arch.vm_event.write_data.status); \
+ (v)->arch.vm_event.write_data.status = mws; \
+ (v)->arch.vm_event.write_data.value = (uint##sz##_t) (val); \
+ _old = READ_SYSREG##sz(r); \
+ vm_event_monitor_cr(cridx, \
+ (uint##sz##_t) (val), \
+ _old); \
+}
+#define TVM_EMUL_LH_VMEVT(v, regs, hsr, val, cridx, mws, l_or_h, r) \
+{ \
+ sysreg64_t _old, _new; \
+ if ( psr_mode_is_user(regs) ) \
+ return inject_undef_exception(regs, hsr); \
+ _new.val64 = (_old.val64 = READ_SYSREG64(r)); \
+ _new.l_or_h = (uint32_t) (val); \
+ ASSERT(MWS_NOWRITE == (v)->arch.vm_event.write_data.status); \
+ (v)->arch.vm_event.write_data.status = mws; \
+ (v)->arch.vm_event.write_data.value = _new.val64; \
+ vm_event_monitor_cr(cridx, \
+ _new.val64, \
+ _old.val64); \
+}
+
+#define PART_FULL32 SZ,32 /* SZ variant, 32-bit counterpart */
+#define PART_FULL64 SZ,64 /* SZ variant, 64-bit counterpart */
+#define PART_LOW LH,low32 /* LH variant, low 32-bits */
+#define PART_HIGH LH,high32 /* LH variant, high 32-bits */
+
+/*
+ * HCR_EL2.TVM trapped registers info (size in bits) for an aarch64 domain.
+ *
+ * ARMv8 (DDI 0487A.e): D1-1569 Table D1-34 (traps from AArch64 state)
+ */
+#define TVMINF_ESR_EL1 PART_FULL32, ESR_EL1
+#define TVMINF_FAR_EL1 PART_FULL64, FAR_EL1
+#define TVMINF_AFSR0_EL1 PART_FULL32, AFSR0_EL1
+#define TVMINF_AFSR1_EL1 PART_FULL32, AFSR1_EL1
+#define TVMINF_MAIR_EL1 PART_FULL64, MAIR_EL1
+#define TVMINF_AMAIR_EL1 PART_FULL64, AMAIR_EL1
+#define TVMINF_CONTEXTIDR_EL1 PART_FULL32, CONTEXTIDR_EL1
+
+#define TVMINF_VMEVT_SCTLR_EL1 VM_EVENT_ARM_SCTLR, MWS_SCTLR, \
+ PART_FULL32, SCTLR_EL1
+#define TVMINF_VMEVT_TTBR0_EL1 VM_EVENT_ARM_TTBR0, MWS_TTBR0, \
+ PART_FULL64, TTBR0_EL1
+#define TVMINF_VMEVT_TTBR1_EL1 VM_EVENT_ARM_TTBR1, MWS_TTBR1, \
+ PART_FULL64, TTBR1_EL1
+#define TVMINF_VMEVT_TCR_EL1 VM_EVENT_ARM_TTBCR, MWS_TTBCR, \
+ PART_FULL64, TCR_EL1
+
+/*
+ * HCR_EL2.TVM trapped registers info for an aarch32 domain.
+ * Specifies the architecturally-mapped aarch64 counterpart register
+ * as well as the actual part the aarch32 register is mapped-to
+ * (full register/low 32-bits/high 32-bits).
+ *
+ * ARMv8 (DDI 0487A.e): D1-1569 Table D1-34 (traps from aarch32 state)
+ */
+#define TVMINF_DACR PART_FULL32, DACR32_EL2
+#define TVMINF_DFSR PART_FULL32, ESR_EL1
+#define TVMINF_IFSR PART_FULL32, IFSR32_EL2
+#define TVMINF_DFAR PART_LOW, FAR_EL1
+#define TVMINF_IFAR PART_HIGH, FAR_EL1
+#define TVMINF_ADFSR PART_FULL32, AFSR0_EL1
+#define TVMINF_AIFSR PART_FULL32, AFSR1_EL1
+#define TVMINF_MAIR0 PART_LOW, MAIR_EL1 /* AKA PRRR */
+#define TVMINF_MAIR1 PART_HIGH, MAIR_EL1 /* AKA NMRR */
+#define TVMINF_AMAIR0 PART_LOW, AMAIR_EL1
+#define TVMINF_AMAIR1 PART_HIGH, AMAIR_EL1
+#define TVMINF_CONTEXTIDR PART_FULL32, CONTEXTIDR_EL1
+
+#define TVMINF_VMEVT_SCTLR VM_EVENT_ARM_SCTLR, MWS_SCTLR, \
+ PART_FULL32, SCTLR_EL1
+#define TVMINF_VMEVT_TTBR0_64 VM_EVENT_ARM_TTBR0, MWS_TTBR0, \
+ PART_FULL64, TTBR0_EL1
+#define TVMINF_VMEVT_TTBR1_64 VM_EVENT_ARM_TTBR1, MWS_TTBR1, \
+ PART_FULL64, TTBR1_EL1
+#define TVMINF_VMEVT_TTBR0_32 VM_EVENT_ARM_TTBR0, MWS_TTBR0, \
+ PART_LOW, TTBR0_EL1
+#define TVMINF_VMEVT_TTBR1_32 VM_EVENT_ARM_TTBR1, MWS_TTBR1, \
+ PART_LOW, TTBR1_EL1
+#define TVMINF_VMEVT_TTBCR VM_EVENT_ARM_TTBCR, MWS_TTBCR, \
+ PART_LOW, TCR_EL1
+
+/*
+ * Wrappers over TVM_EMUL_{SZ,LH}/TVM_EMUL_{SZ,LH}_VMEVT variants which use
+ * the TVMINF_* defs.
+ */
+#define TVM_EMUL_VAR(regs, hsr, val, var, sz_or_lh, r...) \
+ TVM_EMUL_##var(regs, hsr, val, sz_or_lh, r)
+#define TVM_EMUL_VAR_VMEVT(v, regs, hsr, val, cridx, mws, var, sz_or_lh, r...) \
+ TVM_EMUL_##var##_VMEVT(v, regs, hsr, val, cridx, mws, sz_or_lh, r)
+#define TVM_EMUL(regs, hsr, val, r) \
+ CALL_MACRO(TVM_EMUL_VAR, regs, hsr, val, TVMINF_##r)
+#define TVM_EMUL_VMEVT(v, regs, hsr, val, r) \
+ CALL_MACRO(TVM_EMUL_VAR_VMEVT, v, regs, hsr, val, TVMINF_VMEVT_##r)
+
+#elif CONFIG_ARM_32
+
+/*
+ * Emulation of system-register trapped writes that do not cause
+ * VM_EVENT_REASON_WRITE_CTRLREG monitor vm-events.
+ * Such writes are collaterally trapped due to setting the HCR.TVM bit.
+ */
+#define TVM_EMUL_SZ(regs, hsr, val, sz, r...) \
+{ \
+ if ( psr_mode_is_user(regs) ) \
+ return inject_undef_exception(regs, hsr); \
+ WRITE_SYSREG##sz((uint##sz##_t) (val), r); \
+}
+
+/*
+ * Emulation of system-register writes that cause VM_EVENT_REASON_WRITE_CTRLREG
+ * monitor vm-events.
+ */
+#define TVM_EMUL_SZ_VMEVT(v, regs, hsr, val, cridx, mws, sz, r...) \
+{ \
+ unsigned long _old; \
+ if ( psr_mode_is_user(regs) ) \
+ return inject_undef_exception(regs, hsr); \
+ ASSERT(MWS_NOWRITE == (v)->arch.vm_event.write_data.status); \
+ (v)->arch.vm_event.write_data.status = mws; \
+ (v)->arch.vm_event.write_data.value = (uint##sz##_t) (val); \
+ _old = READ_SYSREG##sz(r); \
+ vm_event_monitor_cr(cridx, \
+ (uint##sz##_t) (val), \
+ _old); \
+}
+
+/*
+ * HCR.TVM trapped registers info (size in bits).
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.13
+ */
+#define TVMINF_DACR 32,DACR
+#define TVMINF_DFSR 32,DFSR
+#define TVMINF_IFSR 32,IFSR
+#define TVMINF_DFAR 32,DFAR
+#define TVMINF_IFAR 32,IFAR
+#define TVMINF_ADFSR 32,ADFSR
+#define TVMINF_AIFSR 32,AIFSR
+#define TVMINF_MAIR0 32,MAIR0 /* AKA PRRR */
+#define TVMINF_MAIR1 32,MAIR1 /* AKA NMRR */
+#define TVMINF_AMAIR0 32,AMAIR0
+#define TVMINF_AMAIR1 32,AMAIR1
+#define TVMINF_CONTEXTIDR 32,CONTEXTIDR
+
+#define TVMINF_VMEVT_SCTLR VM_EVENT_ARM_SCTLR, MWS_SCTLR, \
+ 32,SCTLR
+#define TVMINF_VMEVT_TTBR0_64 VM_EVENT_ARM_TTBR0, MWS_TTBR0, \
+ 64,TTBR0
+#define TVMINF_VMEVT_TTBR1_64 VM_EVENT_ARM_TTBR1, MWS_TTBR1, \
+ 64,TTBR1
+#define TVMINF_VMEVT_TTBR0_32 VM_EVENT_ARM_TTBR0, MWS_TTBR0_32, \
+ 32,TTBR0_32
+#define TVMINF_VMEVT_TTBR1_32 VM_EVENT_ARM_TTBR1, MWS_TTBR1_32, \
+ 32,TTBR1_32
+#define TVMINF_VMEVT_TTBCR VM_EVENT_ARM_TTBCR, MWS_TTBCR, \
+ 32,TTBCR
+
+/* Wrappers over TVM_EMUL_SZ/TVM_EMUL_SZ_VMEVT which use the TVMINF_* defs. */
+#define TVM_EMUL(regs, hsr, val, r) \
+ CALL_MACRO(TVM_EMUL_SZ, regs, hsr, val, TVMINF_##r)
+#define TVM_EMUL_VMEVT(v, regs, hsr, val, r) \
+ CALL_MACRO(TVM_EMUL_SZ_VMEVT, v, regs, hsr, val, TVMINF_VMEVT_##r)
+
+#endif
+
+#endif /* __ASM_ARM_TRAPS_H__ */
diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index 4e5a272..edf9654 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -30,6 +30,12 @@ static inline int vm_event_init_domain(struct domain *d)
static inline void vm_event_cleanup_domain(struct domain *d)
{
+ struct vcpu *v;
+
+ for_each_vcpu ( d, v )
+ memset(&v->arch.vm_event, 0, sizeof(v->arch.vm_event));
+
+ memset(&d->arch.monitor, 0, sizeof(d->arch.monitor));
memset(&d->monitor, 0, sizeof(d->monitor));
}
@@ -41,7 +47,13 @@ static inline void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
static inline
void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t *rsp)
{
- /* Not supported on ARM. */
+ /* X86 VM_EVENT_REASON_MOV_TO_MSR could (but shouldn't) end-up here too. */
+ if ( unlikely(VM_EVENT_REASON_WRITE_CTRLREG != rsp->reason) )
+ return;
+
+ if ( (rsp->flags & VM_EVENT_FLAG_DENY) &&
+ (rsp->flags & VM_EVENT_FLAG_VCPU_PAUSED) )
+ v->arch.vm_event.write_data.status = MWS_NOWRITE;
}
static inline
@@ -55,10 +67,7 @@ static inline void vm_event_fill_regs(vm_event_request_t *req)
/* Not supported on ARM. */
}
-static inline void arch_vm_event_vcpu_enter(struct vcpu *v)
-{
- /* Nothing to do. */
-}
+void arch_vm_event_vcpu_enter(struct vcpu *v);
/*
* Monitor vm-events.
@@ -67,7 +76,8 @@ static inline uint32_t vm_event_monitor_get_capabilities(struct domain *d)
{
uint32_t capabilities = 0;
- capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
+ capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
+ (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
return capabilities;
}
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index 8f94e20..ec3eaca 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -121,12 +121,18 @@
/* An event has been requested via HVMOP_guest_request_vm_event. */
#define VM_EVENT_REASON_GUEST_REQUEST 8
-/* Supported values for the vm_event_write_ctrlreg index. */
+/* Supported values for the vm_event_write_ctrlreg index (x86). */
#define VM_EVENT_X86_CR0 0
#define VM_EVENT_X86_CR3 1
#define VM_EVENT_X86_CR4 2
#define VM_EVENT_X86_XCR0 3
+/* Supported values for the vm_event_write_ctrlreg index (arm). */
+#define VM_EVENT_ARM_SCTLR 0 /* SCTLR_EL1 (aarch64), SCTLR (aarch32) */
+#define VM_EVENT_ARM_TTBR0 1 /* TTBR0_EL1 (aarch64), TTBR0 (aarch32) */
+#define VM_EVENT_ARM_TTBR1 2 /* TTBR1_EL1 (aarch64), TTBR1 (aarch32) */
+#define VM_EVENT_ARM_TTBCR 3 /* TCR_EL1 (aarch64), TTBCR (aarch32) */
+
/*
* Using a custom struct (not hvm_hw_cpu) so as to not fill
* the vm_event ring buffer too quickly.
diff --git a/xen/include/xen/monitor.h b/xen/include/xen/monitor.h
index 422fd93..dc5b9d7 100644
--- a/xen/include/xen/monitor.h
+++ b/xen/include/xen/monitor.h
@@ -25,9 +25,7 @@
struct domain;
struct xen_domctl_monitor_op;
-#if CONFIG_X86
#define monitor_ctrlreg_bitmask(ctrlreg_index) (1U << (ctrlreg_index))
-#endif
int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *op);
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index 71ae84a..8b1acd0 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -96,7 +96,6 @@ void vm_event_vcpu_unpause(struct vcpu *v);
int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
vm_event_request_t *req);
-#if CONFIG_X86
/*
* Called for the current vCPU on control-register changes by guest.
* The event might not fire if the client has subscribed to it in onchangeonly
@@ -104,7 +103,6 @@ int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
*/
bool_t vm_event_monitor_cr(unsigned int index, unsigned long value,
unsigned long old);
-#endif
void vm_event_monitor_guest_request(void);
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 73+ messages in thread
* Re: [PATCH 1/7] minor (formatting) fixes
2016-06-16 14:06 ` [PATCH 1/7] minor (formatting) fixes Corneliu ZUZU
@ 2016-06-16 14:24 ` Jan Beulich
2016-06-16 19:19 ` Corneliu ZUZU
2016-06-16 16:02 ` Tamas K Lengyel
1 sibling, 1 reply; 73+ messages in thread
From: Jan Beulich @ 2016-06-16 14:24 UTC (permalink / raw)
To: Corneliu ZUZU
Cc: Stefano Stabellini, Razvan Cojocaru, Andrew Cooper, xen-devel,
Julien Grall, Tamas K Lengyel
>>> On 16.06.16 at 16:06, <czuzu@bitdefender.com> wrote:
> --- a/xen/arch/x86/hvm/event.c
> +++ b/xen/arch/x86/hvm/event.c
> @@ -23,6 +23,7 @@
>
> #include <xen/vm_event.h>
> #include <asm/hvm/event.h>
> +#include <asm/paging.h>
> #include <asm/monitor.h>
> #include <asm/vm_event.h>
> #include <public/vm_event.h>
> diff --git a/xen/common/monitor.c b/xen/common/monitor.c
> index d950a7c..b30857a 100644
> --- a/xen/common/monitor.c
> +++ b/xen/common/monitor.c
> @@ -22,7 +22,6 @@
> #include <xen/monitor.h>
> #include <xen/sched.h>
> #include <xsm/xsm.h>
> -#include <public/domctl.h>
> #include <asm/monitor.h>
> #include <asm/vm_event.h>
These two adjustments clearly don't fit title / description. I certainly
don't mind unnecessary inclusions to be dropped, but the addition of
one clearly needs explanation (after all thing build fine without it).
> --- a/xen/include/asm-x86/vm_event.h
> +++ b/xen/include/asm-x86/vm_event.h
> @@ -44,6 +44,9 @@ void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp);
>
> void vm_event_fill_regs(vm_event_request_t *req);
>
> +/*
> + * Monitor vm-events.
> + */
This is a single line comment (also elsewhere).
> --- a/xen/include/xen/vm_event.h
> +++ b/xen/include/xen/vm_event.h
> @@ -85,7 +85,6 @@ void vm_event_monitor_guest_request(void);
>
> #endif /* __VM_EVENT_H__ */
>
> -
> /*
> * Local variables:
> * mode: C
Why don't you remove the other stray blank line at once?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-16 14:13 ` [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events Corneliu ZUZU
@ 2016-06-16 14:26 ` Julien Grall
2016-06-16 19:24 ` Corneliu ZUZU
2016-06-16 16:49 ` Julien Grall
1 sibling, 1 reply; 73+ messages in thread
From: Julien Grall @ 2016-06-16 14:26 UTC (permalink / raw)
To: Corneliu ZUZU, xen-devel
Cc: Stefano Stabellini, Tamas K Lengyel, Razvan Cojocaru
Hello Corneliu,
On 16/06/16 15:13, Corneliu ZUZU wrote:
> Add ARM support for control-register write monitoring through the vm-events
> subsystem.
>
> Chosen ARM system control-registers that can be monitored are:
> - VM_EVENT_ARM_SCTLR: AArch32 SCTLR, AArch64 SCTLR_EL1
> - VM_EVENT_ARM_TTBR{0,1}: AArch32 TTBR{0,1}, AArch64 TTBR{0,1}_EL1
> - VM_EVENT_ARM_TTBCR: AArch32 TTBCR, AArch64 TCR_EL1
>
> Trapping of write operations of these registers was attained by setting the
> HCR_EL2.TVM / HCR.TVM bit.
>
> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
> ---
> MAINTAINERS | 1 +
> xen/arch/arm/Makefile | 1 +
> xen/arch/arm/traps.c | 126 +++++++++++++++++++-
> xen/arch/arm/vm_event.c | 112 ++++++++++++++++++
> xen/common/monitor.c | 2 -
> xen/common/vm_event.c | 2 -
> xen/include/asm-arm/domain.h | 30 +++++
> xen/include/asm-arm/traps.h | 253 +++++++++++++++++++++++++++++++++++++++++
> xen/include/asm-arm/vm_event.h | 22 +++-
> xen/include/public/vm_event.h | 8 +-
> xen/include/xen/monitor.h | 2 -
> xen/include/xen/vm_event.h | 2 -
> 12 files changed, 543 insertions(+), 18 deletions(-)
I think this patch would benefit to be split in multiple patches to ease
the review and also describe the infrastructure you have introduced
(TVM_* & co).
I will review in detail later.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter
2016-06-16 14:08 ` [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter Corneliu ZUZU
@ 2016-06-16 14:51 ` Jan Beulich
2016-06-16 20:10 ` Corneliu ZUZU
2016-06-16 16:17 ` Tamas K Lengyel
2016-06-17 8:55 ` Julien Grall
2 siblings, 1 reply; 73+ messages in thread
From: Jan Beulich @ 2016-06-16 14:51 UTC (permalink / raw)
To: Corneliu ZUZU
Cc: Kevin Tian, Stefano Stabellini, Razvan Cojocaru, George Dunlap,
Andrew Cooper, xen-devel, Julien Grall, Paul Durrant,
Tamas K Lengyel, Jun Nakajima
>>> On 16.06.16 at 16:08, <czuzu@bitdefender.com> wrote:
> @@ -509,6 +508,8 @@ void hvm_do_resume(struct vcpu *v)
> }
> }
>
> + vm_event_vcpu_enter(v);
Why here?
> @@ -3874,6 +3875,9 @@ void vmx_vmenter_helper(const struct cpu_user_regs *regs)
> }
>
> out:
> + if ( guest_mode(regs) )
> + vm_event_vcpu_enter(curr);
> +
> HVMTRACE_ND(VMENTRY, 0, 1/*cycles*/, 0, 0, 0, 0, 0, 0, 0);
>
> __vmwrite(GUEST_RIP, regs->rip);
Why with a conditional? The registers can't possibly hold to non-
guest state when you're here.
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -36,7 +36,6 @@
> #include <asm/hvm/nestedhvm.h>
> #include <asm/altp2m.h>
> #include <asm/hvm/svm/amd-iommu-proto.h>
> -#include <asm/vm_event.h>
> #include <xsm/xsm.h>
There are way too many of these #include adjustments here. If
you really mean to clean these up, please don't randomly throw
this into various unrelated patches.
> --- a/xen/common/monitor.c
> +++ b/xen/common/monitor.c
> @@ -22,8 +22,8 @@
> #include <xen/monitor.h>
> #include <xen/sched.h>
> #include <xsm/xsm.h>
> +#include <xen/vm_event.h>
> #include <asm/monitor.h>
> -#include <asm/vm_event.h>
Please retain at least basic grouping (i.e. all xen/ ones together,
meaning the insertion should move up by one line).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 4/7] vm-event/x86: use vm_event_vcpu_enter properly
2016-06-16 14:09 ` [PATCH 4/7] vm-event/x86: use vm_event_vcpu_enter properly Corneliu ZUZU
@ 2016-06-16 15:00 ` Jan Beulich
2016-06-16 20:20 ` Corneliu ZUZU
2016-06-16 16:27 ` Tamas K Lengyel
1 sibling, 1 reply; 73+ messages in thread
From: Jan Beulich @ 2016-06-16 15:00 UTC (permalink / raw)
To: Corneliu ZUZU
Cc: Kevin Tian, Tamas K Lengyel, Razvan Cojocaru, Andrew Cooper,
xen-devel, Jun Nakajima
>>> On 16.06.16 at 16:09, <czuzu@bitdefender.com> wrote:
> @@ -2199,7 +2153,9 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
>
> if ( hvm_event_crX(CR0, value, old_value) )
> {
> - /* The actual write will occur in hvm_do_resume(), if permitted. */
> + /* The actual write will occur in vcpu_enter_write_data(), if
> + * permitted.
> + */
Coding style.
> @@ -1432,18 +1430,16 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned int cr)
> if ( paging_mode_hap(v->domain) )
> {
> /* Manage GUEST_CR3 when CR0.PE=0. */
> + uint32_t old_ctls = v->arch.hvm_vmx.exec_control;
> uint32_t cr3_ctls = (CPU_BASED_CR3_LOAD_EXITING |
> CPU_BASED_CR3_STORE_EXITING);
> +
> v->arch.hvm_vmx.exec_control &= ~cr3_ctls;
> if ( !hvm_paging_enabled(v) && !vmx_unrestricted_guest(v) )
> v->arch.hvm_vmx.exec_control |= cr3_ctls;
>
> - /* Trap CR3 updates if CR3 memory events are enabled. */
> - if ( v->domain->arch.monitor.write_ctrlreg_enabled &
> - monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
> - v->arch.hvm_vmx.exec_control |= CPU_BASED_CR3_LOAD_EXITING;
> -
> - vmx_update_cpu_exec_control(v);
> + if ( old_ctls != v->arch.hvm_vmx.exec_control )
> + vmx_update_cpu_exec_control(v);
> }
How does this match up with the rest of this patch?
> @@ -179,6 +182,105 @@ void vm_event_fill_regs(vm_event_request_t *req)
> req->data.regs.x86.cs_arbytes = seg.attr.bytes;
> }
>
> +static inline void vcpu_enter_write_data(struct vcpu *v)
Please allow the compiler to decide whether to inline such larger
functions.
> +void arch_vm_event_vcpu_enter(struct vcpu *v)
> +{
> + /* vmx only */
> + ASSERT( cpu_has_vmx );
Stray blanks.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr
2016-06-16 14:12 ` [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr Corneliu ZUZU
@ 2016-06-16 15:16 ` Jan Beulich
2016-06-17 8:25 ` Corneliu ZUZU
2016-06-16 16:55 ` Tamas K Lengyel
1 sibling, 1 reply; 73+ messages in thread
From: Jan Beulich @ 2016-06-16 15:16 UTC (permalink / raw)
To: Corneliu ZUZU; +Cc: Andrew Cooper, Tamas K Lengyel, Razvan Cojocaru, xen-devel
>>> On 16.06.16 at 16:12, <czuzu@bitdefender.com> wrote:
> Prepare for ARM implementation of control-register write vm-events by moving
> X86-specific hvm_event_cr to the common-side.
>
> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
> ---
> xen/arch/x86/hvm/event.c | 30 ------------------------------
> xen/arch/x86/hvm/hvm.c | 2 +-
> xen/arch/x86/monitor.c | 37 -------------------------------------
> xen/arch/x86/vm_event.c | 2 +-
> xen/common/monitor.c | 40 ++++++++++++++++++++++++++++++++++++++++
> xen/common/vm_event.c | 31 +++++++++++++++++++++++++++++++
> xen/include/asm-x86/hvm/event.h | 13 ++++---------
> xen/include/asm-x86/monitor.h | 2 --
> xen/include/xen/monitor.h | 4 ++++
> xen/include/xen/vm_event.h | 10 ++++++++++
> 10 files changed, 91 insertions(+), 80 deletions(-)
Considering that there's no ARM file getting altered here at all,
mentioning ARM in the subject is a little odd.
> --- a/xen/common/monitor.c
> +++ b/xen/common/monitor.c
> @@ -62,6 +62,46 @@ int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
>
> switch ( mop->event )
> {
> +#if CONFIG_X86
#ifdef please.
> + case XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG:
> + {
> + struct arch_domain *ad = &d->arch;
Peeking into the next patch I see that this stays there. Common code,
however, shouldn't access ->arch sub-structures - respective fields
should be moved out.
And looking at all the uses of this variable I get the impression that
you really want a shorthand for &d->arch.monitor (if any such
helper variable is worthwhile to have here in the first place).
> --- a/xen/include/asm-x86/monitor.h
> +++ b/xen/include/asm-x86/monitor.h
> @@ -24,8 +24,6 @@
>
> #include <xen/sched.h>
>
> -#define monitor_ctrlreg_bitmask(ctrlreg_index) (1U << (ctrlreg_index))
> -
> static inline
> int arch_monitor_domctl_op(struct domain *d, struct xen_domctl_monitor_op *mop)
> {
> --- a/xen/include/xen/monitor.h
> +++ b/xen/include/xen/monitor.h
> @@ -25,6 +25,10 @@
> struct domain;
> struct xen_domctl_monitor_op;
>
> +#if CONFIG_X86
> +#define monitor_ctrlreg_bitmask(ctrlreg_index) (1U << (ctrlreg_index))
> +#endif
What's the point in removing this from the x86 header if then it
needs to be put in such a conditional? If the conditional gets
dropped in the next patch, then I think you have two options:
Leave it where it is here, and move it there. Or move it here,
but omit the conditional right away - I can't see this definition
being present to harm the ARM build in any way.
> --- a/xen/include/xen/vm_event.h
> +++ b/xen/include/xen/vm_event.h
> @@ -96,6 +96,16 @@ void vm_event_vcpu_unpause(struct vcpu *v);
> int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
> vm_event_request_t *req);
>
> +#if CONFIG_X86
> +/*
> + * Called for the current vCPU on control-register changes by guest.
> + * The event might not fire if the client has subscribed to it in onchangeonly
> + * mode, hence the bool_t return type for control register write events.
> + */
> +bool_t vm_event_monitor_cr(unsigned int index, unsigned long value,
> + unsigned long old);
> +#endif
Same goes for the declaration here.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 1/7] minor (formatting) fixes
2016-06-16 14:06 ` [PATCH 1/7] minor (formatting) fixes Corneliu ZUZU
2016-06-16 14:24 ` Jan Beulich
@ 2016-06-16 16:02 ` Tamas K Lengyel
2016-06-17 8:33 ` Corneliu ZUZU
1 sibling, 1 reply; 73+ messages in thread
From: Tamas K Lengyel @ 2016-06-16 16:02 UTC (permalink / raw)
To: Corneliu ZUZU
Cc: Stefano Stabellini, Razvan Cojocaru, Andrew Cooper, Xen-devel,
Julien Grall, Jan Beulich
> diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
> index 014d9ba..05c3027 100644
> --- a/xen/include/asm-arm/vm_event.h
> +++ b/xen/include/asm-arm/vm_event.h
> @@ -23,21 +23,18 @@
> #include <xen/vm_event.h>
> #include <public/domctl.h>
>
> -static inline
> -int vm_event_init_domain(struct domain *d)
> +static inline int vm_event_init_domain(struct domain *d)
> {
> /* Nothing to do. */
> return 0;
> }
>
> -static inline
> -void vm_event_cleanup_domain(struct domain *d)
> +static inline void vm_event_cleanup_domain(struct domain *d)
> {
> memset(&d->monitor, 0, sizeof(d->monitor));
> }
>
> -static inline
> -void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
> +static inline void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
> {
> /* Not supported on ARM. */
> }
> @@ -59,6 +56,9 @@ static inline void vm_event_fill_regs(vm_event_request_t *req)
> /* Not supported on ARM. */
> }
>
> +/*
> + * Monitor vm-events.
> + */
I already have an acked patch that relocates monitor-related functions
from here and the x86 header to the monitor subsystem
(https://patchwork.kernel.org/patch/9139999/). Generally, I'm trying
to keep monitor-related stuff in the appropriately named files, so if
you encounter things like this in the future the best course of action
is to relocate them. vm_event should be use-case neutral by not having
specific things for the monitor subsystem and just be the i/o system
used for passing messages.
> static inline uint32_t vm_event_monitor_get_capabilities(struct domain *d)
> {
> uint32_t capabilities = 0;
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 2/7] vm-event: VM_EVENT_FLAG_DENY requires VM_EVENT_FLAG_VCPU_PAUSED
2016-06-16 14:07 ` [PATCH 2/7] vm-event: VM_EVENT_FLAG_DENY requires VM_EVENT_FLAG_VCPU_PAUSED Corneliu ZUZU
@ 2016-06-16 16:11 ` Tamas K Lengyel
2016-06-17 8:43 ` Corneliu ZUZU
2016-06-21 11:26 ` Corneliu ZUZU
0 siblings, 2 replies; 73+ messages in thread
From: Tamas K Lengyel @ 2016-06-16 16:11 UTC (permalink / raw)
To: Corneliu ZUZU; +Cc: Andrew Cooper, Jan Beulich, Razvan Cojocaru, Xen-devel
On Thu, Jun 16, 2016 at 8:07 AM, Corneliu ZUZU <czuzu@bitdefender.com> wrote:
> For VM_EVENT_FLAG_DENY to work, the vcpu must be paused (sync = 1) until the
> vm-event is handled. A vm-event response having VM_EVENT_FLAG_DENY flag set
> should also set the VM_EVENT_FLAG_VCPU_PAUSED flag. Enforce that in
> vm_event_register_write_resume().
Well, the problem with this is that the user can set the VCPU_PAUSED
flag any time it wants. It can happen that Xen hasn't paused the vCPU
but the user still sends that flag, in which case the unpause the flag
induces will not actually do anything. You should also check if the
vCPU is in fact paused rather then just relying on this flag.
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter
2016-06-16 14:08 ` [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter Corneliu ZUZU
2016-06-16 14:51 ` Jan Beulich
@ 2016-06-16 16:17 ` Tamas K Lengyel
2016-06-17 9:19 ` Corneliu ZUZU
2016-06-17 8:55 ` Julien Grall
2 siblings, 1 reply; 73+ messages in thread
From: Tamas K Lengyel @ 2016-06-16 16:17 UTC (permalink / raw)
To: Corneliu ZUZU
Cc: Kevin Tian, Stefano Stabellini, Jun Nakajima, Razvan Cojocaru,
George Dunlap, Andrew Cooper, Xen-devel, Julien Grall,
Paul Durrant, Jan Beulich
On Thu, Jun 16, 2016 at 8:08 AM, Corneliu ZUZU <czuzu@bitdefender.com> wrote:
> In an effort to improve on the vm-event interface, we introduce a new function
> called vm_event_vcpu_enter. Its significance is that of a "final touch" vCPU
> function - i.e. it should be called by implementing architectures just before
> re-entering vCPUs.
> On X86 for example, it is called on the scheduling tail (hvm_do_resume) and just
> before reentering the guest world after a hypervisor trap (vmx_vmenter_helper).
>
I don't think this belongs to the vm_event system. It should probably
be in the monitor subsystem as it has nothing to do with passing
messages, which is essentially what vm_event is for.
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 4/7] vm-event/x86: use vm_event_vcpu_enter properly
2016-06-16 14:09 ` [PATCH 4/7] vm-event/x86: use vm_event_vcpu_enter properly Corneliu ZUZU
2016-06-16 15:00 ` Jan Beulich
@ 2016-06-16 16:27 ` Tamas K Lengyel
2016-06-17 9:24 ` Corneliu ZUZU
1 sibling, 1 reply; 73+ messages in thread
From: Tamas K Lengyel @ 2016-06-16 16:27 UTC (permalink / raw)
To: Corneliu ZUZU
Cc: Kevin Tian, Jan Beulich, Razvan Cojocaru, Andrew Cooper,
Xen-devel, Jun Nakajima
> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
> index 1fec412..1e5445f 100644
> --- a/xen/arch/x86/monitor.c
> +++ b/xen/arch/x86/monitor.c
> @@ -20,7 +20,6 @@
> */
>
> #include <asm/monitor.h>
> -#include <public/vm_event.h>
>
> int arch_monitor_domctl_event(struct domain *d,
> struct xen_domctl_monitor_op *mop)
> @@ -62,14 +61,6 @@ int arch_monitor_domctl_event(struct domain *d,
> else
> ad->monitor.write_ctrlreg_enabled &= ~ctrlreg_bitmask;
>
> - if ( VM_EVENT_X86_CR3 == mop->u.mov_to_cr.index )
> - {
> - struct vcpu *v;
> - /* Latches new CR3 mask through CR0 code. */
> - for_each_vcpu ( d, v )
> - hvm_update_guest_cr(v, 0);
> - }
> -
So this block is not really getting relocated as the commit message
suggests as much as being completely reworked at a different location?
It would be better for it to be it's own separate patch as the changes
are not trivial.
> domain_unpause(d);
>
> break;
Thanks,
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-16 14:13 ` [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events Corneliu ZUZU
2016-06-16 14:26 ` Julien Grall
@ 2016-06-16 16:49 ` Julien Grall
2016-06-17 10:36 ` Corneliu ZUZU
1 sibling, 1 reply; 73+ messages in thread
From: Julien Grall @ 2016-06-16 16:49 UTC (permalink / raw)
To: Corneliu ZUZU, xen-devel
Cc: Stefano Stabellini, Tamas K Lengyel, Razvan Cojocaru
Hello Corneliu,
On 16/06/16 15:13, Corneliu ZUZU wrote:
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 8c50685..af61ac3 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -43,6 +43,7 @@
> #include <asm/mmio.h>
> #include <asm/cpufeature.h>
> #include <asm/flushtlb.h>
> +#include <asm/traps.h>
>
> #include "decode.h"
> #include "vtimer.h"
> @@ -124,7 +125,12 @@ void init_traps(void)
> WRITE_SYSREG((HCPTR_CP_MASK & ~(HCPTR_CP(10) | HCPTR_CP(11))) | HCPTR_TTA,
> CPTR_EL2);
>
> - /* Setup hypervisor traps */
> + /* Setup hypervisor traps
> + *
> + * Note: HCR_TVM bit is also set for system-register write monitoring
> + * purposes (see vm_event_monitor_cr), but (for performance reasons) that's
> + * done selectively (see vcpu_enter_adjust_traps).
> + */
> WRITE_SYSREG(HCR_PTW|HCR_BSU_INNER|HCR_AMO|HCR_IMO|HCR_FMO|HCR_VM|
> HCR_TWE|HCR_TWI|HCR_TSC|HCR_TAC|HCR_SWIO|HCR_TIDCP|HCR_FB,
> HCR_EL2);
> @@ -1720,6 +1726,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
> const struct hsr_cp32 cp32 = hsr.cp32;
> int regidx = cp32.reg;
> struct vcpu *v = current;
> + register_t r = get_user_reg(regs, regidx);
>
> if ( !check_conditional_instr(regs, hsr) )
> {
> @@ -1730,6 +1737,61 @@ static void do_cp15_32(struct cpu_user_regs *regs,
> switch ( hsr.bits & HSR_CP32_REGS_MASK )
> {
> /*
> + * HCR_EL2.TVM / HCR.TVM
> + *
> + * ARMv7 (DDI 0406C.b): B1.14.13
Please try to mention the most recent spec. This was published in 2012,
the latest release (C.c) was published in 2014.
> + * ARMv8 (DDI 0487A.e): D1-1569 Table D1-34
Ditto. This was published in 2014, whilst the most recent was published
in 2016.
> + */
> + case HSR_CPREG32(SCTLR):
> + TVM_EMUL_VMEVT(v, regs, hsr, r, SCTLR);
> + break;
> + case HSR_CPREG32(TTBR0_32):
> + TVM_EMUL_VMEVT(v, regs, hsr, r, TTBR0_32);
> + break;
> + case HSR_CPREG32(TTBR1_32):
> + TVM_EMUL_VMEVT(v, regs, hsr, r, TTBR1_32);
> + break;
> + case HSR_CPREG32(TTBCR):
> + TVM_EMUL_VMEVT(v, regs, hsr, r, TTBCR);
> + break;
> + case HSR_CPREG32(DACR):
> + TVM_EMUL(regs, hsr, r, DACR);
> + break;
> + case HSR_CPREG32(DFSR):
> + TVM_EMUL(regs, hsr, r, DFSR);
> + break;
> + case HSR_CPREG32(IFSR):
> + TVM_EMUL(regs, hsr, r, IFSR);
> + break;
> + case HSR_CPREG32(DFAR):
> + TVM_EMUL(regs, hsr, r, DFAR);
> + break;
> + case HSR_CPREG32(IFAR):
> + TVM_EMUL(regs, hsr, r, IFAR);
> + break;
[...]
> + case HSR_CPREG32(ADFSR):
> + TVM_EMUL(regs, hsr, r, ADFSR);
> + break;
> + case HSR_CPREG32(AIFSR):
> + TVM_EMUL(regs, hsr, r, AIFSR);
> + break;
> + case HSR_CPREG32(MAIR0):
> + TVM_EMUL(regs, hsr, r, MAIR0);
> + break;
> + case HSR_CPREG32(MAIR1):
> + TVM_EMUL(regs, hsr, r, MAIR1);
> + break;
Please mention that PRRR and NMRR are aliased to respectively MAIR0 and
MAIR1. This will avoid to spend time trying to understanding why the
spec says they are trapped but you don't "handle" them.
> + case HSR_CPREG32(AMAIR0):
> + TVM_EMUL(regs, hsr, r, AMAIR0);
> + break;
> + case HSR_CPREG32(AMAIR1):
> + TVM_EMUL(regs, hsr, r, AMAIR1);
> + break;
> + case HSR_CPREG32(CONTEXTIDR):
> + TVM_EMUL(regs, hsr, r, CONTEXTIDR);
> + break;
> +
> + /*
> * !CNTHCTL_EL2.EL1PCEN / !CNTHCTL.PL1PCEN
> *
> * ARMv7 (DDI 0406C.b): B4.1.22
> @@ -1853,6 +1915,13 @@ static void do_cp15_32(struct cpu_user_regs *regs,
> static void do_cp15_64(struct cpu_user_regs *regs,
> const union hsr hsr)
> {
> + struct vcpu *v = current;
> + const struct hsr_cp64 cp64 = hsr.cp64;
> + sysreg64_t r = {
> + .low32 = (uint32_t) get_user_reg(regs, cp64.reg1),
The cast is not necessary.
> + .high32 = (uint32_t) get_user_reg(regs, cp64.reg2)
Ditto.
> + };
> +
> if ( !check_conditional_instr(regs, hsr) )
> {
> advance_pc(regs, hsr);
> @@ -1862,6 +1931,19 @@ static void do_cp15_64(struct cpu_user_regs *regs,
> switch ( hsr.bits & HSR_CP64_REGS_MASK )
> {
> /*
> + * HCR_EL2.TVM / HCR.TVM
> + *
> + * ARMv7 (DDI 0406C.b): B1.14.13
> + * ARMv8 (DDI 0487A.e): D1-1569 Table D1-34
Same remarks as above for the spec version.
> + */
> + case HSR_CPREG64(TTBR0):
> + TVM_EMUL_VMEVT(v, regs, hsr, r.val64, TTBR0_64);
> + break;
> + case HSR_CPREG64(TTBR1):
> + TVM_EMUL_VMEVT(v, regs, hsr, r.val64, TTBR1_64);
> + break;
> +
> + /*
> * !CNTHCTL_EL2.EL1PCEN / !CNTHCTL.PL1PCEN
> *
> * ARMv7 (DDI 0406C.b): B4.1.22
> @@ -1891,8 +1973,6 @@ static void do_cp15_64(struct cpu_user_regs *regs,
> */
> default:
> {
> - const struct hsr_cp64 cp64 = hsr.cp64;
> -
> gdprintk(XENLOG_ERR,
> "%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
> cp64.read ? "mrrc" : "mcrr",
> @@ -2128,10 +2208,50 @@ static void do_sysreg(struct cpu_user_regs *regs,
> {
> int regidx = hsr.sysreg.reg;
> struct vcpu *v = current;
> + register_t r = get_user_reg(regs, regidx);
>
> switch ( hsr.bits & HSR_SYSREG_REGS_MASK )
> {
> /*
> + * HCR_EL2.TVM
> + *
> + * ARMv8 (DDI 0487A.e): D1-1569 Table D1-34
Ditto for the spec version.
[...]
> diff --git a/xen/arch/arm/vm_event.c b/xen/arch/arm/vm_event.c
> new file mode 100644
> index 0000000..3f23fec
> --- /dev/null
> +++ b/xen/arch/arm/vm_event.c
> @@ -0,0 +1,112 @@
[...]
> +#include <xen/vm_event.h>
> +#include <asm/traps.h>
> +
> +#if CONFIG_ARM_64
> +
> +#define MWSINF_SCTLR 32,SCTLR_EL1
> +#define MWSINF_TTBR0 64,TTBR0_EL1
> +#define MWSINF_TTBR1 64,TTBR1_EL1
> +#define MWSINF_TTBCR 64,TCR_EL1
> +
> +#elif CONFIG_ARM_32
> +
> +#define MWSINF_SCTLR 32,SCTLR
> +#define MWSINF_TTBR0 64,TTBR0
> +#define MWSINF_TTBR1 64,TTBR1
The values are the same as for arm64 (*_EL1 is aliased to * for arm32).
Please avoid duplication.
> +#define MWSINF_TTBR0_32 32,TTBR0_32
> +#define MWSINF_TTBR1_32 32,TTBR1_32
> +#define MWSINF_TTBCR 32,TTBCR
> +
> +#endif
> +
> +#define MWS_EMUL_(val, sz, r...) WRITE_SYSREG##sz((uint##sz##_t) (val), r)
The cast is not necessary.
> +#define MWS_EMUL(r) CALL_MACRO(MWS_EMUL_, w->value, MWSINF_##r)
> +
> +static inline void vcpu_enter_write_data(struct vcpu *v)
> +{
> + struct monitor_write_data *w = &v->arch.vm_event.write_data;
> +
> + if ( likely(MWS_NOWRITE == w->status) )
> + return;
> +
> + switch ( w->status )
> + {
> + case MWS_SCTLR:
> + MWS_EMUL(SCTLR);
> + break;
> + case MWS_TTBR0:
> + MWS_EMUL(TTBR0);
> + break;
> + case MWS_TTBR1:
> + MWS_EMUL(TTBR1);
> + break;
> +#if CONFIG_ARM_32
> + case MWS_TTBR0_32:
> + MWS_EMUL(TTBR0_32);
> + break;
> + case MWS_TTBR1_32:
> + MWS_EMUL(TTBR1_32);
> + break;
> +#endif
Aarch32 kernel can return on an AArch64 Xen. This means that
TTBR{0,1}_32 could be trapped and the write therefore be properly emulated.
> + case MWS_TTBCR:
> + MWS_EMUL(TTBCR);
> + break;
> + default:
> + break;
> + }
> +
> + w->status = MWS_NOWRITE;
> +}
> +
> +static inline void vcpu_enter_adjust_traps(struct vcpu *v)
> +{
> + register_t old_hcr, hcr;
> +
> + hcr = (old_hcr = READ_SYSREG(HCR_EL2));
> +
> + if ( unlikely(0 != v->domain->arch.monitor.write_ctrlreg_enabled) )
> + hcr |= HCR_TVM;
> + else
> + hcr &= ~HCR_TVM;
> +
> + if ( unlikely(hcr != old_hcr) )
> + {
> + WRITE_SYSREG(hcr, HCR_EL2);
> + isb();
> + }
The HCR register is also updated in p2m_restore_state to set HCR_EL2.RW.
I would prefer to have a single place where HCR is updated.
Maybe we should store the HCR value per-domain?
> +}
> +
> +void arch_vm_event_vcpu_enter(struct vcpu *v)
> +{
> + vcpu_enter_write_data(v);
> + vcpu_enter_adjust_traps(v);
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/common/monitor.c b/xen/common/monitor.c
> index 2366bae..c35a717 100644
> --- a/xen/common/monitor.c
> +++ b/xen/common/monitor.c
> @@ -62,7 +62,6 @@ int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
>
> switch ( mop->event )
> {
> -#if CONFIG_X86
> case XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG:
> {
> struct arch_domain *ad = &d->arch;
> @@ -100,7 +99,6 @@ int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
>
> break;
> }
> -#endif
>
> case XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST:
> {
> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> index 53dc048..e0f999e 100644
> --- a/xen/common/vm_event.c
> +++ b/xen/common/vm_event.c
> @@ -824,7 +824,6 @@ int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
> return 1;
> }
>
> -#if CONFIG_X86
> bool_t vm_event_monitor_cr(unsigned int index, unsigned long value,
> unsigned long old)
> {
> @@ -852,7 +851,6 @@ bool_t vm_event_monitor_cr(unsigned int index, unsigned long value,
>
> return 0;
> }
> -#endif
>
> void vm_event_monitor_guest_request(void)
> {
[...]
> diff --git a/xen/include/asm-arm/traps.h b/xen/include/asm-arm/traps.h
> new file mode 100644
> index 0000000..9e246a7
> --- /dev/null
> +++ b/xen/include/asm-arm/traps.h
This file is very difficult to review. Can you explain why you need to
duplicate most of the things between the AArch64 and AArch32 port?
Whilst I understand that some registers are accessible in a different
way between AArch64 and Aarch32, we were able to get rid of most of them
in the Xen port by aliasing registers (see asm-arm/cpregs.h).
From a quick look, I believe this is possible to do and would reduce a
lot the size/complexity of this file.
> @@ -0,0 +1,253 @@
[...]
> +/*
> + * Emulation of system-register trapped writes that do not cause
> + * VM_EVENT_REASON_WRITE_CTRLREG monitor vm-events.
> + * Such writes are collaterally trapped due to setting the HCR_EL2.TVM bit.
> + *
> + * Regarding aarch32 domains, note that from Xen's perspective system-registers
> + * of such domains are architecturally-mapped to aarch64 registers in one of
> + * three ways:
> + * - low 32-bits mapping (e.g. aarch32 DFAR -> aarch64 FAR_EL1[31:0])
> + * - high 32-bits mapping (e.g. aarch32 IFAR -> aarch64 FAR_EL1[63:32])
> + * - full mapping (e.g. aarch32 SCTLR -> aarch64 SCTLR_EL1)
> + *
> + * Hence we define 2 macro variants:
> + * - TVM_EMUL_SZ variant, for full mappings
> + * - TVM_EMUL_LH variant, for low/high 32-bits mappings
> + */
> +#define TVM_EMUL_SZ(regs, hsr, val, sz, r...) \
> +{ \
> + if ( psr_mode_is_user(regs) ) \
Those registers are not accessible at EL0.
> + return inject_undef_exception(regs, hsr); \
> + WRITE_SYSREG##sz((uint##sz##_t) (val), r);
[...]
> diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
> index 4e5a272..edf9654 100644
> --- a/xen/include/asm-arm/vm_event.h
> +++ b/xen/include/asm-arm/vm_event.h
> @@ -30,6 +30,12 @@ static inline int vm_event_init_domain(struct domain *d)
>
> static inline void vm_event_cleanup_domain(struct domain *d)
> {
> + struct vcpu *v;
> +
> + for_each_vcpu ( d, v )
> + memset(&v->arch.vm_event, 0, sizeof(v->arch.vm_event));
> +
> + memset(&d->arch.monitor, 0, sizeof(d->arch.monitor));
> memset(&d->monitor, 0, sizeof(d->monitor));
> }
>
> @@ -41,7 +47,13 @@ static inline void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
> static inline
> void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t *rsp)
> {
> - /* Not supported on ARM. */
> + /* X86 VM_EVENT_REASON_MOV_TO_MSR could (but shouldn't) end-up here too. */
This should be an ASSERT/BUG_ON then.
> + if ( unlikely(VM_EVENT_REASON_WRITE_CTRLREG != rsp->reason) )
> + return;
> +
> + if ( (rsp->flags & VM_EVENT_FLAG_DENY) &&
> + (rsp->flags & VM_EVENT_FLAG_VCPU_PAUSED) )
> + v->arch.vm_event.write_data.status = MWS_NOWRITE;
> }
>
> static inline
> @@ -55,10 +67,7 @@ static inline void vm_event_fill_regs(vm_event_request_t *req)
> /* Not supported on ARM. */
> }
>
> -static inline void arch_vm_event_vcpu_enter(struct vcpu *v)
> -{
> - /* Nothing to do. */
> -}
> +void arch_vm_event_vcpu_enter(struct vcpu *v);
>
> /*
> * Monitor vm-events.
> @@ -67,7 +76,8 @@ static inline uint32_t vm_event_monitor_get_capabilities(struct domain *d)
> {
> uint32_t capabilities = 0;
>
> - capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
> + capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
> + (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
>
> return capabilities;
> }
> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> index 8f94e20..ec3eaca 100644
> --- a/xen/include/public/vm_event.h
> +++ b/xen/include/public/vm_event.h
[...]
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr
2016-06-16 14:12 ` [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr Corneliu ZUZU
2016-06-16 15:16 ` Jan Beulich
@ 2016-06-16 16:55 ` Tamas K Lengyel
2016-06-17 10:37 ` Corneliu ZUZU
1 sibling, 1 reply; 73+ messages in thread
From: Tamas K Lengyel @ 2016-06-16 16:55 UTC (permalink / raw)
To: Corneliu ZUZU; +Cc: Andrew Cooper, Razvan Cojocaru, Jan Beulich, Xen-devel
On Thu, Jun 16, 2016 at 8:12 AM, Corneliu ZUZU <czuzu@bitdefender.com> wrote:
> Prepare for ARM implementation of control-register write vm-events by moving
> X86-specific hvm_event_cr to the common-side.
>
> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
> ---
> xen/arch/x86/hvm/event.c | 30 ------------------------------
> xen/arch/x86/hvm/hvm.c | 2 +-
> xen/arch/x86/monitor.c | 37 -------------------------------------
> xen/arch/x86/vm_event.c | 2 +-
> xen/common/monitor.c | 40 ++++++++++++++++++++++++++++++++++++++++
> xen/common/vm_event.c | 31 +++++++++++++++++++++++++++++++
> xen/include/asm-x86/hvm/event.h | 13 ++++---------
> xen/include/asm-x86/monitor.h | 2 --
> xen/include/xen/monitor.h | 4 ++++
> xen/include/xen/vm_event.h | 10 ++++++++++
> 10 files changed, 91 insertions(+), 80 deletions(-)
Some of the code-movement here touches code I cleaned up in
https://patchwork.kernel.org/patch/9151229 to keep vm_event and
monitor code separate as much as possible. The same separation should
be followed when we move code to common.
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 1/7] minor (formatting) fixes
2016-06-16 14:24 ` Jan Beulich
@ 2016-06-16 19:19 ` Corneliu ZUZU
2016-06-17 7:06 ` Jan Beulich
0 siblings, 1 reply; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-16 19:19 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Razvan Cojocaru, Andrew Cooper, xen-devel,
Julien Grall, Tamas K Lengyel
On 6/16/2016 5:24 PM, Jan Beulich wrote:
>>>> On 16.06.16 at 16:06, <czuzu@bitdefender.com> wrote:
>> --- a/xen/arch/x86/hvm/event.c
>> +++ b/xen/arch/x86/hvm/event.c
>> @@ -23,6 +23,7 @@
>>
>> #include <xen/vm_event.h>
>> #include <asm/hvm/event.h>
>> +#include <asm/paging.h>
>> #include <asm/monitor.h>
>> #include <asm/vm_event.h>
>> #include <public/vm_event.h>
>> diff --git a/xen/common/monitor.c b/xen/common/monitor.c
>> index d950a7c..b30857a 100644
>> --- a/xen/common/monitor.c
>> +++ b/xen/common/monitor.c
>> @@ -22,7 +22,6 @@
>> #include <xen/monitor.h>
>> #include <xen/sched.h>
>> #include <xsm/xsm.h>
>> -#include <public/domctl.h>
>> #include <asm/monitor.h>
>> #include <asm/vm_event.h>
> These two adjustments clearly don't fit title / description. I certainly
> don't mind unnecessary inclusions to be dropped, but the addition of
> one clearly needs explanation (after all thing build fine without it).
Sorry, that was done out of reflex, should have stated the reasoning.
Generally, if:
- event.c includes event.h
- event.c needs paging.h
- event.h -doesn't need- paging.h
then I prefer to include paging.h in event.c, not in event.h (include
strictly -where- needed).
Also since xen/paging.h included asm/paging.h and event.c only needs the
asm/paging.h part, I also changed xen/paging.h inclusion -> asm/paging.h
inclusion (include strictly -what's- needed).
But I can revert that if you want me to (not that important and these
little things are better done with automatic tools anyway), or should I
leave the change and update the commit message?
>> --- a/xen/include/asm-x86/vm_event.h
>> +++ b/xen/include/asm-x86/vm_event.h
>> @@ -44,6 +44,9 @@ void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp);
>>
>> void vm_event_fill_regs(vm_event_request_t *req);
>>
>> +/*
>> + * Monitor vm-events.
>> + */
> This is a single line comment (also elsewhere).
Ack.
>
>> --- a/xen/include/xen/vm_event.h
>> +++ b/xen/include/xen/vm_event.h
>> @@ -85,7 +85,6 @@ void vm_event_monitor_guest_request(void);
>>
>> #endif /* __VM_EVENT_H__ */
>>
>> -
>> /*
>> * Local variables:
>> * mode: C
> Why don't you remove the other stray blank line at once?
>
> Jan
What stray line? Shouldn't there be -one- blank line between the #endif
and the local vars block?
Looking @ other files that rule seems to hold...
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-16 14:26 ` Julien Grall
@ 2016-06-16 19:24 ` Corneliu ZUZU
2016-06-16 21:28 ` Julien Grall
0 siblings, 1 reply; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-16 19:24 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: Stefano Stabellini, Tamas K Lengyel, Razvan Cojocaru
On 6/16/2016 5:26 PM, Julien Grall wrote:
> Hello Corneliu,
>
> On 16/06/16 15:13, Corneliu ZUZU wrote:
>> Add ARM support for control-register write monitoring through the
>> vm-events
>> subsystem.
>>
>> Chosen ARM system control-registers that can be monitored are:
>> - VM_EVENT_ARM_SCTLR: AArch32 SCTLR, AArch64 SCTLR_EL1
>> - VM_EVENT_ARM_TTBR{0,1}: AArch32 TTBR{0,1}, AArch64 TTBR{0,1}_EL1
>> - VM_EVENT_ARM_TTBCR: AArch32 TTBCR, AArch64 TCR_EL1
>>
>> Trapping of write operations of these registers was attained by
>> setting the
>> HCR_EL2.TVM / HCR.TVM bit.
>>
>> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
>> ---
>> MAINTAINERS | 1 +
>> xen/arch/arm/Makefile | 1 +
>> xen/arch/arm/traps.c | 126 +++++++++++++++++++-
>> xen/arch/arm/vm_event.c | 112 ++++++++++++++++++
>> xen/common/monitor.c | 2 -
>> xen/common/vm_event.c | 2 -
>> xen/include/asm-arm/domain.h | 30 +++++
>> xen/include/asm-arm/traps.h | 253
>> +++++++++++++++++++++++++++++++++++++++++
>> xen/include/asm-arm/vm_event.h | 22 +++-
>> xen/include/public/vm_event.h | 8 +-
>> xen/include/xen/monitor.h | 2 -
>> xen/include/xen/vm_event.h | 2 -
>> 12 files changed, 543 insertions(+), 18 deletions(-)
>
> I think this patch would benefit to be split in multiple patches to
> ease the review and also describe the infrastructure you have
> introduced (TVM_* & co).
>
> I will review in detail later.
>
> Regards,
>
Hi Julien. Yes, I agree that it's complex, I would have preferred to
split it up too and I actually tried, but the changes are tightly
coupled and they don't seem to be 'split-able'.
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter
2016-06-16 14:51 ` Jan Beulich
@ 2016-06-16 20:10 ` Corneliu ZUZU
2016-06-16 20:33 ` Razvan Cojocaru
2016-06-17 7:17 ` Jan Beulich
0 siblings, 2 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-16 20:10 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Stefano Stabellini, Razvan Cojocaru, George Dunlap,
Andrew Cooper, xen-devel, Julien Grall, Paul Durrant,
Tamas K Lengyel, Jun Nakajima
On 6/16/2016 5:51 PM, Jan Beulich wrote:
>>>> On 16.06.16 at 16:08, <czuzu@bitdefender.com> wrote:
>> @@ -509,6 +508,8 @@ void hvm_do_resume(struct vcpu *v)
>> }
>> }
>>
>> + vm_event_vcpu_enter(v);
> Why here?
Why indeed. It made sense because monitor_write_data handling was
originally there and then the plan was to move it to vm_event_vcpu_enter
(which happens in the following commit).
The question is though, why was monitor_write_data handled there in the
first place? Why was it not put e.g. in vmx_do_resume immediately after
the call to hvm_do_resume and just before
the reset_stack_and_jump...? And what happens with handling
monitor_write_data if this:
if ( !handle_hvm_io_completion(v) )
return;
causes a return?
>> @@ -3874,6 +3875,9 @@ void vmx_vmenter_helper(const struct cpu_user_regs *regs)
>> }
>>
>> out:
>> + if ( guest_mode(regs) )
>> + vm_event_vcpu_enter(curr);
>> +
>> HVMTRACE_ND(VMENTRY, 0, 1/*cycles*/, 0, 0, 0, 0, 0, 0, 0);
>>
>> __vmwrite(GUEST_RIP, regs->rip);
> Why with a conditional? The registers can't possibly hold to non-
> guest state when you're here.
Right, I must've mistakenly taken that from ARM-side @ some point. There
it made sense, here it doesn't.
I'll remove it in V2.
>
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -36,7 +36,6 @@
>> #include <asm/hvm/nestedhvm.h>
>> #include <asm/altp2m.h>
>> #include <asm/hvm/svm/amd-iommu-proto.h>
>> -#include <asm/vm_event.h>
>> #include <xsm/xsm.h>
> There are way too many of these #include adjustments here. If
> you really mean to clean these up, please don't randomly throw
> this into various unrelated patches.
I haven't thrown anything "randomly into unrelated patches", please
first ask for my reasoning and then draw such conclusions.
That was removed because xen/vm_event.h includes asm/vm_event.h with
this patch (because it calls arch_vm_event_vcpu_enter) and this file
(p2m.c) already included xen/vm_event.h.
>> --- a/xen/common/monitor.c
>> +++ b/xen/common/monitor.c
>> @@ -22,8 +22,8 @@
>> #include <xen/monitor.h>
>> #include <xen/sched.h>
>> #include <xsm/xsm.h>
>> +#include <xen/vm_event.h>
>> #include <asm/monitor.h>
>> -#include <asm/vm_event.h>
> Please retain at least basic grouping (i.e. all xen/ ones together,
> meaning the insertion should move up by one line).
>
> Jan
>
>
I usually do that, in this case I just didn't notice. Acked.
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 4/7] vm-event/x86: use vm_event_vcpu_enter properly
2016-06-16 15:00 ` Jan Beulich
@ 2016-06-16 20:20 ` Corneliu ZUZU
2016-06-17 7:20 ` Jan Beulich
0 siblings, 1 reply; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-16 20:20 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Tamas K Lengyel, Razvan Cojocaru, Andrew Cooper,
xen-devel, Jun Nakajima
On 6/16/2016 6:00 PM, Jan Beulich wrote:
>>>> On 16.06.16 at 16:09, <czuzu@bitdefender.com> wrote:
>> @@ -2199,7 +2153,9 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
>>
>> if ( hvm_event_crX(CR0, value, old_value) )
>> {
>> - /* The actual write will occur in hvm_do_resume(), if permitted. */
>> + /* The actual write will occur in vcpu_enter_write_data(), if
>> + * permitted.
>> + */
> Coding style.
Ack.
>
>> @@ -1432,18 +1430,16 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned int cr)
>> if ( paging_mode_hap(v->domain) )
>> {
>> /* Manage GUEST_CR3 when CR0.PE=0. */
>> + uint32_t old_ctls = v->arch.hvm_vmx.exec_control;
>> uint32_t cr3_ctls = (CPU_BASED_CR3_LOAD_EXITING |
>> CPU_BASED_CR3_STORE_EXITING);
>> +
>> v->arch.hvm_vmx.exec_control &= ~cr3_ctls;
>> if ( !hvm_paging_enabled(v) && !vmx_unrestricted_guest(v) )
>> v->arch.hvm_vmx.exec_control |= cr3_ctls;
>>
>> - /* Trap CR3 updates if CR3 memory events are enabled. */
>> - if ( v->domain->arch.monitor.write_ctrlreg_enabled &
>> - monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
>> - v->arch.hvm_vmx.exec_control |= CPU_BASED_CR3_LOAD_EXITING;
>> -
>> - vmx_update_cpu_exec_control(v);
>> + if ( old_ctls != v->arch.hvm_vmx.exec_control )
>> + vmx_update_cpu_exec_control(v);
>> }
> How does this match up with the rest of this patch?
And by 'this' you mean slightly optimizing this sequence by adding in
old_ctls?
It seems pretty straight-forward to me, I figured if I am to move the
monitor.write_ctrlreg_enabled part from here
it wouldn't be much of a stretch to also do this little
optimization...what would have been appropriate?
To do this in a separate patch? To mention it in the commit message?
>
>> @@ -179,6 +182,105 @@ void vm_event_fill_regs(vm_event_request_t *req)
>> req->data.regs.x86.cs_arbytes = seg.attr.bytes;
>> }
>>
>> +static inline void vcpu_enter_write_data(struct vcpu *v)
> Please allow the compiler to decide whether to inline such larger
> functions.
Ack.
>> +void arch_vm_event_vcpu_enter(struct vcpu *v)
>> +{
>> + /* vmx only */
>> + ASSERT( cpu_has_vmx );
> Stray blanks.
>
> Jan
>
>
Ack.
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter
2016-06-16 20:10 ` Corneliu ZUZU
@ 2016-06-16 20:33 ` Razvan Cojocaru
2016-06-17 10:41 ` Corneliu ZUZU
2016-06-17 7:17 ` Jan Beulich
1 sibling, 1 reply; 73+ messages in thread
From: Razvan Cojocaru @ 2016-06-16 20:33 UTC (permalink / raw)
To: Corneliu ZUZU, Jan Beulich
Cc: Kevin Tian, Stefano Stabellini, George Dunlap, Andrew Cooper,
xen-devel, Julien Grall, Paul Durrant, Tamas K Lengyel,
Jun Nakajima
On 06/16/16 23:10, Corneliu ZUZU wrote:
> On 6/16/2016 5:51 PM, Jan Beulich wrote:
>>>>> On 16.06.16 at 16:08, <czuzu@bitdefender.com> wrote:
>>> @@ -509,6 +508,8 @@ void hvm_do_resume(struct vcpu *v)
>>> }
>>> }
>>> + vm_event_vcpu_enter(v);
>> Why here?
> Why indeed. It made sense because monitor_write_data handling was
> originally there and then the plan was to move it to vm_event_vcpu_enter
> (which happens in the following commit).
> The question is though, why was monitor_write_data handled there in the
> first place? Why was it not put e.g. in vmx_do_resume immediately after
> the call to hvm_do_resume and just before
> the reset_stack_and_jump...? And what happens with handling
> monitor_write_data if this:
>
> if ( !handle_hvm_io_completion(v) )
> return;
>
> causes a return?
It's in hvm_do_resume() because, for one, that's the place that was
suggested (or at least confirmed when I've proposed it for such things)
on this list back when I wrote the code. And then it's here because
vmx_do_things()-type functions are, well, VMX, and I had hoped that by
choosing hvm-prefixed functions I'd get SVM support for free.
As for the handle_hvm_io_completion(v) return, my understanding was that
that would eventually cause another exit, and eventually we'd get to the
code below once the IO part is done.
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-16 19:24 ` Corneliu ZUZU
@ 2016-06-16 21:28 ` Julien Grall
2016-06-17 11:46 ` Corneliu ZUZU
0 siblings, 1 reply; 73+ messages in thread
From: Julien Grall @ 2016-06-16 21:28 UTC (permalink / raw)
To: Corneliu ZUZU, Julien Grall, xen-devel
Cc: Stefano Stabellini, Tamas K Lengyel, Razvan Cojocaru
On 16/06/2016 20:24, Corneliu ZUZU wrote:
> On 6/16/2016 5:26 PM, Julien Grall wrote:
> Hi Julien. Yes, I agree that it's complex, I would have preferred to
> split it up too and I actually tried, but the changes are tightly
> coupled and they don't seem to be 'split-able'.
After I reviewed this patch I think it could be simplified a lot.
Most of the registers not trapped by vm-event could be emulated with
one-line WRITE_SYSREGxx and does not require specific case depending on
the architecture.
You can give a look how we handle the domain context switch in C
(arch/arm/domain.c).
Only few of the registers will require more than one-line (such as
MAIR*, *FAR) which could be over a macro.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 1/7] minor (formatting) fixes
2016-06-16 19:19 ` Corneliu ZUZU
@ 2016-06-17 7:06 ` Jan Beulich
2016-06-17 10:46 ` Corneliu ZUZU
0 siblings, 1 reply; 73+ messages in thread
From: Jan Beulich @ 2016-06-17 7:06 UTC (permalink / raw)
To: Corneliu ZUZU
Cc: Stefano Stabellini, Razvan Cojocaru, Andrew Cooper, xen-devel,
Julien Grall, Tamas K Lengyel
>>> On 16.06.16 at 21:19, <czuzu@bitdefender.com> wrote:
> On 6/16/2016 5:24 PM, Jan Beulich wrote:
>>>>> On 16.06.16 at 16:06, <czuzu@bitdefender.com> wrote:
>>> --- a/xen/arch/x86/hvm/event.c
>>> +++ b/xen/arch/x86/hvm/event.c
>>> @@ -23,6 +23,7 @@
>>>
>>> #include <xen/vm_event.h>
>>> #include <asm/hvm/event.h>
>>> +#include <asm/paging.h>
>>> #include <asm/monitor.h>
>>> #include <asm/vm_event.h>
>>> #include <public/vm_event.h>
>>> diff --git a/xen/common/monitor.c b/xen/common/monitor.c
>>> index d950a7c..b30857a 100644
>>> --- a/xen/common/monitor.c
>>> +++ b/xen/common/monitor.c
>>> @@ -22,7 +22,6 @@
>>> #include <xen/monitor.h>
>>> #include <xen/sched.h>
>>> #include <xsm/xsm.h>
>>> -#include <public/domctl.h>
>>> #include <asm/monitor.h>
>>> #include <asm/vm_event.h>
>> These two adjustments clearly don't fit title / description. I certainly
>> don't mind unnecessary inclusions to be dropped, but the addition of
>> one clearly needs explanation (after all thing build fine without it).
>
> Sorry, that was done out of reflex, should have stated the reasoning.
> Generally, if:
> - event.c includes event.h
> - event.c needs paging.h
> - event.h -doesn't need- paging.h
> then I prefer to include paging.h in event.c, not in event.h (include
> strictly -where- needed).
> Also since xen/paging.h included asm/paging.h and event.c only needs the
> asm/paging.h part, I also changed xen/paging.h inclusion -> asm/paging.h
> inclusion (include strictly -what's- needed).
> But I can revert that if you want me to (not that important and these
> little things are better done with automatic tools anyway), or should I
> leave the change and update the commit message?
Well, I'd leave the ultimate decision to the maintainers, but I'd say
this doesn't belong in a patch dealing with formatting issues. I.e.
I'm fine with the cleanup, but either under a different title (and
with at least an abbreviated version of what you said above), or
in a separate patch. Considering that you appear to do the same
in later patches, perhaps consolidating all the #include adjustments
into one patch would a good idea?
>>> --- a/xen/include/xen/vm_event.h
>>> +++ b/xen/include/xen/vm_event.h
>>> @@ -85,7 +85,6 @@ void vm_event_monitor_guest_request(void);
>>>
>>> #endif /* __VM_EVENT_H__ */
>>>
>>> -
>>> /*
>>> * Local variables:
>>> * mode: C
>> Why don't you remove the other stray blank line at once?
>
> What stray line? Shouldn't there be -one- blank line between the #endif
> and the local vars block?
> Looking @ other files that rule seems to hold...
Oh, you're right. I thought I had frequently seen it the other way
around (and it would seem more logical to me), but I must have been
misremembering.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter
2016-06-16 20:10 ` Corneliu ZUZU
2016-06-16 20:33 ` Razvan Cojocaru
@ 2016-06-17 7:17 ` Jan Beulich
2016-06-17 11:13 ` Corneliu ZUZU
1 sibling, 1 reply; 73+ messages in thread
From: Jan Beulich @ 2016-06-17 7:17 UTC (permalink / raw)
To: Corneliu ZUZU
Cc: Kevin Tian, Stefano Stabellini, Razvan Cojocaru, George Dunlap,
Andrew Cooper, xen-devel, Julien Grall, Paul Durrant,
Tamas K Lengyel, Jun Nakajima
>>> On 16.06.16 at 22:10, <czuzu@bitdefender.com> wrote:
> On 6/16/2016 5:51 PM, Jan Beulich wrote:
>>>>> On 16.06.16 at 16:08, <czuzu@bitdefender.com> wrote:
>>> @@ -509,6 +508,8 @@ void hvm_do_resume(struct vcpu *v)
>>> }
>>> }
>>>
>>> + vm_event_vcpu_enter(v);
>> Why here?
> Why indeed. It made sense because monitor_write_data handling was
> originally there and then the plan was to move it to vm_event_vcpu_enter
> (which happens in the following commit).
> The question is though, why was monitor_write_data handled there in the
> first place? Why was it not put e.g. in vmx_do_resume immediately after
> the call to hvm_do_resume and just before
> the reset_stack_and_jump...? And what happens with handling
> monitor_write_data if this:
>
> if ( !handle_hvm_io_completion(v) )
> return;
>
> causes a return?
I see Razvan responded to this. I don't have a strong opinion
either way, my only request if for the call to be in exactly one
place.
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -36,7 +36,6 @@
>>> #include <asm/hvm/nestedhvm.h>
>>> #include <asm/altp2m.h>
>>> #include <asm/hvm/svm/amd-iommu-proto.h>
>>> -#include <asm/vm_event.h>
>>> #include <xsm/xsm.h>
>> There are way too many of these #include adjustments here. If
>> you really mean to clean these up, please don't randomly throw
>> this into various unrelated patches.
>
> I haven't thrown anything "randomly into unrelated patches", please
> first ask for my reasoning and then draw such conclusions.
See patch 1. Plus I don't think I (or in fact any reviewer) should ask
for such reasoning: Instead you should state extra cleanup you do
to unrelated (to the purpose of your patch) files in the description.
Or even better, split it off to a follow-on, purely cleanup patch.
(And to be clear, I much appreciate any form of reduction of the
sometimes extremely long lists of #include-s, just not [apparently
or really] randomly mixed with other, substantial changes. That's
namely because it's not clear whether source files should explicitly
include everything they need, or instead be allowed to rely on
headers they include to include further headers they also
_explicitly_ rely on. IOW there's likely a discussion to be had for
this kind of cleanup, and such a discussion should be a separate
thread from the one on the functional adjustments here.)
Jan
> That was removed because xen/vm_event.h includes asm/vm_event.h with
> this patch (because it calls arch_vm_event_vcpu_enter) and this file
> (p2m.c) already included xen/vm_event.h.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 4/7] vm-event/x86: use vm_event_vcpu_enter properly
2016-06-16 20:20 ` Corneliu ZUZU
@ 2016-06-17 7:20 ` Jan Beulich
2016-06-17 11:23 ` Corneliu ZUZU
0 siblings, 1 reply; 73+ messages in thread
From: Jan Beulich @ 2016-06-17 7:20 UTC (permalink / raw)
To: Corneliu ZUZU
Cc: Kevin Tian, Tamas K Lengyel, Razvan Cojocaru, Andrew Cooper,
xen-devel, Jun Nakajima
>>> On 16.06.16 at 22:20, <czuzu@bitdefender.com> wrote:
> On 6/16/2016 6:00 PM, Jan Beulich wrote:
>>>>> On 16.06.16 at 16:09, <czuzu@bitdefender.com> wrote:
>>> @@ -1432,18 +1430,16 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned int cr)
>>> if ( paging_mode_hap(v->domain) )
>>> {
>>> /* Manage GUEST_CR3 when CR0.PE=0. */
>>> + uint32_t old_ctls = v->arch.hvm_vmx.exec_control;
>>> uint32_t cr3_ctls = (CPU_BASED_CR3_LOAD_EXITING |
>>> CPU_BASED_CR3_STORE_EXITING);
>>> +
>>> v->arch.hvm_vmx.exec_control &= ~cr3_ctls;
>>> if ( !hvm_paging_enabled(v) && !vmx_unrestricted_guest(v) )
>>> v->arch.hvm_vmx.exec_control |= cr3_ctls;
>>>
>>> - /* Trap CR3 updates if CR3 memory events are enabled. */
>>> - if ( v->domain->arch.monitor.write_ctrlreg_enabled &
>>> - monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
>>> - v->arch.hvm_vmx.exec_control |= CPU_BASED_CR3_LOAD_EXITING;
>>> -
>>> - vmx_update_cpu_exec_control(v);
>>> + if ( old_ctls != v->arch.hvm_vmx.exec_control )
>>> + vmx_update_cpu_exec_control(v);
>>> }
>> How does this match up with the rest of this patch?
>
> And by 'this' you mean slightly optimizing this sequence by adding in
> old_ctls?
> It seems pretty straight-forward to me, I figured if I am to move the
> monitor.write_ctrlreg_enabled part from here
> it wouldn't be much of a stretch to also do this little
> optimization...what would have been appropriate?
> To do this in a separate patch? To mention it in the commit message?
At least the latter, and perhaps better the former. Without even
mentioning it the readers (reviewers) have to guess whether this
is an integral part of the change, or - as you now confirm - just a
minor optimization done along the road.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr
2016-06-16 15:16 ` Jan Beulich
@ 2016-06-17 8:25 ` Corneliu ZUZU
2016-06-17 8:38 ` Jan Beulich
2016-06-21 7:08 ` Corneliu ZUZU
0 siblings, 2 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-17 8:25 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, Tamas K Lengyel, Razvan Cojocaru, xen-devel
On 6/16/2016 6:16 PM, Jan Beulich wrote:
>>>> On 16.06.16 at 16:12, <czuzu@bitdefender.com> wrote:
>> Prepare for ARM implementation of control-register write vm-events by moving
>> X86-specific hvm_event_cr to the common-side.
>>
>> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
>> ---
>> xen/arch/x86/hvm/event.c | 30 ------------------------------
>> xen/arch/x86/hvm/hvm.c | 2 +-
>> xen/arch/x86/monitor.c | 37 -------------------------------------
>> xen/arch/x86/vm_event.c | 2 +-
>> xen/common/monitor.c | 40 ++++++++++++++++++++++++++++++++++++++++
>> xen/common/vm_event.c | 31 +++++++++++++++++++++++++++++++
>> xen/include/asm-x86/hvm/event.h | 13 ++++---------
>> xen/include/asm-x86/monitor.h | 2 --
>> xen/include/xen/monitor.h | 4 ++++
>> xen/include/xen/vm_event.h | 10 ++++++++++
>> 10 files changed, 91 insertions(+), 80 deletions(-)
> Considering that there's no ARM file getting altered here at all,
> mentioning ARM in the subject is a little odd.
This patch and the following one should be meld together.
I only split them to ease reviewing, sorry I forgot to mention that in
the cover letter.
>
>> --- a/xen/common/monitor.c
>> +++ b/xen/common/monitor.c
>> @@ -62,6 +62,46 @@ int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
>>
>> switch ( mop->event )
>> {
>> +#if CONFIG_X86
> #ifdef please.
Ack.
>> + case XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG:
>> + {
>> + struct arch_domain *ad = &d->arch;
> Peeking into the next patch I see that this stays there. Common code,
> however, shouldn't access ->arch sub-structures - respective fields
> should be moved out.
Then we need to find a resolution that avoids code duplication.
The code is the same, but those bits that are currently on the arch side
(arch.monitor.write_ctrlreg_*) cannot be moved to common as they are,
since their -number- might differ from arch-to-arch.
But we could:
- in public/vm_event.h, besides the VM_EVENT_X86_* and VM_EVENT_ARM_*
defines (wcr index), also have
#define VM_EVENT_X86_CR_COUNT 4
#define VM_EVENT_ARM_CR_COUNT 4
- move the 3 write_ctrlreg_{enabled,sync,onchangeonly} fields from
arch_domain to domain (common) and make them 8-bits wide each for now
(widened more in the future if the need arises)
- let monitor_ctrlreg_bitmask() macro to be architecture-dependent and
use the introduced VM_EVENT_<arch>_CR_COUNT
Tamas, we also talked on this matter @ some point (when I sent the
patches that moved vm-event parts to common). What do you think of the
above?
>
> And looking at all the uses of this variable I get the impression that
> you really want a shorthand for &d->arch.monitor (if any such
> helper variable is worthwhile to have here in the first place).
Well, this was a simple cut-paste operation, not very old content aware :)
Personally I prefer the current shorthand (ad) (seems more intuitive and
is consistent with the other XEN_DOMCTL_MONITOR_EVENT_* cases), but if
you prefer I'll change that shorthand to am = &d->arch.monitor?
>> --- a/xen/include/asm-x86/monitor.h
>> +++ b/xen/include/asm-x86/monitor.h
>> @@ -24,8 +24,6 @@
>>
>> #include <xen/sched.h>
>>
>> -#define monitor_ctrlreg_bitmask(ctrlreg_index) (1U << (ctrlreg_index))
>> -
>> static inline
>> int arch_monitor_domctl_op(struct domain *d, struct xen_domctl_monitor_op *mop)
>> {
>> --- a/xen/include/xen/monitor.h
>> +++ b/xen/include/xen/monitor.h
>> @@ -25,6 +25,10 @@
>> struct domain;
>> struct xen_domctl_monitor_op;
>>
>> +#if CONFIG_X86
>> +#define monitor_ctrlreg_bitmask(ctrlreg_index) (1U << (ctrlreg_index))
>> +#endif
> What's the point in removing this from the x86 header if then it
> needs to be put in such a conditional? If the conditional gets
> dropped in the next patch, then I think you have two options:
> Leave it where it is here, and move it there. Or move it here,
> but omit the conditional right away - I can't see this definition
> being present to harm the ARM build in any way.
Meld comment above.
>
>> --- a/xen/include/xen/vm_event.h
>> +++ b/xen/include/xen/vm_event.h
>> @@ -96,6 +96,16 @@ void vm_event_vcpu_unpause(struct vcpu *v);
>> int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
>> vm_event_request_t *req);
>>
>> +#if CONFIG_X86
>> +/*
>> + * Called for the current vCPU on control-register changes by guest.
>> + * The event might not fire if the client has subscribed to it in onchangeonly
>> + * mode, hence the bool_t return type for control register write events.
>> + */
>> +bool_t vm_event_monitor_cr(unsigned int index, unsigned long value,
>> + unsigned long old);
>> +#endif
> Same goes for the declaration here.
>
> Jan
>
>
Meld comment above.
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 1/7] minor (formatting) fixes
2016-06-16 16:02 ` Tamas K Lengyel
@ 2016-06-17 8:33 ` Corneliu ZUZU
2016-06-17 8:36 ` Razvan Cojocaru
0 siblings, 1 reply; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-17 8:33 UTC (permalink / raw)
To: Tamas K Lengyel
Cc: Stefano Stabellini, Razvan Cojocaru, Andrew Cooper, Xen-devel,
Julien Grall, Jan Beulich
On 6/16/2016 7:02 PM, Tamas K Lengyel wrote:
>> diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
>> index 014d9ba..05c3027 100644
>> --- a/xen/include/asm-arm/vm_event.h
>> +++ b/xen/include/asm-arm/vm_event.h
>> @@ -23,21 +23,18 @@
>> #include <xen/vm_event.h>
>> #include <public/domctl.h>
>>
>> -static inline
>> -int vm_event_init_domain(struct domain *d)
>> +static inline int vm_event_init_domain(struct domain *d)
>> {
>> /* Nothing to do. */
>> return 0;
>> }
>>
>> -static inline
>> -void vm_event_cleanup_domain(struct domain *d)
>> +static inline void vm_event_cleanup_domain(struct domain *d)
>> {
>> memset(&d->monitor, 0, sizeof(d->monitor));
>> }
>>
>> -static inline
>> -void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
>> +static inline void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
>> {
>> /* Not supported on ARM. */
>> }
>> @@ -59,6 +56,9 @@ static inline void vm_event_fill_regs(vm_event_request_t *req)
>> /* Not supported on ARM. */
>> }
>>
>> +/*
>> + * Monitor vm-events.
>> + */
> I already have an acked patch that relocates monitor-related functions
> from here and the x86 header to the monitor subsystem
> (https://patchwork.kernel.org/patch/9139999/). Generally, I'm trying
> to keep monitor-related stuff in the appropriately named files, so if
> you encounter things like this in the future the best course of action
> is to relocate them. vm_event should be use-case neutral by not having
> specific things for the monitor subsystem and just be the i/o system
> used for passing messages.
>
>> static inline uint32_t vm_event_monitor_get_capabilities(struct domain *d)
>> {
>> uint32_t capabilities = 0;
Ah, ok. Didn't that patch make it to staging yet? I pulled the latest.
Since you already have a patch for that I guess it's ok to remove those
comments and leave the rest as it is and merge later when one of these
patches makes it to staging?
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 1/7] minor (formatting) fixes
2016-06-17 8:33 ` Corneliu ZUZU
@ 2016-06-17 8:36 ` Razvan Cojocaru
2016-06-17 9:29 ` Andrew Cooper
2016-06-17 9:33 ` Jan Beulich
0 siblings, 2 replies; 73+ messages in thread
From: Razvan Cojocaru @ 2016-06-17 8:36 UTC (permalink / raw)
To: Corneliu ZUZU, Tamas K Lengyel
Cc: Andrew Cooper, Julien Grall, Stefano Stabellini, Jan Beulich, Xen-devel
On 06/17/2016 11:33 AM, Corneliu ZUZU wrote:
> On 6/16/2016 7:02 PM, Tamas K Lengyel wrote:
>>> diff --git a/xen/include/asm-arm/vm_event.h
>>> b/xen/include/asm-arm/vm_event.h
>>> index 014d9ba..05c3027 100644
>>> --- a/xen/include/asm-arm/vm_event.h
>>> +++ b/xen/include/asm-arm/vm_event.h
>>> @@ -23,21 +23,18 @@
>>> #include <xen/vm_event.h>
>>> #include <public/domctl.h>
>>>
>>> -static inline
>>> -int vm_event_init_domain(struct domain *d)
>>> +static inline int vm_event_init_domain(struct domain *d)
>>> {
>>> /* Nothing to do. */
>>> return 0;
>>> }
>>>
>>> -static inline
>>> -void vm_event_cleanup_domain(struct domain *d)
>>> +static inline void vm_event_cleanup_domain(struct domain *d)
>>> {
>>> memset(&d->monitor, 0, sizeof(d->monitor));
>>> }
>>>
>>> -static inline
>>> -void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
>>> +static inline void vm_event_toggle_singlestep(struct domain *d,
>>> struct vcpu *v)
>>> {
>>> /* Not supported on ARM. */
>>> }
>>> @@ -59,6 +56,9 @@ static inline void
>>> vm_event_fill_regs(vm_event_request_t *req)
>>> /* Not supported on ARM. */
>>> }
>>>
>>> +/*
>>> + * Monitor vm-events.
>>> + */
>> I already have an acked patch that relocates monitor-related functions
>> from here and the x86 header to the monitor subsystem
>> (https://patchwork.kernel.org/patch/9139999/). Generally, I'm trying
>> to keep monitor-related stuff in the appropriately named files, so if
>> you encounter things like this in the future the best course of action
>> is to relocate them. vm_event should be use-case neutral by not having
>> specific things for the monitor subsystem and just be the i/o system
>> used for passing messages.
>>
>>> static inline uint32_t vm_event_monitor_get_capabilities(struct
>>> domain *d)
>>> {
>>> uint32_t capabilities = 0;
>
> Ah, ok. Didn't that patch make it to staging yet? I pulled the latest.
> Since you already have a patch for that I guess it's ok to remove those
> comments and leave the rest as it is and merge later when one of these
> patches makes it to staging?
I think there's a delay caused by the 4.7 release. I also have an acked
patch waiting to go in that might cause you to have to rebase (part of)
the series: https://patchwork.kernel.org/patch/9033771/
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr
2016-06-17 8:25 ` Corneliu ZUZU
@ 2016-06-17 8:38 ` Jan Beulich
2016-06-17 11:31 ` Corneliu ZUZU
2016-06-21 7:08 ` Corneliu ZUZU
1 sibling, 1 reply; 73+ messages in thread
From: Jan Beulich @ 2016-06-17 8:38 UTC (permalink / raw)
To: Corneliu ZUZU; +Cc: Andrew Cooper, Tamas K Lengyel, Razvan Cojocaru, xen-devel
>>> On 17.06.16 at 10:25, <czuzu@bitdefender.com> wrote:
> On 6/16/2016 6:16 PM, Jan Beulich wrote:
>> And looking at all the uses of this variable I get the impression that
>> you really want a shorthand for &d->arch.monitor (if any such
>> helper variable is worthwhile to have here in the first place).
>
> Well, this was a simple cut-paste operation, not very old content aware :)
> Personally I prefer the current shorthand (ad) (seems more intuitive and
> is consistent with the other XEN_DOMCTL_MONITOR_EVENT_* cases), but if
> you prefer I'll change that shorthand to am = &d->arch.monitor?
I'd prefer either no shorthand, or one eliminating the longest common
prefix across all uses.
>>> --- a/xen/include/asm-x86/monitor.h
>>> +++ b/xen/include/asm-x86/monitor.h
>>> @@ -24,8 +24,6 @@
>>>
>>> #include <xen/sched.h>
>>>
>>> -#define monitor_ctrlreg_bitmask(ctrlreg_index) (1U << (ctrlreg_index))
>>> -
>>> static inline
>>> int arch_monitor_domctl_op(struct domain *d, struct xen_domctl_monitor_op *mop)
>>> {
>>> --- a/xen/include/xen/monitor.h
>>> +++ b/xen/include/xen/monitor.h
>>> @@ -25,6 +25,10 @@
>>> struct domain;
>>> struct xen_domctl_monitor_op;
>>>
>>> +#if CONFIG_X86
>>> +#define monitor_ctrlreg_bitmask(ctrlreg_index) (1U << (ctrlreg_index))
>>> +#endif
>> What's the point in removing this from the x86 header if then it
>> needs to be put in such a conditional? If the conditional gets
>> dropped in the next patch, then I think you have two options:
>> Leave it where it is here, and move it there. Or move it here,
>> but omit the conditional right away - I can't see this definition
>> being present to harm the ARM build in any way.
>
> Meld comment above.
I don't follow - having split the patches for reviewability was
a good idea. I merely commented on some oddities resulting
from that split, which - afaict - could be easily corrected without
folding the patches together.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 2/7] vm-event: VM_EVENT_FLAG_DENY requires VM_EVENT_FLAG_VCPU_PAUSED
2016-06-16 16:11 ` Tamas K Lengyel
@ 2016-06-17 8:43 ` Corneliu ZUZU
2016-06-21 11:26 ` Corneliu ZUZU
1 sibling, 0 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-17 8:43 UTC (permalink / raw)
To: Tamas K Lengyel; +Cc: Andrew Cooper, Jan Beulich, Razvan Cojocaru, Xen-devel
On 6/16/2016 7:11 PM, Tamas K Lengyel wrote:
> On Thu, Jun 16, 2016 at 8:07 AM, Corneliu ZUZU <czuzu@bitdefender.com> wrote:
>> For VM_EVENT_FLAG_DENY to work, the vcpu must be paused (sync = 1) until the
>> vm-event is handled. A vm-event response having VM_EVENT_FLAG_DENY flag set
>> should also set the VM_EVENT_FLAG_VCPU_PAUSED flag. Enforce that in
>> vm_event_register_write_resume().
> Well, the problem with this is that the user can set the VCPU_PAUSED
> flag any time it wants. It can happen that Xen hasn't paused the vCPU
> but the user still sends that flag, in which case the unpause the flag
> induces will not actually do anything. You should also check if the
> vCPU is in fact paused rather then just relying on this flag.
>
> Tamas
>
Right, I actually meant to take a second look over that.
I see a situation like that was taken into account in
vm_event_vcpu_unpause (comment "prevent underflow of the vcpu pause count.")
How can I check for vcpu pause here?
Thanks,
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter
2016-06-16 14:08 ` [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter Corneliu ZUZU
2016-06-16 14:51 ` Jan Beulich
2016-06-16 16:17 ` Tamas K Lengyel
@ 2016-06-17 8:55 ` Julien Grall
2016-06-17 11:40 ` Corneliu ZUZU
2 siblings, 1 reply; 73+ messages in thread
From: Julien Grall @ 2016-06-17 8:55 UTC (permalink / raw)
To: Corneliu ZUZU, xen-devel
Cc: Kevin Tian, Stefano Stabellini, Jan Beulich, Razvan Cojocaru,
George Dunlap, Andrew Cooper, Paul Durrant, Tamas K Lengyel,
Jun Nakajima
Hello,
On 16/06/16 15:08, Corneliu ZUZU wrote:
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index d31f821..ba248c8 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -19,6 +19,7 @@
> #include <xen/errno.h>
> #include <xen/bitops.h>
> #include <xen/grant_table.h>
> +#include <xen/vm_event.h>
>
> #include <asm/current.h>
> #include <asm/event.h>
> @@ -251,6 +252,8 @@ static void schedule_tail(struct vcpu *prev)
>
> ctxt_switch_to(current);
>
> + vm_event_vcpu_enter(current);
> +
> local_irq_enable();
>
> context_saved(prev);
> @@ -296,7 +299,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
>
> void continue_running(struct vcpu *same)
> {
> - /* Nothing to do */
> + vm_event_vcpu_enter(same);
> }
>
> void sync_local_execstate(void)
From my understanding of the commit message, vm_event_vcpu_enter should
be called before returning to the guest. The scheduling functions are
not called every-time Xen is returning to the guest. So if you want to
do every time Xen is re-entering to the guest, then this should be done
in leave_hypervisor_tail.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter
2016-06-16 16:17 ` Tamas K Lengyel
@ 2016-06-17 9:19 ` Corneliu ZUZU
0 siblings, 0 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-17 9:19 UTC (permalink / raw)
To: Tamas K Lengyel
Cc: Kevin Tian, Stefano Stabellini, Jun Nakajima, Razvan Cojocaru,
George Dunlap, Andrew Cooper, Xen-devel, Julien Grall,
Paul Durrant, Jan Beulich
On 6/16/2016 7:17 PM, Tamas K Lengyel wrote:
> On Thu, Jun 16, 2016 at 8:08 AM, Corneliu ZUZU <czuzu@bitdefender.com> wrote:
>> In an effort to improve on the vm-event interface, we introduce a new function
>> called vm_event_vcpu_enter. Its significance is that of a "final touch" vCPU
>> function - i.e. it should be called by implementing architectures just before
>> re-entering vCPUs.
>> On X86 for example, it is called on the scheduling tail (hvm_do_resume) and just
>> before reentering the guest world after a hypervisor trap (vmx_vmenter_helper).
>>
> I don't think this belongs to the vm_event system. It should probably
> be in the monitor subsystem as it has nothing to do with passing
> messages, which is essentially what vm_event is for.
>
> Tamas
>
I figured it's usage is Xen-internal and it's meant to be of eventual
use - whenever the need arises to do something just before a vCPU is
reentered from the vm-event subsystem, you can simply adjust the
implementation of that function.
I thought non-monitor vm-events could also be 'eventual users'. But then
again by this reasoning I could broaden its significance even more,
outside the vm-event world and make it 'usable' by any parts of code in Xen.
Shall I then rename it to vm_event_monitor_vcpu_enter and put it
alongside the other vm_event_monitor_* functions?
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 4/7] vm-event/x86: use vm_event_vcpu_enter properly
2016-06-16 16:27 ` Tamas K Lengyel
@ 2016-06-17 9:24 ` Corneliu ZUZU
0 siblings, 0 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-17 9:24 UTC (permalink / raw)
To: Tamas K Lengyel
Cc: Kevin Tian, Jan Beulich, Razvan Cojocaru, Andrew Cooper,
Xen-devel, Jun Nakajima
On 6/16/2016 7:27 PM, Tamas K Lengyel wrote:
>> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
>> index 1fec412..1e5445f 100644
>> --- a/xen/arch/x86/monitor.c
>> +++ b/xen/arch/x86/monitor.c
>> @@ -20,7 +20,6 @@
>> */
>>
>> #include <asm/monitor.h>
>> -#include <public/vm_event.h>
>>
>> int arch_monitor_domctl_event(struct domain *d,
>> struct xen_domctl_monitor_op *mop)
>> @@ -62,14 +61,6 @@ int arch_monitor_domctl_event(struct domain *d,
>> else
>> ad->monitor.write_ctrlreg_enabled &= ~ctrlreg_bitmask;
>>
>> - if ( VM_EVENT_X86_CR3 == mop->u.mov_to_cr.index )
>> - {
>> - struct vcpu *v;
>> - /* Latches new CR3 mask through CR0 code. */
>> - for_each_vcpu ( d, v )
>> - hvm_update_guest_cr(v, 0);
>> - }
>> -
> So this block is not really getting relocated as the commit message
> suggests as much as being completely reworked at a different location?
> It would be better for it to be it's own separate patch as the changes
> are not trivial.
That's actually not reworked, it's completely removed since there's no
need for it anymore.
That is: "latching of CR3 mask" is not done "through CR0" anymore but
rather through the vm_event_vcpu_enter function instead and you don't
have to do anything more here in arch_monitor_domctl_event for that to
happen.
>> domain_unpause(d);
>>
>> break;
> Thanks,
> Tamas
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 1/7] minor (formatting) fixes
2016-06-17 8:36 ` Razvan Cojocaru
@ 2016-06-17 9:29 ` Andrew Cooper
2016-06-17 9:35 ` Jan Beulich
2016-06-17 9:33 ` Jan Beulich
1 sibling, 1 reply; 73+ messages in thread
From: Andrew Cooper @ 2016-06-17 9:29 UTC (permalink / raw)
To: Razvan Cojocaru, Corneliu ZUZU, Tamas K Lengyel
Cc: Julien Grall, Stefano Stabellini, Jan Beulich, Xen-devel
On 17/06/16 09:36, Razvan Cojocaru wrote:
> On 06/17/2016 11:33 AM, Corneliu ZUZU wrote:
>> On 6/16/2016 7:02 PM, Tamas K Lengyel wrote:
>>>> diff --git a/xen/include/asm-arm/vm_event.h
>>>> b/xen/include/asm-arm/vm_event.h
>>>> index 014d9ba..05c3027 100644
>>>> --- a/xen/include/asm-arm/vm_event.h
>>>> +++ b/xen/include/asm-arm/vm_event.h
>>>> @@ -23,21 +23,18 @@
>>>> #include <xen/vm_event.h>
>>>> #include <public/domctl.h>
>>>>
>>>> -static inline
>>>> -int vm_event_init_domain(struct domain *d)
>>>> +static inline int vm_event_init_domain(struct domain *d)
>>>> {
>>>> /* Nothing to do. */
>>>> return 0;
>>>> }
>>>>
>>>> -static inline
>>>> -void vm_event_cleanup_domain(struct domain *d)
>>>> +static inline void vm_event_cleanup_domain(struct domain *d)
>>>> {
>>>> memset(&d->monitor, 0, sizeof(d->monitor));
>>>> }
>>>>
>>>> -static inline
>>>> -void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
>>>> +static inline void vm_event_toggle_singlestep(struct domain *d,
>>>> struct vcpu *v)
>>>> {
>>>> /* Not supported on ARM. */
>>>> }
>>>> @@ -59,6 +56,9 @@ static inline void
>>>> vm_event_fill_regs(vm_event_request_t *req)
>>>> /* Not supported on ARM. */
>>>> }
>>>>
>>>> +/*
>>>> + * Monitor vm-events.
>>>> + */
>>> I already have an acked patch that relocates monitor-related functions
>>> from here and the x86 header to the monitor subsystem
>>> (https://patchwork.kernel.org/patch/9139999/). Generally, I'm trying
>>> to keep monitor-related stuff in the appropriately named files, so if
>>> you encounter things like this in the future the best course of action
>>> is to relocate them. vm_event should be use-case neutral by not having
>>> specific things for the monitor subsystem and just be the i/o system
>>> used for passing messages.
>>>
>>>> static inline uint32_t vm_event_monitor_get_capabilities(struct
>>>> domain *d)
>>>> {
>>>> uint32_t capabilities = 0;
>> Ah, ok. Didn't that patch make it to staging yet? I pulled the latest.
>> Since you already have a patch for that I guess it's ok to remove those
>> comments and leave the rest as it is and merge later when one of these
>> patches makes it to staging?
> I think there's a delay caused by the 4.7 release. I also have an acked
> patch waiting to go in that might cause you to have to rebase (part of)
> the series: https://patchwork.kernel.org/patch/9033771/
Staging is now open for Xen 4.8 submissions.
Would it be possible for previous submissions to be resent, or a summary
email pointing at the intended versions of the patches? I will see
about getting stuff in.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 1/7] minor (formatting) fixes
2016-06-17 8:36 ` Razvan Cojocaru
2016-06-17 9:29 ` Andrew Cooper
@ 2016-06-17 9:33 ` Jan Beulich
2016-06-17 9:36 ` Razvan Cojocaru
2016-06-17 19:05 ` Tamas K Lengyel
1 sibling, 2 replies; 73+ messages in thread
From: Jan Beulich @ 2016-06-17 9:33 UTC (permalink / raw)
To: Razvan Cojocaru
Cc: Stefano Stabellini, Andrew Cooper, Xen-devel, Julien Grall,
Tamas K Lengyel, Corneliu ZUZU
>>> On 17.06.16 at 10:36, <rcojocaru@bitdefender.com> wrote:
> On 06/17/2016 11:33 AM, Corneliu ZUZU wrote:
>> Ah, ok. Didn't that patch make it to staging yet? I pulled the latest.
>> Since you already have a patch for that I guess it's ok to remove those
>> comments and leave the rest as it is and merge later when one of these
>> patches makes it to staging?
>
> I think there's a delay caused by the 4.7 release. I also have an acked
> patch waiting to go in that might cause you to have to rebase (part of)
> the series: https://patchwork.kernel.org/patch/9033771/
Well, there's a slight difference here: Yours is indeed delayed until
4.7 is set in stone, for being more intrusive. Tamas'es, otoh, I would
probably have put in already if it had all necessary acks (or they
had at least been pinged for, at which point we could waive the need
for some trivial adjustments).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 1/7] minor (formatting) fixes
2016-06-17 9:29 ` Andrew Cooper
@ 2016-06-17 9:35 ` Jan Beulich
0 siblings, 0 replies; 73+ messages in thread
From: Jan Beulich @ 2016-06-17 9:35 UTC (permalink / raw)
To: Andrew Cooper
Cc: Stefano Stabellini, Razvan Cojocaru, Xen-devel, Julien Grall,
Tamas K Lengyel, Corneliu ZUZU
>>> On 17.06.16 at 11:29, <andrew.cooper3@citrix.com> wrote:
> Staging is now open for Xen 4.8 submissions.
Just to clarify - not fully. Intrusive changes (with a higher risk of
causing backporting conflicts for eventual changes still wanting to
go into 4.7) were agreed to not get put in yet.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 1/7] minor (formatting) fixes
2016-06-17 9:33 ` Jan Beulich
@ 2016-06-17 9:36 ` Razvan Cojocaru
2016-06-17 9:40 ` Jan Beulich
2016-06-17 19:05 ` Tamas K Lengyel
1 sibling, 1 reply; 73+ messages in thread
From: Razvan Cojocaru @ 2016-06-17 9:36 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Andrew Cooper, Xen-devel, Julien Grall,
Tamas K Lengyel, Corneliu ZUZU
On 06/17/2016 12:33 PM, Jan Beulich wrote:
>>>> On 17.06.16 at 10:36, <rcojocaru@bitdefender.com> wrote:
>> On 06/17/2016 11:33 AM, Corneliu ZUZU wrote:
>>> Ah, ok. Didn't that patch make it to staging yet? I pulled the latest.
>>> Since you already have a patch for that I guess it's ok to remove those
>>> comments and leave the rest as it is and merge later when one of these
>>> patches makes it to staging?
>>
>> I think there's a delay caused by the 4.7 release. I also have an acked
>> patch waiting to go in that might cause you to have to rebase (part of)
>> the series: https://patchwork.kernel.org/patch/9033771/
>
> Well, there's a slight difference here: Yours is indeed delayed until
> 4.7 is set in stone, for being more intrusive. Tamas'es, otoh, I would
> probably have put in already if it had all necessary acks (or they
> had at least been pinged for, at which point we could waive the need
> for some trivial adjustments).
Right, so should I resend as Andrew has requested, or just wait?
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 1/7] minor (formatting) fixes
2016-06-17 9:36 ` Razvan Cojocaru
@ 2016-06-17 9:40 ` Jan Beulich
2016-06-17 9:42 ` Razvan Cojocaru
0 siblings, 1 reply; 73+ messages in thread
From: Jan Beulich @ 2016-06-17 9:40 UTC (permalink / raw)
To: Razvan Cojocaru
Cc: Stefano Stabellini, Andrew Cooper, Xen-devel, Julien Grall,
Tamas K Lengyel, Corneliu ZUZU
>>> On 17.06.16 at 11:36, <rcojocaru@bitdefender.com> wrote:
> On 06/17/2016 12:33 PM, Jan Beulich wrote:
>>>>> On 17.06.16 at 10:36, <rcojocaru@bitdefender.com> wrote:
>>> On 06/17/2016 11:33 AM, Corneliu ZUZU wrote:
>>>> Ah, ok. Didn't that patch make it to staging yet? I pulled the latest.
>>>> Since you already have a patch for that I guess it's ok to remove those
>>>> comments and leave the rest as it is and merge later when one of these
>>>> patches makes it to staging?
>>>
>>> I think there's a delay caused by the 4.7 release. I also have an acked
>>> patch waiting to go in that might cause you to have to rebase (part of)
>>> the series: https://patchwork.kernel.org/patch/9033771/
>>
>> Well, there's a slight difference here: Yours is indeed delayed until
>> 4.7 is set in stone, for being more intrusive. Tamas'es, otoh, I would
>> probably have put in already if it had all necessary acks (or they
>> had at least been pinged for, at which point we could waive the need
>> for some trivial adjustments).
>
> Right, so should I resend as Andrew has requested, or just wait?
I have the patch queued, so unless it needs rebasing I don't see a
strict need for resending.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 1/7] minor (formatting) fixes
2016-06-17 9:40 ` Jan Beulich
@ 2016-06-17 9:42 ` Razvan Cojocaru
0 siblings, 0 replies; 73+ messages in thread
From: Razvan Cojocaru @ 2016-06-17 9:42 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Andrew Cooper, Xen-devel, Julien Grall,
Tamas K Lengyel, Corneliu ZUZU
On 06/17/2016 12:40 PM, Jan Beulich wrote:
>>>> On 17.06.16 at 11:36, <rcojocaru@bitdefender.com> wrote:
>> On 06/17/2016 12:33 PM, Jan Beulich wrote:
>>>>>> On 17.06.16 at 10:36, <rcojocaru@bitdefender.com> wrote:
>>>> On 06/17/2016 11:33 AM, Corneliu ZUZU wrote:
>>>>> Ah, ok. Didn't that patch make it to staging yet? I pulled the latest.
>>>>> Since you already have a patch for that I guess it's ok to remove those
>>>>> comments and leave the rest as it is and merge later when one of these
>>>>> patches makes it to staging?
>>>>
>>>> I think there's a delay caused by the 4.7 release. I also have an acked
>>>> patch waiting to go in that might cause you to have to rebase (part of)
>>>> the series: https://patchwork.kernel.org/patch/9033771/
>>>
>>> Well, there's a slight difference here: Yours is indeed delayed until
>>> 4.7 is set in stone, for being more intrusive. Tamas'es, otoh, I would
>>> probably have put in already if it had all necessary acks (or they
>>> had at least been pinged for, at which point we could waive the need
>>> for some trivial adjustments).
>>
>> Right, so should I resend as Andrew has requested, or just wait?
>
> I have the patch queued, so unless it needs rebasing I don't see a
> strict need for resending.
Checking just now, it doesn't seem to need rebasing.
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-16 16:49 ` Julien Grall
@ 2016-06-17 10:36 ` Corneliu ZUZU
2016-06-17 13:18 ` Julien Grall
2016-06-22 16:35 ` Corneliu ZUZU
0 siblings, 2 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-17 10:36 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: Stefano Stabellini, Tamas K Lengyel, Razvan Cojocaru
On 6/16/2016 7:49 PM, Julien Grall wrote:
> Hello Corneliu,
>
> On 16/06/16 15:13, Corneliu ZUZU wrote:
>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>> index 8c50685..af61ac3 100644
>> --- a/xen/arch/arm/traps.c
>> +++ b/xen/arch/arm/traps.c
>> @@ -43,6 +43,7 @@
>> #include <asm/mmio.h>
>> #include <asm/cpufeature.h>
>> #include <asm/flushtlb.h>
>> +#include <asm/traps.h>
>>
>> #include "decode.h"
>> #include "vtimer.h"
>> @@ -124,7 +125,12 @@ void init_traps(void)
>> WRITE_SYSREG((HCPTR_CP_MASK & ~(HCPTR_CP(10) | HCPTR_CP(11))) |
>> HCPTR_TTA,
>> CPTR_EL2);
>>
>> - /* Setup hypervisor traps */
>> + /* Setup hypervisor traps
>> + *
>> + * Note: HCR_TVM bit is also set for system-register write
>> monitoring
>> + * purposes (see vm_event_monitor_cr), but (for performance
>> reasons) that's
>> + * done selectively (see vcpu_enter_adjust_traps).
>> + */
>> WRITE_SYSREG(HCR_PTW|HCR_BSU_INNER|HCR_AMO|HCR_IMO|HCR_FMO|HCR_VM|
>> HCR_TWE|HCR_TWI|HCR_TSC|HCR_TAC|HCR_SWIO|HCR_TIDCP|HCR_FB,
>> HCR_EL2);
>> @@ -1720,6 +1726,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
>> const struct hsr_cp32 cp32 = hsr.cp32;
>> int regidx = cp32.reg;
>> struct vcpu *v = current;
>> + register_t r = get_user_reg(regs, regidx);
>>
>> if ( !check_conditional_instr(regs, hsr) )
>> {
>> @@ -1730,6 +1737,61 @@ static void do_cp15_32(struct cpu_user_regs
>> *regs,
>> switch ( hsr.bits & HSR_CP32_REGS_MASK )
>> {
>> /*
>> + * HCR_EL2.TVM / HCR.TVM
>> + *
>> + * ARMv7 (DDI 0406C.b): B1.14.13
>
> Please try to mention the most recent spec. This was published in
> 2012, the latest release (C.c) was published in 2014.
Ack.
>
>> + * ARMv8 (DDI 0487A.e): D1-1569 Table D1-34
>
> Ditto. This was published in 2014, whilst the most recent was
> published in 2016.
>
>> + */
>> + case HSR_CPREG32(SCTLR):
>> + TVM_EMUL_VMEVT(v, regs, hsr, r, SCTLR);
>> + break;
>> + case HSR_CPREG32(TTBR0_32):
>> + TVM_EMUL_VMEVT(v, regs, hsr, r, TTBR0_32);
>> + break;
>> + case HSR_CPREG32(TTBR1_32):
>> + TVM_EMUL_VMEVT(v, regs, hsr, r, TTBR1_32);
>> + break;
>> + case HSR_CPREG32(TTBCR):
>> + TVM_EMUL_VMEVT(v, regs, hsr, r, TTBCR);
>> + break;
>> + case HSR_CPREG32(DACR):
>> + TVM_EMUL(regs, hsr, r, DACR);
>> + break;
>> + case HSR_CPREG32(DFSR):
>> + TVM_EMUL(regs, hsr, r, DFSR);
>> + break;
>> + case HSR_CPREG32(IFSR):
>> + TVM_EMUL(regs, hsr, r, IFSR);
>> + break;
>> + case HSR_CPREG32(DFAR):
>> + TVM_EMUL(regs, hsr, r, DFAR);
>> + break;
>> + case HSR_CPREG32(IFAR):
>> + TVM_EMUL(regs, hsr, r, IFAR);
>> + break;
> [...]
>> + case HSR_CPREG32(ADFSR):
>> + TVM_EMUL(regs, hsr, r, ADFSR);
>> + break;
>> + case HSR_CPREG32(AIFSR):
>> + TVM_EMUL(regs, hsr, r, AIFSR);
>> + break;
>> + case HSR_CPREG32(MAIR0):
>> + TVM_EMUL(regs, hsr, r, MAIR0);
>> + break;
>> + case HSR_CPREG32(MAIR1):
>> + TVM_EMUL(regs, hsr, r, MAIR1);
>> + break;
>
> Please mention that PRRR and NMRR are aliased to respectively MAIR0
> and MAIR1. This will avoid to spend time trying to understanding why
> the spec says they are trapped but you don't "handle" them.
I mentioned that in traps.h (see "AKA" comments). Will put the same
comment here then.
>
>> + case HSR_CPREG32(AMAIR0):
>> + TVM_EMUL(regs, hsr, r, AMAIR0);
>> + break;
>> + case HSR_CPREG32(AMAIR1):
>> + TVM_EMUL(regs, hsr, r, AMAIR1);
>> + break;
>> + case HSR_CPREG32(CONTEXTIDR):
>> + TVM_EMUL(regs, hsr, r, CONTEXTIDR);
>> + break;
>> +
>> + /*
>> * !CNTHCTL_EL2.EL1PCEN / !CNTHCTL.PL1PCEN
>> *
>> * ARMv7 (DDI 0406C.b): B4.1.22
>> @@ -1853,6 +1915,13 @@ static void do_cp15_32(struct cpu_user_regs
>> *regs,
>> static void do_cp15_64(struct cpu_user_regs *regs,
>> const union hsr hsr)
>> {
>> + struct vcpu *v = current;
>> + const struct hsr_cp64 cp64 = hsr.cp64;
>> + sysreg64_t r = {
>> + .low32 = (uint32_t) get_user_reg(regs, cp64.reg1),
>
> The cast is not necessary.
Ack.
>
>> + .high32 = (uint32_t) get_user_reg(regs, cp64.reg2)
>
> Ditto.
>
>> + };
>> +
>> if ( !check_conditional_instr(regs, hsr) )
>> {
>> advance_pc(regs, hsr);
>> @@ -1862,6 +1931,19 @@ static void do_cp15_64(struct cpu_user_regs
>> *regs,
>> switch ( hsr.bits & HSR_CP64_REGS_MASK )
>> {
>> /*
>> + * HCR_EL2.TVM / HCR.TVM
>> + *
>> + * ARMv7 (DDI 0406C.b): B1.14.13
>> + * ARMv8 (DDI 0487A.e): D1-1569 Table D1-34
>
> Same remarks as above for the spec version.
>
>> + */
>> + case HSR_CPREG64(TTBR0):
>> + TVM_EMUL_VMEVT(v, regs, hsr, r.val64, TTBR0_64);
>> + break;
>> + case HSR_CPREG64(TTBR1):
>> + TVM_EMUL_VMEVT(v, regs, hsr, r.val64, TTBR1_64);
>> + break;
>> +
>> + /*
>> * !CNTHCTL_EL2.EL1PCEN / !CNTHCTL.PL1PCEN
>> *
>> * ARMv7 (DDI 0406C.b): B4.1.22
>> @@ -1891,8 +1973,6 @@ static void do_cp15_64(struct cpu_user_regs *regs,
>> */
>> default:
>> {
>> - const struct hsr_cp64 cp64 = hsr.cp64;
>> -
>> gdprintk(XENLOG_ERR,
>> "%s p15, %d, r%d, r%d, cr%d @
>> 0x%"PRIregister"\n",
>> cp64.read ? "mrrc" : "mcrr",
>> @@ -2128,10 +2208,50 @@ static void do_sysreg(struct cpu_user_regs
>> *regs,
>> {
>> int regidx = hsr.sysreg.reg;
>> struct vcpu *v = current;
>> + register_t r = get_user_reg(regs, regidx);
>>
>> switch ( hsr.bits & HSR_SYSREG_REGS_MASK )
>> {
>> /*
>> + * HCR_EL2.TVM
>> + *
>> + * ARMv8 (DDI 0487A.e): D1-1569 Table D1-34
>
> Ditto for the spec version.
>
> [...]
>
>> diff --git a/xen/arch/arm/vm_event.c b/xen/arch/arm/vm_event.c
>> new file mode 100644
>> index 0000000..3f23fec
>> --- /dev/null
>> +++ b/xen/arch/arm/vm_event.c
>> @@ -0,0 +1,112 @@
>
> [...]
>
>> +#include <xen/vm_event.h>
>> +#include <asm/traps.h>
>> +
>> +#if CONFIG_ARM_64
>> +
>> +#define MWSINF_SCTLR 32,SCTLR_EL1
>> +#define MWSINF_TTBR0 64,TTBR0_EL1
>> +#define MWSINF_TTBR1 64,TTBR1_EL1
>> +#define MWSINF_TTBCR 64,TCR_EL1
>> +
>> +#elif CONFIG_ARM_32
>> +
>> +#define MWSINF_SCTLR 32,SCTLR
>> +#define MWSINF_TTBR0 64,TTBR0
>> +#define MWSINF_TTBR1 64,TTBR1
>
> The values are the same as for arm64 (*_EL1 is aliased to * for
> arm32). Please avoid duplication.
(see comment below about later reply)
>
>> +#define MWSINF_TTBR0_32 32,TTBR0_32
>> +#define MWSINF_TTBR1_32 32,TTBR1_32
>> +#define MWSINF_TTBCR 32,TTBCR
>> +
>> +#endif
>> +
>> +#define MWS_EMUL_(val, sz, r...) WRITE_SYSREG##sz((uint##sz##_t)
>> (val), r)
>
> The cast is not necessary.
>
>> +#define MWS_EMUL(r) CALL_MACRO(MWS_EMUL_, w->value, MWSINF_##r)
>> +
>> +static inline void vcpu_enter_write_data(struct vcpu *v)
>> +{
>> + struct monitor_write_data *w = &v->arch.vm_event.write_data;
>> +
>> + if ( likely(MWS_NOWRITE == w->status) )
>> + return;
>> +
>> + switch ( w->status )
>> + {
>> + case MWS_SCTLR:
>> + MWS_EMUL(SCTLR);
>> + break;
>> + case MWS_TTBR0:
>> + MWS_EMUL(TTBR0);
>> + break;
>> + case MWS_TTBR1:
>> + MWS_EMUL(TTBR1);
>> + break;
>> +#if CONFIG_ARM_32
>> + case MWS_TTBR0_32:
>> + MWS_EMUL(TTBR0_32);
>> + break;
>> + case MWS_TTBR1_32:
>> + MWS_EMUL(TTBR1_32);
>> + break;
>> +#endif
>
> Aarch32 kernel can return on an AArch64 Xen. This means that
> TTBR{0,1}_32 could be trapped and the write therefore be properly
> emulated.
MCR TTBRx writes from AArch32 guests appear as writes of the low 32-bits
of AArch64 TTBRx_EL1 (architecturally mapped).
MCRR TTBRx writes from AArch32 guests appear as writes to AArch64 TTBRx_EL1.
Therefore, in the end the register we need to write is still TTBRx_EL1.
>
>> + case MWS_TTBCR:
>> + MWS_EMUL(TTBCR);
>> + break;
>> + default:
>> + break;
>> + }
>> +
>> + w->status = MWS_NOWRITE;
>> +}
>> +
>> +static inline void vcpu_enter_adjust_traps(struct vcpu *v)
>> +{
>> + register_t old_hcr, hcr;
>> +
>> + hcr = (old_hcr = READ_SYSREG(HCR_EL2));
>> +
>> + if ( unlikely(0 != v->domain->arch.monitor.write_ctrlreg_enabled) )
>> + hcr |= HCR_TVM;
>> + else
>> + hcr &= ~HCR_TVM;
>> +
>> + if ( unlikely(hcr != old_hcr) )
>> + {
>> + WRITE_SYSREG(hcr, HCR_EL2);
>> + isb();
>> + }
>
> The HCR register is also updated in p2m_restore_state to set
> HCR_EL2.RW. I would prefer to have a single place where HCR is updated.
>
> Maybe we should store the HCR value per-domain?
Yes, that would be nice. Will look into that for v2.
>
>> +}
>> +
>> +void arch_vm_event_vcpu_enter(struct vcpu *v)
>> +{
>> + vcpu_enter_write_data(v);
>> + vcpu_enter_adjust_traps(v);
>> +}
>> +
>> +/*
>> + * Local variables:
>> + * mode: C
>> + * c-file-style: "BSD"
>> + * c-basic-offset: 4
>> + * indent-tabs-mode: nil
>> + * End:
>> + */
>> diff --git a/xen/common/monitor.c b/xen/common/monitor.c
>> index 2366bae..c35a717 100644
>> --- a/xen/common/monitor.c
>> +++ b/xen/common/monitor.c
>> @@ -62,7 +62,6 @@ int monitor_domctl(struct domain *d, struct
>> xen_domctl_monitor_op *mop)
>>
>> switch ( mop->event )
>> {
>> -#if CONFIG_X86
>> case XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG:
>> {
>> struct arch_domain *ad = &d->arch;
>> @@ -100,7 +99,6 @@ int monitor_domctl(struct domain *d, struct
>> xen_domctl_monitor_op *mop)
>>
>> break;
>> }
>> -#endif
>>
>> case XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST:
>> {
>> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
>> index 53dc048..e0f999e 100644
>> --- a/xen/common/vm_event.c
>> +++ b/xen/common/vm_event.c
>> @@ -824,7 +824,6 @@ int vm_event_monitor_traps(struct vcpu *v,
>> uint8_t sync,
>> return 1;
>> }
>>
>> -#if CONFIG_X86
>> bool_t vm_event_monitor_cr(unsigned int index, unsigned long value,
>> unsigned long old)
>> {
>> @@ -852,7 +851,6 @@ bool_t vm_event_monitor_cr(unsigned int index,
>> unsigned long value,
>>
>> return 0;
>> }
>> -#endif
>>
>> void vm_event_monitor_guest_request(void)
>> {
>
> [...]
>
>> diff --git a/xen/include/asm-arm/traps.h b/xen/include/asm-arm/traps.h
>> new file mode 100644
>> index 0000000..9e246a7
>> --- /dev/null
>> +++ b/xen/include/asm-arm/traps.h
>
> This file is very difficult to review. Can you explain why you need to
> duplicate most of the things between the AArch64 and AArch32 port?
>
> Whilst I understand that some registers are accessible in a different
> way between AArch64 and Aarch32, we were able to get rid of most of
> them in the Xen port by aliasing registers (see asm-arm/cpregs.h).
>
> From a quick look, I believe this is possible to do and would reduce a
> lot the size/complexity of this file.
I realize all this looks complex, heck I've spent about 3-4 working days
trying to find an acceptable macros combination that looks readable,
useful (shortens code) and also works.
Since the cover letter isn't the right place to include such detailed
explanations, I will come back with a reply detailing this patch alone,
I just need some time to reinspect it since I've done this work a few
months ago (went in sick leave).
>
>> @@ -0,0 +1,253 @@
>
> [...]
>
>> +/*
>> + * Emulation of system-register trapped writes that do not cause
>> + * VM_EVENT_REASON_WRITE_CTRLREG monitor vm-events.
>> + * Such writes are collaterally trapped due to setting the
>> HCR_EL2.TVM bit.
>> + *
>> + * Regarding aarch32 domains, note that from Xen's perspective
>> system-registers
>> + * of such domains are architecturally-mapped to aarch64 registers
>> in one of
>> + * three ways:
>> + * - low 32-bits mapping (e.g. aarch32 DFAR -> aarch64
>> FAR_EL1[31:0])
>> + * - high 32-bits mapping (e.g. aarch32 IFAR -> aarch64
>> FAR_EL1[63:32])
>> + * - full mapping (e.g. aarch32 SCTLR -> aarch64 SCTLR_EL1)
>> + *
>> + * Hence we define 2 macro variants:
>> + * - TVM_EMUL_SZ variant, for full mappings
>> + * - TVM_EMUL_LH variant, for low/high 32-bits mappings
>> + */
>> +#define TVM_EMUL_SZ(regs, hsr, val, sz,
>> r...) \
>> +{ \
>> + if ( psr_mode_is_user(regs)
>> ) \
>
> Those registers are not accessible at EL0.
Hmm, I have this question noted.
I remember finding from the manuals that a write from user-mode of those
regs would still trap to EL2, but I didn't test that yet.
Will put that to test and come back with results for v2.
>
>> + return inject_undef_exception(regs,
>> hsr); \
>> + WRITE_SYSREG##sz((uint##sz##_t) (val), r);
>
> [...]
>
>> diff --git a/xen/include/asm-arm/vm_event.h
>> b/xen/include/asm-arm/vm_event.h
>> index 4e5a272..edf9654 100644
>> --- a/xen/include/asm-arm/vm_event.h
>> +++ b/xen/include/asm-arm/vm_event.h
>> @@ -30,6 +30,12 @@ static inline int vm_event_init_domain(struct
>> domain *d)
>>
>> static inline void vm_event_cleanup_domain(struct domain *d)
>> {
>> + struct vcpu *v;
>> +
>> + for_each_vcpu ( d, v )
>> + memset(&v->arch.vm_event, 0, sizeof(v->arch.vm_event));
>> +
>> + memset(&d->arch.monitor, 0, sizeof(d->arch.monitor));
>> memset(&d->monitor, 0, sizeof(d->monitor));
>> }
>>
>> @@ -41,7 +47,13 @@ static inline void
>> vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
>> static inline
>> void vm_event_register_write_resume(struct vcpu *v,
>> vm_event_response_t *rsp)
>> {
>> - /* Not supported on ARM. */
>> + /* X86 VM_EVENT_REASON_MOV_TO_MSR could (but shouldn't) end-up
>> here too. */
>
> This should be an ASSERT/BUG_ON then.
We can't ASSERT/BUG_ON here because rsp->reason is controlled by the
toolstack user.
This has to do with the implementation of vm_event_resume.
What I think we should do instead is to surround "case
VM_EVENT_REASON_MOV_TO_MSR" there with #ifdef CONFIG_X86.
Would that be suitable?
>
>> + if ( unlikely(VM_EVENT_REASON_WRITE_CTRLREG != rsp->reason) )
>> + return;
>> +
>> + if ( (rsp->flags & VM_EVENT_FLAG_DENY) &&
>> + (rsp->flags & VM_EVENT_FLAG_VCPU_PAUSED) )
>> + v->arch.vm_event.write_data.status = MWS_NOWRITE;
>> }
>>
>> static inline
>> @@ -55,10 +67,7 @@ static inline void
>> vm_event_fill_regs(vm_event_request_t *req)
>> /* Not supported on ARM. */
>> }
>>
>> -static inline void arch_vm_event_vcpu_enter(struct vcpu *v)
>> -{
>> - /* Nothing to do. */
>> -}
>> +void arch_vm_event_vcpu_enter(struct vcpu *v);
>>
>> /*
>> * Monitor vm-events.
>> @@ -67,7 +76,8 @@ static inline uint32_t
>> vm_event_monitor_get_capabilities(struct domain *d)
>> {
>> uint32_t capabilities = 0;
>>
>> - capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
>> + capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
>> + (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
>>
>> return capabilities;
>> }
>> diff --git a/xen/include/public/vm_event.h
>> b/xen/include/public/vm_event.h
>> index 8f94e20..ec3eaca 100644
>> --- a/xen/include/public/vm_event.h
>> +++ b/xen/include/public/vm_event.h
>
> [...]
>
Regards,
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr
2016-06-16 16:55 ` Tamas K Lengyel
@ 2016-06-17 10:37 ` Corneliu ZUZU
0 siblings, 0 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-17 10:37 UTC (permalink / raw)
To: Tamas K Lengyel; +Cc: Andrew Cooper, Razvan Cojocaru, Jan Beulich, Xen-devel
On 6/16/2016 7:55 PM, Tamas K Lengyel wrote:
> On Thu, Jun 16, 2016 at 8:12 AM, Corneliu ZUZU <czuzu@bitdefender.com> wrote:
>> Prepare for ARM implementation of control-register write vm-events by moving
>> X86-specific hvm_event_cr to the common-side.
>>
>> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
>> ---
>> xen/arch/x86/hvm/event.c | 30 ------------------------------
>> xen/arch/x86/hvm/hvm.c | 2 +-
>> xen/arch/x86/monitor.c | 37 -------------------------------------
>> xen/arch/x86/vm_event.c | 2 +-
>> xen/common/monitor.c | 40 ++++++++++++++++++++++++++++++++++++++++
>> xen/common/vm_event.c | 31 +++++++++++++++++++++++++++++++
>> xen/include/asm-x86/hvm/event.h | 13 ++++---------
>> xen/include/asm-x86/monitor.h | 2 --
>> xen/include/xen/monitor.h | 4 ++++
>> xen/include/xen/vm_event.h | 10 ++++++++++
>> 10 files changed, 91 insertions(+), 80 deletions(-)
> Some of the code-movement here touches code I cleaned up in
> https://patchwork.kernel.org/patch/9151229 to keep vm_event and
> monitor code separate as much as possible. The same separation should
> be followed when we move code to common.
>
> Tamas
>
Again, that didn't make it to staging. We'll see which gets in first and
merge afterwards?
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter
2016-06-16 20:33 ` Razvan Cojocaru
@ 2016-06-17 10:41 ` Corneliu ZUZU
0 siblings, 0 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-17 10:41 UTC (permalink / raw)
To: Razvan Cojocaru, Jan Beulich
Cc: Kevin Tian, Stefano Stabellini, George Dunlap, Andrew Cooper,
xen-devel, Julien Grall, Paul Durrant, Tamas K Lengyel,
Jun Nakajima
On 6/16/2016 11:33 PM, Razvan Cojocaru wrote:
> On 06/16/16 23:10, Corneliu ZUZU wrote:
>> On 6/16/2016 5:51 PM, Jan Beulich wrote:
>>>>>> On 16.06.16 at 16:08, <czuzu@bitdefender.com> wrote:
>>>> @@ -509,6 +508,8 @@ void hvm_do_resume(struct vcpu *v)
>>>> }
>>>> }
>>>> + vm_event_vcpu_enter(v);
>>> Why here?
>> Why indeed. It made sense because monitor_write_data handling was
>> originally there and then the plan was to move it to vm_event_vcpu_enter
>> (which happens in the following commit).
>> The question is though, why was monitor_write_data handled there in the
>> first place? Why was it not put e.g. in vmx_do_resume immediately after
>> the call to hvm_do_resume and just before
>> the reset_stack_and_jump...? And what happens with handling
>> monitor_write_data if this:
>>
>> if ( !handle_hvm_io_completion(v) )
>> return;
>>
>> causes a return?
> It's in hvm_do_resume() because, for one, that's the place that was
> suggested (or at least confirmed when I've proposed it for such things)
> on this list back when I wrote the code. And then it's here because
> vmx_do_things()-type functions are, well, VMX, and I had hoped that by
> choosing hvm-prefixed functions I'd get SVM support for free.
>
> As for the handle_hvm_io_completion(v) return, my understanding was that
> that would eventually cause another exit, and eventually we'd get to the
> code below once the IO part is done.
>
>
> Thanks,
> Razvan
Thanks, so then indeed the vm_event_vcpu_enter call should be there to
avoid wrongfully calling it many times before actually entering the vCPU
(due to IO).
I wonder though if anything wrong would happen if I put the call after
the "inject pending hw/sw trap" part.
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 1/7] minor (formatting) fixes
2016-06-17 7:06 ` Jan Beulich
@ 2016-06-17 10:46 ` Corneliu ZUZU
0 siblings, 0 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-17 10:46 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Razvan Cojocaru, Andrew Cooper, xen-devel,
Julien Grall, Tamas K Lengyel
On 6/17/2016 10:06 AM, Jan Beulich wrote:
>>>> On 16.06.16 at 21:19, <czuzu@bitdefender.com> wrote:
>> On 6/16/2016 5:24 PM, Jan Beulich wrote:
>>>>>> On 16.06.16 at 16:06, <czuzu@bitdefender.com> wrote:
>>>> --- a/xen/arch/x86/hvm/event.c
>>>> +++ b/xen/arch/x86/hvm/event.c
>>>> @@ -23,6 +23,7 @@
>>>>
>>>> #include <xen/vm_event.h>
>>>> #include <asm/hvm/event.h>
>>>> +#include <asm/paging.h>
>>>> #include <asm/monitor.h>
>>>> #include <asm/vm_event.h>
>>>> #include <public/vm_event.h>
>>>> diff --git a/xen/common/monitor.c b/xen/common/monitor.c
>>>> index d950a7c..b30857a 100644
>>>> --- a/xen/common/monitor.c
>>>> +++ b/xen/common/monitor.c
>>>> @@ -22,7 +22,6 @@
>>>> #include <xen/monitor.h>
>>>> #include <xen/sched.h>
>>>> #include <xsm/xsm.h>
>>>> -#include <public/domctl.h>
>>>> #include <asm/monitor.h>
>>>> #include <asm/vm_event.h>
>>> These two adjustments clearly don't fit title / description. I certainly
>>> don't mind unnecessary inclusions to be dropped, but the addition of
>>> one clearly needs explanation (after all thing build fine without it).
>> Sorry, that was done out of reflex, should have stated the reasoning.
>> Generally, if:
>> - event.c includes event.h
>> - event.c needs paging.h
>> - event.h -doesn't need- paging.h
>> then I prefer to include paging.h in event.c, not in event.h (include
>> strictly -where- needed).
>> Also since xen/paging.h included asm/paging.h and event.c only needs the
>> asm/paging.h part, I also changed xen/paging.h inclusion -> asm/paging.h
>> inclusion (include strictly -what's- needed).
>> But I can revert that if you want me to (not that important and these
>> little things are better done with automatic tools anyway), or should I
>> leave the change and update the commit message?
> Well, I'd leave the ultimate decision to the maintainers, but I'd say
> this doesn't belong in a patch dealing with formatting issues. I.e.
> I'm fine with the cleanup, but either under a different title (and
> with at least an abbreviated version of what you said above), or
> in a separate patch. Considering that you appear to do the same
> in later patches, perhaps consolidating all the #include adjustments
> into one patch would a good idea?
I tend to prefer organizing what's easy to understand/minor first (to
let reviewers get rid of those in a flash), so I'd prefer to leave it in
this patch with the other minor fixes and update the commit message instead.
But either way it's fine by me.
>>>> --- a/xen/include/xen/vm_event.h
>>>> +++ b/xen/include/xen/vm_event.h
>>>> @@ -85,7 +85,6 @@ void vm_event_monitor_guest_request(void);
>>>>
>>>> #endif /* __VM_EVENT_H__ */
>>>>
>>>> -
>>>> /*
>>>> * Local variables:
>>>> * mode: C
>>> Why don't you remove the other stray blank line at once?
>> What stray line? Shouldn't there be -one- blank line between the #endif
>> and the local vars block?
>> Looking @ other files that rule seems to hold...
> Oh, you're right. I thought I had frequently seen it the other way
> around (and it would seem more logical to me), but I must have been
> misremembering.
>
> Jan
>
>
Thanks,
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter
2016-06-17 7:17 ` Jan Beulich
@ 2016-06-17 11:13 ` Corneliu ZUZU
2016-06-17 11:27 ` Jan Beulich
0 siblings, 1 reply; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-17 11:13 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Stefano Stabellini, Razvan Cojocaru, George Dunlap,
Andrew Cooper, xen-devel, Julien Grall, Paul Durrant,
Tamas K Lengyel, Jun Nakajima
On 6/17/2016 10:17 AM, Jan Beulich wrote:
>>>> On 16.06.16 at 22:10, <czuzu@bitdefender.com> wrote:
>> On 6/16/2016 5:51 PM, Jan Beulich wrote:
>>>>>> On 16.06.16 at 16:08, <czuzu@bitdefender.com> wrote:
>>>> @@ -509,6 +508,8 @@ void hvm_do_resume(struct vcpu *v)
>>>> }
>>>> }
>>>>
>>>> + vm_event_vcpu_enter(v);
>>> Why here?
>> Why indeed. It made sense because monitor_write_data handling was
>> originally there and then the plan was to move it to vm_event_vcpu_enter
>> (which happens in the following commit).
>> The question is though, why was monitor_write_data handled there in the
>> first place? Why was it not put e.g. in vmx_do_resume immediately after
>> the call to hvm_do_resume and just before
>> the reset_stack_and_jump...? And what happens with handling
>> monitor_write_data if this:
>>
>> if ( !handle_hvm_io_completion(v) )
>> return;
>>
>> causes a return?
> I see Razvan responded to this. I don't have a strong opinion
> either way, my only request if for the call to be in exactly one
> place.
>
>>>> --- a/xen/arch/x86/mm/p2m.c
>>>> +++ b/xen/arch/x86/mm/p2m.c
>>>> @@ -36,7 +36,6 @@
>>>> #include <asm/hvm/nestedhvm.h>
>>>> #include <asm/altp2m.h>
>>>> #include <asm/hvm/svm/amd-iommu-proto.h>
>>>> -#include <asm/vm_event.h>
>>>> #include <xsm/xsm.h>
>>> There are way too many of these #include adjustments here. If
>>> you really mean to clean these up, please don't randomly throw
>>> this into various unrelated patches.
>> I haven't thrown anything "randomly into unrelated patches", please
>> first ask for my reasoning and then draw such conclusions.
> See patch 1.
"Sorry, that was done out of reflex, should have stated the reasoning."
> Plus I don't think I (or in fact any reviewer) should ask
> for such reasoning: Instead you should state extra cleanup you do
> to unrelated (to the purpose of your patch) files in the description.
Is that still the case when that reasoning is obvious? (at least it
seemed to me)
but anyway..
> Or even better, split it off to a follow-on, purely cleanup patch.
I agree with this. Will keep in mind with v2.
> (And to be clear, I much appreciate any form of reduction of the
> sometimes extremely long lists of #include-s, just not [apparently
> or really] randomly mixed with other, substantial changes. That's
> namely because it's not clear whether source files should explicitly
> include everything they need, or instead be allowed to rely on
> headers they include to include further headers they also
> _explicitly_ rely on.
Personally I prefer the former since I think it also cuts down
compilation time.
Having header H include every header Ni needed by source S makes H
unnecessarily bulky at compilation time for other sources <> S that
don't need headers Ni but which depend on H nonetheless.
> IOW there's likely a discussion to be had for
> this kind of cleanup, and such a discussion should be a separate
> thread from the one on the functional adjustments here.)
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 4/7] vm-event/x86: use vm_event_vcpu_enter properly
2016-06-17 7:20 ` Jan Beulich
@ 2016-06-17 11:23 ` Corneliu ZUZU
0 siblings, 0 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-17 11:23 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Tamas K Lengyel, Razvan Cojocaru, Andrew Cooper,
xen-devel, Jun Nakajima
On 6/17/2016 10:20 AM, Jan Beulich wrote:
>>>> On 16.06.16 at 22:20, <czuzu@bitdefender.com> wrote:
>> On 6/16/2016 6:00 PM, Jan Beulich wrote:
>>>>>> On 16.06.16 at 16:09, <czuzu@bitdefender.com> wrote:
>>>> @@ -1432,18 +1430,16 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned int cr)
>>>> if ( paging_mode_hap(v->domain) )
>>>> {
>>>> /* Manage GUEST_CR3 when CR0.PE=0. */
>>>> + uint32_t old_ctls = v->arch.hvm_vmx.exec_control;
>>>> uint32_t cr3_ctls = (CPU_BASED_CR3_LOAD_EXITING |
>>>> CPU_BASED_CR3_STORE_EXITING);
>>>> +
>>>> v->arch.hvm_vmx.exec_control &= ~cr3_ctls;
>>>> if ( !hvm_paging_enabled(v) && !vmx_unrestricted_guest(v) )
>>>> v->arch.hvm_vmx.exec_control |= cr3_ctls;
>>>>
>>>> - /* Trap CR3 updates if CR3 memory events are enabled. */
>>>> - if ( v->domain->arch.monitor.write_ctrlreg_enabled &
>>>> - monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
>>>> - v->arch.hvm_vmx.exec_control |= CPU_BASED_CR3_LOAD_EXITING;
>>>> -
>>>> - vmx_update_cpu_exec_control(v);
>>>> + if ( old_ctls != v->arch.hvm_vmx.exec_control )
>>>> + vmx_update_cpu_exec_control(v);
>>>> }
>>> How does this match up with the rest of this patch?
>> And by 'this' you mean slightly optimizing this sequence by adding in
>> old_ctls?
>> It seems pretty straight-forward to me, I figured if I am to move the
>> monitor.write_ctrlreg_enabled part from here
>> it wouldn't be much of a stretch to also do this little
>> optimization...what would have been appropriate?
>> To do this in a separate patch? To mention it in the commit message?
> At least the latter, and perhaps better the former. Without even
> mentioning it the readers (reviewers) have to guess whether this
> is an integral part of the change, or - as you now confirm - just a
> minor optimization done along the road.
>
> Jan
Ack, will split in separate patch in v2.
You're right, I've got to be more attentive to always separate unrelated
code changes, however minor they are :)
Thanks,
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter
2016-06-17 11:13 ` Corneliu ZUZU
@ 2016-06-17 11:27 ` Jan Beulich
2016-06-17 12:13 ` Corneliu ZUZU
0 siblings, 1 reply; 73+ messages in thread
From: Jan Beulich @ 2016-06-17 11:27 UTC (permalink / raw)
To: Corneliu ZUZU
Cc: Kevin Tian, Stefano Stabellini, Razvan Cojocaru, George Dunlap,
Andrew Cooper, xen-devel, Julien Grall, Paul Durrant,
Tamas K Lengyel, Jun Nakajima
>>> On 17.06.16 at 13:13, <czuzu@bitdefender.com> wrote:
> On 6/17/2016 10:17 AM, Jan Beulich wrote:
>> (And to be clear, I much appreciate any form of reduction of the
>> sometimes extremely long lists of #include-s, just not [apparently
>> or really] randomly mixed with other, substantial changes. That's
>> namely because it's not clear whether source files should explicitly
>> include everything they need, or instead be allowed to rely on
>> headers they include to include further headers they also
>> _explicitly_ rely on.
>
> Personally I prefer the former since I think it also cuts down
> compilation time.
> Having header H include every header Ni needed by source S makes H
> unnecessarily bulky at compilation time for other sources <> S that
> don't need headers Ni but which depend on H nonetheless.
I nowhere said every _header_ should include everything any of
its _consumers_ would require. My point was solely about source
files. For example, if S depends on both H1 and H2, and H2
already includes H1, whether S then needs to just include H2, or
should also explicitly include H1 (such that S doesn't need changing
when the inclusion of H1 by H2 goes away).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr
2016-06-17 8:38 ` Jan Beulich
@ 2016-06-17 11:31 ` Corneliu ZUZU
0 siblings, 0 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-17 11:31 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, Tamas K Lengyel, Razvan Cojocaru, xen-devel
On 6/17/2016 11:38 AM, Jan Beulich wrote:
>>>> On 17.06.16 at 10:25, <czuzu@bitdefender.com> wrote:
>> On 6/16/2016 6:16 PM, Jan Beulich wrote:
>>> And looking at all the uses of this variable I get the impression that
>>> you really want a shorthand for &d->arch.monitor (if any such
>>> helper variable is worthwhile to have here in the first place).
>> Well, this was a simple cut-paste operation, not very old content aware :)
>> Personally I prefer the current shorthand (ad) (seems more intuitive and
>> is consistent with the other XEN_DOMCTL_MONITOR_EVENT_* cases), but if
>> you prefer I'll change that shorthand to am = &d->arch.monitor?
> I'd prefer either no shorthand, or one eliminating the longest common
> prefix across all uses.
am = &d->arch.monitor it is then.
>>>> --- a/xen/include/asm-x86/monitor.h
>>>> +++ b/xen/include/asm-x86/monitor.h
>>>> @@ -24,8 +24,6 @@
>>>>
>>>> #include <xen/sched.h>
>>>>
>>>> -#define monitor_ctrlreg_bitmask(ctrlreg_index) (1U << (ctrlreg_index))
>>>> -
>>>> static inline
>>>> int arch_monitor_domctl_op(struct domain *d, struct xen_domctl_monitor_op *mop)
>>>> {
>>>> --- a/xen/include/xen/monitor.h
>>>> +++ b/xen/include/xen/monitor.h
>>>> @@ -25,6 +25,10 @@
>>>> struct domain;
>>>> struct xen_domctl_monitor_op;
>>>>
>>>> +#if CONFIG_X86
>>>> +#define monitor_ctrlreg_bitmask(ctrlreg_index) (1U << (ctrlreg_index))
>>>> +#endif
>>> What's the point in removing this from the x86 header if then it
>>> needs to be put in such a conditional? If the conditional gets
>>> dropped in the next patch, then I think you have two options:
>>> Leave it where it is here, and move it there. Or move it here,
>>> but omit the conditional right away - I can't see this definition
>>> being present to harm the ARM build in any way.
>> Meld comment above.
> I don't follow - having split the patches for reviewability was
> a good idea. I merely commented on some oddities resulting
> from that split, which - afaict - could be easily corrected without
> folding the patches together.
>
> Jan
Ooh, haha, sorry I've re-read your comment now. You're right, there's no
point in that change, I'll leave it on the X86 side until the ARM part
is actually implemented (last patch).
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter
2016-06-17 8:55 ` Julien Grall
@ 2016-06-17 11:40 ` Corneliu ZUZU
2016-06-17 13:22 ` Julien Grall
0 siblings, 1 reply; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-17 11:40 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: Kevin Tian, Stefano Stabellini, Jan Beulich, Razvan Cojocaru,
George Dunlap, Andrew Cooper, Paul Durrant, Tamas K Lengyel,
Jun Nakajima
On 6/17/2016 11:55 AM, Julien Grall wrote:
> Hello,
>
> On 16/06/16 15:08, Corneliu ZUZU wrote:
>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>> index d31f821..ba248c8 100644
>> --- a/xen/arch/arm/domain.c
>> +++ b/xen/arch/arm/domain.c
>> @@ -19,6 +19,7 @@
>> #include <xen/errno.h>
>> #include <xen/bitops.h>
>> #include <xen/grant_table.h>
>> +#include <xen/vm_event.h>
>>
>> #include <asm/current.h>
>> #include <asm/event.h>
>> @@ -251,6 +252,8 @@ static void schedule_tail(struct vcpu *prev)
>>
>> ctxt_switch_to(current);
>>
>> + vm_event_vcpu_enter(current);
>> +
>> local_irq_enable();
>>
>> context_saved(prev);
>> @@ -296,7 +299,7 @@ void context_switch(struct vcpu *prev, struct
>> vcpu *next)
>>
>> void continue_running(struct vcpu *same)
>> {
>> - /* Nothing to do */
>> + vm_event_vcpu_enter(same);
>> }
>>
>> void sync_local_execstate(void)
>
> From my understanding of the commit message, vm_event_vcpu_enter
> should be called before returning to the guest. The scheduling
> functions are not called every-time Xen is returning to the guest. So
> if you want to do every time Xen is re-entering to the guest, then
> this should be done in leave_hypervisor_tail.
>
> Regards,
>
Which is also done, vm_event_vcpu_enter is called from
leave_hypervisor_tail as well.
Are you saying that calling from leave_hypervisor_tail is enough and
that the schedule_tail call is not necessary?
Thanks,
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-16 21:28 ` Julien Grall
@ 2016-06-17 11:46 ` Corneliu ZUZU
0 siblings, 0 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-17 11:46 UTC (permalink / raw)
To: Julien Grall, Julien Grall, xen-devel
Cc: Stefano Stabellini, Tamas K Lengyel, Razvan Cojocaru
On 6/17/2016 12:28 AM, Julien Grall wrote:
>
>
> On 16/06/2016 20:24, Corneliu ZUZU wrote:
>> On 6/16/2016 5:26 PM, Julien Grall wrote:
>> Hi Julien. Yes, I agree that it's complex, I would have preferred to
>> split it up too and I actually tried, but the changes are tightly
>> coupled and they don't seem to be 'split-able'.
>
> After I reviewed this patch I think it could be simplified a lot.
>
> Most of the registers not trapped by vm-event could be emulated with
> one-line WRITE_SYSREGxx and does not require specific case depending
> on the architecture.
>
> You can give a look how we handle the domain context switch in C
> (arch/arm/domain.c).
>
> Only few of the registers will require more than one-line (such as
> MAIR*, *FAR) which could be over a macro.
>
> Regards,
>
Ok, I'll take a look again but I'm not that optimistic, I remember
trying pretty hard to simplify this (and kind of failing), I got the
best I could.
I think it had to do with the fact the SCTLR macros & such got expanded
too early (where I wanted to use them as prefixes to construct other
macros).
Having said this, I'll look into your suggestions and reinspect the code
to recall why those macros got to be the way the are and get back with
conclusions.
Regards,
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter
2016-06-17 11:27 ` Jan Beulich
@ 2016-06-17 12:13 ` Corneliu ZUZU
0 siblings, 0 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-17 12:13 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Stefano Stabellini, Razvan Cojocaru, George Dunlap,
Andrew Cooper, xen-devel, Julien Grall, Paul Durrant,
Tamas K Lengyel, Jun Nakajima
On 6/17/2016 2:27 PM, Jan Beulich wrote:
>>>> On 17.06.16 at 13:13, <czuzu@bitdefender.com> wrote:
>> On 6/17/2016 10:17 AM, Jan Beulich wrote:
>>> (And to be clear, I much appreciate any form of reduction of the
>>> sometimes extremely long lists of #include-s, just not [apparently
>>> or really] randomly mixed with other, substantial changes. That's
>>> namely because it's not clear whether source files should explicitly
>>> include everything they need, or instead be allowed to rely on
>>> headers they include to include further headers they also
>>> _explicitly_ rely on.
>> Personally I prefer the former since I think it also cuts down
>> compilation time.
>> Having header H include every header Ni needed by source S makes H
>> unnecessarily bulky at compilation time for other sources <> S that
>> don't need headers Ni but which depend on H nonetheless.
> I nowhere said every _header_ should include everything any of
> its _consumers_ would require. My point was solely about source
> files. For example, if S depends on both H1 and H2, and H2
> already includes H1, whether S then needs to just include H2, or
> should also explicitly include H1 (such that S doesn't need changing
> when the inclusion of H1 by H2 goes away).
>
> Jan
>
>
Ah, ok got it.
I restate my view of treating these "issues" with automation tools
rather than leaving the programmer to do primitive work that he
shouldn't be required to do with a nowadays programming language.
Clang for example offers a powerful parsing library (can parse GCC too)
with python bindings, it would be nice to take more advantage of that.
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-17 10:36 ` Corneliu ZUZU
@ 2016-06-17 13:18 ` Julien Grall
2016-06-22 16:35 ` Corneliu ZUZU
1 sibling, 0 replies; 73+ messages in thread
From: Julien Grall @ 2016-06-17 13:18 UTC (permalink / raw)
To: Corneliu ZUZU, xen-devel
Cc: Stefano Stabellini, Tamas K Lengyel, Razvan Cojocaru
Hello Corneliu,
On 17/06/16 11:36, Corneliu ZUZU wrote:
> On 6/16/2016 7:49 PM, Julien Grall wrote:
>> On 16/06/16 15:13, Corneliu ZUZU wrote:
[...]
>> Please mention that PRRR and NMRR are aliased to respectively MAIR0
>> and MAIR1. This will avoid to spend time trying to understanding why
>> the spec says they are trapped but you don't "handle" them.
>
> I mentioned that in traps.h (see "AKA" comments). Will put the same
> comment here then.
I noticed it later. But it was not obvious to find.
[...]
>>> diff --git a/xen/arch/arm/vm_event.c b/xen/arch/arm/vm_event.c
>>> new file mode 100644
>>> index 0000000..3f23fec
>>> --- /dev/null
>>> +++ b/xen/arch/arm/vm_event.c
>>> @@ -0,0 +1,112 @@
>>
>> [...]
>>
>>> +#include <xen/vm_event.h>
>>> +#include <asm/traps.h>
>>> +
>>> +#if CONFIG_ARM_64
>>> +
>>> +#define MWSINF_SCTLR 32,SCTLR_EL1
>>> +#define MWSINF_TTBR0 64,TTBR0_EL1
>>> +#define MWSINF_TTBR1 64,TTBR1_EL1
>>> +#define MWSINF_TTBCR 64,TCR_EL1
>>> +
>>> +#elif CONFIG_ARM_32
>>> +
>>> +#define MWSINF_SCTLR 32,SCTLR
>>> +#define MWSINF_TTBR0 64,TTBR0
>>> +#define MWSINF_TTBR1 64,TTBR1
>>
>> The values are the same as for arm64 (*_EL1 is aliased to * for
>> arm32). Please avoid duplication.
>
> (see comment below about later reply)
Your later reply explain why you did not expose TTBR*_32 to ARM64, but
does not explain why the 3 define above is the same as the ARM64.
>
>>
>>> +#define MWSINF_TTBR0_32 32,TTBR0_32
>>> +#define MWSINF_TTBR1_32 32,TTBR1_32
>>> +#define MWSINF_TTBCR 32,TTBCR
>>> +
>>> +#endif
>>> +
>>> +#define MWS_EMUL_(val, sz, r...) WRITE_SYSREG##sz((uint##sz##_t)
>>> (val), r)
>>
>> The cast is not necessary.
>>
>>> +#define MWS_EMUL(r) CALL_MACRO(MWS_EMUL_, w->value, MWSINF_##r)
>>> +
>>> +static inline void vcpu_enter_write_data(struct vcpu *v)
>>> +{
>>> + struct monitor_write_data *w = &v->arch.vm_event.write_data;
>>> +
>>> + if ( likely(MWS_NOWRITE == w->status) )
>>> + return;
>>> +
>>> + switch ( w->status )
>>> + {
>>> + case MWS_SCTLR:
>>> + MWS_EMUL(SCTLR);
>>> + break;
>>> + case MWS_TTBR0:
>>> + MWS_EMUL(TTBR0);
>>> + break;
>>> + case MWS_TTBR1:
>>> + MWS_EMUL(TTBR1);
>>> + break;
>>> +#if CONFIG_ARM_32
>>> + case MWS_TTBR0_32:
>>> + MWS_EMUL(TTBR0_32);
>>> + break;
>>> + case MWS_TTBR1_32:
>>> + MWS_EMUL(TTBR1_32);
>>> + break;
>>> +#endif
>>
>> Aarch32 kernel can return on an AArch64 Xen. This means that
>> TTBR{0,1}_32 could be trapped and the write therefore be properly
>> emulated.
>
> MCR TTBRx writes from AArch32 guests appear as writes of the low 32-bits
> of AArch64 TTBRx_EL1 (architecturally mapped).
> MCRR TTBRx writes from AArch32 guests appear as writes to AArch64
> TTBRx_EL1.
> Therefore, in the end the register we need to write is still TTBRx_EL1.
Why would you want to notify write to TTBR*_32 when Xen is running in
AArch32 mode and none in Aaarch64 mode?
The vm-events for an AArch32 guests should be exactly the same
regardless of Xen mode (i.e AArch32 vs AArch64).
[...]
>>
>>> @@ -0,0 +1,253 @@
>>
>> [...]
>>
>>> +/*
>>> + * Emulation of system-register trapped writes that do not cause
>>> + * VM_EVENT_REASON_WRITE_CTRLREG monitor vm-events.
>>> + * Such writes are collaterally trapped due to setting the
>>> HCR_EL2.TVM bit.
>>> + *
>>> + * Regarding aarch32 domains, note that from Xen's perspective
>>> system-registers
>>> + * of such domains are architecturally-mapped to aarch64 registers
>>> in one of
>>> + * three ways:
>>> + * - low 32-bits mapping (e.g. aarch32 DFAR -> aarch64
>>> FAR_EL1[31:0])
>>> + * - high 32-bits mapping (e.g. aarch32 IFAR -> aarch64
>>> FAR_EL1[63:32])
>>> + * - full mapping (e.g. aarch32 SCTLR -> aarch64 SCTLR_EL1)
>>> + *
>>> + * Hence we define 2 macro variants:
>>> + * - TVM_EMUL_SZ variant, for full mappings
>>> + * - TVM_EMUL_LH variant, for low/high 32-bits mappings
>>> + */
>>> +#define TVM_EMUL_SZ(regs, hsr, val, sz,
>>> r...) \
>>> +{ \
>>> + if ( psr_mode_is_user(regs)
>>> ) \
>>
>> Those registers are not accessible at EL0.
>
> Hmm, I have this question noted.
> I remember finding from the manuals that a write from user-mode of those
> regs would still trap to EL2, but I didn't test that yet.
> Will put that to test and come back with results for v2.
Testing will not tell you if a trap will occur or not. The ARM ARM may
define it as IMPLEMENTATION DEFINED.
From my understanding of the ARMv7 spec (B1.14.1 and B1.14.13 in ARM
DDI 0406C.c), the instruction at PL0 (user mode) will not trap to the
hypervisor:
"Setting HCR.TVM to 1 means that any attempt, to write to a Non-secure
memory control register from a Non-secure
PL1 or PL0 mode, that this reference manual does not describe as
UNDEFINED , generates a Hyp Trap exception."
For ARMv8 (See description of HCR_EL2.TVM D7-1971 in ARM DDI 0487A.j),
only NS EL1 write to the registers will be trapped.
>>
>>> + return inject_undef_exception(regs,
>>> hsr); \
>>> + WRITE_SYSREG##sz((uint##sz##_t) (val), r);
>>
>> [...]
>>
>>> diff --git a/xen/include/asm-arm/vm_event.h
>>> b/xen/include/asm-arm/vm_event.h
>>> index 4e5a272..edf9654 100644
>>> --- a/xen/include/asm-arm/vm_event.h
>>> +++ b/xen/include/asm-arm/vm_event.h
>>> @@ -30,6 +30,12 @@ static inline int vm_event_init_domain(struct
>>> domain *d)
>>>
>>> static inline void vm_event_cleanup_domain(struct domain *d)
>>> {
>>> + struct vcpu *v;
>>> +
>>> + for_each_vcpu ( d, v )
>>> + memset(&v->arch.vm_event, 0, sizeof(v->arch.vm_event));
>>> +
>>> + memset(&d->arch.monitor, 0, sizeof(d->arch.monitor));
>>> memset(&d->monitor, 0, sizeof(d->monitor));
>>> }
>>>
>>> @@ -41,7 +47,13 @@ static inline void
>>> vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
>>> static inline
>>> void vm_event_register_write_resume(struct vcpu *v,
>>> vm_event_response_t *rsp)
>>> {
>>> - /* Not supported on ARM. */
>>> + /* X86 VM_EVENT_REASON_MOV_TO_MSR could (but shouldn't) end-up
>>> here too. */
>>
>> This should be an ASSERT/BUG_ON then.
>
> We can't ASSERT/BUG_ON here because rsp->reason is controlled by the
> toolstack user.
Your comment says "shouldn't" which I interpret as this would be a bug
if VM_EVENT_REASON_MOV_TO_MSR ends up here.
If not a BUG_ON, at least returning an error. We should not silently
ignore something that shouldn't happen.
> This has to do with the implementation of vm_event_resume.
> What I think we should do instead is to surround "case
> VM_EVENT_REASON_MOV_TO_MSR" there with #ifdef CONFIG_X86.
> Would that be suitable?
x86 vm-event reason should never be accessible on ARM (similarly for ARM
vm-event on x86). So the hypervisor should return an error if someone is
calling with the wrong vm-event.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter
2016-06-17 11:40 ` Corneliu ZUZU
@ 2016-06-17 13:22 ` Julien Grall
0 siblings, 0 replies; 73+ messages in thread
From: Julien Grall @ 2016-06-17 13:22 UTC (permalink / raw)
To: Corneliu ZUZU, xen-devel
Cc: Kevin Tian, Stefano Stabellini, Jan Beulich, Razvan Cojocaru,
George Dunlap, Andrew Cooper, Paul Durrant, Tamas K Lengyel,
Jun Nakajima
Hello,
On 17/06/16 12:40, Corneliu ZUZU wrote:
> On 6/17/2016 11:55 AM, Julien Grall wrote:
>> On 16/06/16 15:08, Corneliu ZUZU wrote:
>>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>>> index d31f821..ba248c8 100644
>>> --- a/xen/arch/arm/domain.c
>>> +++ b/xen/arch/arm/domain.c
>>> @@ -19,6 +19,7 @@
>>> #include <xen/errno.h>
>>> #include <xen/bitops.h>
>>> #include <xen/grant_table.h>
>>> +#include <xen/vm_event.h>
>>>
>>> #include <asm/current.h>
>>> #include <asm/event.h>
>>> @@ -251,6 +252,8 @@ static void schedule_tail(struct vcpu *prev)
>>>
>>> ctxt_switch_to(current);
>>>
>>> + vm_event_vcpu_enter(current);
>>> +
>>> local_irq_enable();
>>>
>>> context_saved(prev);
>>> @@ -296,7 +299,7 @@ void context_switch(struct vcpu *prev, struct
>>> vcpu *next)
>>>
>>> void continue_running(struct vcpu *same)
>>> {
>>> - /* Nothing to do */
>>> + vm_event_vcpu_enter(same);
>>> }
>>>
>>> void sync_local_execstate(void)
>>
>> From my understanding of the commit message, vm_event_vcpu_enter
>> should be called before returning to the guest. The scheduling
>> functions are not called every-time Xen is returning to the guest. So
>> if you want to do every time Xen is re-entering to the guest, then
>> this should be done in leave_hypervisor_tail.
>>
>> Regards,
>>
>
> Which is also done, vm_event_vcpu_enter is called from
> leave_hypervisor_tail as well.
Sorry I did not spot this one.
> Are you saying that calling from leave_hypervisor_tail is enough and
> that the schedule_tail call is not necessary?
leave_hypervisor_tail will always be called before returning to the
guest. So a call to vm_event_vcpu_enter in this function will be sufficient.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 1/7] minor (formatting) fixes
2016-06-17 9:33 ` Jan Beulich
2016-06-17 9:36 ` Razvan Cojocaru
@ 2016-06-17 19:05 ` Tamas K Lengyel
1 sibling, 0 replies; 73+ messages in thread
From: Tamas K Lengyel @ 2016-06-17 19:05 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Razvan Cojocaru, Andrew Cooper, Xen-devel,
Julien Grall, Corneliu ZUZU
On Fri, Jun 17, 2016 at 3:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 17.06.16 at 10:36, <rcojocaru@bitdefender.com> wrote:
>> On 06/17/2016 11:33 AM, Corneliu ZUZU wrote:
>>> Ah, ok. Didn't that patch make it to staging yet? I pulled the latest.
>>> Since you already have a patch for that I guess it's ok to remove those
>>> comments and leave the rest as it is and merge later when one of these
>>> patches makes it to staging?
>>
>> I think there's a delay caused by the 4.7 release. I also have an acked
>> patch waiting to go in that might cause you to have to rebase (part of)
>> the series: https://patchwork.kernel.org/patch/9033771/
>
> Well, there's a slight difference here: Yours is indeed delayed until
> 4.7 is set in stone, for being more intrusive. Tamas'es, otoh, I would
> probably have put in already if it had all necessary acks (or they
> had at least been pinged for, at which point we could waive the need
> for some trivial adjustments).
Patches 1 through 4 of my v5 series already has acks, so I guess I'll
issue a ping for the other maintainers to check.
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr
2016-06-17 8:25 ` Corneliu ZUZU
2016-06-17 8:38 ` Jan Beulich
@ 2016-06-21 7:08 ` Corneliu ZUZU
2016-06-21 7:20 ` Jan Beulich
1 sibling, 1 reply; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-21 7:08 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, Tamas K Lengyel, Razvan Cojocaru, xen-devel
On 6/17/2016 11:25 AM, Corneliu ZUZU wrote:
> On 6/16/2016 6:16 PM, Jan Beulich wrote:
>>>>> On 16.06.16 at 16:12, <czuzu@bitdefender.com> wrote:
>>> Prepare for ARM implementation of control-register write vm-events
>>> by moving
>>> X86-specific hvm_event_cr to the common-side.
>>>
>>> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
>>> ---
>>> xen/arch/x86/hvm/event.c | 30 ------------------------------
>>> xen/arch/x86/hvm/hvm.c | 2 +-
>>> xen/arch/x86/monitor.c | 37
>>> -------------------------------------
>>> xen/arch/x86/vm_event.c | 2 +-
>>> xen/common/monitor.c | 40
>>> ++++++++++++++++++++++++++++++++++++++++
>>> xen/common/vm_event.c | 31 +++++++++++++++++++++++++++++++
>>> xen/include/asm-x86/hvm/event.h | 13 ++++---------
>>> xen/include/asm-x86/monitor.h | 2 --
>>> xen/include/xen/monitor.h | 4 ++++
>>> xen/include/xen/vm_event.h | 10 ++++++++++
>>> 10 files changed, 91 insertions(+), 80 deletions(-)
>> Considering that there's no ARM file getting altered here at all,
>> mentioning ARM in the subject is a little odd.
>
> This patch and the following one should be meld together.
> I only split them to ease reviewing, sorry I forgot to mention that in
> the cover letter.
>
>>
>>> --- a/xen/common/monitor.c
>>> +++ b/xen/common/monitor.c
>>> @@ -62,6 +62,46 @@ int monitor_domctl(struct domain *d, struct
>>> xen_domctl_monitor_op *mop)
>>> switch ( mop->event )
>>> {
>>> +#if CONFIG_X86
>> #ifdef please.
> Ack.
>>> + case XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG:
>>> + {
>>> + struct arch_domain *ad = &d->arch;
>> Peeking into the next patch I see that this stays there. Common code,
>> however, shouldn't access ->arch sub-structures - respective fields
>> should be moved out.
>
> Then we need to find a resolution that avoids code duplication.
> The code is the same, but those bits that are currently on the arch
> side (arch.monitor.write_ctrlreg_*) cannot be moved to common as they
> are, since their -number- might differ from arch-to-arch.
> But we could:
> - in public/vm_event.h, besides the VM_EVENT_X86_* and VM_EVENT_ARM_*
> defines (wcr index), also have
> #define VM_EVENT_X86_CR_COUNT 4
> #define VM_EVENT_ARM_CR_COUNT 4
> - move the 3 write_ctrlreg_{enabled,sync,onchangeonly} fields from
> arch_domain to domain (common) and make them 8-bits wide each for now
> (widened more in the future if the need arises)
> - let monitor_ctrlreg_bitmask() macro to be architecture-dependent and
> use the introduced VM_EVENT_<arch>_CR_COUNT
>
> Tamas, we also talked on this matter @ some point (when I sent the
> patches that moved vm-event parts to common). What do you think of the
> above?
Tamas, Jan, thoughts on this?
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr
2016-06-21 7:08 ` Corneliu ZUZU
@ 2016-06-21 7:20 ` Jan Beulich
2016-06-21 15:22 ` Tamas K Lengyel
0 siblings, 1 reply; 73+ messages in thread
From: Jan Beulich @ 2016-06-21 7:20 UTC (permalink / raw)
To: Corneliu ZUZU; +Cc: Andrew Cooper, Tamas K Lengyel, Razvan Cojocaru, xen-devel
>>> On 21.06.16 at 09:08, <czuzu@bitdefender.com> wrote:
> On 6/17/2016 11:25 AM, Corneliu ZUZU wrote:
>> On 6/16/2016 6:16 PM, Jan Beulich wrote:
>>>>>> On 16.06.16 at 16:12, <czuzu@bitdefender.com> wrote:
>>>> Prepare for ARM implementation of control-register write vm-events
>>>> by moving
>>>> X86-specific hvm_event_cr to the common-side.
>>>>
>>>> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
>>>> ---
>>>> xen/arch/x86/hvm/event.c | 30 ------------------------------
>>>> xen/arch/x86/hvm/hvm.c | 2 +-
>>>> xen/arch/x86/monitor.c | 37
>>>> -------------------------------------
>>>> xen/arch/x86/vm_event.c | 2 +-
>>>> xen/common/monitor.c | 40
>>>> ++++++++++++++++++++++++++++++++++++++++
>>>> xen/common/vm_event.c | 31 +++++++++++++++++++++++++++++++
>>>> xen/include/asm-x86/hvm/event.h | 13 ++++---------
>>>> xen/include/asm-x86/monitor.h | 2 --
>>>> xen/include/xen/monitor.h | 4 ++++
>>>> xen/include/xen/vm_event.h | 10 ++++++++++
>>>> 10 files changed, 91 insertions(+), 80 deletions(-)
>>> Considering that there's no ARM file getting altered here at all,
>>> mentioning ARM in the subject is a little odd.
>>
>> This patch and the following one should be meld together.
>> I only split them to ease reviewing, sorry I forgot to mention that in
>> the cover letter.
>>
>>>
>>>> --- a/xen/common/monitor.c
>>>> +++ b/xen/common/monitor.c
>>>> @@ -62,6 +62,46 @@ int monitor_domctl(struct domain *d, struct
>>>> xen_domctl_monitor_op *mop)
>>>> switch ( mop->event )
>>>> {
>>>> +#if CONFIG_X86
>>> #ifdef please.
>> Ack.
>>>> + case XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG:
>>>> + {
>>>> + struct arch_domain *ad = &d->arch;
>>> Peeking into the next patch I see that this stays there. Common code,
>>> however, shouldn't access ->arch sub-structures - respective fields
>>> should be moved out.
>>
>> Then we need to find a resolution that avoids code duplication.
>> The code is the same, but those bits that are currently on the arch
>> side (arch.monitor.write_ctrlreg_*) cannot be moved to common as they
>> are, since their -number- might differ from arch-to-arch.
>> But we could:
>> - in public/vm_event.h, besides the VM_EVENT_X86_* and VM_EVENT_ARM_*
>> defines (wcr index), also have
>> #define VM_EVENT_X86_CR_COUNT 4
>> #define VM_EVENT_ARM_CR_COUNT 4
>> - move the 3 write_ctrlreg_{enabled,sync,onchangeonly} fields from
>> arch_domain to domain (common) and make them 8-bits wide each for now
>> (widened more in the future if the need arises)
>> - let monitor_ctrlreg_bitmask() macro to be architecture-dependent and
>> use the introduced VM_EVENT_<arch>_CR_COUNT
>>
>> Tamas, we also talked on this matter @ some point (when I sent the
>> patches that moved vm-event parts to common). What do you think of the
>> above?
I don't really care about the specifics, my only request is what I
already voiced: Common code should not access arch-specific
fields. Having the field to hold the control register bits common,
but the definitions for the individual bits arch-specific is perfectly
fine for this (assuming that these per-arch definitions then again
don't get used in common code).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 2/7] vm-event: VM_EVENT_FLAG_DENY requires VM_EVENT_FLAG_VCPU_PAUSED
2016-06-16 16:11 ` Tamas K Lengyel
2016-06-17 8:43 ` Corneliu ZUZU
@ 2016-06-21 11:26 ` Corneliu ZUZU
2016-06-21 15:09 ` Tamas K Lengyel
1 sibling, 1 reply; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-21 11:26 UTC (permalink / raw)
To: Tamas K Lengyel; +Cc: Andrew Cooper, Jan Beulich, Razvan Cojocaru, Xen-devel
On 6/16/2016 7:11 PM, Tamas K Lengyel wrote:
> On Thu, Jun 16, 2016 at 8:07 AM, Corneliu ZUZU <czuzu@bitdefender.com> wrote:
>> For VM_EVENT_FLAG_DENY to work, the vcpu must be paused (sync = 1) until the
>> vm-event is handled. A vm-event response having VM_EVENT_FLAG_DENY flag set
>> should also set the VM_EVENT_FLAG_VCPU_PAUSED flag. Enforce that in
>> vm_event_register_write_resume().
> Well, the problem with this is that the user can set the VCPU_PAUSED
> flag any time it wants. It can happen that Xen hasn't paused the vCPU
> but the user still sends that flag, in which case the unpause the flag
> induces will not actually do anything. You should also check if the
> vCPU is in fact paused rather then just relying on this flag.
>
> Tamas
>
Tamas,
Isn't that also the case with the following block @ vm_event_resume:
if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
{
if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
vm_event_set_registers(v, &rsp);
if ( rsp.flags & VM_EVENT_FLAG_TOGGLE_SINGLESTEP )
vm_event_toggle_singlestep(d, v);
vm_event_vcpu_unpause(v);
}
, i.e. shouldn't it be fixed to:
/* check flags which apply only when the vCPU is paused */
if ( atomic_read(&v->vm_event_pause_count) )
{
if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
vm_event_set_registers(v, &rsp);
if ( rsp.flags & VM_EVENT_FLAG_TOGGLE_SINGLESTEP )
vm_event_toggle_singlestep(d, v);
if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
vm_event_vcpu_unpause(v);
}
?
If this holds, the check for vCPU pause can also be removed from
vm_event_toggle_singlestep (maybe turned into an ASSERT which could also
be added to vm_event_set_registers).
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 2/7] vm-event: VM_EVENT_FLAG_DENY requires VM_EVENT_FLAG_VCPU_PAUSED
2016-06-21 11:26 ` Corneliu ZUZU
@ 2016-06-21 15:09 ` Tamas K Lengyel
2016-06-22 8:34 ` Corneliu ZUZU
0 siblings, 1 reply; 73+ messages in thread
From: Tamas K Lengyel @ 2016-06-21 15:09 UTC (permalink / raw)
To: Corneliu ZUZU; +Cc: Andrew Cooper, Jan Beulich, Razvan Cojocaru, Xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 2069 bytes --]
On Jun 21, 2016 05:26, "Corneliu ZUZU" <czuzu@bitdefender.com> wrote:
>
> On 6/16/2016 7:11 PM, Tamas K Lengyel wrote:
>>
>> On Thu, Jun 16, 2016 at 8:07 AM, Corneliu ZUZU <czuzu@bitdefender.com>
wrote:
>>>
>>> For VM_EVENT_FLAG_DENY to work, the vcpu must be paused (sync = 1)
until the
>>> vm-event is handled. A vm-event response having VM_EVENT_FLAG_DENY flag
set
>>> should also set the VM_EVENT_FLAG_VCPU_PAUSED flag. Enforce that in
>>> vm_event_register_write_resume().
>>
>> Well, the problem with this is that the user can set the VCPU_PAUSED
>> flag any time it wants. It can happen that Xen hasn't paused the vCPU
>> but the user still sends that flag, in which case the unpause the flag
>> induces will not actually do anything. You should also check if the
>> vCPU is in fact paused rather then just relying on this flag.
>>
>> Tamas
>>
>
> Tamas,
>
> Isn't that also the case with the following block @ vm_event_resume:
>
> if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
> {
> if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
> vm_event_set_registers(v, &rsp);
>
> if ( rsp.flags & VM_EVENT_FLAG_TOGGLE_SINGLESTEP )
> vm_event_toggle_singlestep(d, v);
>
> vm_event_vcpu_unpause(v);
> }
>
> , i.e. shouldn't it be fixed to:
>
> /* check flags which apply only when the vCPU is paused */
> if ( atomic_read(&v->vm_event_pause_count) )
> {
> if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
> vm_event_set_registers(v, &rsp);
> if ( rsp.flags & VM_EVENT_FLAG_TOGGLE_SINGLESTEP )
> vm_event_toggle_singlestep(d, v);
> if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
> vm_event_vcpu_unpause(v);
> }
> ?
>
> If this holds, the check for vCPU pause can also be removed from
vm_event_toggle_singlestep (maybe turned into an ASSERT which could also be
added to vm_event_set_registers).
>
Yes, reworking that whole part as you outlined above would be nice!
Tamas
[-- Attachment #1.2: Type: text/html, Size: 2853 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr
2016-06-21 7:20 ` Jan Beulich
@ 2016-06-21 15:22 ` Tamas K Lengyel
2016-06-22 6:33 ` Jan Beulich
0 siblings, 1 reply; 73+ messages in thread
From: Tamas K Lengyel @ 2016-06-21 15:22 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, xen-devel, Razvan Cojocaru, Corneliu ZUZU
[-- Attachment #1.1: Type: text/plain, Size: 3768 bytes --]
On Jun 21, 2016 01:20, "Jan Beulich" <JBeulich@suse.com> wrote:
>
> >>> On 21.06.16 at 09:08, <czuzu@bitdefender.com> wrote:
> > On 6/17/2016 11:25 AM, Corneliu ZUZU wrote:
> >> On 6/16/2016 6:16 PM, Jan Beulich wrote:
> >>>>>> On 16.06.16 at 16:12, <czuzu@bitdefender.com> wrote:
> >>>> Prepare for ARM implementation of control-register write vm-events
> >>>> by moving
> >>>> X86-specific hvm_event_cr to the common-side.
> >>>>
> >>>> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
> >>>> ---
> >>>> xen/arch/x86/hvm/event.c | 30 ------------------------------
> >>>> xen/arch/x86/hvm/hvm.c | 2 +-
> >>>> xen/arch/x86/monitor.c | 37
> >>>> -------------------------------------
> >>>> xen/arch/x86/vm_event.c | 2 +-
> >>>> xen/common/monitor.c | 40
> >>>> ++++++++++++++++++++++++++++++++++++++++
> >>>> xen/common/vm_event.c | 31
+++++++++++++++++++++++++++++++
> >>>> xen/include/asm-x86/hvm/event.h | 13 ++++---------
> >>>> xen/include/asm-x86/monitor.h | 2 --
> >>>> xen/include/xen/monitor.h | 4 ++++
> >>>> xen/include/xen/vm_event.h | 10 ++++++++++
> >>>> 10 files changed, 91 insertions(+), 80 deletions(-)
> >>> Considering that there's no ARM file getting altered here at all,
> >>> mentioning ARM in the subject is a little odd.
> >>
> >> This patch and the following one should be meld together.
> >> I only split them to ease reviewing, sorry I forgot to mention that in
> >> the cover letter.
> >>
> >>>
> >>>> --- a/xen/common/monitor.c
> >>>> +++ b/xen/common/monitor.c
> >>>> @@ -62,6 +62,46 @@ int monitor_domctl(struct domain *d, struct
> >>>> xen_domctl_monitor_op *mop)
> >>>> switch ( mop->event )
> >>>> {
> >>>> +#if CONFIG_X86
> >>> #ifdef please.
> >> Ack.
> >>>> + case XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG:
> >>>> + {
> >>>> + struct arch_domain *ad = &d->arch;
> >>> Peeking into the next patch I see that this stays there. Common code,
> >>> however, shouldn't access ->arch sub-structures - respective fields
> >>> should be moved out.
> >>
> >> Then we need to find a resolution that avoids code duplication.
> >> The code is the same, but those bits that are currently on the arch
> >> side (arch.monitor.write_ctrlreg_*) cannot be moved to common as they
> >> are, since their -number- might differ from arch-to-arch.
> >> But we could:
> >> - in public/vm_event.h, besides the VM_EVENT_X86_* and VM_EVENT_ARM_*
> >> defines (wcr index), also have
> >> #define VM_EVENT_X86_CR_COUNT 4
> >> #define VM_EVENT_ARM_CR_COUNT 4
> >> - move the 3 write_ctrlreg_{enabled,sync,onchangeonly} fields from
> >> arch_domain to domain (common) and make them 8-bits wide each for now
> >> (widened more in the future if the need arises)
> >> - let monitor_ctrlreg_bitmask() macro to be architecture-dependent and
> >> use the introduced VM_EVENT_<arch>_CR_COUNT
> >>
> >> Tamas, we also talked on this matter @ some point (when I sent the
> >> patches that moved vm-event parts to common). What do you think of the
> >> above?
>
> I don't really care about the specifics, my only request is what I
> already voiced: Common code should not access arch-specific
> fields. Having the field to hold the control register bits common,
> but the definitions for the individual bits arch-specific is perfectly
> fine for this (assuming that these per-arch definitions then again
> don't get used in common code).
>
> Jan
As Jan says it would be fine to have the holder field on the common struct
but IMHO it wouldn't be easier to follow the logic that way and the only
benefit is reducing code duplication a little bit. I think for now it is
acceptable to just rather have some code duplication.
Tamas
[-- Attachment #1.2: Type: text/html, Size: 5360 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr
2016-06-21 15:22 ` Tamas K Lengyel
@ 2016-06-22 6:33 ` Jan Beulich
0 siblings, 0 replies; 73+ messages in thread
From: Jan Beulich @ 2016-06-22 6:33 UTC (permalink / raw)
To: Tamas K Lengyel; +Cc: Andrew Cooper, xen-devel, Razvan Cojocaru, Corneliu ZUZU
>>> On 21.06.16 at 17:22, <tamas@tklengyel.com> wrote:
> On Jun 21, 2016 01:20, "Jan Beulich" <JBeulich@suse.com> wrote:
>>
>> >>> On 21.06.16 at 09:08, <czuzu@bitdefender.com> wrote:
>> > On 6/17/2016 11:25 AM, Corneliu ZUZU wrote:
>> >> On 6/16/2016 6:16 PM, Jan Beulich wrote:
>> >>>>>> On 16.06.16 at 16:12, <czuzu@bitdefender.com> wrote:
>> >>>> Prepare for ARM implementation of control-register write vm-events
>> >>>> by moving
>> >>>> X86-specific hvm_event_cr to the common-side.
>> >>>>
>> >>>> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
>> >>>> ---
>> >>>> xen/arch/x86/hvm/event.c | 30 ------------------------------
>> >>>> xen/arch/x86/hvm/hvm.c | 2 +-
>> >>>> xen/arch/x86/monitor.c | 37
>> >>>> -------------------------------------
>> >>>> xen/arch/x86/vm_event.c | 2 +-
>> >>>> xen/common/monitor.c | 40
>> >>>> ++++++++++++++++++++++++++++++++++++++++
>> >>>> xen/common/vm_event.c | 31
> +++++++++++++++++++++++++++++++
>> >>>> xen/include/asm-x86/hvm/event.h | 13 ++++---------
>> >>>> xen/include/asm-x86/monitor.h | 2 --
>> >>>> xen/include/xen/monitor.h | 4 ++++
>> >>>> xen/include/xen/vm_event.h | 10 ++++++++++
>> >>>> 10 files changed, 91 insertions(+), 80 deletions(-)
>> >>> Considering that there's no ARM file getting altered here at all,
>> >>> mentioning ARM in the subject is a little odd.
>> >>
>> >> This patch and the following one should be meld together.
>> >> I only split them to ease reviewing, sorry I forgot to mention that in
>> >> the cover letter.
>> >>
>> >>>
>> >>>> --- a/xen/common/monitor.c
>> >>>> +++ b/xen/common/monitor.c
>> >>>> @@ -62,6 +62,46 @@ int monitor_domctl(struct domain *d, struct
>> >>>> xen_domctl_monitor_op *mop)
>> >>>> switch ( mop->event )
>> >>>> {
>> >>>> +#if CONFIG_X86
>> >>> #ifdef please.
>> >> Ack.
>> >>>> + case XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG:
>> >>>> + {
>> >>>> + struct arch_domain *ad = &d->arch;
>> >>> Peeking into the next patch I see that this stays there. Common code,
>> >>> however, shouldn't access ->arch sub-structures - respective fields
>> >>> should be moved out.
>> >>
>> >> Then we need to find a resolution that avoids code duplication.
>> >> The code is the same, but those bits that are currently on the arch
>> >> side (arch.monitor.write_ctrlreg_*) cannot be moved to common as they
>> >> are, since their -number- might differ from arch-to-arch.
>> >> But we could:
>> >> - in public/vm_event.h, besides the VM_EVENT_X86_* and VM_EVENT_ARM_*
>> >> defines (wcr index), also have
>> >> #define VM_EVENT_X86_CR_COUNT 4
>> >> #define VM_EVENT_ARM_CR_COUNT 4
>> >> - move the 3 write_ctrlreg_{enabled,sync,onchangeonly} fields from
>> >> arch_domain to domain (common) and make them 8-bits wide each for now
>> >> (widened more in the future if the need arises)
>> >> - let monitor_ctrlreg_bitmask() macro to be architecture-dependent and
>> >> use the introduced VM_EVENT_<arch>_CR_COUNT
>> >>
>> >> Tamas, we also talked on this matter @ some point (when I sent the
>> >> patches that moved vm-event parts to common). What do you think of the
>> >> above?
>>
>> I don't really care about the specifics, my only request is what I
>> already voiced: Common code should not access arch-specific
>> fields. Having the field to hold the control register bits common,
>> but the definitions for the individual bits arch-specific is perfectly
>> fine for this (assuming that these per-arch definitions then again
>> don't get used in common code).
>
> As Jan says it would be fine to have the holder field on the common struct
> but IMHO it wouldn't be easier to follow the logic that way and the only
> benefit is reducing code duplication a little bit. I think for now it is
> acceptable to just rather have some code duplication.
Code duplication isn't the main issue here. Inviting further
conceptually wrong code additions (accessing per-arch fields from
common code), by setting a(nother) bad precedent, is what I want
to avoid from the beginning.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 2/7] vm-event: VM_EVENT_FLAG_DENY requires VM_EVENT_FLAG_VCPU_PAUSED
2016-06-21 15:09 ` Tamas K Lengyel
@ 2016-06-22 8:34 ` Corneliu ZUZU
0 siblings, 0 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-22 8:34 UTC (permalink / raw)
To: Tamas K Lengyel; +Cc: Andrew Cooper, Jan Beulich, Razvan Cojocaru, Xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 3207 bytes --]
On 6/21/2016 6:09 PM, Tamas K Lengyel wrote:
>
>
> On Jun 21, 2016 05:26, "Corneliu ZUZU" <czuzu@bitdefender.com
> <mailto:czuzu@bitdefender.com>> wrote:
> >
> > On 6/16/2016 7:11 PM, Tamas K Lengyel wrote:
> >>
> >> On Thu, Jun 16, 2016 at 8:07 AM, Corneliu ZUZU
> <czuzu@bitdefender.com <mailto:czuzu@bitdefender.com>> wrote:
> >>>
> >>> For VM_EVENT_FLAG_DENY to work, the vcpu must be paused (sync = 1)
> until the
> >>> vm-event is handled. A vm-event response having VM_EVENT_FLAG_DENY
> flag set
> >>> should also set the VM_EVENT_FLAG_VCPU_PAUSED flag. Enforce that in
> >>> vm_event_register_write_resume().
> >>
> >> Well, the problem with this is that the user can set the VCPU_PAUSED
> >> flag any time it wants. It can happen that Xen hasn't paused the vCPU
> >> but the user still sends that flag, in which case the unpause the flag
> >> induces will not actually do anything. You should also check if the
> >> vCPU is in fact paused rather then just relying on this flag.
> >>
> >> Tamas
> >>
> >
> > Tamas,
> >
> > Isn't that also the case with the following block @ vm_event_resume:
> >
> > if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
> > {
> > if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
> > vm_event_set_registers(v, &rsp);
> >
> > if ( rsp.flags & VM_EVENT_FLAG_TOGGLE_SINGLESTEP )
> > vm_event_toggle_singlestep(d, v);
> >
> > vm_event_vcpu_unpause(v);
> > }
> >
> > , i.e. shouldn't it be fixed to:
> >
> > /* check flags which apply only when the vCPU is paused */
> > if ( atomic_read(&v->vm_event_pause_count) )
> > {
> > if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
> > vm_event_set_registers(v, &rsp);
> > if ( rsp.flags & VM_EVENT_FLAG_TOGGLE_SINGLESTEP )
> > vm_event_toggle_singlestep(d, v);
> > if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
> > vm_event_vcpu_unpause(v);
> > }
> > ?
> >
> > If this holds, the check for vCPU pause can also be removed from
> vm_event_toggle_singlestep (maybe turned into an ASSERT which could
> also be added to vm_event_set_registers).
> >
>
> Yes, reworking that whole part as you outlined above would be nice!
>
> Tamas
>
I've also noticed there's a vm-event vCPU pause count
(v->vm_event_pause_count), which is synchronized with the global pause
count (v->pause_count).
Since we rely on vm_event_pause_count to determine if the vCPU is
paused, I'm wondering if it can't be 'corrupted' by the user.
More specifically, is the code written to ensure that the following
can't happen:
1. v->vm_event_pause_count > 0 (vm-event subsystem reports that the vCPU
is paused)
2. the toolstack user can somehow decrement the global v->pause_count
without decrementing v->vm_event_pause_count (maybe by doing consecutive
domain resumes)
3. after many decrements by the user (2.), v->pause_count = 0 (the vCPU
becomes unpaused), but v->vm_event_pause_count is still > 0
?
Apparently it can't since there's a separate per-domain pause_count as
well, but the code is a bit involved so I'm just asking to be sure.
Corneliu.
[-- Attachment #1.2: Type: text/html, Size: 5035 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-17 10:36 ` Corneliu ZUZU
2016-06-17 13:18 ` Julien Grall
@ 2016-06-22 16:35 ` Corneliu ZUZU
2016-06-22 17:17 ` Julien Grall
1 sibling, 1 reply; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-22 16:35 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: Stefano Stabellini, Tamas K Lengyel, Razvan Cojocaru
On 6/17/2016 1:36 PM, Corneliu ZUZU wrote:
> On 6/16/2016 7:49 PM, Julien Grall wrote:
>> Hello Corneliu,
>>
>> On 16/06/16 15:13, Corneliu ZUZU wrote:
>>
>>> + case MWS_TTBCR:
>>> + MWS_EMUL(TTBCR);
>>> + break;
>>> + default:
>>> + break;
>>> + }
>>> +
>>> + w->status = MWS_NOWRITE;
>>> +}
>>> +
>>> +static inline void vcpu_enter_adjust_traps(struct vcpu *v)
>>> +{
>>> + register_t old_hcr, hcr;
>>> +
>>> + hcr = (old_hcr = READ_SYSREG(HCR_EL2));
>>> +
>>> + if ( unlikely(0 !=
>>> v->domain->arch.monitor.write_ctrlreg_enabled) )
>>> + hcr |= HCR_TVM;
>>> + else
>>> + hcr &= ~HCR_TVM;
>>> +
>>> + if ( unlikely(hcr != old_hcr) )
>>> + {
>>> + WRITE_SYSREG(hcr, HCR_EL2);
>>> + isb();
>>> + }
>>
>> The HCR register is also updated in p2m_restore_state to set
>> HCR_EL2.RW. I would prefer to have a single place where HCR is updated.
>>
>> Maybe we should store the HCR value per-domain?
>
> Yes, that would be nice. Will look into that for v2.
Julien,
I was trying to implement having HCR stored in arch_domain or arch_vcpu
as suggested above and I'm a bit confused about the code in
p2m_restore_state.
I'm hoping you can provide some feedback on this matter. Here's the
current implementation of the function:
void p2m_restore_state(struct vcpu *n)
{
register_t hcr;
hcr = READ_SYSREG(HCR_EL2);
WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
isb();
p2m_load_VTTBR(n->domain);
isb();
if ( is_32bit_domain(n->domain) )
hcr &= ~HCR_RW;
else
hcr |= HCR_RW;
WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
isb();
WRITE_SYSREG(hcr, HCR_EL2);
isb();
}
First of all, I see the HCR_VM bit being unset (=0) but I don't quite
understand why and even more peculiar is the fact that I couldn't find
any place where the bit is set (=1) again.
Secondly, why this order of operations? More specifically, why is
p2m_load_VTTBR done after the HCR_VM bit is unset and before the HCR_RW
bit is set/unset? Can't we write HCR only once here?
And finally, I see the function is called by construct_dom0. The code
there looks like:
/*
* The following loads use the domain's p2m and require current to
* be a vcpu of the domain, temporarily switch
*/
saved_current = current;
p2m_restore_state(v);
[...]
/* Now that we are done restore the original p2m and current. */
set_current(saved_current);
p2m_restore_state(saved_current);
I suppose the significant changes p2m_restore_state does for the code in
between ("[...]") is setting VTTBR & SCTLR which are used by translation
functions such as gvirt_to_maddr (which seems to use PAR_EL1).
What I don't grasp is what effect setting the VTTBR has if HCR.HCR_VM is
unset and left unset...
Thanks,
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-22 16:35 ` Corneliu ZUZU
@ 2016-06-22 17:17 ` Julien Grall
2016-06-22 18:39 ` Corneliu ZUZU
2016-06-23 11:00 ` Julien Grall
0 siblings, 2 replies; 73+ messages in thread
From: Julien Grall @ 2016-06-22 17:17 UTC (permalink / raw)
To: Corneliu ZUZU, xen-devel
Cc: Andre Przywara, Stefano Stabellini, Tamas K Lengyel,
Razvan Cojocaru, Steve Capper
On 22/06/16 17:35, Corneliu ZUZU wrote:
> Julien,
Hello Corneliu,
> I was trying to implement having HCR stored in arch_domain or arch_vcpu
> as suggested above and I'm a bit confused about the code in
> p2m_restore_state.
> I'm hoping you can provide some feedback on this matter. Here's the
> current implementation of the function:
>
> void p2m_restore_state(struct vcpu *n)
> {
> register_t hcr;
>
> hcr = READ_SYSREG(HCR_EL2);
> WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
> isb();
>
> p2m_load_VTTBR(n->domain);
> isb();
>
> if ( is_32bit_domain(n->domain) )
> hcr &= ~HCR_RW;
> else
> hcr |= HCR_RW;
>
> WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
> isb();
>
> WRITE_SYSREG(hcr, HCR_EL2);
> isb();
> }
>
> First of all, I see the HCR_VM bit being unset (=0) but I don't quite
> understand why and even more peculiar is the fact that I couldn't find
> any place where the bit is set (=1) again.
After the first write to HCR_EL2, "hcr" still have the VM bit set as we
only mask it. So the second write will re-set the VM bit.
I am not sure why the VM bit is unset/set in this function. I am not
able to find a paragraph justifying it in the ARM ARM. I have CCed some
ARM folks to check if I missed something.
> Secondly, why this order of operations? More specifically, why is
> p2m_load_VTTBR done after the HCR_VM bit is unset and before the HCR_RW
> bit is set/unset? Can't we write HCR only once here?
> And finally, I see the function is called by construct_dom0. The code
> there looks like:
>
> /*
> * The following loads use the domain's p2m and require current to
> * be a vcpu of the domain, temporarily switch
> */
> saved_current = current;
> p2m_restore_state(v);
> [...]
> /* Now that we are done restore the original p2m and current. */
> set_current(saved_current);
> p2m_restore_state(saved_current);
>
> I suppose the significant changes p2m_restore_state does for the code in
> between ("[...]") is setting VTTBR & SCTLR which are used by translation
> functions such as gvirt_to_maddr (which seems to use PAR_EL1).
> What I don't grasp is what effect setting the VTTBR has if HCR.HCR_VM is
> unset and left unset...
HCR.VM is not left unset (see why above).
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-22 17:17 ` Julien Grall
@ 2016-06-22 18:39 ` Corneliu ZUZU
2016-06-22 19:37 ` Corneliu ZUZU
2016-06-23 11:00 ` Julien Grall
1 sibling, 1 reply; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-22 18:39 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: Andre Przywara, Stefano Stabellini, Tamas K Lengyel,
Razvan Cojocaru, Steve Capper
On 6/22/2016 8:17 PM, Julien Grall wrote:
> On 22/06/16 17:35, Corneliu ZUZU wrote:
>
>> Julien,
>
> Hello Corneliu,
>
>> I was trying to implement having HCR stored in arch_domain or arch_vcpu
>> as suggested above and I'm a bit confused about the code in
>> p2m_restore_state.
>> I'm hoping you can provide some feedback on this matter. Here's the
>> current implementation of the function:
>>
>> void p2m_restore_state(struct vcpu *n)
>> {
>> register_t hcr;
>>
>> hcr = READ_SYSREG(HCR_EL2);
>> WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
>> isb();
>>
>> p2m_load_VTTBR(n->domain);
>> isb();
>>
>> if ( is_32bit_domain(n->domain) )
>> hcr &= ~HCR_RW;
>> else
>> hcr |= HCR_RW;
>>
>> WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
>> isb();
>>
>> WRITE_SYSREG(hcr, HCR_EL2);
>> isb();
>> }
>>
>> First of all, I see the HCR_VM bit being unset (=0) but I don't quite
>> understand why and even more peculiar is the fact that I couldn't find
>> any place where the bit is set (=1) again.
>
> After the first write to HCR_EL2, "hcr" still have the VM bit set as
> we only mask it. So the second write will re-set the VM bit.
>
Ooh..right. Don't know how I missed that, I guess I was too focused in
finding a -different- place where HCR was modified.
> I am not sure why the VM bit is unset/set in this function. I am not
> able to find a paragraph justifying it in the ARM ARM. I have CCed
> some ARM folks to check if I missed something.
>
An answer to that would be useful. I'm also curious if there's a reason
why HCR_RW is set/unset afterwards and not before and why there's an
isb() after calling p2m_load_VTTBR if that function already has an isb()
@ its end.
>> Secondly, why this order of operations? More specifically, why is
>> p2m_load_VTTBR done after the HCR_VM bit is unset and before the HCR_RW
>> bit is set/unset? Can't we write HCR only once here?
>> And finally, I see the function is called by construct_dom0. The code
>> there looks like:
>>
>> /*
>> * The following loads use the domain's p2m and require current to
>> * be a vcpu of the domain, temporarily switch
>> */
>> saved_current = current;
>> p2m_restore_state(v);
>> [...]
>> /* Now that we are done restore the original p2m and current. */
>> set_current(saved_current);
>> p2m_restore_state(saved_current);
>>
>> I suppose the significant changes p2m_restore_state does for the code in
>> between ("[...]") is setting VTTBR & SCTLR which are used by translation
>> functions such as gvirt_to_maddr (which seems to use PAR_EL1).
>> What I don't grasp is what effect setting the VTTBR has if HCR.HCR_VM is
>> unset and left unset...
>
> HCR.VM is not left unset (see why above).
>
> Regards,
>
Thanks,
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-22 18:39 ` Corneliu ZUZU
@ 2016-06-22 19:37 ` Corneliu ZUZU
2016-06-22 19:41 ` Julien Grall
0 siblings, 1 reply; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-22 19:37 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: Andre Przywara, Stefano Stabellini, Tamas K Lengyel,
Razvan Cojocaru, Steve Capper
On 6/22/2016 9:39 PM, Corneliu ZUZU wrote:
> On 6/22/2016 8:17 PM, Julien Grall wrote:
>> On 22/06/16 17:35, Corneliu ZUZU wrote:
>>
>>> Julien,
>>
>> Hello Corneliu,
>>
>>> I was trying to implement having HCR stored in arch_domain or arch_vcpu
>>> as suggested above and I'm a bit confused about the code in
>>> p2m_restore_state.
>>> I'm hoping you can provide some feedback on this matter. Here's the
>>> current implementation of the function:
>>>
>>> void p2m_restore_state(struct vcpu *n)
>>> {
>>> register_t hcr;
>>>
>>> hcr = READ_SYSREG(HCR_EL2);
>>> WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
>>> isb();
>>>
>>> p2m_load_VTTBR(n->domain);
>>> isb();
>>>
>>> if ( is_32bit_domain(n->domain) )
>>> hcr &= ~HCR_RW;
>>> else
>>> hcr |= HCR_RW;
>>>
>>> WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
>>> isb();
>>>
>>> WRITE_SYSREG(hcr, HCR_EL2);
>>> isb();
>>> }
>>>
>>> First of all, I see the HCR_VM bit being unset (=0) but I don't quite
>>> understand why and even more peculiar is the fact that I couldn't find
>>> any place where the bit is set (=1) again.
>>
>> After the first write to HCR_EL2, "hcr" still have the VM bit set as
>> we only mask it. So the second write will re-set the VM bit.
>>
>
> Ooh..right. Don't know how I missed that, I guess I was too focused in
> finding a -different- place where HCR was modified.
>
>> I am not sure why the VM bit is unset/set in this function. I am not
>> able to find a paragraph justifying it in the ARM ARM. I have CCed
>> some ARM folks to check if I missed something.
>>
>
> An answer to that would be useful. I'm also curious if there's a
> reason why HCR_RW is set/unset afterwards and not before and why
> there's an isb() after calling p2m_load_VTTBR if that function already
> has an isb() @ its end.
>
>>> Secondly, why this order of operations? More specifically, why is
>>> p2m_load_VTTBR done after the HCR_VM bit is unset and before the HCR_RW
>>> bit is set/unset? Can't we write HCR only once here?
>>> And finally, I see the function is called by construct_dom0. The code
>>> there looks like:
>>>
>>> /*
>>> * The following loads use the domain's p2m and require current to
>>> * be a vcpu of the domain, temporarily switch
>>> */
>>> saved_current = current;
>>> p2m_restore_state(v);
>>> [...]
>>> /* Now that we are done restore the original p2m and current. */
>>> set_current(saved_current);
>>> p2m_restore_state(saved_current);
>>>
>>> I suppose the significant changes p2m_restore_state does for the
>>> code in
>>> between ("[...]") is setting VTTBR & SCTLR which are used by
>>> translation
>>> functions such as gvirt_to_maddr (which seems to use PAR_EL1).
>>> What I don't grasp is what effect setting the VTTBR has if
>>> HCR.HCR_VM is
>>> unset and left unset...
>>
>> HCR.VM is not left unset (see why above).
>>
>> Regards,
>>
>
> Thanks,
> Corneliu.
Julien,
I've also realized that it's a bit complicated to avoid writing HCR from
2 places.
That's because:
- p2m_restore_state is part of the process of switching to another vCPU
and the HCR write _must be committed_ here because other components
depend on that, like address-translation functions
- I want vm_event_vcpu_enter to be called _after_ the switch to the vCPU
is completed
- I want HCR_TVM to be set in vm_event_vcpu_enter because setting
necessary traps _for cr vm-events_ to work should be done there (setting
HCR_TVM bit makes sense to be there and the purpose is to centralize
operations such as this for code comprehensibility; also, on the X86
counterpart a similar operation is done for trapping CR3, so it would be
nice to keep the symmetry)
Would it be such a stretch to have HCR written in 2 places? (the second
time happens rarely anyway: it's unlikely(..) to have to do the write in
vm_event_vcpu_enter)
Regards,
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-22 19:37 ` Corneliu ZUZU
@ 2016-06-22 19:41 ` Julien Grall
2016-06-23 5:31 ` Corneliu ZUZU
0 siblings, 1 reply; 73+ messages in thread
From: Julien Grall @ 2016-06-22 19:41 UTC (permalink / raw)
To: Corneliu ZUZU, xen-devel
Cc: Andre Przywara, Stefano Stabellini, Tamas K Lengyel,
Razvan Cojocaru, Steve Capper
On 22/06/2016 20:37, Corneliu ZUZU wrote:
> I've also realized that it's a bit complicated to avoid writing HCR from
> 2 places.
> That's because:
> - p2m_restore_state is part of the process of switching to another vCPU
> and the HCR write _must be committed_ here because other components
> depend on that, like address-translation functions
> - I want vm_event_vcpu_enter to be called _after_ the switch to the vCPU
> is completed
> - I want HCR_TVM to be set in vm_event_vcpu_enter because setting
> necessary traps _for cr vm-events_ to work should be done there (setting
> HCR_TVM bit makes sense to be there and the purpose is to centralize
> operations such as this for code comprehensibility; also, on the X86
> counterpart a similar operation is done for trapping CR3, so it would be
> nice to keep the symmetry)
>
> Would it be such a stretch to have HCR written in 2 places? (the second
> time happens rarely anyway: it's unlikely(..) to have to do the write in
> vm_event_vcpu_enter)
Not really. It was mostly to avoid setting/clearing HCR bits in
different place in the code. It makes more difficult to know what is the
final result of the register.
Anyway, let's skip it for now, if it is too difficult.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-22 19:41 ` Julien Grall
@ 2016-06-23 5:31 ` Corneliu ZUZU
2016-06-23 5:49 ` Corneliu ZUZU
0 siblings, 1 reply; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-23 5:31 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: Andre Przywara, Stefano Stabellini, Tamas K Lengyel,
Razvan Cojocaru, Steve Capper
On 6/22/2016 10:41 PM, Julien Grall wrote:
>
>
> On 22/06/2016 20:37, Corneliu ZUZU wrote:
>> I've also realized that it's a bit complicated to avoid writing HCR from
>> 2 places.
>> That's because:
>> - p2m_restore_state is part of the process of switching to another vCPU
>> and the HCR write _must be committed_ here because other components
>> depend on that, like address-translation functions
>> - I want vm_event_vcpu_enter to be called _after_ the switch to the vCPU
>> is completed
>> - I want HCR_TVM to be set in vm_event_vcpu_enter because setting
>> necessary traps _for cr vm-events_ to work should be done there (setting
>> HCR_TVM bit makes sense to be there and the purpose is to centralize
>> operations such as this for code comprehensibility; also, on the X86
>> counterpart a similar operation is done for trapping CR3, so it would be
>> nice to keep the symmetry)
>>
>> Would it be such a stretch to have HCR written in 2 places? (the second
>> time happens rarely anyway: it's unlikely(..) to have to do the write in
>> vm_event_vcpu_enter)
>
> Not really. It was mostly to avoid setting/clearing HCR bits in
> different place in the code. It makes more difficult to know what is
> the final result of the register.
>
> Anyway, let's skip it for now, if it is too difficult.
>
> Regards,
>
Then perhaps something like the following would be suitable:
1. store hcr in arch_domain (register_t hcr)
2. add a function in asm-arm/processor.h (or where else?) which only does:
static inline void update_hcr(struct domain *d)
{
WRITE_SYSREG(d->arch.hcr, HCR_EL2);
isb();
}
3. modify p2m_restore_state to do:
n->domain->arch.hcr &= ~HCR_VM;
update_hcr(n->domain);
p2m_load_VTTBR(n->domain);
n->domain->arch.hcr |= HCR_VM;
if ( is_32bit_domain(n->domain) )
n->domain->arch.hcr &= ~HCR_RW;
else
n->domain->arch.hcr |= HCR_RW;
update_hcr(n->domain);
WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
isb();
4. and vcpu_enter_adjust_traps to
if ( unlikely(0 != v->domain->arch.monitor.write_ctrlreg_enabled) )
{
if ( likely(v->domain->arch.hcr & HCR_TVM) )
return;
v->domain->arch.hcr |= HCR_TVM;
}
else
{
if ( likely(!(v->domain->arch.hcr & HCR_TVM)) )
return;
v->domain->arch.hcr &= ~HCR_TVM;
}
update_hcr(v->domain);
That way at least it's easier to follow where update_hcr is called.
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-23 5:31 ` Corneliu ZUZU
@ 2016-06-23 5:49 ` Corneliu ZUZU
2016-06-23 11:11 ` Julien Grall
0 siblings, 1 reply; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-23 5:49 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: Andre Przywara, Stefano Stabellini, Tamas K Lengyel,
Razvan Cojocaru, Steve Capper
On 6/23/2016 8:31 AM, Corneliu ZUZU wrote:
> On 6/22/2016 10:41 PM, Julien Grall wrote:
>>
>>
>> On 22/06/2016 20:37, Corneliu ZUZU wrote:
>>> I've also realized that it's a bit complicated to avoid writing HCR
>>> from
>>> 2 places.
>>> That's because:
>>> - p2m_restore_state is part of the process of switching to another vCPU
>>> and the HCR write _must be committed_ here because other components
>>> depend on that, like address-translation functions
>>> - I want vm_event_vcpu_enter to be called _after_ the switch to the
>>> vCPU
>>> is completed
>>> - I want HCR_TVM to be set in vm_event_vcpu_enter because setting
>>> necessary traps _for cr vm-events_ to work should be done there
>>> (setting
>>> HCR_TVM bit makes sense to be there and the purpose is to centralize
>>> operations such as this for code comprehensibility; also, on the X86
>>> counterpart a similar operation is done for trapping CR3, so it
>>> would be
>>> nice to keep the symmetry)
>>>
>>> Would it be such a stretch to have HCR written in 2 places? (the second
>>> time happens rarely anyway: it's unlikely(..) to have to do the
>>> write in
>>> vm_event_vcpu_enter)
>>
>> Not really. It was mostly to avoid setting/clearing HCR bits in
>> different place in the code. It makes more difficult to know what is
>> the final result of the register.
>>
>> Anyway, let's skip it for now, if it is too difficult.
>>
>> Regards,
>>
>
> Then perhaps something like the following would be suitable:
>
> 1. store hcr in arch_domain (register_t hcr)
>
> 2. add a function in asm-arm/processor.h (or where else?) which only
> does:
> static inline void update_hcr(struct domain *d)
> {
> WRITE_SYSREG(d->arch.hcr, HCR_EL2);
> isb();
> }
>
> 3. modify p2m_restore_state to do:
> n->domain->arch.hcr &= ~HCR_VM;
> update_hcr(n->domain);
> p2m_load_VTTBR(n->domain);
>
> n->domain->arch.hcr |= HCR_VM;
>
> if ( is_32bit_domain(n->domain) )
> n->domain->arch.hcr &= ~HCR_RW;
> else
> n->domain->arch.hcr |= HCR_RW;
>
> update_hcr(n->domain);
>
> WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
> isb();
>
> 4. and vcpu_enter_adjust_traps to
>
> if ( unlikely(0 != v->domain->arch.monitor.write_ctrlreg_enabled) )
> {
> if ( likely(v->domain->arch.hcr & HCR_TVM) )
> return;
> v->domain->arch.hcr |= HCR_TVM;
> }
> else
> {
> if ( likely(!(v->domain->arch.hcr & HCR_TVM)) )
> return;
> v->domain->arch.hcr &= ~HCR_TVM;
> }
>
> update_hcr(v->domain);
>
> That way at least it's easier to follow where update_hcr is called.
>
> Corneliu.
And also set the initial value of HCR at the moment of creation, i.e. in
arch_domain_create as
d->arch.hcr = READ_SYSREG(HCR_EL2)
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-22 17:17 ` Julien Grall
2016-06-22 18:39 ` Corneliu ZUZU
@ 2016-06-23 11:00 ` Julien Grall
1 sibling, 0 replies; 73+ messages in thread
From: Julien Grall @ 2016-06-23 11:00 UTC (permalink / raw)
To: Corneliu ZUZU, xen-devel
Cc: Andre Przywara, Stefano Stabellini, Tamas K Lengyel,
Razvan Cojocaru, Steve Capper
Hello,
On 22/06/16 18:17, Julien Grall wrote:
> On 22/06/16 17:35, Corneliu ZUZU wrote:
>
>> Julien,
>
> Hello Corneliu,
>
>> I was trying to implement having HCR stored in arch_domain or arch_vcpu
>> as suggested above and I'm a bit confused about the code in
>> p2m_restore_state.
>> I'm hoping you can provide some feedback on this matter. Here's the
>> current implementation of the function:
>>
>> void p2m_restore_state(struct vcpu *n)
>> {
>> register_t hcr;
>>
>> hcr = READ_SYSREG(HCR_EL2);
>> WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
>> isb();
>>
>> p2m_load_VTTBR(n->domain);
>> isb();
>>
>> if ( is_32bit_domain(n->domain) )
>> hcr &= ~HCR_RW;
>> else
>> hcr |= HCR_RW;
>>
>> WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
>> isb();
>>
>> WRITE_SYSREG(hcr, HCR_EL2);
>> isb();
>> }
>>
>> First of all, I see the HCR_VM bit being unset (=0) but I don't quite
>> understand why and even more peculiar is the fact that I couldn't find
>> any place where the bit is set (=1) again.
>
> After the first write to HCR_EL2, "hcr" still have the VM bit set as we
> only mask it. So the second write will re-set the VM bit.
>
> I am not sure why the VM bit is unset/set in this function. I am not
> able to find a paragraph justifying it in the ARM ARM. I have CCed some
> ARM folks to check if I missed something.
After talking with different ARM folks, I confirm that it is not
necessary to disable the HCR_VM before setting TTBR0.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-23 5:49 ` Corneliu ZUZU
@ 2016-06-23 11:11 ` Julien Grall
2016-06-24 9:32 ` Corneliu ZUZU
0 siblings, 1 reply; 73+ messages in thread
From: Julien Grall @ 2016-06-23 11:11 UTC (permalink / raw)
To: Corneliu ZUZU, xen-devel
Cc: Andre Przywara, Stefano Stabellini, Tamas K Lengyel,
Razvan Cojocaru, Steve Capper
Hello,
On 23/06/16 06:49, Corneliu ZUZU wrote:
> On 6/23/2016 8:31 AM, Corneliu ZUZU wrote:
>> On 6/22/2016 10:41 PM, Julien Grall wrote:
>>>
>>>
>>> On 22/06/2016 20:37, Corneliu ZUZU wrote:
>>>> I've also realized that it's a bit complicated to avoid writing HCR
>>>> from
>>>> 2 places.
>>>> That's because:
>>>> - p2m_restore_state is part of the process of switching to another vCPU
>>>> and the HCR write _must be committed_ here because other components
>>>> depend on that, like address-translation functions
>>>> - I want vm_event_vcpu_enter to be called _after_ the switch to the
>>>> vCPU
>>>> is completed
>>>> - I want HCR_TVM to be set in vm_event_vcpu_enter because setting
>>>> necessary traps _for cr vm-events_ to work should be done there
>>>> (setting
>>>> HCR_TVM bit makes sense to be there and the purpose is to centralize
>>>> operations such as this for code comprehensibility; also, on the X86
>>>> counterpart a similar operation is done for trapping CR3, so it
>>>> would be
>>>> nice to keep the symmetry)
>>>>
>>>> Would it be such a stretch to have HCR written in 2 places? (the second
>>>> time happens rarely anyway: it's unlikely(..) to have to do the
>>>> write in
>>>> vm_event_vcpu_enter)
>>>
>>> Not really. It was mostly to avoid setting/clearing HCR bits in
>>> different place in the code. It makes more difficult to know what is
>>> the final result of the register.
>>>
>>> Anyway, let's skip it for now, if it is too difficult.
>>>
>>> Regards,
>>>
>>
>> Then perhaps something like the following would be suitable:
>>
>> 1. store hcr in arch_domain (register_t hcr)
>>
>> 2. add a function in asm-arm/processor.h (or where else?) which only
>> does:
>> static inline void update_hcr(struct domain *d)
>> {
>> WRITE_SYSREG(d->arch.hcr, HCR_EL2);
>> isb();
>> }
>>
>> 3. modify p2m_restore_state to do:
>> n->domain->arch.hcr &= ~HCR_VM;
>> update_hcr(n->domain);
>> p2m_load_VTTBR(n->domain);
>>
>> n->domain->arch.hcr |= HCR_VM;
>>
>> if ( is_32bit_domain(n->domain) )
>> n->domain->arch.hcr &= ~HCR_RW;
>> else
>> n->domain->arch.hcr |= HCR_RW;
This is not safe at all, p2m_restore_state is vCPU specific at you
modify domain information.
However, if we store the hcr per domain, overriding every context switch
is pointless as the domain will always be 32-bit/64-bit.
>>
>> update_hcr(n->domain);
>>
>> WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
>> isb();
>>
>> 4. and vcpu_enter_adjust_traps to
>>
>> if ( unlikely(0 != v->domain->arch.monitor.write_ctrlreg_enabled) )
>> {
>> if ( likely(v->domain->arch.hcr & HCR_TVM) )
>> return;
>> v->domain->arch.hcr |= HCR_TVM;
>> }
>> else
>> {
>> if ( likely(!(v->domain->arch.hcr & HCR_TVM)) )
>> return;
>> v->domain->arch.hcr &= ~HCR_TVM;
>> }
This does not need to be done in vcpu_enter_adjust_traps everytime. You
can set the bit in arch.hcr in DOMCTL_MONITOR_EVENT_WRITE_CTRLREG.
>>
>> update_hcr(v->domain);
>>
>> That way at least it's easier to follow where update_hcr is called.
I don't see much reason to store the value in the domain and have
multiple update_hcr. If we store the value, then we should only call
update_hcr once when returning to the guest.
> And also set the initial value of HCR at the moment of creation, i.e. in
> arch_domain_create as
>
> d->arch.hcr = READ_SYSREG(HCR_EL2)
We control the value of HCR_EL2, so it would be better to assign the
list of flags here.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
2016-06-23 11:11 ` Julien Grall
@ 2016-06-24 9:32 ` Corneliu ZUZU
0 siblings, 0 replies; 73+ messages in thread
From: Corneliu ZUZU @ 2016-06-24 9:32 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: Andre Przywara, Stefano Stabellini, Tamas K Lengyel,
Razvan Cojocaru, Steve Capper
On 6/23/2016 2:11 PM, Julien Grall wrote:
> Hello,
>
> On 23/06/16 06:49, Corneliu ZUZU wrote:
>> On 6/23/2016 8:31 AM, Corneliu ZUZU wrote:
>>> On 6/22/2016 10:41 PM, Julien Grall wrote:
>>>>
>>>>
>>>> On 22/06/2016 20:37, Corneliu ZUZU wrote:
>>>>> I've also realized that it's a bit complicated to avoid writing HCR
>>>>> from
>>>>> 2 places.
>>>>> That's because:
>>>>> - p2m_restore_state is part of the process of switching to another
>>>>> vCPU
>>>>> and the HCR write _must be committed_ here because other components
>>>>> depend on that, like address-translation functions
>>>>> - I want vm_event_vcpu_enter to be called _after_ the switch to the
>>>>> vCPU
>>>>> is completed
>>>>> - I want HCR_TVM to be set in vm_event_vcpu_enter because setting
>>>>> necessary traps _for cr vm-events_ to work should be done there
>>>>> (setting
>>>>> HCR_TVM bit makes sense to be there and the purpose is to centralize
>>>>> operations such as this for code comprehensibility; also, on the X86
>>>>> counterpart a similar operation is done for trapping CR3, so it
>>>>> would be
>>>>> nice to keep the symmetry)
>>>>>
>>>>> Would it be such a stretch to have HCR written in 2 places? (the
>>>>> second
>>>>> time happens rarely anyway: it's unlikely(..) to have to do the
>>>>> write in
>>>>> vm_event_vcpu_enter)
>>>>
>>>> Not really. It was mostly to avoid setting/clearing HCR bits in
>>>> different place in the code. It makes more difficult to know what is
>>>> the final result of the register.
>>>>
>>>> Anyway, let's skip it for now, if it is too difficult.
>>>>
>>>> Regards,
>>>>
>>>
>>> Then perhaps something like the following would be suitable:
>>>
>>> 1. store hcr in arch_domain (register_t hcr)
>>>
>>> 2. add a function in asm-arm/processor.h (or where else?) which only
>>> does:
>>> static inline void update_hcr(struct domain *d)
>>> {
>>> WRITE_SYSREG(d->arch.hcr, HCR_EL2);
>>> isb();
>>> }
>>>
>>> 3. modify p2m_restore_state to do:
>>> n->domain->arch.hcr &= ~HCR_VM;
>>> update_hcr(n->domain);
>>> p2m_load_VTTBR(n->domain);
>>>
>>> n->domain->arch.hcr |= HCR_VM;
>>>
>>> if ( is_32bit_domain(n->domain) )
>>> n->domain->arch.hcr &= ~HCR_RW;
>>> else
>>> n->domain->arch.hcr |= HCR_RW;
>
> This is not safe at all, p2m_restore_state is vCPU specific at you
> modify domain information.
>
> However, if we store the hcr per domain, overriding every context
> switch is pointless as the domain will always be 32-bit/64-bit.
Oh right, the RW bit needs not be set/unset anymore with this change.
>
>>>
>>> update_hcr(n->domain);
>>>
>>> WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
>>> isb();
>>>
>>> 4. and vcpu_enter_adjust_traps to
>>>
>>> if ( unlikely(0 != v->domain->arch.monitor.write_ctrlreg_enabled) )
>>> {
>>> if ( likely(v->domain->arch.hcr & HCR_TVM) )
>>> return;
>>> v->domain->arch.hcr |= HCR_TVM;
>>> }
>>> else
>>> {
>>> if ( likely(!(v->domain->arch.hcr & HCR_TVM)) )
>>> return;
>>> v->domain->arch.hcr &= ~HCR_TVM;
>>> }
>
> This does not need to be done in vcpu_enter_adjust_traps everytime.
> You can set the bit in arch.hcr in DOMCTL_MONITOR_EVENT_WRITE_CTRLREG.
I wanted to keep X86-ARM symmetry and it seemed more intuitive to have
these kind of adjustments with the vcpu_enter code motion. But now that
I think about it, given the fact that we have the guarantee that after
monitor_domctl and before reentering the vCPU p2m_restore_state gets
called (due to domain_pause/domain_unpause) - thus actually committing
the hcr update at the proper time - technically monitor_domctl _is_ the
optimal place to set arch.hcr in. In conclusion, I'm thinking of
discarding the entire idea of introducing vm_event_vcpu_enter, it seems
to me now that this would also render a simpler code.
>
>>>
>>> update_hcr(v->domain);
>>>
>>> That way at least it's easier to follow where update_hcr is called.
>
> I don't see much reason to store the value in the domain and have
> multiple update_hcr. If we store the value, then we should only call
> update_hcr once when returning to the guest.
Yep, that will happen with the above-mentioned discarding of
vm_event_vcpu_enter idea.
>
>> And also set the initial value of HCR at the moment of creation, i.e. in
>> arch_domain_create as
>>
>> d->arch.hcr = READ_SYSREG(HCR_EL2)
>
> We control the value of HCR_EL2, so it would be better to assign the
> list of flags here.
Right, that will happen too.
>
> Regards,
>
Thanks for the useful insights,
Corneliu.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 73+ messages in thread
end of thread, other threads:[~2016-06-24 9:32 UTC | newest]
Thread overview: 73+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-16 14:04 [PATCH 0/7] vm-event: Implement ARM support for control-register writes Corneliu ZUZU
2016-06-16 14:06 ` [PATCH 1/7] minor (formatting) fixes Corneliu ZUZU
2016-06-16 14:24 ` Jan Beulich
2016-06-16 19:19 ` Corneliu ZUZU
2016-06-17 7:06 ` Jan Beulich
2016-06-17 10:46 ` Corneliu ZUZU
2016-06-16 16:02 ` Tamas K Lengyel
2016-06-17 8:33 ` Corneliu ZUZU
2016-06-17 8:36 ` Razvan Cojocaru
2016-06-17 9:29 ` Andrew Cooper
2016-06-17 9:35 ` Jan Beulich
2016-06-17 9:33 ` Jan Beulich
2016-06-17 9:36 ` Razvan Cojocaru
2016-06-17 9:40 ` Jan Beulich
2016-06-17 9:42 ` Razvan Cojocaru
2016-06-17 19:05 ` Tamas K Lengyel
2016-06-16 14:07 ` [PATCH 2/7] vm-event: VM_EVENT_FLAG_DENY requires VM_EVENT_FLAG_VCPU_PAUSED Corneliu ZUZU
2016-06-16 16:11 ` Tamas K Lengyel
2016-06-17 8:43 ` Corneliu ZUZU
2016-06-21 11:26 ` Corneliu ZUZU
2016-06-21 15:09 ` Tamas K Lengyel
2016-06-22 8:34 ` Corneliu ZUZU
2016-06-16 14:08 ` [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter Corneliu ZUZU
2016-06-16 14:51 ` Jan Beulich
2016-06-16 20:10 ` Corneliu ZUZU
2016-06-16 20:33 ` Razvan Cojocaru
2016-06-17 10:41 ` Corneliu ZUZU
2016-06-17 7:17 ` Jan Beulich
2016-06-17 11:13 ` Corneliu ZUZU
2016-06-17 11:27 ` Jan Beulich
2016-06-17 12:13 ` Corneliu ZUZU
2016-06-16 16:17 ` Tamas K Lengyel
2016-06-17 9:19 ` Corneliu ZUZU
2016-06-17 8:55 ` Julien Grall
2016-06-17 11:40 ` Corneliu ZUZU
2016-06-17 13:22 ` Julien Grall
2016-06-16 14:09 ` [PATCH 4/7] vm-event/x86: use vm_event_vcpu_enter properly Corneliu ZUZU
2016-06-16 15:00 ` Jan Beulich
2016-06-16 20:20 ` Corneliu ZUZU
2016-06-17 7:20 ` Jan Beulich
2016-06-17 11:23 ` Corneliu ZUZU
2016-06-16 16:27 ` Tamas K Lengyel
2016-06-17 9:24 ` Corneliu ZUZU
2016-06-16 14:10 ` [PATCH 5/7] x86: replace monitor_write_data.do_write with enum Corneliu ZUZU
2016-06-16 14:12 ` [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr Corneliu ZUZU
2016-06-16 15:16 ` Jan Beulich
2016-06-17 8:25 ` Corneliu ZUZU
2016-06-17 8:38 ` Jan Beulich
2016-06-17 11:31 ` Corneliu ZUZU
2016-06-21 7:08 ` Corneliu ZUZU
2016-06-21 7:20 ` Jan Beulich
2016-06-21 15:22 ` Tamas K Lengyel
2016-06-22 6:33 ` Jan Beulich
2016-06-16 16:55 ` Tamas K Lengyel
2016-06-17 10:37 ` Corneliu ZUZU
2016-06-16 14:13 ` [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events Corneliu ZUZU
2016-06-16 14:26 ` Julien Grall
2016-06-16 19:24 ` Corneliu ZUZU
2016-06-16 21:28 ` Julien Grall
2016-06-17 11:46 ` Corneliu ZUZU
2016-06-16 16:49 ` Julien Grall
2016-06-17 10:36 ` Corneliu ZUZU
2016-06-17 13:18 ` Julien Grall
2016-06-22 16:35 ` Corneliu ZUZU
2016-06-22 17:17 ` Julien Grall
2016-06-22 18:39 ` Corneliu ZUZU
2016-06-22 19:37 ` Corneliu ZUZU
2016-06-22 19:41 ` Julien Grall
2016-06-23 5:31 ` Corneliu ZUZU
2016-06-23 5:49 ` Corneliu ZUZU
2016-06-23 11:11 ` Julien Grall
2016-06-24 9:32 ` Corneliu ZUZU
2016-06-23 11:00 ` Julien Grall
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).