thr3ads.net - Xen devel - [PATCH v3 0/4] Nested VMX: APIC-v related bug fixing [Aug 2013]

If this information is useful, please help other people find it:
Share via:

Yang Zhang

2013-Aug-22 07:24 UTC

[PATCH v3 0/4] Nested VMX: APIC-v related bug fixing

From: Yang Zhang <yang.z.zhang@Intel.com>

The following patches fix the issue that fail to boot L2 guest on APIC-v
available machine. The main problem is that with APIC-v, virtual interrupt
inject
L1 is totally through APIC-v. But if virtual interrupt is arrived when L2 is
running,
L1 will detect interrupt through vmexit with reason external interrupt. If this
happens,
we should update RVI/SVI to make APIC-v working accordingly.

Changes from V2:
*   Rebase on top of Xen upstream
*   Merge patch 1(Introduce interrupt source supporting) and patch 3(Add
interface to update vPPR)
    into the place where there were used.
*   Reorder the patch set.

Yang Zhang (4):
  Nested VMX: Check whether interrupt is blocked by TPR
  Nested VMX: Force check ISR when L2 is running
  Nested VMX: Clear APIC-v control bit in vmcs02
  Nested VMX: Update APIC-v(RVI/SVI) when vmexit to L1

 xen/arch/x86/hvm/irq.c             |    2 +-
 xen/arch/x86/hvm/vlapic.c          |   24 +++++++++++++-----
 xen/arch/x86/hvm/vmx/intr.c        |    9 +++++-
 xen/arch/x86/hvm/vmx/vmx.c         |   14 ++++++----
 xen/arch/x86/hvm/vmx/vvmx.c        |   45 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-x86/hvm/vlapic.h   |    3 +-
 xen/include/asm-x86/hvm/vmx/vmx.h  |    2 +-
 xen/include/asm-x86/hvm/vmx/vvmx.h |    1 +
 8 files changed, 82 insertions(+), 18 deletions(-)

Yang Zhang

2013-Aug-22 07:24 UTC

head link

[PATCH v3 1/4] Nested VMX: Check whether interrupt is blocked by TPR

From: Yang Zhang <yang.z.zhang@Intel.com>

If interrupt is blocked by L1''s TPR, L2 should not see it and keep
running. Adding the check before L2 to retrive interrupt.

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
---
 xen/arch/x86/hvm/vmx/intr.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
index e376f3c..cab9109 100644
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -165,6 +165,11 @@ static int nvmx_intr_intercept(struct vcpu *v, struct
hvm_intack intack)
 {
     u32 ctrl;
 
+    /* If blocked by L1''s tpr, then nothing to do. */
+    if ( nestedhvm_vcpu_in_guestmode(v) &&
+         hvm_interrupt_blocked(v, intack) == hvm_intblk_tpr )
+        return 1;
+
     if ( nvmx_intr_blocked(v) != hvm_intblk_none )
     {
         enable_intr_window(v, intack);
-- 
1.7.1

Yang Zhang

2013-Aug-22 07:24 UTC

head link

[PATCH v3 2/4] Nested VMX: Force check ISR when L2 is running

From: Yang Zhang <yang.z.zhang@Intel.com>

External interrupt is allowed to notify CPU only when it has higher
priority than current in servicing interrupt. With APIC-v, the priority
comparing is done by hardware and hardware will inject the interrupt to
VCPU when it recognizes an interrupt. Currently, there is no virtual
APIC-v feature available for L1 to use, so when L2 is running, we still need
to compare interrupt priority with ISR in hypervisor instead via hardware.

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
---
 xen/arch/x86/hvm/vlapic.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 7a154f9..f1530fd 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -37,6 +37,7 @@
 #include <asm/hvm/io.h>
 #include <asm/hvm/support.h>
 #include <asm/hvm/vmx/vmx.h>
+#include <asm/hvm/nestedhvm.h>
 #include <public/hvm/ioreq.h>
 #include <public/hvm/params.h>
 
@@ -1037,7 +1038,8 @@ int vlapic_has_pending_irq(struct vcpu *v)
     if ( irr == -1 )
         return -1;
 
-    if ( vlapic_virtual_intr_delivery_enabled() )
+    if ( vlapic_virtual_intr_delivery_enabled() &&
+         !nestedhvm_vcpu_in_guestmode(v) )
         return irr;
 
     isr = vlapic_find_highest_isr(vlapic);
-- 
1.7.1

Yang Zhang

2013-Aug-22 07:24 UTC

head link

[PATCH v3 3/4] Nested VMX: Clear APIC-v control bit in vmcs02

From: Yang Zhang <yang.z.zhang@Intel.com>

There is no vAPIC-v supporting, so mask APIC-v control bit when
constructing vmcs02.

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
---
 xen/arch/x86/hvm/vmx/vvmx.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 5dfbc54..4792019 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -613,8 +613,15 @@ void nvmx_update_secondary_exec_control(struct vcpu *v,
     u32 shadow_cntrl;
     struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
     struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
+    u32 apicv_bit = SECONDARY_EXEC_APIC_REGISTER_VIRT |
+                    SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY;
 
+    host_cntrl &= ~apicv_bit;
     shadow_cntrl = __get_vvmcs(nvcpu->nv_vvmcx, SECONDARY_VM_EXEC_CONTROL);
+
+    /* No vAPIC-v support, so it shouldn''t be set in vmcs12. */
+    ASSERT( !(shadow_cntrl & apicv_bit) );
+
     nvmx->ept.enabled = !!(shadow_cntrl & SECONDARY_EXEC_ENABLE_EPT);
     shadow_cntrl |= host_cntrl;
     __vmwrite(SECONDARY_VM_EXEC_CONTROL, shadow_cntrl);
@@ -625,7 +632,12 @@ static void nvmx_update_pin_control(struct vcpu *v,
unsigned long host_cntrl)
     u32 shadow_cntrl;
     struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
 
+    host_cntrl &= ~PIN_BASED_POSTED_INTERRUPT;
     shadow_cntrl = __get_vvmcs(nvcpu->nv_vvmcx, PIN_BASED_VM_EXEC_CONTROL);
+
+    /* No vAPIC-v support, so it shouldn''t be set in vmcs12. */
+    ASSERT( !(shadow_cntrl & PIN_BASED_POSTED_INTERRUPT) );
+
     shadow_cntrl |= host_cntrl;
     __vmwrite(PIN_BASED_VM_EXEC_CONTROL, shadow_cntrl);
 }
-- 
1.7.1

Yang Zhang

2013-Aug-22 07:25 UTC

head link

[PATCH v3 4/4] Nested VMX: Update APIC-v(RVI/SVI) when vmexit to L1

From: Yang Zhang <yang.z.zhang@Intel.com>

If enabling APIC-v, all interrupts to L1 are delivered through APIC-v.
But when L2 is running, external interrupt will casue L1 vmexit with
reason external interrupt. Then L1 will pick up the interrupt through
vmcs12. when L1 ack the interrupt, since the APIC-v is enabled when
L1 is running, so APIC-v hardware still will do vEOI updating. The problem
is that the interrupt is delivered not through APIC-v hardware, this means
SVI/RVI/vPPR are not setting, but hardware required them when doing vEOI
updating. The solution is that, when L1 tried to pick up the interrupt
from vmcs12, then hypervisor will help to update the SVI/RVI/vPPR to make
sure the following vEOI updating and vPPR updating corrently.

Also, since interrupt is delivered through vmcs12, so APIC-v hardware will
not cleare vIRR and hypervisor need to clear it before L1 running.

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
---
 xen/arch/x86/hvm/irq.c             |    2 +-
 xen/arch/x86/hvm/vlapic.c          |   20 ++++++++++++++------
 xen/arch/x86/hvm/vmx/intr.c        |    4 ++--
 xen/arch/x86/hvm/vmx/vmx.c         |   14 ++++++++------
 xen/arch/x86/hvm/vmx/vvmx.c        |   33 +++++++++++++++++++++++++++++++++
 xen/include/asm-x86/hvm/vlapic.h   |    3 ++-
 xen/include/asm-x86/hvm/vmx/vmx.h  |    2 +-
 xen/include/asm-x86/hvm/vmx/vvmx.h |    1 +
 8 files changed, 62 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 9eae5de..6a6fb68 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -437,7 +437,7 @@ struct hvm_intack hvm_vcpu_ack_pending_irq(
             intack.vector = (uint8_t)vector;
         break;
     case hvm_intsrc_lapic:
-        if ( !vlapic_ack_pending_irq(v, intack.vector) )
+        if ( !vlapic_ack_pending_irq(v, intack.vector, 0) )
             intack = hvm_intack_none;
         break;
     case hvm_intsrc_vector:
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index f1530fd..d21a6c9 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -168,6 +168,14 @@ static uint32_t vlapic_get_ppr(struct vlapic *vlapic)
     return ppr;
 }
 
+uint32_t vlapic_set_ppr(struct vlapic *vlapic)
+{
+   uint32_t ppr = vlapic_get_ppr(vlapic);
+
+   vlapic_set_reg(vlapic, APIC_PROCPRI, ppr);
+   return ppr;
+}
+
 static int vlapic_match_logical_addr(struct vlapic *vlapic, uint8_t mda)
 {
     int result = 0;
@@ -1050,15 +1058,15 @@ int vlapic_has_pending_irq(struct vcpu *v)
     return irr;
 }
 
-int vlapic_ack_pending_irq(struct vcpu *v, int vector)
+int vlapic_ack_pending_irq(struct vcpu *v, int vector, int force_ack)
 {
     struct vlapic *vlapic = vcpu_vlapic(v);
 
-    if ( vlapic_virtual_intr_delivery_enabled() )
-        return 1;
-
-    vlapic_set_vector(vector, &vlapic->regs->data[APIC_ISR]);
-    vlapic_clear_irr(vector, vlapic);
+    if ( force_ack || !vlapic_virtual_intr_delivery_enabled() )
+    {
+        vlapic_set_vector(vector, &vlapic->regs->data[APIC_ISR]);
+        vlapic_clear_irr(vector, vlapic);
+    }
 
     return 1;
 }
diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
index cab9109..45942ab 100644
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -185,7 +185,7 @@ static int nvmx_intr_intercept(struct vcpu *v, struct
hvm_intack intack)
             if ( !(ctrl & PIN_BASED_EXT_INTR_MASK) )
                 return 0;
 
-            vmx_inject_extint(intack.vector);
+            vmx_inject_extint(intack.vector, intack.source);
 
             ctrl = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, VM_EXIT_CONTROLS);
             if ( ctrl & VM_EXIT_ACK_INTR_ON_EXIT )
@@ -314,7 +314,7 @@ void vmx_intr_assist(void)
     else
     {
         HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
-        vmx_inject_extint(intack.vector);
+        vmx_inject_extint(intack.vector, intack.source);
         pt_intr_post(v, intack);
     }
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 8ed7026..011a817 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1208,7 +1208,7 @@ static void vmx_update_guest_efer(struct vcpu *v)
 }
 
 void nvmx_enqueue_n2_exceptions(struct vcpu *v, 
-            unsigned long intr_fields, int error_code)
+            unsigned long intr_fields, int error_code, uint8_t source)
 {
     struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
 
@@ -1216,6 +1216,7 @@ void nvmx_enqueue_n2_exceptions(struct vcpu *v,
         /* enqueue the exception till the VMCS switch back to L1 */
         nvmx->intr.intr_info = intr_fields;
         nvmx->intr.error_code = error_code;
+        nvmx->intr.source = source;
         vcpu_nestedhvm(v).nv_vmexit_pending = 1;
         return;
     }
@@ -1227,7 +1228,8 @@ void nvmx_enqueue_n2_exceptions(struct vcpu *v,
 
 static int nvmx_vmexit_trap(struct vcpu *v, struct hvm_trap *trap)
 {
-    nvmx_enqueue_n2_exceptions(v, trap->vector, trap->error_code);
+    nvmx_enqueue_n2_exceptions(v, trap->vector, trap->error_code,
+                               hvm_intsrc_none);
     return NESTEDHVM_VMEXIT_DONE;
 }
 
@@ -1258,7 +1260,7 @@ static void __vmx_inject_exception(int trap, int type, int
error_code)
         curr->arch.hvm_vmx.vmx_emulate = 1;
 }
 
-void vmx_inject_extint(int trap)
+void vmx_inject_extint(int trap, uint8_t source)
 {
     struct vcpu *v = current;
     u32    pin_based_cntrl;
@@ -1269,7 +1271,7 @@ void vmx_inject_extint(int trap)
         if ( pin_based_cntrl & PIN_BASED_EXT_INTR_MASK ) {
             nvmx_enqueue_n2_exceptions (v, 
                INTR_INFO_VALID_MASK | (X86_EVENTTYPE_EXT_INTR<<8) | trap,
-               HVM_DELIVER_NO_ERROR_CODE);
+               HVM_DELIVER_NO_ERROR_CODE, source);
             return;
         }
     }
@@ -1288,7 +1290,7 @@ void vmx_inject_nmi(void)
         if ( pin_based_cntrl & PIN_BASED_NMI_EXITING ) {
             nvmx_enqueue_n2_exceptions (v, 
                INTR_INFO_VALID_MASK | (X86_EVENTTYPE_NMI<<8) | TRAP_nmi,
-               HVM_DELIVER_NO_ERROR_CODE);
+               HVM_DELIVER_NO_ERROR_CODE, hvm_intsrc_nmi);
             return;
         }
     }
@@ -1356,7 +1358,7 @@ static void vmx_inject_trap(struct hvm_trap *trap)
     {
         nvmx_enqueue_n2_exceptions (curr, 
             INTR_INFO_VALID_MASK | (_trap.type<<8) | _trap.vector,
-            _trap.error_code); 
+            _trap.error_code, hvm_intsrc_none);
         return;
     }
     else
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 4792019..4f6f614 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1295,6 +1295,36 @@ static void sync_exception_state(struct vcpu *v)
     }
 }
 
+static void nvmx_update_apicv(struct vcpu *v)
+{
+    struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
+    struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+    unsigned long reason = __get_vvmcs(nvcpu->nv_vvmcx, VM_EXIT_REASON);
+    uint32_t intr_info = __get_vvmcs(nvcpu->nv_vvmcx, VM_EXIT_INTR_INFO);
+
+    if ( reason == EXIT_REASON_EXTERNAL_INTERRUPT &&
+         nvmx->intr.source == hvm_intsrc_lapic &&
+         (intr_info & INTR_INFO_VALID_MASK) )
+    {
+        uint16_t status;
+        uint32_t rvi, ppr;
+        uint32_t vector = intr_info & 0xff;
+        struct vlapic *vlapic = vcpu_vlapic(v);
+
+        vlapic_ack_pending_irq(v, vector, 1);
+
+        ppr = vlapic_set_ppr(vlapic);
+        WARN_ON( (ppr & 0xf0) != (vector & 0xf0) );
+
+        status = vector << 8;
+        rvi = vlapic_has_pending_irq(v);
+        if ( rvi != -1 )
+            status |= rvi & 0xff;
+
+        __vmwrite(GUEST_INTR_STATUS, status);
+    }
+}
+
 static void virtual_vmexit(struct cpu_user_regs *regs)
 {
     struct vcpu *v = current;
@@ -1340,6 +1370,9 @@ static void virtual_vmexit(struct cpu_user_regs *regs)
     /* updating host cr0 to sync TS bit */
     __vmwrite(HOST_CR0, v->arch.hvm_vmx.host_cr0);
 
+    if ( cpu_has_vmx_virtual_intr_delivery )
+        nvmx_update_apicv(v);
+
     vmreturn(regs, VMSUCCEED);
 }
 
diff --git a/xen/include/asm-x86/hvm/vlapic.h b/xen/include/asm-x86/hvm/vlapic.h
index 021a5f2..6109137 100644
--- a/xen/include/asm-x86/hvm/vlapic.h
+++ b/xen/include/asm-x86/hvm/vlapic.h
@@ -96,7 +96,7 @@ bool_t is_vlapic_lvtpc_enabled(struct vlapic *vlapic);
 void vlapic_set_irq(struct vlapic *vlapic, uint8_t vec, uint8_t trig);
 
 int vlapic_has_pending_irq(struct vcpu *v);
-int vlapic_ack_pending_irq(struct vcpu *v, int vector);
+int vlapic_ack_pending_irq(struct vcpu *v, int vector, int force_ack);
 
 int  vlapic_init(struct vcpu *v);
 void vlapic_destroy(struct vcpu *v);
@@ -108,6 +108,7 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t
value);
 uint64_t vlapic_tdt_msr_get(struct vlapic *vlapic);
 
 int vlapic_accept_pic_intr(struct vcpu *v);
+uint32_t vlapic_set_ppr(struct vlapic *vlapic);
 
 void vlapic_adjust_i8259_target(struct domain *d);
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h
b/xen/include/asm-x86/hvm/vmx/vmx.h
index c33b9f9..f4d759b 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -448,7 +448,7 @@ static inline int __vmxon(u64 addr)
 
 void vmx_get_segment_register(struct vcpu *, enum x86_segment,
                               struct segment_register *);
-void vmx_inject_extint(int trap);
+void vmx_inject_extint(int trap, uint8_t source);
 void vmx_inject_nmi(void);
 
 int ept_p2m_init(struct p2m_domain *p2m);
diff --git a/xen/include/asm-x86/hvm/vmx/vvmx.h
b/xen/include/asm-x86/hvm/vmx/vvmx.h
index 3874525..be2b5c6 100644
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h
@@ -36,6 +36,7 @@ struct nestedvmx {
     struct {
         unsigned long intr_info;
         u32           error_code;
+        uint8_t       source;
     } intr;
     struct {
         bool_t   enabled;
-- 
1.7.1

Dong, Eddie

2013-Aug-22 07:35 UTC

head link

Re: [PATCH v3 0/4] Nested VMX: APIC-v related bug fixing

Acked.

-----Original Message-----
From: Zhang, Yang Z 
Sent: Thursday, August 22, 2013 3:25 PM
To: xen-devel@lists.xensource.com
Cc: JBeulich@suse.com; Andrew.Cooper3@citrix.com; Dong, Eddie; Nakajima, Jun;
Zhang, Yang Z
Subject: [PATCH v3 0/4] Nested VMX: APIC-v related bug fixing

From: Yang Zhang <yang.z.zhang@Intel.com>

The following patches fix the issue that fail to boot L2 guest on APIC-v
available machine. The main problem is that with APIC-v, virtual interrupt
inject
L1 is totally through APIC-v. But if virtual interrupt is arrived when L2 is
running,
L1 will detect interrupt through vmexit with reason external interrupt. If this
happens, we should update RVI/SVI to make APIC-v working accordingly.

Changes from V2:
*   Rebase on top of Xen upstream
*   Merge patch 1(Introduce interrupt source supporting) and patch 3(Add
interface to update vPPR)
    into the place where there were used.
*   Reorder the patch set.

Yang Zhang (4):
  Nested VMX: Check whether interrupt is blocked by TPR
  Nested VMX: Force check ISR when L2 is running
  Nested VMX: Clear APIC-v control bit in vmcs02
  Nested VMX: Update APIC-v(RVI/SVI) when vmexit to L1

 xen/arch/x86/hvm/irq.c             |    2 +-
 xen/arch/x86/hvm/vlapic.c          |   24 +++++++++++++-----
 xen/arch/x86/hvm/vmx/intr.c        |    9 +++++-
 xen/arch/x86/hvm/vmx/vmx.c         |   14 ++++++----
 xen/arch/x86/hvm/vmx/vvmx.c        |   45 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-x86/hvm/vlapic.h   |    3 +-
 xen/include/asm-x86/hvm/vmx/vmx.h  |    2 +-
 xen/include/asm-x86/hvm/vmx/vvmx.h |    1 +
 8 files changed, 82 insertions(+), 18 deletions(-)

Jan Beulich

2013-Aug-23 07:12 UTC

head link

Re: [PATCH v3 0/4] Nested VMX: APIC-v related bug fixing

>>> On 22.08.13 at 09:24, Yang Zhang <yang.z.zhang@intel.com>
wrote:
> The following patches fix the issue that fail to boot L2 guest on APIC-v
> available machine. The main problem is that with APIC-v, virtual interrupt 
> inject
> L1 is totally through APIC-v. But if virtual interrupt is arrived when L2
is
> running,
> L1 will detect interrupt through vmexit with reason external interrupt. If 
> this happens,
> we should update RVI/SVI to make APIC-v working accordingly.
Am I right in assuming that this series wants to be backported to 4.3?

Jan

Zhang, Yang Z

2013-Aug-23 07:17 UTC

head link

Re: [PATCH v3 0/4] Nested VMX: APIC-v related bug fixing

Jan Beulich wrote on 2013-08-23:>>>> On 22.08.13 at 09:24, Yang Zhang <yang.z.zhang@intel.com>
wrote:
>> The following patches fix the issue that fail to boot L2 guest on
>> APIC-v available machine. The main problem is that with APIC-v,
>> virtual interrupt inject
>> L1 is totally through APIC-v. But if virtual interrupt is arrived
>> when
>> L2 is running,
>> L1 will detect interrupt through vmexit with reason external
>> interrupt. If this happens, we should update RVI/SVI to make APIC-v
>> working accordingly.
> 
> Am I right in assuming that this series wants to be backported to 4.3?
Sure. It''s ok to back port them to 4.3.

Best regards,
Yang

Jan Beulich

2013-Aug-23 07:25 UTC

head link

Re: [PATCH v3 0/4] Nested VMX: APIC-v related bug fixing

>>> On 23.08.13 at 09:17, "Zhang, Yang Z"
<yang.z.zhang@intel.com> wrote:
> Jan Beulich wrote on 2013-08-23:
>>>>> On 22.08.13 at 09:24, Yang Zhang
<yang.z.zhang@intel.com> wrote:
>>> The following patches fix the issue that fail to boot L2 guest on
>>> APIC-v available machine. The main problem is that with APIC-v,
>>> virtual interrupt inject
>>> L1 is totally through APIC-v. But if virtual interrupt is arrived
>>> when
>>> L2 is running,
>>> L1 will detect interrupt through vmexit with reason external
>>> interrupt. If this happens, we should update RVI/SVI to make APIC-v
>>> working accordingly.
>> 
>> Am I right in assuming that this series wants to be backported to 4.3?
> 
> Sure. It''s ok to back port them to 4.3.
The question wasn''t whether it''s okay, but whether its
necessary
or at least desirable.

Jan

Zhang, Yang Z

2013-Aug-23 07:38 UTC

head link

Re: [PATCH v3 0/4] Nested VMX: APIC-v related bug fixing

Jan Beulich wrote on 2013-08-23:>>>> On 23.08.13 at 09:17, "Zhang, Yang Z"
<yang.z.zhang@intel.com> wrote:
>> Jan Beulich wrote on 2013-08-23:
>>>>>> On 22.08.13 at 09:24, Yang Zhang
<yang.z.zhang@intel.com> wrote:
>>>> The following patches fix the issue that fail to boot L2 guest
on
>>>> APIC-v available machine. The main problem is that with APIC-v,
>>>> virtual interrupt inject
>>>> L1 is totally through APIC-v. But if virtual interrupt is
arrived
>>>> when
>>>> L2 is running,
>>>> L1 will detect interrupt through vmexit with reason external
>>>> interrupt. If this happens, we should update RVI/SVI to make
>>>> APIC-v working accordingly.
>>> 
>>> Am I right in assuming that this series wants to be backported to
4.3?
>> 
>> Sure. It''s ok to back port them to 4.3.
> 
> The question wasn''t whether it''s okay, but whether its
necessary or at
> least desirable.Without this patch, all platforms with apicv feature will fail to boot L2 guest.
So I think we should backport them into xen 4.3.

Best regards,
Yang

Possibly Parallel Threads

Search for more reasonably related threads

Xen devel - Aug 2013 - [PATCH v3 0/4] Nested VMX: APIC-v related bug fixing

[PATCH v3 0/4] Nested VMX: APIC-v related bug fixing

[PATCH v3 1/4] Nested VMX: Check whether interrupt is blocked by TPR

[PATCH v3 2/4] Nested VMX: Force check ISR when L2 is running

[PATCH v3 3/4] Nested VMX: Clear APIC-v control bit in vmcs02

[PATCH v3 4/4] Nested VMX: Update APIC-v(RVI/SVI) when vmexit to L1

Re: [PATCH v3 0/4] Nested VMX: APIC-v related bug fixing

Re: [PATCH v3 0/4] Nested VMX: APIC-v related bug fixing

Re: [PATCH v3 0/4] Nested VMX: APIC-v related bug fixing

Re: [PATCH v3 0/4] Nested VMX: APIC-v related bug fixing

Re: [PATCH v3 0/4] Nested VMX: APIC-v related bug fixing

Possibly Parallel Threads