Message ID | 1478851609-4226-1-git-send-email-rcojocaru@bitdefender.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
>>> 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
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
>>> 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
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
>>> 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
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>
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
>>> 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
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
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__ */ /*
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(-)