* [PATCH V3] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
@ 2016-11-11 8:06 Razvan Cojocaru
2016-11-11 10:02 ` Jan Beulich
2016-11-11 15:09 ` Tamas K Lengyel
0 siblings, 2 replies; 10+ messages in thread
From: Razvan Cojocaru @ 2016-11-11 8:06 UTC (permalink / raw)
To: xen-devel
Cc: kevin.tian, tamas, suravee.suthikulpanit, Razvan Cojocaru,
andrew.cooper3, julien.grall, jbeulich, sstabellini, jun.nakajima,
boris.ostrovsky
Added support for a new event type, VM_EVENT_REASON_INTERRUPT,
which is now fired in a one-shot manner when enabled via the new
VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.
The patch also fixes the behaviour of the xc_hvm_inject_trap()
hypercall, which would lead to non-architectural interrupts
overwriting pending (specifically reinjected) architectural ones.
Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
---
Changes since V2:
- Clarified VM_EVENT_FLAG_GET_NEXT_INTERRUPT comment.
- Removed monitor_next_interrupt from struct arch_vm_event, and
put the flag in the v->arch.monitor.next_interrupt_enabled
bitfield, to separate the vm_event / monitor code and mirror
the domain.h structure.
- Moved the SVM and VMX assignments of .get_pending_event to
reflect their previous move in struct hvm_function_table.
- Made hvm_get_pending_event() static.
- Fixed vm_event_interrupt_x86 padding.
---
xen/arch/x86/hvm/hvm.c | 22 +++++++++++++++++++++-
xen/arch/x86/hvm/monitor.c | 14 ++++++++++++++
xen/arch/x86/hvm/svm/svm.c | 15 +++++++++++++++
xen/arch/x86/hvm/vmx/vmx.c | 20 ++++++++++++++++++++
xen/arch/x86/vm_event.c | 5 +++++
xen/common/vm_event.c | 3 +++
xen/include/asm-arm/vm_event.h | 6 ++++++
xen/include/asm-x86/domain.h | 4 ++++
xen/include/asm-x86/hvm/hvm.h | 1 +
xen/include/asm-x86/hvm/monitor.h | 2 ++
xen/include/asm-x86/monitor.h | 3 ++-
xen/include/public/domctl.h | 1 +
xen/include/public/vm_event.h | 18 ++++++++++++++++++
xen/include/xen/vm_event.h | 2 ++
14 files changed, 114 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 704fd64..e4430fd 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -469,6 +469,12 @@ void hvm_migrate_pirqs(struct vcpu *v)
spin_unlock(&d->event_lock);
}
+static bool hvm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
+{
+ info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
+ return hvm_funcs.get_pending_event(v, info);
+}
+
void hvm_do_resume(struct vcpu *v)
{
check_wakeup_from_wait();
@@ -535,9 +541,23 @@ void hvm_do_resume(struct vcpu *v)
/* Inject pending hw/sw trap */
if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
{
- hvm_inject_trap(&v->arch.hvm_vcpu.inject_trap);
+ if ( !hvm_event_pending(v) )
+ hvm_inject_trap(&v->arch.hvm_vcpu.inject_trap);
+
v->arch.hvm_vcpu.inject_trap.vector = -1;
}
+
+ if ( unlikely(v->arch.vm_event) && v->arch.monitor.next_interrupt_enabled )
+ {
+ struct hvm_trap info;
+
+ if ( hvm_get_pending_event(v, &info) )
+ {
+ hvm_monitor_interrupt(info.vector, info.type, info.error_code,
+ info.cr2);
+ v->arch.monitor.next_interrupt_enabled = 0;
+ }
+ }
}
static int hvm_print_line(
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index 401a8c6..69a88ad 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -150,6 +150,20 @@ int hvm_monitor_cpuid(unsigned long insn_length, unsigned int leaf,
return monitor_traps(curr, 1, &req);
}
+void hvm_monitor_interrupt(unsigned int vector, unsigned int type,
+ unsigned int err, uint64_t cr2)
+{
+ vm_event_request_t req = {
+ .reason = VM_EVENT_REASON_INTERRUPT,
+ .u.interrupt.x86.vector = vector,
+ .u.interrupt.x86.type = type,
+ .u.interrupt.x86.error_code = err,
+ .u.interrupt.x86.cr2 = cr2,
+ };
+
+ monitor_traps(current, 1, &req);
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 16427f6..a4fd69a 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2220,6 +2220,20 @@ static void svm_invlpg(struct vcpu *v, unsigned long vaddr)
svm_asid_g_invlpg(v, vaddr);
}
+static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
+{
+ struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+
+ if ( vmcb->eventinj.fields.v )
+ return false;
+
+ info->vector = vmcb->eventinj.fields.vector;
+ info->type = vmcb->eventinj.fields.type;
+ info->error_code = vmcb->eventinj.fields.errorcode;
+
+ return true;
+}
+
static struct hvm_function_table __initdata svm_function_table = {
.name = "SVM",
.cpu_up_prepare = svm_cpu_up_prepare,
@@ -2250,6 +2264,7 @@ static struct hvm_function_table __initdata svm_function_table = {
.inject_trap = svm_inject_trap,
.init_hypercall_page = svm_init_hypercall_page,
.event_pending = svm_event_pending,
+ .get_pending_event = svm_get_pending_event,
.invlpg = svm_invlpg,
.cpuid_intercept = svm_cpuid_intercept,
.wbinvd_intercept = svm_wbinvd_intercept,
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 9a8f694..961a20b 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2134,6 +2134,25 @@ static int vmx_set_mode(struct vcpu *v, int mode)
return 0;
}
+static bool vmx_get_pending_event(struct vcpu *v, struct hvm_trap *info)
+{
+ unsigned long intr_info, error_code;
+
+ vmx_vmcs_enter(v);
+ __vmread(VM_ENTRY_INTR_INFO, &intr_info);
+ __vmread(VM_ENTRY_EXCEPTION_ERROR_CODE, &error_code);
+ vmx_vmcs_exit(v);
+
+ if ( !(intr_info & INTR_INFO_VALID_MASK) )
+ return false;
+
+ info->vector = MASK_EXTR(intr_info, INTR_INFO_VECTOR_MASK);
+ info->type = MASK_EXTR(intr_info, INTR_INFO_INTR_TYPE_MASK);
+ info->error_code = error_code;
+
+ return true;
+}
+
static struct hvm_function_table __initdata vmx_function_table = {
.name = "VMX",
.cpu_up_prepare = vmx_cpu_up_prepare,
@@ -2163,6 +2182,7 @@ static struct hvm_function_table __initdata vmx_function_table = {
.inject_trap = vmx_inject_trap,
.init_hypercall_page = vmx_init_hypercall_page,
.event_pending = vmx_event_pending,
+ .get_pending_event = vmx_get_pending_event,
.invlpg = vmx_invlpg,
.cpu_up = vmx_cpu_up,
.cpu_down = vmx_cpu_down,
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 1e88d67..89667cb 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -134,6 +134,11 @@ void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp)
v->arch.user_regs.eip = rsp->data.regs.x86.rip;
}
+void vm_event_monitor_next_interrupt(struct vcpu *v)
+{
+ v->arch.monitor.next_interrupt_enabled = 1;
+}
+
void vm_event_fill_regs(vm_event_request_t *req)
{
const struct cpu_user_regs *regs = guest_cpu_user_regs();
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 907ab40..c947706 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -433,6 +433,9 @@ void vm_event_resume(struct domain *d, struct vm_event_domain *ved)
if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
vm_event_set_registers(v, &rsp);
+ if ( rsp.flags & VM_EVENT_FLAG_GET_NEXT_INTERRUPT )
+ vm_event_monitor_next_interrupt(v);
+
if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
vm_event_vcpu_unpause(v);
}
diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index 66f2474..ab9c8cb 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -52,4 +52,10 @@ void vm_event_emulate_check(struct vcpu *v, vm_event_response_t *rsp)
/* Not supported on ARM. */
}
+static inline
+void vm_event_monitor_next_interrupt(struct vcpu *v)
+{
+ /* Not supported on ARM. */
+}
+
#endif /* __ASM_ARM_VM_EVENT_H__ */
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index f6a40eb..faa7037 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -576,6 +576,10 @@ struct arch_vcpu
XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
struct arch_vm_event *vm_event;
+
+ struct {
+ unsigned int next_interrupt_enabled : 1;
+ } monitor;
};
smap_check_policy_t smap_policy_change(struct vcpu *v,
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 7e7462e..4cb76b5 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -157,6 +157,7 @@ struct hvm_function_table {
void (*init_hypercall_page)(struct domain *d, void *hypercall_page);
int (*event_pending)(struct vcpu *v);
+ bool (*get_pending_event)(struct vcpu *v, struct hvm_trap *info);
void (*invlpg)(struct vcpu *v, unsigned long vaddr);
int (*cpu_up_prepare)(unsigned int cpu);
diff --git a/xen/include/asm-x86/hvm/monitor.h b/xen/include/asm-x86/hvm/monitor.h
index 82b85ec..85ca678 100644
--- a/xen/include/asm-x86/hvm/monitor.h
+++ b/xen/include/asm-x86/hvm/monitor.h
@@ -42,6 +42,8 @@ int hvm_monitor_debug(unsigned long rip, enum hvm_monitor_debug_type type,
unsigned long trap_type, unsigned long insn_length);
int hvm_monitor_cpuid(unsigned long insn_length, unsigned int leaf,
unsigned int subleaf);
+void hvm_monitor_interrupt(unsigned int vector, unsigned int type,
+ unsigned int err, uint64_t cr2);
#endif /* __ASM_X86_HVM_MONITOR_H__ */
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index 63a994b..e409373 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -76,7 +76,8 @@ static inline uint32_t arch_monitor_get_capabilities(struct domain *d)
(1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
(1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
(1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
- (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID);
+ (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
+ (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT);
/* Since we know this is on VMX, we can just call the hvm func */
if ( hvm_is_singlestep_supported() )
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 177319d..85cbb7c 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1086,6 +1086,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cmt_op_t);
#define XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION 5
#define XEN_DOMCTL_MONITOR_EVENT_CPUID 6
#define XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL 7
+#define XEN_DOMCTL_MONITOR_EVENT_INTERRUPT 8
struct xen_domctl_monitor_op {
uint32_t op; /* XEN_DOMCTL_MONITOR_OP_* */
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index c28be5a..b7487a1 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -105,6 +105,11 @@
* if any of those flags are set, only those will be honored).
*/
#define VM_EVENT_FLAG_SET_EMUL_INSN_DATA (1 << 9)
+/*
+ * Have a one-shot VM_EVENT_REASON_INTERRUPT event sent for the first
+ * interrupt pending after resuming the VCPU.
+ */
+#define VM_EVENT_FLAG_GET_NEXT_INTERRUPT (1 << 10)
/*
* Reasons for the vm event request
@@ -139,6 +144,8 @@
* These kinds of events will be filtered out in future versions.
*/
#define VM_EVENT_REASON_PRIVILEGED_CALL 11
+/* An interrupt has been delivered. */
+#define VM_EVENT_REASON_INTERRUPT 12
/* Supported values for the vm_event_write_ctrlreg index. */
#define VM_EVENT_X86_CR0 0
@@ -259,6 +266,14 @@ struct vm_event_cpuid {
uint32_t _pad;
};
+struct vm_event_interrupt_x86 {
+ uint32_t vector;
+ uint32_t type;
+ uint32_t error_code;
+ uint32_t _pad;
+ uint64_t cr2;
+};
+
#define MEM_PAGING_DROP_PAGE (1 << 0)
#define MEM_PAGING_EVICT_FAIL (1 << 1)
@@ -302,6 +317,9 @@ typedef struct vm_event_st {
struct vm_event_debug software_breakpoint;
struct vm_event_debug debug_exception;
struct vm_event_cpuid cpuid;
+ union {
+ struct vm_event_interrupt_x86 x86;
+ } interrupt;
} u;
union {
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index 4f088c8..2fb3951 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -78,6 +78,8 @@ void vm_event_vcpu_unpause(struct vcpu *v);
void vm_event_fill_regs(vm_event_request_t *req);
void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp);
+void vm_event_monitor_next_interrupt(struct vcpu *v);
+
#endif /* __VM_EVENT_H__ */
/*
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH V3] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
2016-11-11 8:06 [PATCH V3] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT Razvan Cojocaru
@ 2016-11-11 10:02 ` Jan Beulich
2016-11-11 10:15 ` Razvan Cojocaru
2016-11-11 15:09 ` Tamas K Lengyel
1 sibling, 1 reply; 10+ messages in thread
From: Jan Beulich @ 2016-11-11 10:02 UTC (permalink / raw)
To: Razvan Cojocaru
Cc: kevin.tian, sstabellini, suravee.suthikulpanit, andrew.cooper3,
xen-devel, julien.grall, tamas, jun.nakajima, boris.ostrovsky
>>> On 11.11.16 at 09:06, <rcojocaru@bitdefender.com> wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -2220,6 +2220,20 @@ static void svm_invlpg(struct vcpu *v, unsigned long vaddr)
> svm_asid_g_invlpg(v, vaddr);
> }
>
> +static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
> +{
> + struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
const please.
> --- a/xen/arch/x86/vm_event.c
> +++ b/xen/arch/x86/vm_event.c
> @@ -134,6 +134,11 @@ void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp)
> v->arch.user_regs.eip = rsp->data.regs.x86.rip;
> }
>
> +void vm_event_monitor_next_interrupt(struct vcpu *v)
> +{
> + v->arch.monitor.next_interrupt_enabled = 1;
true?
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -576,6 +576,10 @@ struct arch_vcpu
> XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
>
> struct arch_vm_event *vm_event;
> +
> + struct {
> + unsigned int next_interrupt_enabled : 1;
bool? Stray spaces. And then (sorry for thinking of this only now) - is
this really usefully an arch-specific flag? I guess there's nothing
precluding this from also being implemented on ARM eventually?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH V3] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
2016-11-11 10:02 ` Jan Beulich
@ 2016-11-11 10:15 ` Razvan Cojocaru
2016-11-11 10:26 ` Jan Beulich
0 siblings, 1 reply; 10+ messages in thread
From: Razvan Cojocaru @ 2016-11-11 10:15 UTC (permalink / raw)
To: Jan Beulich
Cc: kevin.tian, sstabellini, suravee.suthikulpanit, andrew.cooper3,
xen-devel, julien.grall, tamas, jun.nakajima, boris.ostrovsky
On 11/11/2016 12:02 PM, Jan Beulich wrote:
>>>> On 11.11.16 at 09:06, <rcojocaru@bitdefender.com> wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -2220,6 +2220,20 @@ static void svm_invlpg(struct vcpu *v, unsigned long vaddr)
>> svm_asid_g_invlpg(v, vaddr);
>> }
>>
>> +static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
>> +{
>> + struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>
> const please.
Will do.
>> --- a/xen/arch/x86/vm_event.c
>> +++ b/xen/arch/x86/vm_event.c
>> @@ -134,6 +134,11 @@ void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp)
>> v->arch.user_regs.eip = rsp->data.regs.x86.rip;
>> }
>>
>> +void vm_event_monitor_next_interrupt(struct vcpu *v)
>> +{
>> + v->arch.monitor.next_interrupt_enabled = 1;
>
> true?
This is no longer bool, so I can't assign true here.
>> --- a/xen/include/asm-x86/domain.h
>> +++ b/xen/include/asm-x86/domain.h
>> @@ -576,6 +576,10 @@ struct arch_vcpu
>> XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
>>
>> struct arch_vm_event *vm_event;
>> +
>> + struct {
>> + unsigned int next_interrupt_enabled : 1;
>
> bool? Stray spaces. And then (sorry for thinking of this only now) - is
> this really usefully an arch-specific flag? I guess there's nothing
> precluding this from also being implemented on ARM eventually?
Stray spaces? Do you mean the newline between "struct arch_vm_event
*vm_event;" and "struct {"?
I'd prefer to leave this as a bitfield for consistency. That is how it
also works in struct arch_domain from xen/include/asm-x86/domain.h:
399 /* Arch-specific monitor options */
400 struct {
401 unsigned int write_ctrlreg_enabled : 4;
402 unsigned int write_ctrlreg_sync : 4;
403 unsigned int write_ctrlreg_onchangeonly : 4;
404 unsigned int singlestep_enabled : 1;
405 unsigned int software_breakpoint_enabled : 1;
406 unsigned int debug_exception_enabled : 1;
407 unsigned int debug_exception_sync : 1;
408 unsigned int cpuid_enabled : 1;
409 struct monitor_msr_bitmap *msr_bitmap;
410 } monitor;
Which leads to your next question: nothing precludes this from also
being implemented on ARM at some point, however the convention so far
has been to have a "monitor" for x86 with all the supported options, and
one for ARM:
130 /* Monitor options */
131 struct {
132 uint8_t privileged_call_enabled : 1;
133 } monitor;
So if and when this does get implemented for ARM, we would expect a
struct monitor to pop up in struct arch_vcpu in
xen/include/asm-arm/domain.h as well.
I'll submit a V4 with the const-ified VMX structure and the newline
removed from domain.h.
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH V3] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
2016-11-11 10:15 ` Razvan Cojocaru
@ 2016-11-11 10:26 ` Jan Beulich
2016-11-11 10:32 ` Razvan Cojocaru
0 siblings, 1 reply; 10+ messages in thread
From: Jan Beulich @ 2016-11-11 10:26 UTC (permalink / raw)
To: Razvan Cojocaru
Cc: kevin.tian, sstabellini, suravee.suthikulpanit, andrew.cooper3,
xen-devel, julien.grall, tamas, jun.nakajima, boris.ostrovsky
>>> On 11.11.16 at 11:15, <rcojocaru@bitdefender.com> wrote:
> On 11/11/2016 12:02 PM, Jan Beulich wrote:
>>>>> On 11.11.16 at 09:06, <rcojocaru@bitdefender.com> wrote:
>>> --- a/xen/include/asm-x86/domain.h
>>> +++ b/xen/include/asm-x86/domain.h
>>> @@ -576,6 +576,10 @@ struct arch_vcpu
>>> XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
>>>
>>> struct arch_vm_event *vm_event;
>>> +
>>> + struct {
>>> + unsigned int next_interrupt_enabled : 1;
>>
>> bool? Stray spaces. And then (sorry for thinking of this only now) - is
>> this really usefully an arch-specific flag? I guess there's nothing
>> precluding this from also being implemented on ARM eventually?
>
> Stray spaces? Do you mean the newline between "struct arch_vm_event
> *vm_event;" and "struct {"?
No. I mean the ones around the colon.
> I'd prefer to leave this as a bitfield for consistency.
Use of bool doesn't preclude the use of a bitfield.
> Which leads to your next question: nothing precludes this from also
> being implemented on ARM at some point, however the convention so far
> has been to have a "monitor" for x86 with all the supported options, and
> one for ARM:
>
> 130 /* Monitor options */
> 131 struct {
> 132 uint8_t privileged_call_enabled : 1;
> 133 } monitor;
I'll leave that part to you and Tamas, as the maintainers of the
subsystem.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH V3] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
2016-11-11 10:26 ` Jan Beulich
@ 2016-11-11 10:32 ` Razvan Cojocaru
2016-11-11 11:09 ` Jan Beulich
0 siblings, 1 reply; 10+ messages in thread
From: Razvan Cojocaru @ 2016-11-11 10:32 UTC (permalink / raw)
To: Jan Beulich
Cc: kevin.tian, sstabellini, suravee.suthikulpanit, andrew.cooper3,
xen-devel, julien.grall, tamas, jun.nakajima, boris.ostrovsky
On 11/11/2016 12:26 PM, Jan Beulich wrote:
>>>> On 11.11.16 at 11:15, <rcojocaru@bitdefender.com> wrote:
>> > On 11/11/2016 12:02 PM, Jan Beulich wrote:
>>>>>> >>>>> On 11.11.16 at 09:06, <rcojocaru@bitdefender.com> wrote:
>>>> >>> --- a/xen/include/asm-x86/domain.h
>>>> >>> +++ b/xen/include/asm-x86/domain.h
>>>> >>> @@ -576,6 +576,10 @@ struct arch_vcpu
>>>> >>> XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
>>>> >>>
>>>> >>> struct arch_vm_event *vm_event;
>>>> >>> +
>>>> >>> + struct {
>>>> >>> + unsigned int next_interrupt_enabled : 1;
>>> >>
>>> >> bool? Stray spaces. And then (sorry for thinking of this only now) - is
>>> >> this really usefully an arch-specific flag? I guess there's nothing
>>> >> precluding this from also being implemented on ARM eventually?
>> >
>> > Stray spaces? Do you mean the newline between "struct arch_vm_event
>> > *vm_event;" and "struct {"?
> No. I mean the ones around the colon.
I'm sorry, I don't follow. The examples I've pasted in the previous
reply make similar use of the colon:
399 /* Arch-specific monitor options */
400 struct {
401 unsigned int write_ctrlreg_enabled : 4;
402 unsigned int write_ctrlreg_sync : 4;
403 unsigned int write_ctrlreg_onchangeonly : 4;
404 unsigned int singlestep_enabled : 1;
405 unsigned int software_breakpoint_enabled : 1;
406 unsigned int debug_exception_enabled : 1;
407 unsigned int debug_exception_sync : 1;
408 unsigned int cpuid_enabled : 1;
409 struct monitor_msr_bitmap *msr_bitmap;
410 } monitor;
and
130 /* Monitor options */
131 struct {
132 uint8_t privileged_call_enabled : 1;
133 } monitor;
I take that you would prefer this?
unsigned int next_interrupt_enabled:1;
I have nothing against the change, I'm just confused about what the
proper and consistent way of writing that is.
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH V3] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
2016-11-11 10:32 ` Razvan Cojocaru
@ 2016-11-11 11:09 ` Jan Beulich
2016-11-11 15:16 ` Razvan Cojocaru
0 siblings, 1 reply; 10+ messages in thread
From: Jan Beulich @ 2016-11-11 11:09 UTC (permalink / raw)
To: Razvan Cojocaru
Cc: kevin.tian, sstabellini, suravee.suthikulpanit, andrew.cooper3,
xen-devel, julien.grall, tamas, jun.nakajima, boris.ostrovsky
>>> On 11.11.16 at 11:32, <rcojocaru@bitdefender.com> wrote:
> On 11/11/2016 12:26 PM, Jan Beulich wrote:
>>>>> On 11.11.16 at 11:15, <rcojocaru@bitdefender.com> wrote:
>>> > On 11/11/2016 12:02 PM, Jan Beulich wrote:
>>>>>>> >>>>> On 11.11.16 at 09:06, <rcojocaru@bitdefender.com> wrote:
>>>>> >>> --- a/xen/include/asm-x86/domain.h
>>>>> >>> +++ b/xen/include/asm-x86/domain.h
>>>>> >>> @@ -576,6 +576,10 @@ struct arch_vcpu
>>>>> >>> XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
>>>>> >>>
>>>>> >>> struct arch_vm_event *vm_event;
>>>>> >>> +
>>>>> >>> + struct {
>>>>> >>> + unsigned int next_interrupt_enabled : 1;
>>>> >>
>>>> >> bool? Stray spaces. And then (sorry for thinking of this only now) - is
>>>> >> this really usefully an arch-specific flag? I guess there's nothing
>>>> >> precluding this from also being implemented on ARM eventually?
>>> >
>>> > Stray spaces? Do you mean the newline between "struct arch_vm_event
>>> > *vm_event;" and "struct {"?
>> No. I mean the ones around the colon.
>
> I'm sorry, I don't follow. The examples I've pasted in the previous
> reply make similar use of the colon:
>
> 399 /* Arch-specific monitor options */
> 400 struct {
> 401 unsigned int write_ctrlreg_enabled : 4;
> 402 unsigned int write_ctrlreg_sync : 4;
> 403 unsigned int write_ctrlreg_onchangeonly : 4;
> 404 unsigned int singlestep_enabled : 1;
> 405 unsigned int software_breakpoint_enabled : 1;
> 406 unsigned int debug_exception_enabled : 1;
> 407 unsigned int debug_exception_sync : 1;
> 408 unsigned int cpuid_enabled : 1;
> 409 struct monitor_msr_bitmap *msr_bitmap;
> 410 } monitor;
>
> and
>
> 130 /* Monitor options */
> 131 struct {
> 132 uint8_t privileged_call_enabled : 1;
> 133 } monitor;
>
> I take that you would prefer this?
>
> unsigned int next_interrupt_enabled:1;
>
> I have nothing against the change, I'm just confused about what the
> proper and consistent way of writing that is.
grep-ing the include/ subtree I see that there are (apart from the
quoted ones) examples of all kinds, so I guess it can as well stay as
is, even if I personally consider the blanks stray here.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH V3] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
2016-11-11 11:09 ` Jan Beulich
@ 2016-11-11 15:16 ` Razvan Cojocaru
2016-11-11 15:33 ` Jan Beulich
0 siblings, 1 reply; 10+ messages in thread
From: Razvan Cojocaru @ 2016-11-11 15:16 UTC (permalink / raw)
To: Jan Beulich
Cc: kevin.tian, sstabellini, suravee.suthikulpanit, andrew.cooper3,
xen-devel, julien.grall, tamas, jun.nakajima, boris.ostrovsky
On 11/11/2016 01:09 PM, Jan Beulich wrote:
>>>> On 11.11.16 at 11:32, <rcojocaru@bitdefender.com> wrote:
>> On 11/11/2016 12:26 PM, Jan Beulich wrote:
>>>>>> On 11.11.16 at 11:15, <rcojocaru@bitdefender.com> wrote:
>>>>> On 11/11/2016 12:02 PM, Jan Beulich wrote:
>>>>>>>>>>>>> On 11.11.16 at 09:06, <rcojocaru@bitdefender.com> wrote:
>>>>>>>>> --- a/xen/include/asm-x86/domain.h
>>>>>>>>> +++ b/xen/include/asm-x86/domain.h
>>>>>>>>> @@ -576,6 +576,10 @@ struct arch_vcpu
>>>>>>>>> XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
>>>>>>>>>
>>>>>>>>> struct arch_vm_event *vm_event;
>>>>>>>>> +
>>>>>>>>> + struct {
>>>>>>>>> + unsigned int next_interrupt_enabled : 1;
>>>>>>>
>>>>>>> bool? Stray spaces. And then (sorry for thinking of this only now) - is
>>>>>>> this really usefully an arch-specific flag? I guess there's nothing
>>>>>>> precluding this from also being implemented on ARM eventually?
>>>>>
>>>>> Stray spaces? Do you mean the newline between "struct arch_vm_event
>>>>> *vm_event;" and "struct {"?
>>> No. I mean the ones around the colon.
>>
>> I'm sorry, I don't follow. The examples I've pasted in the previous
>> reply make similar use of the colon:
>>
>> 399 /* Arch-specific monitor options */
>> 400 struct {
>> 401 unsigned int write_ctrlreg_enabled : 4;
>> 402 unsigned int write_ctrlreg_sync : 4;
>> 403 unsigned int write_ctrlreg_onchangeonly : 4;
>> 404 unsigned int singlestep_enabled : 1;
>> 405 unsigned int software_breakpoint_enabled : 1;
>> 406 unsigned int debug_exception_enabled : 1;
>> 407 unsigned int debug_exception_sync : 1;
>> 408 unsigned int cpuid_enabled : 1;
>> 409 struct monitor_msr_bitmap *msr_bitmap;
>> 410 } monitor;
>>
>> and
>>
>> 130 /* Monitor options */
>> 131 struct {
>> 132 uint8_t privileged_call_enabled : 1;
>> 133 } monitor;
>>
>> I take that you would prefer this?
>>
>> unsigned int next_interrupt_enabled:1;
>>
>> I have nothing against the change, I'm just confused about what the
>> proper and consistent way of writing that is.
>
> grep-ing the include/ subtree I see that there are (apart from the
> quoted ones) examples of all kinds, so I guess it can as well stay as
> is, even if I personally consider the blanks stray here.
Alright, thanks! So since Tamas has given his ack, I guess all that's
required now is to const-ify struct vmcb_struct *vmcb in
svm_get_pending_event() (and also I now see in the examples above that a
uint8_t is probably better suited than an unsigned int for
next_interrupt_enabled, so that it will take less space in struct arch_vcpu.
I'll submit V4 shortly with these two changes.
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH V3] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
2016-11-11 15:16 ` Razvan Cojocaru
@ 2016-11-11 15:33 ` Jan Beulich
2016-11-11 15:39 ` Razvan Cojocaru
0 siblings, 1 reply; 10+ messages in thread
From: Jan Beulich @ 2016-11-11 15:33 UTC (permalink / raw)
To: Razvan Cojocaru
Cc: kevin.tian, sstabellini, suravee.suthikulpanit, andrew.cooper3,
xen-devel, julien.grall, tamas, jun.nakajima, boris.ostrovsky
>>> On 11.11.16 at 16:16, <rcojocaru@bitdefender.com> wrote:
> On 11/11/2016 01:09 PM, Jan Beulich wrote:
>>>>> On 11.11.16 at 11:32, <rcojocaru@bitdefender.com> wrote:
>>> On 11/11/2016 12:26 PM, Jan Beulich wrote:
>>>>>>> On 11.11.16 at 11:15, <rcojocaru@bitdefender.com> wrote:
>>>>>> On 11/11/2016 12:02 PM, Jan Beulich wrote:
>>>>>>>>>>>>>> On 11.11.16 at 09:06, <rcojocaru@bitdefender.com> wrote:
>>>>>>>>>> --- a/xen/include/asm-x86/domain.h
>>>>>>>>>> +++ b/xen/include/asm-x86/domain.h
>>>>>>>>>> @@ -576,6 +576,10 @@ struct arch_vcpu
>>>>>>>>>> XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
>>>>>>>>>>
>>>>>>>>>> struct arch_vm_event *vm_event;
>>>>>>>>>> +
>>>>>>>>>> + struct {
>>>>>>>>>> + unsigned int next_interrupt_enabled : 1;
>>>>>>>>
>>>>>>>> bool? Stray spaces. And then (sorry for thinking of this only now) - is
>>>>>>>> this really usefully an arch-specific flag? I guess there's nothing
>>>>>>>> precluding this from also being implemented on ARM eventually?
>>>>>>
>>>>>> Stray spaces? Do you mean the newline between "struct arch_vm_event
>>>>>> *vm_event;" and "struct {"?
>>>> No. I mean the ones around the colon.
>>>
>>> I'm sorry, I don't follow. The examples I've pasted in the previous
>>> reply make similar use of the colon:
>>>
>>> 399 /* Arch-specific monitor options */
>>> 400 struct {
>>> 401 unsigned int write_ctrlreg_enabled : 4;
>>> 402 unsigned int write_ctrlreg_sync : 4;
>>> 403 unsigned int write_ctrlreg_onchangeonly : 4;
>>> 404 unsigned int singlestep_enabled : 1;
>>> 405 unsigned int software_breakpoint_enabled : 1;
>>> 406 unsigned int debug_exception_enabled : 1;
>>> 407 unsigned int debug_exception_sync : 1;
>>> 408 unsigned int cpuid_enabled : 1;
>>> 409 struct monitor_msr_bitmap *msr_bitmap;
>>> 410 } monitor;
>>>
>>> and
>>>
>>> 130 /* Monitor options */
>>> 131 struct {
>>> 132 uint8_t privileged_call_enabled : 1;
>>> 133 } monitor;
>>>
>>> I take that you would prefer this?
>>>
>>> unsigned int next_interrupt_enabled:1;
>>>
>>> I have nothing against the change, I'm just confused about what the
>>> proper and consistent way of writing that is.
>>
>> grep-ing the include/ subtree I see that there are (apart from the
>> quoted ones) examples of all kinds, so I guess it can as well stay as
>> is, even if I personally consider the blanks stray here.
>
> Alright, thanks! So since Tamas has given his ack, I guess all that's
> required now is to const-ify struct vmcb_struct *vmcb in
> svm_get_pending_event() (and also I now see in the examples above that a
> uint8_t is probably better suited than an unsigned int for
> next_interrupt_enabled, so that it will take less space in struct arch_vcpu.
I still think it should be bool (and may not even need to be a bitfield
at this point).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH V3] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
2016-11-11 15:33 ` Jan Beulich
@ 2016-11-11 15:39 ` Razvan Cojocaru
0 siblings, 0 replies; 10+ messages in thread
From: Razvan Cojocaru @ 2016-11-11 15:39 UTC (permalink / raw)
To: Jan Beulich
Cc: kevin.tian, sstabellini, suravee.suthikulpanit, andrew.cooper3,
xen-devel, julien.grall, tamas, jun.nakajima, boris.ostrovsky
On 11/11/2016 05:33 PM, Jan Beulich wrote:
>>>> On 11.11.16 at 16:16, <rcojocaru@bitdefender.com> wrote:
>> On 11/11/2016 01:09 PM, Jan Beulich wrote:
>>>>>> On 11.11.16 at 11:32, <rcojocaru@bitdefender.com> wrote:
>>>> On 11/11/2016 12:26 PM, Jan Beulich wrote:
>>>>>>>> On 11.11.16 at 11:15, <rcojocaru@bitdefender.com> wrote:
>>>>>>> On 11/11/2016 12:02 PM, Jan Beulich wrote:
>>>>>>>>>>>>>>> On 11.11.16 at 09:06, <rcojocaru@bitdefender.com> wrote:
>>>>>>>>>>> --- a/xen/include/asm-x86/domain.h
>>>>>>>>>>> +++ b/xen/include/asm-x86/domain.h
>>>>>>>>>>> @@ -576,6 +576,10 @@ struct arch_vcpu
>>>>>>>>>>> XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
>>>>>>>>>>>
>>>>>>>>>>> struct arch_vm_event *vm_event;
>>>>>>>>>>> +
>>>>>>>>>>> + struct {
>>>>>>>>>>> + unsigned int next_interrupt_enabled : 1;
>>>>>>>>>
>>>>>>>>> bool? Stray spaces. And then (sorry for thinking of this only now) - is
>>>>>>>>> this really usefully an arch-specific flag? I guess there's nothing
>>>>>>>>> precluding this from also being implemented on ARM eventually?
>>>>>>>
>>>>>>> Stray spaces? Do you mean the newline between "struct arch_vm_event
>>>>>>> *vm_event;" and "struct {"?
>>>>> No. I mean the ones around the colon.
>>>>
>>>> I'm sorry, I don't follow. The examples I've pasted in the previous
>>>> reply make similar use of the colon:
>>>>
>>>> 399 /* Arch-specific monitor options */
>>>> 400 struct {
>>>> 401 unsigned int write_ctrlreg_enabled : 4;
>>>> 402 unsigned int write_ctrlreg_sync : 4;
>>>> 403 unsigned int write_ctrlreg_onchangeonly : 4;
>>>> 404 unsigned int singlestep_enabled : 1;
>>>> 405 unsigned int software_breakpoint_enabled : 1;
>>>> 406 unsigned int debug_exception_enabled : 1;
>>>> 407 unsigned int debug_exception_sync : 1;
>>>> 408 unsigned int cpuid_enabled : 1;
>>>> 409 struct monitor_msr_bitmap *msr_bitmap;
>>>> 410 } monitor;
>>>>
>>>> and
>>>>
>>>> 130 /* Monitor options */
>>>> 131 struct {
>>>> 132 uint8_t privileged_call_enabled : 1;
>>>> 133 } monitor;
>>>>
>>>> I take that you would prefer this?
>>>>
>>>> unsigned int next_interrupt_enabled:1;
>>>>
>>>> I have nothing against the change, I'm just confused about what the
>>>> proper and consistent way of writing that is.
>>>
>>> grep-ing the include/ subtree I see that there are (apart from the
>>> quoted ones) examples of all kinds, so I guess it can as well stay as
>>> is, even if I personally consider the blanks stray here.
>>
>> Alright, thanks! So since Tamas has given his ack, I guess all that's
>> required now is to const-ify struct vmcb_struct *vmcb in
>> svm_get_pending_event() (and also I now see in the examples above that a
>> uint8_t is probably better suited than an unsigned int for
>> next_interrupt_enabled, so that it will take less space in struct arch_vcpu.
>
> I still think it should be bool (and may not even need to be a bitfield
> at this point).
OK, I'll make it a plain bool, and it can be changed later to a bitfield
if need be. This would also clear the spaces around the colon debate. I
assume Tamas won't mind such a simple change.
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH V3] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
2016-11-11 8:06 [PATCH V3] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT Razvan Cojocaru
2016-11-11 10:02 ` Jan Beulich
@ 2016-11-11 15:09 ` Tamas K Lengyel
1 sibling, 0 replies; 10+ messages in thread
From: Tamas K Lengyel @ 2016-11-11 15:09 UTC (permalink / raw)
To: Razvan Cojocaru
Cc: Kevin Tian, Stefano Stabellini, suravee.suthikulpanit,
Andrew Cooper, Julien Grall, Xen-devel, Jan Beulich, Jun Nakajima,
boris.ostrovsky
[-- Attachment #1.1: Type: text/plain, Size: 585 bytes --]
On Fri, Nov 11, 2016 at 1:06 AM, Razvan Cojocaru <rcojocaru@bitdefender.com>
wrote:
> Added support for a new event type, VM_EVENT_REASON_INTERRUPT,
> which is now fired in a one-shot manner when enabled via the new
> VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.
> The patch also fixes the behaviour of the xc_hvm_inject_trap()
> hypercall, which would lead to non-architectural interrupts
> overwriting pending (specifically reinjected) architectural ones.
>
> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
[-- Attachment #1.2: Type: text/html, Size: 1103 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-11-11 15:39 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-11-11 8:06 [PATCH V3] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT Razvan Cojocaru
2016-11-11 10:02 ` Jan Beulich
2016-11-11 10:15 ` Razvan Cojocaru
2016-11-11 10:26 ` Jan Beulich
2016-11-11 10:32 ` Razvan Cojocaru
2016-11-11 11:09 ` Jan Beulich
2016-11-11 15:16 ` Razvan Cojocaru
2016-11-11 15:33 ` Jan Beulich
2016-11-11 15:39 ` Razvan Cojocaru
2016-11-11 15:09 ` Tamas K Lengyel
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).