* [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.