diff mbox

[V3] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

Message ID 1478851609-4226-1-git-send-email-rcojocaru@bitdefender.com (mailing list archive)
State New, archived
Headers show

Commit Message

Razvan Cojocaru Nov. 11, 2016, 8:06 a.m. UTC
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(-)

Comments

Jan Beulich Nov. 11, 2016, 10:02 a.m. UTC | #1
>>> 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
Razvan Cojocaru Nov. 11, 2016, 10:15 a.m. UTC | #2
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
Jan Beulich Nov. 11, 2016, 10:26 a.m. UTC | #3
>>> 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
Razvan Cojocaru Nov. 11, 2016, 10:32 a.m. UTC | #4
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
Jan Beulich Nov. 11, 2016, 11:09 a.m. UTC | #5
>>> 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
Tamas K Lengyel Nov. 11, 2016, 3:09 p.m. UTC | #6
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>
Razvan Cojocaru Nov. 11, 2016, 3:16 p.m. UTC | #7
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
Jan Beulich Nov. 11, 2016, 3:33 p.m. UTC | #8
>>> 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
Razvan Cojocaru Nov. 11, 2016, 3:39 p.m. UTC | #9
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 mbox

Patch

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__ */
 
 /*