All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events
@ 2018-12-14 11:49 Razvan Cojocaru
  2018-12-25  2:29 ` Tian, Kevin
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Razvan Cojocaru @ 2018-12-14 11:49 UTC (permalink / raw)
  To: xen-devel
  Cc: kevin.tian, tamas, wei.liu2, suravee.suthikulpanit,
	Razvan Cojocaru, jun.nakajima, andrew.cooper3, julien.grall,
	sstabellini, jbeulich, boris.ostrovsky, brian.woods, roger.pau

Block interrupts (in vmx_intr_assist()) for the duration of
processing a sync vm_event (similarly to the strategy
currently used for single-stepping). Otherwise, attempting
to emulate an instruction when requested by a vm_event
reply may legitimately need to call e.g.
hvm_inject_page_fault(), which then overwrites the active
interrupt in the VMCS.

The sync vm_event handling path on x86/VMX is (roughly):
monitor_traps() -> process vm_event -> vmx_intr_assist()
(possibly writing VM_ENTRY_INTR_INFO) ->
hvm_vm_event_do_resume() -> hvm_emulate_one_vm_event()
(possibly overwriting the VM_ENTRY_INTR_INFO value).

This patch may also be helpful for the future removal
of may_defer in hvm_set_cr{0,3,4} and hvm_set_msr().

Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>

---
Changes since V2:
 - Renamed intr_block to sync_event and
   vm_event_block_interrupts() to vm_event_sync_event().
 - Rephrased and / or removed stale comments.
 - Added more details to the commit description.
---
 xen/arch/x86/hvm/svm/intr.c    | 5 +++++
 xen/arch/x86/hvm/vm_event.c    | 2 ++
 xen/arch/x86/hvm/vmx/intr.c    | 5 +++++
 xen/arch/x86/vm_event.c        | 5 +++++
 xen/common/monitor.c           | 1 +
 xen/include/asm-arm/vm_event.h | 6 ++++++
 xen/include/asm-x86/vm_event.h | 4 ++++
 7 files changed, 28 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/intr.c b/xen/arch/x86/hvm/svm/intr.c
index 7967353..ff75516 100644
--- a/xen/arch/x86/hvm/svm/intr.c
+++ b/xen/arch/x86/hvm/svm/intr.c
@@ -32,6 +32,7 @@
 #include <asm/hvm/svm/svm.h>
 #include <asm/hvm/svm/intr.h>
 #include <asm/hvm/nestedhvm.h> /* for nestedhvm_vcpu_in_guestmode */
+#include <asm/vm_event.h>
 #include <xen/event.h>
 #include <xen/kernel.h>
 #include <public/hvm/ioreq.h>
@@ -137,6 +138,10 @@ void svm_intr_assist(void)
     struct hvm_intack intack;
     enum hvm_intblk intblk;
 
+    /* Block event injection while handling a sync vm_event. */
+    if ( unlikely(v->arch.vm_event) && v->arch.vm_event->sync_event )
+        return;
+
     /* Crank the handle on interrupt state. */
     pt_update_irq(v);
 
diff --git a/xen/arch/x86/hvm/vm_event.c b/xen/arch/x86/hvm/vm_event.c
index 0df8ab4..121de23 100644
--- a/xen/arch/x86/hvm/vm_event.c
+++ b/xen/arch/x86/hvm/vm_event.c
@@ -124,6 +124,8 @@ void hvm_vm_event_do_resume(struct vcpu *v)
 
         w->do_write.msr = 0;
     }
+
+    vm_event_sync_event(v, false);
 }
 
 /*
diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
index 5e8cbd4..0d097cf 100644
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -37,6 +37,7 @@
 #include <asm/hvm/nestedhvm.h>
 #include <public/hvm/ioreq.h>
 #include <asm/hvm/trace.h>
+#include <asm/vm_event.h>
 
 /*
  * A few notes on virtual NMI and INTR delivery, and interactions with
@@ -239,6 +240,10 @@ void vmx_intr_assist(void)
         return;
     }
 
+    /* Block event injection while handling a sync vm_event. */
+    if ( unlikely(v->arch.vm_event) && v->arch.vm_event->sync_event )
+        return;
+
     /* Crank the handle on interrupt state. */
     pt_vector = pt_update_irq(v);
 
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 713e684..51c3493 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -122,6 +122,11 @@ void vm_event_monitor_next_interrupt(struct vcpu *v)
     v->arch.monitor.next_interrupt_enabled = true;
 }
 
+void vm_event_sync_event(struct vcpu *v, bool value)
+{
+    v->arch.vm_event->sync_event = value;
+}
+
 #ifdef CONFIG_HVM
 static void vm_event_pack_segment_register(enum x86_segment segment,
                                            struct vm_event_regs_x86 *reg)
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index c606683..cb5f37f 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -113,6 +113,7 @@ int monitor_traps(struct vcpu *v, bool sync, vm_event_request_t *req)
     if ( sync )
     {
         req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
+        vm_event_sync_event(v, true);
         vm_event_vcpu_pause(v);
         rc = 1;
     }
diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index 66f2474..14d1d34 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_sync_event(struct vcpu *v, bool value)
+{
+    /* Not supported on ARM. */
+}
+
 #endif /* __ASM_ARM_VM_EVENT_H__ */
diff --git a/xen/include/asm-x86/vm_event.h b/xen/include/asm-x86/vm_event.h
index 39e73c8..23e6557 100644
--- a/xen/include/asm-x86/vm_event.h
+++ b/xen/include/asm-x86/vm_event.h
@@ -34,6 +34,8 @@ struct arch_vm_event {
     struct monitor_write_data write_data;
     struct vm_event_regs_x86 gprs;
     bool set_gprs;
+    /* A sync vm_event has been sent and we're not done handling it. */
+    bool sync_event;
 };
 
 int vm_event_init_domain(struct domain *d);
@@ -47,4 +49,6 @@ void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t *rsp);
 
 void vm_event_emulate_check(struct vcpu *v, vm_event_response_t *rsp);
 
+void vm_event_sync_event(struct vcpu *v, bool value);
+
 #endif /* __ASM_X86_VM_EVENT_H__ */
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events
  2018-12-14 11:49 [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events Razvan Cojocaru
@ 2018-12-25  2:29 ` Tian, Kevin
  2019-01-11 10:31   ` Razvan Cojocaru
  2019-01-11 11:36 ` Roger Pau Monné
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 15+ messages in thread
From: Tian, Kevin @ 2018-12-25  2:29 UTC (permalink / raw)
  To: Razvan Cojocaru, xen-devel
  Cc: tamas, wei.liu2, suravee.suthikulpanit, Nakajima, Jun,
	andrew.cooper3, julien.grall, sstabellini, jbeulich,
	boris.ostrovsky, brian.woods, roger.pau

> From: Razvan Cojocaru [mailto:rcojocaru@bitdefender.com]
> Sent: Friday, December 14, 2018 7:50 PM
> 
> Block interrupts (in vmx_intr_assist()) for the duration of
> processing a sync vm_event (similarly to the strategy
> currently used for single-stepping). Otherwise, attempting
> to emulate an instruction when requested by a vm_event
> reply may legitimately need to call e.g.
> hvm_inject_page_fault(), which then overwrites the active
> interrupt in the VMCS.
> 
> The sync vm_event handling path on x86/VMX is (roughly):
> monitor_traps() -> process vm_event -> vmx_intr_assist()
> (possibly writing VM_ENTRY_INTR_INFO) ->
> hvm_vm_event_do_resume() -> hvm_emulate_one_vm_event()
> (possibly overwriting the VM_ENTRY_INTR_INFO value).
> 
> This patch may also be helpful for the future removal
> of may_defer in hvm_set_cr{0,3,4} and hvm_set_msr().
> 
> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
> 

Reviewed-by: Kevin Tian <kevin.tian@intel.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events
  2018-12-25  2:29 ` Tian, Kevin
@ 2019-01-11 10:31   ` Razvan Cojocaru
  0 siblings, 0 replies; 15+ messages in thread
From: Razvan Cojocaru @ 2019-01-11 10:31 UTC (permalink / raw)
  To: xen-devel
  Cc: Tian, Kevin, tamas, wei.liu2, suravee.suthikulpanit, Nakajima,
	Jun, andrew.cooper3, julien.grall, sstabellini, jbeulich,
	boris.ostrovsky, brian.woods, roger.pau

On 12/25/18 4:29 AM, Tian, Kevin wrote:
>> From: Razvan Cojocaru [mailto:rcojocaru@bitdefender.com]
>> Sent: Friday, December 14, 2018 7:50 PM
>>
>> Block interrupts (in vmx_intr_assist()) for the duration of
>> processing a sync vm_event (similarly to the strategy
>> currently used for single-stepping). Otherwise, attempting
>> to emulate an instruction when requested by a vm_event
>> reply may legitimately need to call e.g.
>> hvm_inject_page_fault(), which then overwrites the active
>> interrupt in the VMCS.
>>
>> The sync vm_event handling path on x86/VMX is (roughly):
>> monitor_traps() -> process vm_event -> vmx_intr_assist()
>> (possibly writing VM_ENTRY_INTR_INFO) ->
>> hvm_vm_event_do_resume() -> hvm_emulate_one_vm_event()
>> (possibly overwriting the VM_ENTRY_INTR_INFO value).
>>
>> This patch may also be helpful for the future removal
>> of may_defer in hvm_set_cr{0,3,4} and hvm_set_msr().
>>
>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>>
> 
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>

Ping?


Thanks,
Razvan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events
  2018-12-14 11:49 [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events Razvan Cojocaru
  2018-12-25  2:29 ` Tian, Kevin
@ 2019-01-11 11:36 ` Roger Pau Monné
  2019-01-11 22:04 ` Boris Ostrovsky
  2019-01-14 14:37 ` Tamas K Lengyel
  3 siblings, 0 replies; 15+ messages in thread
From: Roger Pau Monné @ 2019-01-11 11:36 UTC (permalink / raw)
  To: Razvan Cojocaru
  Cc: Kevin Tian, Tamas K Lengyel, Wei Liu, suravee.suthikulpanit,
	Andrew Cooper, Julien Grall, Stefano Stabellini, Jan Beulich,
	jun.nakajima, xen-devel, Boris Ostrovsky, Brian Woods,
	Roger Pau Monne

On Fri, Dec 14, 2018 at 12:50 PM Razvan Cojocaru
<rcojocaru@bitdefender.com> wrote:
>
> Block interrupts (in vmx_intr_assist()) for the duration of
> processing a sync vm_event (similarly to the strategy
> currently used for single-stepping). Otherwise, attempting
> to emulate an instruction when requested by a vm_event
> reply may legitimately need to call e.g.
> hvm_inject_page_fault(), which then overwrites the active
> interrupt in the VMCS.
>
> The sync vm_event handling path on x86/VMX is (roughly):
> monitor_traps() -> process vm_event -> vmx_intr_assist()
> (possibly writing VM_ENTRY_INTR_INFO) ->
> hvm_vm_event_do_resume() -> hvm_emulate_one_vm_event()
> (possibly overwriting the VM_ENTRY_INTR_INFO value).
>
> This patch may also be helpful for the future removal
> of may_defer in hvm_set_cr{0,3,4} and hvm_set_msr().
>
> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events
  2018-12-14 11:49 [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events Razvan Cojocaru
  2018-12-25  2:29 ` Tian, Kevin
  2019-01-11 11:36 ` Roger Pau Monné
@ 2019-01-11 22:04 ` Boris Ostrovsky
  2019-01-14  9:34   ` Razvan Cojocaru
  2019-01-14 14:37 ` Tamas K Lengyel
  3 siblings, 1 reply; 15+ messages in thread
From: Boris Ostrovsky @ 2019-01-11 22:04 UTC (permalink / raw)
  To: Razvan Cojocaru, xen-devel
  Cc: kevin.tian, tamas, wei.liu2, suravee.suthikulpanit, jun.nakajima,
	andrew.cooper3, julien.grall, sstabellini, jbeulich, brian.woods,
	roger.pau

On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
> Block interrupts (in vmx_intr_assist()) for the duration of
> processing a sync vm_event (similarly to the strategy
> currently used for single-stepping). Otherwise, attempting
> to emulate an instruction when requested by a vm_event
> reply may legitimately need to call e.g.
> hvm_inject_page_fault(), which then overwrites the active
> interrupt in the VMCS.
>
> The sync vm_event handling path on x86/VMX is (roughly):
> monitor_traps() -> process vm_event -> vmx_intr_assist()
> (possibly writing VM_ENTRY_INTR_INFO) ->
> hvm_vm_event_do_resume() -> hvm_emulate_one_vm_event()
> (possibly overwriting the VM_ENTRY_INTR_INFO value).
>
> This patch may also be helpful for the future removal
> of may_defer in hvm_set_cr{0,3,4} and hvm_set_msr().
>
> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>


Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events
  2019-01-11 22:04 ` Boris Ostrovsky
@ 2019-01-14  9:34   ` Razvan Cojocaru
  2019-01-14  9:53     ` Jan Beulich
  2019-01-14 10:43     ` Julien Grall
  0 siblings, 2 replies; 15+ messages in thread
From: Razvan Cojocaru @ 2019-01-14  9:34 UTC (permalink / raw)
  To: xen-devel, tamas, sstabellini, julien.grall
  Cc: kevin.tian, wei.liu2, suravee.suthikulpanit, jun.nakajima,
	andrew.cooper3, jbeulich, Boris Ostrovsky, brian.woods,
	roger.pau

On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
> On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
>> Block interrupts (in vmx_intr_assist()) for the duration of
>> processing a sync vm_event (similarly to the strategy
>> currently used for single-stepping). Otherwise, attempting
>> to emulate an instruction when requested by a vm_event
>> reply may legitimately need to call e.g.
>> hvm_inject_page_fault(), which then overwrites the active
>> interrupt in the VMCS.
>>
>> The sync vm_event handling path on x86/VMX is (roughly):
>> monitor_traps() -> process vm_event -> vmx_intr_assist()
>> (possibly writing VM_ENTRY_INTR_INFO) ->
>> hvm_vm_event_do_resume() -> hvm_emulate_one_vm_event()
>> (possibly overwriting the VM_ENTRY_INTR_INFO value).
>>
>> This patch may also be helpful for the future removal
>> of may_defer in hvm_set_cr{0,3,4} and hvm_set_msr().
>>
>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
> 
> 
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Thanks! So now we have three reviewed-bys, if I'm not mistaken all we 
need is Tamas' (for the vm_event part) and Julien / Stefano's (for ARM) 
acks (or otherwise).

Could you please take a look?


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events
  2019-01-14  9:34   ` Razvan Cojocaru
@ 2019-01-14  9:53     ` Jan Beulich
  2019-01-14 10:56       ` Razvan Cojocaru
  2019-01-14 10:43     ` Julien Grall
  1 sibling, 1 reply; 15+ messages in thread
From: Jan Beulich @ 2019-01-14  9:53 UTC (permalink / raw)
  To: Razvan Cojocaru
  Cc: Kevin Tian, Stefano Stabellini, Wei Liu, Jun Nakajima,
	Andrew Cooper, Julien Grall, Tamas K Lengyel,
	Suravee Suthikulpanit, xen-devel, Boris Ostrovsky, Brian Woods,
	Roger Pau Monne

>>> On 14.01.19 at 10:34, <rcojocaru@bitdefender.com> wrote:
> On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
>> On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
>>> Block interrupts (in vmx_intr_assist()) for the duration of
>>> processing a sync vm_event (similarly to the strategy
>>> currently used for single-stepping). Otherwise, attempting
>>> to emulate an instruction when requested by a vm_event
>>> reply may legitimately need to call e.g.
>>> hvm_inject_page_fault(), which then overwrites the active
>>> interrupt in the VMCS.
>>>
>>> The sync vm_event handling path on x86/VMX is (roughly):
>>> monitor_traps() -> process vm_event -> vmx_intr_assist()
>>> (possibly writing VM_ENTRY_INTR_INFO) ->
>>> hvm_vm_event_do_resume() -> hvm_emulate_one_vm_event()
>>> (possibly overwriting the VM_ENTRY_INTR_INFO value).
>>>
>>> This patch may also be helpful for the future removal
>>> of may_defer in hvm_set_cr{0,3,4} and hvm_set_msr().
>>>
>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>> 
>> 
>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> 
> Thanks! So now we have three reviewed-bys, if I'm not mistaken all we 
> need is Tamas' (for the vm_event part) and Julien / Stefano's (for ARM) 
> acks (or otherwise).

And you'd need to talk Jürgen into allowing this in, now that we're
past the freeze point.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events
  2019-01-14  9:34   ` Razvan Cojocaru
  2019-01-14  9:53     ` Jan Beulich
@ 2019-01-14 10:43     ` Julien Grall
  1 sibling, 0 replies; 15+ messages in thread
From: Julien Grall @ 2019-01-14 10:43 UTC (permalink / raw)
  To: Razvan Cojocaru, xen-devel, tamas, sstabellini
  Cc: kevin.tian, wei.liu2, suravee.suthikulpanit, jun.nakajima,
	andrew.cooper3, jbeulich, Boris Ostrovsky, brian.woods,
	roger.pau

Hi,

On 14/01/2019 09:34, Razvan Cojocaru wrote:
> On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
>> On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
>>> Block interrupts (in vmx_intr_assist()) for the duration of
>>> processing a sync vm_event (similarly to the strategy
>>> currently used for single-stepping). Otherwise, attempting
>>> to emulate an instruction when requested by a vm_event
>>> reply may legitimately need to call e.g.
>>> hvm_inject_page_fault(), which then overwrites the active
>>> interrupt in the VMCS.
>>>
>>> The sync vm_event handling path on x86/VMX is (roughly):
>>> monitor_traps() -> process vm_event -> vmx_intr_assist()
>>> (possibly writing VM_ENTRY_INTR_INFO) ->
>>> hvm_vm_event_do_resume() -> hvm_emulate_one_vm_event()
>>> (possibly overwriting the VM_ENTRY_INTR_INFO value).
>>>
>>> This patch may also be helpful for the future removal
>>> of may_defer in hvm_set_cr{0,3,4} and hvm_set_msr().
>>>
>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>>
>>
>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> 
> Thanks! So now we have three reviewed-bys, if I'm not mistaken all we need is 
> Tamas' (for the vm_event part) and Julien / Stefano's (for ARM) acks (or 
> otherwise).
> 
> Could you please take a look?

All the Arm code modified falls under "VM EVENT, MEM ACCESS and MONITOR". So I 
don't think you need an ack from Stefano or I.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events
  2019-01-14  9:53     ` Jan Beulich
@ 2019-01-14 10:56       ` Razvan Cojocaru
  2019-01-14 14:42         ` Juergen Gross
  0 siblings, 1 reply; 15+ messages in thread
From: Razvan Cojocaru @ 2019-01-14 10:56 UTC (permalink / raw)
  To: Jan Beulich, Tamas K Lengyel, Juergen Gross
  Cc: Kevin Tian, Stefano Stabellini, Wei Liu, Jun Nakajima,
	Andrew Cooper, Julien Grall, Suravee Suthikulpanit, xen-devel,
	Boris Ostrovsky, Brian Woods, Roger Pau Monne

On 1/14/19 11:53 AM, Jan Beulich wrote:
>>>> On 14.01.19 at 10:34, <rcojocaru@bitdefender.com> wrote:
>> On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
>>> On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
>>>> Block interrupts (in vmx_intr_assist()) for the duration of
>>>> processing a sync vm_event (similarly to the strategy
>>>> currently used for single-stepping). Otherwise, attempting
>>>> to emulate an instruction when requested by a vm_event
>>>> reply may legitimately need to call e.g.
>>>> hvm_inject_page_fault(), which then overwrites the active
>>>> interrupt in the VMCS.
>>>>
>>>> The sync vm_event handling path on x86/VMX is (roughly):
>>>> monitor_traps() -> process vm_event -> vmx_intr_assist()
>>>> (possibly writing VM_ENTRY_INTR_INFO) ->
>>>> hvm_vm_event_do_resume() -> hvm_emulate_one_vm_event()
>>>> (possibly overwriting the VM_ENTRY_INTR_INFO value).
>>>>
>>>> This patch may also be helpful for the future removal
>>>> of may_defer in hvm_set_cr{0,3,4} and hvm_set_msr().
>>>>
>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>>>
>>>
>>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>
>> Thanks! So now we have three reviewed-bys, if I'm not mistaken all we
>> need is Tamas' (for the vm_event part) and Julien / Stefano's (for ARM)
>> acks (or otherwise).
> 
> And you'd need to talk Jürgen into allowing this in, now that we're
> past the freeze point.

(Adding Jürgen to the conversation.)

Right, that would be ideal if possible - the code has absolutely no 
impact on anything unless vm_event is active on the domain, which is 
never the case for the use-cases considered for a Xen release.

So the case I'm making for the patch to go in 4.12 is that:

1. It's perfectly harmless (it affects nothing, except for introspection).

2. It's trivial and thus very easy to see that it's correct.

3. It fixes a major headache for us, and thus it is a great improvement 
from an introspection standpoint (fixes OS crashes / hangs which we'd 
otherwise need to work around in rather painful ways).

4. V3 of the patch has been sent out on Dec 14th - it's just that 
reviewers have had other priorities and it did not gather all acks in time.

However, if it's not possible or desirable to allow this in the next 
best thing is to at least have all the acks necessary for it to go in 
first thing once the freeze is over.

 From Julien's reply I understand that the last ack necessary is Tamas'.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events
  2018-12-14 11:49 [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events Razvan Cojocaru
                   ` (2 preceding siblings ...)
  2019-01-11 22:04 ` Boris Ostrovsky
@ 2019-01-14 14:37 ` Tamas K Lengyel
  3 siblings, 0 replies; 15+ messages in thread
From: Tamas K Lengyel @ 2019-01-14 14:37 UTC (permalink / raw)
  To: Razvan Cojocaru
  Cc: Kevin Tian, Stefano Stabellini, Wei Liu, Suravee Suthikulpanit,
	Jun Nakajima, Andrew Cooper, Julien Grall, Jan Beulich,
	Xen-devel, Boris Ostrovsky, Brian Woods, Roger Pau Monné

On Fri, Dec 14, 2018 at 4:50 AM Razvan Cojocaru
<rcojocaru@bitdefender.com> wrote:
>
> Block interrupts (in vmx_intr_assist()) for the duration of
> processing a sync vm_event (similarly to the strategy
> currently used for single-stepping). Otherwise, attempting
> to emulate an instruction when requested by a vm_event
> reply may legitimately need to call e.g.
> hvm_inject_page_fault(), which then overwrites the active
> interrupt in the VMCS.
>
> The sync vm_event handling path on x86/VMX is (roughly):
> monitor_traps() -> process vm_event -> vmx_intr_assist()
> (possibly writing VM_ENTRY_INTR_INFO) ->
> hvm_vm_event_do_resume() -> hvm_emulate_one_vm_event()
> (possibly overwriting the VM_ENTRY_INTR_INFO value).
>
> This patch may also be helpful for the future removal
> of may_defer in hvm_set_cr{0,3,4} and hvm_set_msr().
>
> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>

Acked-by: Tamas K Lengyel <tamas@tklengyel.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events
  2019-01-14 10:56       ` Razvan Cojocaru
@ 2019-01-14 14:42         ` Juergen Gross
  2019-01-14 14:44           ` Razvan Cojocaru
  2019-01-16  7:10           ` Razvan Cojocaru
  0 siblings, 2 replies; 15+ messages in thread
From: Juergen Gross @ 2019-01-14 14:42 UTC (permalink / raw)
  To: Razvan Cojocaru, Jan Beulich, Tamas K Lengyel
  Cc: Kevin Tian, Stefano Stabellini, Wei Liu, Jun Nakajima,
	Andrew Cooper, Julien Grall, Suravee Suthikulpanit, xen-devel,
	Boris Ostrovsky, Brian Woods, Roger Pau Monne

On 14/01/2019 11:56, Razvan Cojocaru wrote:
> On 1/14/19 11:53 AM, Jan Beulich wrote:
>>>>> On 14.01.19 at 10:34, <rcojocaru@bitdefender.com> wrote:
>>> On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
>>>> On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
>>>>> Block interrupts (in vmx_intr_assist()) for the duration of
>>>>> processing a sync vm_event (similarly to the strategy
>>>>> currently used for single-stepping). Otherwise, attempting
>>>>> to emulate an instruction when requested by a vm_event
>>>>> reply may legitimately need to call e.g.
>>>>> hvm_inject_page_fault(), which then overwrites the active
>>>>> interrupt in the VMCS.
>>>>>
>>>>> The sync vm_event handling path on x86/VMX is (roughly):
>>>>> monitor_traps() -> process vm_event -> vmx_intr_assist()
>>>>> (possibly writing VM_ENTRY_INTR_INFO) ->
>>>>> hvm_vm_event_do_resume() -> hvm_emulate_one_vm_event()
>>>>> (possibly overwriting the VM_ENTRY_INTR_INFO value).
>>>>>
>>>>> This patch may also be helpful for the future removal
>>>>> of may_defer in hvm_set_cr{0,3,4} and hvm_set_msr().
>>>>>
>>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>>>>
>>>>
>>>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>
>>> Thanks! So now we have three reviewed-bys, if I'm not mistaken all we
>>> need is Tamas' (for the vm_event part) and Julien / Stefano's (for ARM)
>>> acks (or otherwise).
>>
>> And you'd need to talk Jürgen into allowing this in, now that we're
>> past the freeze point.
> 
> (Adding Jürgen to the conversation.)
> 
> Right, that would be ideal if possible - the code has absolutely no
> impact on anything unless vm_event is active on the domain, which is
> never the case for the use-cases considered for a Xen release.
> 
> So the case I'm making for the patch to go in 4.12 is that:
> 
> 1. It's perfectly harmless (it affects nothing, except for introspection).
> 
> 2. It's trivial and thus very easy to see that it's correct.
> 
> 3. It fixes a major headache for us, and thus it is a great improvement
> from an introspection standpoint (fixes OS crashes / hangs which we'd
> otherwise need to work around in rather painful ways).
> 
> 4. V3 of the patch has been sent out on Dec 14th - it's just that
> reviewers have had other priorities and it did not gather all acks in time.
> 
> However, if it's not possible or desirable to allow this in the next
> best thing is to at least have all the acks necessary for it to go in
> first thing once the freeze is over.
> 
> From Julien's reply I understand that the last ack necessary is Tamas'.

With that ack just arrived:

Release-acked-by: Juergen Gross <jgross@suse.com>


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events
  2019-01-14 14:42         ` Juergen Gross
@ 2019-01-14 14:44           ` Razvan Cojocaru
  2019-01-16  7:10           ` Razvan Cojocaru
  1 sibling, 0 replies; 15+ messages in thread
From: Razvan Cojocaru @ 2019-01-14 14:44 UTC (permalink / raw)
  To: Juergen Gross, Jan Beulich, Tamas K Lengyel
  Cc: Kevin Tian, Stefano Stabellini, Wei Liu, Jun Nakajima,
	Andrew Cooper, Julien Grall, Suravee Suthikulpanit, xen-devel,
	Boris Ostrovsky, Brian Woods, Roger Pau Monne

On 1/14/19 4:42 PM, Juergen Gross wrote:
> On 14/01/2019 11:56, Razvan Cojocaru wrote:
>> On 1/14/19 11:53 AM, Jan Beulich wrote:
>>>>>> On 14.01.19 at 10:34, <rcojocaru@bitdefender.com> wrote:
>>>> On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
>>>>> On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
>>>>>> Block interrupts (in vmx_intr_assist()) for the duration of
>>>>>> processing a sync vm_event (similarly to the strategy
>>>>>> currently used for single-stepping). Otherwise, attempting
>>>>>> to emulate an instruction when requested by a vm_event
>>>>>> reply may legitimately need to call e.g.
>>>>>> hvm_inject_page_fault(), which then overwrites the active
>>>>>> interrupt in the VMCS.
>>>>>>
>>>>>> The sync vm_event handling path on x86/VMX is (roughly):
>>>>>> monitor_traps() -> process vm_event -> vmx_intr_assist()
>>>>>> (possibly writing VM_ENTRY_INTR_INFO) ->
>>>>>> hvm_vm_event_do_resume() -> hvm_emulate_one_vm_event()
>>>>>> (possibly overwriting the VM_ENTRY_INTR_INFO value).
>>>>>>
>>>>>> This patch may also be helpful for the future removal
>>>>>> of may_defer in hvm_set_cr{0,3,4} and hvm_set_msr().
>>>>>>
>>>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>>>>>
>>>>>
>>>>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>>
>>>> Thanks! So now we have three reviewed-bys, if I'm not mistaken all we
>>>> need is Tamas' (for the vm_event part) and Julien / Stefano's (for ARM)
>>>> acks (or otherwise).
>>>
>>> And you'd need to talk Jürgen into allowing this in, now that we're
>>> past the freeze point.
>>
>> (Adding Jürgen to the conversation.)
>>
>> Right, that would be ideal if possible - the code has absolutely no
>> impact on anything unless vm_event is active on the domain, which is
>> never the case for the use-cases considered for a Xen release.
>>
>> So the case I'm making for the patch to go in 4.12 is that:
>>
>> 1. It's perfectly harmless (it affects nothing, except for introspection).
>>
>> 2. It's trivial and thus very easy to see that it's correct.
>>
>> 3. It fixes a major headache for us, and thus it is a great improvement
>> from an introspection standpoint (fixes OS crashes / hangs which we'd
>> otherwise need to work around in rather painful ways).
>>
>> 4. V3 of the patch has been sent out on Dec 14th - it's just that
>> reviewers have had other priorities and it did not gather all acks in time.
>>
>> However, if it's not possible or desirable to allow this in the next
>> best thing is to at least have all the acks necessary for it to go in
>> first thing once the freeze is over.
>>
>>  From Julien's reply I understand that the last ack necessary is Tamas'.
> 
> With that ack just arrived:
> 
> Release-acked-by: Juergen Gross <jgross@suse.com>

Thanks! Very much appreciated.


Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events
  2019-01-14 14:42         ` Juergen Gross
  2019-01-14 14:44           ` Razvan Cojocaru
@ 2019-01-16  7:10           ` Razvan Cojocaru
  2019-01-16  8:58             ` Jan Beulich
  1 sibling, 1 reply; 15+ messages in thread
From: Razvan Cojocaru @ 2019-01-16  7:10 UTC (permalink / raw)
  To: Juergen Gross, Jan Beulich, Tamas K Lengyel
  Cc: Kevin Tian, Stefano Stabellini, Wei Liu, Jun Nakajima,
	Andrew Cooper, Julien Grall, Suravee Suthikulpanit, xen-devel,
	Boris Ostrovsky, Brian Woods, Roger Pau Monne

On 1/14/19 4:42 PM, Juergen Gross wrote:
> On 14/01/2019 11:56, Razvan Cojocaru wrote:
>> On 1/14/19 11:53 AM, Jan Beulich wrote:
>>>>>> On 14.01.19 at 10:34, <rcojocaru@bitdefender.com> wrote:
>>>> On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
>>>>> On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
>>>>>> Block interrupts (in vmx_intr_assist()) for the duration of
>>>>>> processing a sync vm_event (similarly to the strategy
>>>>>> currently used for single-stepping). Otherwise, attempting
>>>>>> to emulate an instruction when requested by a vm_event
>>>>>> reply may legitimately need to call e.g.
>>>>>> hvm_inject_page_fault(), which then overwrites the active
>>>>>> interrupt in the VMCS.
>>>>>>
>>>>>> The sync vm_event handling path on x86/VMX is (roughly):
>>>>>> monitor_traps() -> process vm_event -> vmx_intr_assist()
>>>>>> (possibly writing VM_ENTRY_INTR_INFO) ->
>>>>>> hvm_vm_event_do_resume() -> hvm_emulate_one_vm_event()
>>>>>> (possibly overwriting the VM_ENTRY_INTR_INFO value).
>>>>>>
>>>>>> This patch may also be helpful for the future removal
>>>>>> of may_defer in hvm_set_cr{0,3,4} and hvm_set_msr().
>>>>>>
>>>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>>>>>
>>>>>
>>>>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>>
>>>> Thanks! So now we have three reviewed-bys, if I'm not mistaken all we
>>>> need is Tamas' (for the vm_event part) and Julien / Stefano's (for ARM)
>>>> acks (or otherwise).
>>>
>>> And you'd need to talk Jürgen into allowing this in, now that we're
>>> past the freeze point.
>>
>> (Adding Jürgen to the conversation.)
>>
>> Right, that would be ideal if possible - the code has absolutely no
>> impact on anything unless vm_event is active on the domain, which is
>> never the case for the use-cases considered for a Xen release.
>>
>> So the case I'm making for the patch to go in 4.12 is that:
>>
>> 1. It's perfectly harmless (it affects nothing, except for introspection).
>>
>> 2. It's trivial and thus very easy to see that it's correct.
>>
>> 3. It fixes a major headache for us, and thus it is a great improvement
>> from an introspection standpoint (fixes OS crashes / hangs which we'd
>> otherwise need to work around in rather painful ways).
>>
>> 4. V3 of the patch has been sent out on Dec 14th - it's just that
>> reviewers have had other priorities and it did not gather all acks in time.
>>
>> However, if it's not possible or desirable to allow this in the next
>> best thing is to at least have all the acks necessary for it to go in
>> first thing once the freeze is over.
>>
>> From Julien's reply I understand that the last ack necessary is Tamas'.
> 
> With that ack just arrived:
> 
> Release-acked-by: Juergen Gross <jgross@suse.com>
AFAICT this is fine to apply to staging now, am I incorrect?


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events
  2019-01-16  7:10           ` Razvan Cojocaru
@ 2019-01-16  8:58             ` Jan Beulich
  2019-01-16  9:02               ` Razvan Cojocaru
  0 siblings, 1 reply; 15+ messages in thread
From: Jan Beulich @ 2019-01-16  8:58 UTC (permalink / raw)
  To: Razvan Cojocaru
  Cc: Juergen Gross, Kevin Tian, Stefano Stabellini, Wei Liu,
	Jun Nakajima, Andrew Cooper, Julien Grall, Tamas K Lengyel,
	Suravee Suthikulpanit, xen-devel, Boris Ostrovsky, Brian Woods,
	Roger Pau Monne

>>> On 16.01.19 at 08:10, <rcojocaru@bitdefender.com> wrote:
> On 1/14/19 4:42 PM, Juergen Gross wrote:
>> On 14/01/2019 11:56, Razvan Cojocaru wrote:
>>> On 1/14/19 11:53 AM, Jan Beulich wrote:
>>>>>>> On 14.01.19 at 10:34, <rcojocaru@bitdefender.com> wrote:
>>>>> On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
>>>>>> On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
>>>>>>> Block interrupts (in vmx_intr_assist()) for the duration of
>>>>>>> processing a sync vm_event (similarly to the strategy
>>>>>>> currently used for single-stepping). Otherwise, attempting
>>>>>>> to emulate an instruction when requested by a vm_event
>>>>>>> reply may legitimately need to call e.g.
>>>>>>> hvm_inject_page_fault(), which then overwrites the active
>>>>>>> interrupt in the VMCS.
>>>>>>>
>>>>>>> The sync vm_event handling path on x86/VMX is (roughly):
>>>>>>> monitor_traps() -> process vm_event -> vmx_intr_assist()
>>>>>>> (possibly writing VM_ENTRY_INTR_INFO) ->
>>>>>>> hvm_vm_event_do_resume() -> hvm_emulate_one_vm_event()
>>>>>>> (possibly overwriting the VM_ENTRY_INTR_INFO value).
>>>>>>>
>>>>>>> This patch may also be helpful for the future removal
>>>>>>> of may_defer in hvm_set_cr{0,3,4} and hvm_set_msr().
>>>>>>>
>>>>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>>>>>>
>>>>>>
>>>>>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>>>
>>>>> Thanks! So now we have three reviewed-bys, if I'm not mistaken all we
>>>>> need is Tamas' (for the vm_event part) and Julien / Stefano's (for ARM)
>>>>> acks (or otherwise).
>>>>
>>>> And you'd need to talk Jürgen into allowing this in, now that we're
>>>> past the freeze point.
>>>
>>> (Adding Jürgen to the conversation.)
>>>
>>> Right, that would be ideal if possible - the code has absolutely no
>>> impact on anything unless vm_event is active on the domain, which is
>>> never the case for the use-cases considered for a Xen release.
>>>
>>> So the case I'm making for the patch to go in 4.12 is that:
>>>
>>> 1. It's perfectly harmless (it affects nothing, except for introspection).
>>>
>>> 2. It's trivial and thus very easy to see that it's correct.
>>>
>>> 3. It fixes a major headache for us, and thus it is a great improvement
>>> from an introspection standpoint (fixes OS crashes / hangs which we'd
>>> otherwise need to work around in rather painful ways).
>>>
>>> 4. V3 of the patch has been sent out on Dec 14th - it's just that
>>> reviewers have had other priorities and it did not gather all acks in time.
>>>
>>> However, if it's not possible or desirable to allow this in the next
>>> best thing is to at least have all the acks necessary for it to go in
>>> first thing once the freeze is over.
>>>
>>> From Julien's reply I understand that the last ack necessary is Tamas'.
>> 
>> With that ack just arrived:
>> 
>> Release-acked-by: Juergen Gross <jgross@suse.com>
> AFAICT this is fine to apply to staging now, am I incorrect?

Yes, but may I ask that you be a little more patient?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events
  2019-01-16  8:58             ` Jan Beulich
@ 2019-01-16  9:02               ` Razvan Cojocaru
  0 siblings, 0 replies; 15+ messages in thread
From: Razvan Cojocaru @ 2019-01-16  9:02 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Juergen Gross, Kevin Tian, Stefano Stabellini, Wei Liu,
	Jun Nakajima, Andrew Cooper, Julien Grall, Tamas K Lengyel,
	Suravee Suthikulpanit, xen-devel, Boris Ostrovsky, Brian Woods,
	Roger Pau Monne

On 1/16/19 10:58 AM, Jan Beulich wrote:
>>>> On 16.01.19 at 08:10, <rcojocaru@bitdefender.com> wrote:
>> On 1/14/19 4:42 PM, Juergen Gross wrote:
>>> On 14/01/2019 11:56, Razvan Cojocaru wrote:
>>>> On 1/14/19 11:53 AM, Jan Beulich wrote:
>>>>>>>> On 14.01.19 at 10:34, <rcojocaru@bitdefender.com> wrote:
>>>>>> On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
>>>>>>> On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
>>>>>>>> Block interrupts (in vmx_intr_assist()) for the duration of
>>>>>>>> processing a sync vm_event (similarly to the strategy
>>>>>>>> currently used for single-stepping). Otherwise, attempting
>>>>>>>> to emulate an instruction when requested by a vm_event
>>>>>>>> reply may legitimately need to call e.g.
>>>>>>>> hvm_inject_page_fault(), which then overwrites the active
>>>>>>>> interrupt in the VMCS.
>>>>>>>>
>>>>>>>> The sync vm_event handling path on x86/VMX is (roughly):
>>>>>>>> monitor_traps() -> process vm_event -> vmx_intr_assist()
>>>>>>>> (possibly writing VM_ENTRY_INTR_INFO) ->
>>>>>>>> hvm_vm_event_do_resume() -> hvm_emulate_one_vm_event()
>>>>>>>> (possibly overwriting the VM_ENTRY_INTR_INFO value).
>>>>>>>>
>>>>>>>> This patch may also be helpful for the future removal
>>>>>>>> of may_defer in hvm_set_cr{0,3,4} and hvm_set_msr().
>>>>>>>>
>>>>>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>>>>>>>
>>>>>>>
>>>>>>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>>>>
>>>>>> Thanks! So now we have three reviewed-bys, if I'm not mistaken all we
>>>>>> need is Tamas' (for the vm_event part) and Julien / Stefano's (for ARM)
>>>>>> acks (or otherwise).
>>>>>
>>>>> And you'd need to talk Jürgen into allowing this in, now that we're
>>>>> past the freeze point.
>>>>
>>>> (Adding Jürgen to the conversation.)
>>>>
>>>> Right, that would be ideal if possible - the code has absolutely no
>>>> impact on anything unless vm_event is active on the domain, which is
>>>> never the case for the use-cases considered for a Xen release.
>>>>
>>>> So the case I'm making for the patch to go in 4.12 is that:
>>>>
>>>> 1. It's perfectly harmless (it affects nothing, except for introspection).
>>>>
>>>> 2. It's trivial and thus very easy to see that it's correct.
>>>>
>>>> 3. It fixes a major headache for us, and thus it is a great improvement
>>>> from an introspection standpoint (fixes OS crashes / hangs which we'd
>>>> otherwise need to work around in rather painful ways).
>>>>
>>>> 4. V3 of the patch has been sent out on Dec 14th - it's just that
>>>> reviewers have had other priorities and it did not gather all acks in time.
>>>>
>>>> However, if it's not possible or desirable to allow this in the next
>>>> best thing is to at least have all the acks necessary for it to go in
>>>> first thing once the freeze is over.
>>>>
>>>>  From Julien's reply I understand that the last ack necessary is Tamas'.
>>>
>>> With that ack just arrived:
>>>
>>> Release-acked-by: Juergen Gross <jgross@suse.com>
>> AFAICT this is fine to apply to staging now, am I incorrect?
> 
> Yes, but may I ask that you be a little more patient?

Of course, apologies. I was just unsure if further action was required 
on my part.


Thank you,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2019-01-16  9:02 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-14 11:49 [PATCH V3] x86/vm_event: block interrupt injection for sync vm_events Razvan Cojocaru
2018-12-25  2:29 ` Tian, Kevin
2019-01-11 10:31   ` Razvan Cojocaru
2019-01-11 11:36 ` Roger Pau Monné
2019-01-11 22:04 ` Boris Ostrovsky
2019-01-14  9:34   ` Razvan Cojocaru
2019-01-14  9:53     ` Jan Beulich
2019-01-14 10:56       ` Razvan Cojocaru
2019-01-14 14:42         ` Juergen Gross
2019-01-14 14:44           ` Razvan Cojocaru
2019-01-16  7:10           ` Razvan Cojocaru
2019-01-16  8:58             ` Jan Beulich
2019-01-16  9:02               ` Razvan Cojocaru
2019-01-14 10:43     ` Julien Grall
2019-01-14 14:37 ` Tamas K Lengyel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.