All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal
@ 2017-04-19 20:22 Chao Gao
  2017-04-20 13:34 ` Jan Beulich
  0 siblings, 1 reply; 9+ messages in thread
From: Chao Gao @ 2017-04-19 20:22 UTC (permalink / raw)
  To: xen-devel; +Cc: Andrew Cooper, Julien Grall, Jan Beulich, Chao Gao

According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
"EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
and APIC ID are preserved when handling INIT signal and a reset places
APIC to xAPIC mode and APIC base address to 0xFEE00000h (this part
is in "Local APIC" -> "Local APIC Status and Location"). So there are
two problems in current code:
1. Using reset logic (aka vlapic_reset) to handle INIT signal.
2. Forgetting resetting APIC mode and base address in vlapic_reset()

This patch introduces a new function vlapic_do_init() and replaces the
wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
in vlapic_reset().

Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
mode is unreasonable. This patch also doesn't reset LDR when handling INIT
signal in x2APIC mode.

Signed-off-by: Chao Gao <chao.gao@intel.com>

---
I regard this patch as a bug fix. But I haven't seen issues caused by
this bug and am not sure of the existance of such issues. Anyhow Cc
Julien and leave the decision to you (Julien and Jan).

---
v3:
- Reset APIC base address in vlapic_reset() and accordingly change the
commit message
- Reset APIC mode before other APIC registers.

v2:
- rename vlapic_INIT to vlapic_do_init
- reset APIC to xAPIC mode in vlapic_reset()
- constify the struct vcpu in vlapic_reset()
- subject, commit message, comment changes   
- properly handle LDR in x2apic mode

---
 xen/arch/x86/hvm/vlapic.c | 36 +++++++++++++++++++++++++++---------
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 2653ba8..4ac9f46 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -83,6 +83,8 @@ static const unsigned int vlapic_lvt_mask[VLAPIC_LVT_NUM] =
     ((vlapic_get_reg(vlapic, APIC_LVTT) & APIC_TIMER_MODE_MASK) \
      == APIC_TIMER_MODE_TSC_DEADLINE)
 
+static void vlapic_do_init(struct vlapic *vlapic);
+
 static int vlapic_find_highest_vector(const void *bitmap)
 {
     const uint32_t *word = bitmap;
@@ -281,7 +283,7 @@ static void vlapic_init_sipi_one(struct vcpu *target, uint32_t icr)
         rc = vcpu_reset(target);
         ASSERT(!rc);
         target->fpu_initialised = fpu_initialised;
-        vlapic_reset(vcpu_vlapic(target));
+        vlapic_do_init(vcpu_vlapic(target));
         domain_unlock(target->domain);
         break;
     }
@@ -1237,16 +1239,14 @@ bool_t is_vlapic_lvtpc_enabled(struct vlapic *vlapic)
             !(vlapic_get_reg(vlapic, APIC_LVTPC) & APIC_LVT_MASKED));
 }
 
-/* Reset the VLPAIC back to its power-on/reset state. */
-void vlapic_reset(struct vlapic *vlapic)
+/* Reset the VLAPIC back to its init state. */
+static void vlapic_do_init(struct vlapic *vlapic)
 {
-    struct vcpu *v = vlapic_vcpu(vlapic);
     int i;
 
-    if ( !has_vlapic(v->domain) )
+    if ( !has_vlapic(vlapic_vcpu(vlapic)->domain) )
         return;
 
-    vlapic_set_reg(vlapic, APIC_ID,  (v->vcpu_id * 2) << 24);
     vlapic_set_reg(vlapic, APIC_LVR, VLAPIC_VERSION);
 
     for ( i = 0; i < 8; i++ )
@@ -1257,7 +1257,12 @@ void vlapic_reset(struct vlapic *vlapic)
     }
     vlapic_set_reg(vlapic, APIC_ICR,     0);
     vlapic_set_reg(vlapic, APIC_ICR2,    0);
-    vlapic_set_reg(vlapic, APIC_LDR,     0);
+    /*
+     * LDR is read-only in x2APIC mode. Preserve its value when handling
+     * INIT signal in x2APIC mode.
+     */
+    if ( !vlapic_x2apic_mode(vlapic) )
+        vlapic_set_reg(vlapic, APIC_LDR, 0);
     vlapic_set_reg(vlapic, APIC_TASKPRI, 0);
     vlapic_set_reg(vlapic, APIC_TMICT,   0);
     vlapic_set_reg(vlapic, APIC_TMCCT,   0);
@@ -1275,6 +1280,21 @@ void vlapic_reset(struct vlapic *vlapic)
     destroy_periodic_time(&vlapic->pt);
 }
 
+/* Reset the VLAPIC back to its power-on/reset state. */
+void vlapic_reset(struct vlapic *vlapic)
+{
+    const struct vcpu *v = vlapic_vcpu(vlapic);
+
+    if ( !has_vlapic(v->domain) )
+        return;
+
+    vlapic->hw.apic_base_msr = (MSR_IA32_APICBASE_ENABLE |
+                                APIC_DEFAULT_PHYS_BASE);
+
+    vlapic_set_reg(vlapic, APIC_ID, (v->vcpu_id * 2) << 24);
+    vlapic_do_init(vlapic);
+}
+
 /* rearm the actimer if needed, after a HVM restore */
 static void lapic_rearm(struct vlapic *s)
 {
@@ -1489,8 +1509,6 @@ int vlapic_init(struct vcpu *v)
 
     vlapic_reset(vlapic);
 
-    vlapic->hw.apic_base_msr = (MSR_IA32_APICBASE_ENABLE |
-                                APIC_DEFAULT_PHYS_BASE);
     if ( v->vcpu_id == 0 )
         vlapic->hw.apic_base_msr |= MSR_IA32_APICBASE_BSP;
 
-- 
1.8.3.1


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

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

* Re: [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal
  2017-04-20 13:34 ` Jan Beulich
@ 2017-04-20  6:59   ` Chao Gao
  2017-04-20 14:15     ` Jan Beulich
  2017-04-20 15:39   ` Julien Grall
  1 sibling, 1 reply; 9+ messages in thread
From: Chao Gao @ 2017-04-20  6:59 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Andrew Cooper, Julien Grall, xen-devel

On Thu, Apr 20, 2017 at 07:34:30AM -0600, Jan Beulich wrote:
>>>> On 19.04.17 at 22:22, <chao.gao@intel.com> wrote:
>> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
>> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
>> and APIC ID are preserved when handling INIT signal and a reset places
>> APIC to xAPIC mode and APIC base address to 0xFEE00000h (this part
>> is in "Local APIC" -> "Local APIC Status and Location"). So there are
>> two problems in current code:
>> 1. Using reset logic (aka vlapic_reset) to handle INIT signal.
>> 2. Forgetting resetting APIC mode and base address in vlapic_reset()
>> 
>> This patch introduces a new function vlapic_do_init() and replaces the
>> wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
>> in vlapic_reset().
>> 
>> Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
>> mode is unreasonable. This patch also doesn't reset LDR when handling INIT
>> signal in x2APIC mode.
>> 
>> Signed-off-by: Chao Gao <chao.gao@intel.com>
>
>Reviewed-by: Jan Beulich <jbeulich@suse.com>
>
>> I regard this patch as a bug fix. But I haven't seen issues caused by
>> this bug and am not sure of the existance of such issues. Anyhow Cc
>> Julien and leave the decision to you (Julien and Jan).
>
>Julien,
>
>I'm slightly in favor of taking it now, but I won't object if you decide
>otherwise.
>
>Jan

I just realize that we also need reset bsp field, otherwise the BSP field
may be cleared in vlapic_reset(). Really Sorry for this. 

Jan, do you think this following change is ok? Could you help add this
part when committing? 

Thanks
Chao

---8<---
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 4ac9f46..cf8ee50 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1290,6 +1290,8 @@ void vlapic_reset(struct vlapic *vlapic)
 
     vlapic->hw.apic_base_msr = (MSR_IA32_APICBASE_ENABLE |
                                 APIC_DEFAULT_PHYS_BASE);
+    if ( v->vcpu_id == 0 )
+        vlapic->hw.apic_base_msr |= MSR_IA32_APICBASE_BSP;
 
     vlapic_set_reg(vlapic, APIC_ID, (v->vcpu_id * 2) << 24);
     vlapic_do_init(vlapic);
@@ -1509,9 +1511,6 @@ int vlapic_init(struct vcpu *v)
 
     vlapic_reset(vlapic);
 
-    if ( v->vcpu_id == 0 )
-        vlapic->hw.apic_base_msr |= MSR_IA32_APICBASE_BSP;
-
     spin_lock_init(&vlapic->esr_lock);
 
     tasklet_init(&vlapic->init_sipi.tasklet,

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

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

* Re: [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal
  2017-04-20 14:15     ` Jan Beulich
@ 2017-04-20  7:37       ` Chao Gao
  2017-04-20 15:05         ` Jan Beulich
  0 siblings, 1 reply; 9+ messages in thread
From: Chao Gao @ 2017-04-20  7:37 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Andrew Cooper, Julien Grall, xen-devel

On Thu, Apr 20, 2017 at 08:15:49AM -0600, Jan Beulich wrote:
>>>> On 20.04.17 at 08:59, <chao.gao@intel.com> wrote:
>> On Thu, Apr 20, 2017 at 07:34:30AM -0600, Jan Beulich wrote:
>>>>>> On 19.04.17 at 22:22, <chao.gao@intel.com> wrote:
>>>> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
>>>> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
>>>> and APIC ID are preserved when handling INIT signal and a reset places
>>>> APIC to xAPIC mode and APIC base address to 0xFEE00000h (this part
>>>> is in "Local APIC" -> "Local APIC Status and Location"). So there are
>>>> two problems in current code:
>>>> 1. Using reset logic (aka vlapic_reset) to handle INIT signal.
>>>> 2. Forgetting resetting APIC mode and base address in vlapic_reset()
>>>> 
>>>> This patch introduces a new function vlapic_do_init() and replaces the
>>>> wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
>>>> in vlapic_reset().
>>>> 
>>>> Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
>>>> mode is unreasonable. This patch also doesn't reset LDR when handling INIT
>>>> signal in x2APIC mode.
>>>> 
>>>> Signed-off-by: Chao Gao <chao.gao@intel.com>
>>>
>>>Reviewed-by: Jan Beulich <jbeulich@suse.com>
>>>
>>>> I regard this patch as a bug fix. But I haven't seen issues caused by
>>>> this bug and am not sure of the existance of such issues. Anyhow Cc
>>>> Julien and leave the decision to you (Julien and Jan).
>>>
>>>Julien,
>>>
>>>I'm slightly in favor of taking it now, but I won't object if you decide
>>>otherwise.
>>>
>>>Jan
>> 
>> I just realize that we also need reset bsp field, otherwise the BSP field
>> may be cleared in vlapic_reset(). Really Sorry for this. 
>> 
>> Jan, do you think this following change is ok? Could you help add this
>> part when committing? 
>
>I could certainly fold it in, but I did indeed think about this bit while
>reviewing, and I'm not convinced it needs to be kept. Aiui its value
>is being established (on real hardware) very early using arbitration
>between CPUs. Forcing the bit on for vCPU0 would probably be in
>line with the vlapic_reset() use by hvm_s3_suspend(), but I'm
>rather uncertain about the use in vlapic_msr_set() in this regard.

I check SDM again. In "MODEL-SPECIFIC REGISTERS" -> "Architechural MSRs",
we can know the BSP field is R/W. So in vlapic_msr_set(), clearing BSP
is allowable. In "Advanced Programmable Interrupt Controller" -> "Local APIC"
-> "Local APIC Status and Location", it says "Following a power-up or reset,
the flag is set to 1 for the processor selected as the BSP and set to 0 for
the remaining processors". Which specific problem you think we may have if
we add this part? I just don't want this patch fixes one bug, incurring
another.

Thanks
Chao

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

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

* Re: [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal
  2017-04-20 15:39   ` Julien Grall
@ 2017-04-20  9:25     ` Chao Gao
  2017-04-21  9:45       ` Julien Grall
  0 siblings, 1 reply; 9+ messages in thread
From: Chao Gao @ 2017-04-20  9:25 UTC (permalink / raw)
  To: Julien Grall; +Cc: Andrew Cooper, Jan Beulich, xen-devel

On Thu, Apr 20, 2017 at 04:39:06PM +0100, Julien Grall wrote:
>Hi,
>
>On 20/04/17 14:34, Jan Beulich wrote:
>> > > > On 19.04.17 at 22:22, <chao.gao@intel.com> wrote:
>> > According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
>> > "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
>> > and APIC ID are preserved when handling INIT signal and a reset places
>> > APIC to xAPIC mode and APIC base address to 0xFEE00000h (this part
>> > is in "Local APIC" -> "Local APIC Status and Location"). So there are
>> > two problems in current code:
>> > 1. Using reset logic (aka vlapic_reset) to handle INIT signal.
>> > 2. Forgetting resetting APIC mode and base address in vlapic_reset()
>> > 
>> > This patch introduces a new function vlapic_do_init() and replaces the
>> > wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
>> > in vlapic_reset().
>> > 
>> > Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
>> > mode is unreasonable. This patch also doesn't reset LDR when handling INIT
>> > signal in x2APIC mode.
>> > 
>> > Signed-off-by: Chao Gao <chao.gao@intel.com>
>> 
>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>> 
>> > I regard this patch as a bug fix. But I haven't seen issues caused by
>> > this bug and am not sure of the existance of such issues. Anyhow Cc
>> > Julien and leave the decision to you (Julien and Jan).
>> 
>> Julien,
>> 
>> I'm slightly in favor of taking it now, but I won't object if you decide
>> otherwise.
>
>Chao, can you assess the benefits/risks of having this patch in Xen 4.9?

I think the risk is low for only fixing SPEC mismatched behavior and
benefit is also small as cases (changing APIC ID or Performance INIT
operation) trigger this bug are rare.

Thanks
Chao

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

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

* Re: [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal
  2017-04-19 20:22 [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal Chao Gao
@ 2017-04-20 13:34 ` Jan Beulich
  2017-04-20  6:59   ` Chao Gao
  2017-04-20 15:39   ` Julien Grall
  0 siblings, 2 replies; 9+ messages in thread
From: Jan Beulich @ 2017-04-20 13:34 UTC (permalink / raw)
  To: Julien Grall, Chao Gao; +Cc: Andrew Cooper, xen-devel

>>> On 19.04.17 at 22:22, <chao.gao@intel.com> wrote:
> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
> and APIC ID are preserved when handling INIT signal and a reset places
> APIC to xAPIC mode and APIC base address to 0xFEE00000h (this part
> is in "Local APIC" -> "Local APIC Status and Location"). So there are
> two problems in current code:
> 1. Using reset logic (aka vlapic_reset) to handle INIT signal.
> 2. Forgetting resetting APIC mode and base address in vlapic_reset()
> 
> This patch introduces a new function vlapic_do_init() and replaces the
> wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
> in vlapic_reset().
> 
> Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
> mode is unreasonable. This patch also doesn't reset LDR when handling INIT
> signal in x2APIC mode.
> 
> Signed-off-by: Chao Gao <chao.gao@intel.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

> I regard this patch as a bug fix. But I haven't seen issues caused by
> this bug and am not sure of the existance of such issues. Anyhow Cc
> Julien and leave the decision to you (Julien and Jan).

Julien,

I'm slightly in favor of taking it now, but I won't object if you decide
otherwise.

Jan


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

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

* Re: [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal
  2017-04-20  6:59   ` Chao Gao
@ 2017-04-20 14:15     ` Jan Beulich
  2017-04-20  7:37       ` Chao Gao
  0 siblings, 1 reply; 9+ messages in thread
From: Jan Beulich @ 2017-04-20 14:15 UTC (permalink / raw)
  To: Chao Gao; +Cc: Andrew Cooper, Julien Grall, xen-devel

>>> On 20.04.17 at 08:59, <chao.gao@intel.com> wrote:
> On Thu, Apr 20, 2017 at 07:34:30AM -0600, Jan Beulich wrote:
>>>>> On 19.04.17 at 22:22, <chao.gao@intel.com> wrote:
>>> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
>>> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
>>> and APIC ID are preserved when handling INIT signal and a reset places
>>> APIC to xAPIC mode and APIC base address to 0xFEE00000h (this part
>>> is in "Local APIC" -> "Local APIC Status and Location"). So there are
>>> two problems in current code:
>>> 1. Using reset logic (aka vlapic_reset) to handle INIT signal.
>>> 2. Forgetting resetting APIC mode and base address in vlapic_reset()
>>> 
>>> This patch introduces a new function vlapic_do_init() and replaces the
>>> wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
>>> in vlapic_reset().
>>> 
>>> Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
>>> mode is unreasonable. This patch also doesn't reset LDR when handling INIT
>>> signal in x2APIC mode.
>>> 
>>> Signed-off-by: Chao Gao <chao.gao@intel.com>
>>
>>Reviewed-by: Jan Beulich <jbeulich@suse.com>
>>
>>> I regard this patch as a bug fix. But I haven't seen issues caused by
>>> this bug and am not sure of the existance of such issues. Anyhow Cc
>>> Julien and leave the decision to you (Julien and Jan).
>>
>>Julien,
>>
>>I'm slightly in favor of taking it now, but I won't object if you decide
>>otherwise.
>>
>>Jan
> 
> I just realize that we also need reset bsp field, otherwise the BSP field
> may be cleared in vlapic_reset(). Really Sorry for this. 
> 
> Jan, do you think this following change is ok? Could you help add this
> part when committing? 

I could certainly fold it in, but I did indeed think about this bit while
reviewing, and I'm not convinced it needs to be kept. Aiui its value
is being established (on real hardware) very early using arbitration
between CPUs. Forcing the bit on for vCPU0 would probably be in
line with the vlapic_reset() use by hvm_s3_suspend(), but I'm
rather uncertain about the use in vlapic_msr_set() in this regard.

Jan


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

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

* Re: [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal
  2017-04-20  7:37       ` Chao Gao
@ 2017-04-20 15:05         ` Jan Beulich
  0 siblings, 0 replies; 9+ messages in thread
From: Jan Beulich @ 2017-04-20 15:05 UTC (permalink / raw)
  To: Chao Gao; +Cc: Andrew Cooper, Julien Grall, xen-devel

>>> On 20.04.17 at 09:37, <chao.gao@intel.com> wrote:
> On Thu, Apr 20, 2017 at 08:15:49AM -0600, Jan Beulich wrote:
>>>>> On 20.04.17 at 08:59, <chao.gao@intel.com> wrote:
>>> On Thu, Apr 20, 2017 at 07:34:30AM -0600, Jan Beulich wrote:
>>>>>>> On 19.04.17 at 22:22, <chao.gao@intel.com> wrote:
>>>>> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
>>>>> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
>>>>> and APIC ID are preserved when handling INIT signal and a reset places
>>>>> APIC to xAPIC mode and APIC base address to 0xFEE00000h (this part
>>>>> is in "Local APIC" -> "Local APIC Status and Location"). So there are
>>>>> two problems in current code:
>>>>> 1. Using reset logic (aka vlapic_reset) to handle INIT signal.
>>>>> 2. Forgetting resetting APIC mode and base address in vlapic_reset()
>>>>> 
>>>>> This patch introduces a new function vlapic_do_init() and replaces the
>>>>> wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
>>>>> in vlapic_reset().
>>>>> 
>>>>> Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
>>>>> mode is unreasonable. This patch also doesn't reset LDR when handling INIT
>>>>> signal in x2APIC mode.
>>>>> 
>>>>> Signed-off-by: Chao Gao <chao.gao@intel.com>
>>>>
>>>>Reviewed-by: Jan Beulich <jbeulich@suse.com>
>>>>
>>>>> I regard this patch as a bug fix. But I haven't seen issues caused by
>>>>> this bug and am not sure of the existance of such issues. Anyhow Cc
>>>>> Julien and leave the decision to you (Julien and Jan).
>>>>
>>>>Julien,
>>>>
>>>>I'm slightly in favor of taking it now, but I won't object if you decide
>>>>otherwise.
>>>>
>>>>Jan
>>> 
>>> I just realize that we also need reset bsp field, otherwise the BSP field
>>> may be cleared in vlapic_reset(). Really Sorry for this. 
>>> 
>>> Jan, do you think this following change is ok? Could you help add this
>>> part when committing? 
>>
>>I could certainly fold it in, but I did indeed think about this bit while
>>reviewing, and I'm not convinced it needs to be kept. Aiui its value
>>is being established (on real hardware) very early using arbitration
>>between CPUs. Forcing the bit on for vCPU0 would probably be in
>>line with the vlapic_reset() use by hvm_s3_suspend(), but I'm
>>rather uncertain about the use in vlapic_msr_set() in this regard.
> 
> I check SDM again. In "MODEL-SPECIFIC REGISTERS" -> "Architechural MSRs",
> we can know the BSP field is R/W. So in vlapic_msr_set(), clearing BSP
> is allowable. In "Advanced Programmable Interrupt Controller" -> "Local APIC"
> -> "Local APIC Status and Location", it says "Following a power-up or reset,
> the flag is set to 1 for the processor selected as the BSP and set to 0 for
> the remaining processors". Which specific problem you think we may have if
> we add this part? I just don't want this patch fixes one bug, incurring
> another.

My primary concern is with the guest possibly offlining its vCPU0.
But having looked again, the additional change you suggested is
benign to vlapic_msr_set(), as the full guest specified value is
being written to vlapic->hw.apic_base_msr soon after the call to
vlapic_reset() anyway. IOW - yes, that addendum should be fine.

Jan


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

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

* Re: [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal
  2017-04-20 13:34 ` Jan Beulich
  2017-04-20  6:59   ` Chao Gao
@ 2017-04-20 15:39   ` Julien Grall
  2017-04-20  9:25     ` Chao Gao
  1 sibling, 1 reply; 9+ messages in thread
From: Julien Grall @ 2017-04-20 15:39 UTC (permalink / raw)
  To: Jan Beulich, Chao Gao; +Cc: Andrew Cooper, xen-devel

Hi,

On 20/04/17 14:34, Jan Beulich wrote:
>>>> On 19.04.17 at 22:22, <chao.gao@intel.com> wrote:
>> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
>> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
>> and APIC ID are preserved when handling INIT signal and a reset places
>> APIC to xAPIC mode and APIC base address to 0xFEE00000h (this part
>> is in "Local APIC" -> "Local APIC Status and Location"). So there are
>> two problems in current code:
>> 1. Using reset logic (aka vlapic_reset) to handle INIT signal.
>> 2. Forgetting resetting APIC mode and base address in vlapic_reset()
>>
>> This patch introduces a new function vlapic_do_init() and replaces the
>> wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
>> in vlapic_reset().
>>
>> Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
>> mode is unreasonable. This patch also doesn't reset LDR when handling INIT
>> signal in x2APIC mode.
>>
>> Signed-off-by: Chao Gao <chao.gao@intel.com>
>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>
>> I regard this patch as a bug fix. But I haven't seen issues caused by
>> this bug and am not sure of the existance of such issues. Anyhow Cc
>> Julien and leave the decision to you (Julien and Jan).
>
> Julien,
>
> I'm slightly in favor of taking it now, but I won't object if you decide
> otherwise.

Chao, can you assess the benefits/risks of having this patch in Xen 4.9?

Cheers,

-- 
Julien Grall

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

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

* Re: [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal
  2017-04-20  9:25     ` Chao Gao
@ 2017-04-21  9:45       ` Julien Grall
  0 siblings, 0 replies; 9+ messages in thread
From: Julien Grall @ 2017-04-21  9:45 UTC (permalink / raw)
  To: Jan Beulich, Andrew Cooper, xen-devel



On 20/04/17 10:25, Chao Gao wrote:
> On Thu, Apr 20, 2017 at 04:39:06PM +0100, Julien Grall wrote:
>> Hi,
>>
>> On 20/04/17 14:34, Jan Beulich wrote:
>>>>>> On 19.04.17 at 22:22, <chao.gao@intel.com> wrote:
>>>> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
>>>> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
>>>> and APIC ID are preserved when handling INIT signal and a reset places
>>>> APIC to xAPIC mode and APIC base address to 0xFEE00000h (this part
>>>> is in "Local APIC" -> "Local APIC Status and Location"). So there are
>>>> two problems in current code:
>>>> 1. Using reset logic (aka vlapic_reset) to handle INIT signal.
>>>> 2. Forgetting resetting APIC mode and base address in vlapic_reset()
>>>>
>>>> This patch introduces a new function vlapic_do_init() and replaces the
>>>> wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
>>>> in vlapic_reset().
>>>>
>>>> Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
>>>> mode is unreasonable. This patch also doesn't reset LDR when handling INIT
>>>> signal in x2APIC mode.
>>>>
>>>> Signed-off-by: Chao Gao <chao.gao@intel.com>
>>>
>>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>>>
>>>> I regard this patch as a bug fix. But I haven't seen issues caused by
>>>> this bug and am not sure of the existance of such issues. Anyhow Cc
>>>> Julien and leave the decision to you (Julien and Jan).
>>>
>>> Julien,
>>>
>>> I'm slightly in favor of taking it now, but I won't object if you decide
>>> otherwise.
>>
>> Chao, can you assess the benefits/risks of having this patch in Xen 4.9?
>
> I think the risk is low for only fixing SPEC mismatched behavior and
> benefit is also small as cases (changing APIC ID or Performance INIT
> operation) trigger this bug are rare.

Release-acked-by: Julien Grall <julien.grall@arm.com>

>
> Thanks
> Chao
>

-- 
Julien Grall

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

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

end of thread, other threads:[~2017-04-21  9:45 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-19 20:22 [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal Chao Gao
2017-04-20 13:34 ` Jan Beulich
2017-04-20  6:59   ` Chao Gao
2017-04-20 14:15     ` Jan Beulich
2017-04-20  7:37       ` Chao Gao
2017-04-20 15:05         ` Jan Beulich
2017-04-20 15:39   ` Julien Grall
2017-04-20  9:25     ` Chao Gao
2017-04-21  9:45       ` Julien Grall

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.