[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] vlapic: fix two flaws in emulating MSR_IA32_APICBASE



>>> On 31.05.17 at 13:34, <chao.gao@xxxxxxxxx> wrote:
> On Wed, May 31, 2017 at 03:15:28AM -0600, Jan Beulich wrote:
>>>>> On 31.05.17 at 10:56, <chao.gao@xxxxxxxxx> wrote:
>>> On Wed, May 31, 2017 at 02:06:50AM -0600, Jan Beulich wrote:
>>>>>>> On 31.05.17 at 09:46, <chao.gao@xxxxxxxxx> wrote:
>>>>> --- a/xen/arch/x86/hvm/vlapic.c
>>>>> +++ b/xen/arch/x86/hvm/vlapic.c
>>>>> @@ -1003,14 +1003,12 @@ bool_t vlapic_msr_set(struct vlapic *vlapic, 
>>>>> uint64_t 
> value)
>>>>>          }
>>>>>          else
>>>>>          {
>>>>> -            if ( unlikely(vlapic_x2apic_mode(vlapic)) )
>>>>> -                return 0;
>>>>>              vlapic->hw.disabled |= VLAPIC_HW_DISABLED;
>>>>>              pt_may_unmask_irq(vlapic_domain(vlapic), NULL);
>>>>>          }
>>>>
>>>>Especially with you not adding any code here, ...
>>>>
>>>>> --- a/xen/include/asm-x86/hvm/vlapic.h
>>>>> +++ b/xen/include/asm-x86/hvm/vlapic.h
>>>>> @@ -53,6 +53,9 @@
>>>>>      ((vlapic)->hw.apic_base_msr & MSR_IA32_APICBASE_BASE)
>>>>>  #define vlapic_x2apic_mode(vlapic)                              \
>>>>>      ((vlapic)->hw.apic_base_msr & MSR_IA32_APICBASE_EXTD)
>>>>> +#define vlapic_xapic_mode(vlapic)                               \
>>>>> +    (((vlapic)->hw.apic_base_msr & MSR_IA32_APICBASE_ENABLE) && \
>>>>> +     !vlapic_x2apic_mode(vlapic))
>>>>
>>>>... I think it is imperative that both macros are fully symmetric,
>>>>i.e. the enabled check should either be present in both or (less
>>>>desirable) absent.
>>> 
>>> The reason I think is we have an assumption here that
>>> vlapic->hw.apic_base_msr is in a valid state. so if EXTD=1, we can
>>> conclude vlapic is in x2apic mode. But if only EN=1, we can't conclude
>>> vlapic is in xapic mode.
>>> Or, do you just mean I shouldn't use vlapic_x2apic_mode() here, like
>>> this:
>>> 
>>> #define vlapic_x2apic_mode(vlapic)   \
>>>     (vlapic_enabled(vlapic) && \
>>>      (vlapic->hw.apic_base_msr & MSR_IA32_APICBASE_EXTD))
>>> 
>>> #define vlapic_xapic_mode(vlapic)   \
>>>     (vlapic_enabled(vlapic) && \
>>>      !(vlapic->hw.apic_base_msr & MSR_IA32_APICBASE_EXTD))
>>
>>I can't get the code in line with "I shouldn't use vlapic_x2apic_mode()
>>here", but beyond that the suggested code is indeed what I think
>>we would want (provided of course this isn't going to break any
>>existing users).
> 
> When I am seeking for evidences to persuade you that it will not
> break the existing users, I found that
> 1. In SDM ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
> Extended XAPIC (x2APIC) -> Detecting and Enabling x2APIC Mode, there
> is a table to illustrate which mode the APIC is in. It doesn't mention
> the global enable/disable bit in MSR_IA32_APICBASE or software
> enable/disable bit in spurious vector register.
> 
> 2. In the same chapter Local APIC->Local APIC state->Local APIC state
> after It Has Been Software Disabled, the APIC been software disabled
> responds normally to SIPI message. To match SIPI's destination, we
> use the marco vlapic_x2apic_mode(), it is weird to return false when 
> an APIC with MSI_IA32_APICBASE EN=1 EXTD=1 but been software disabled,
> what's more, it is software disabled by default when enabling x2APIC.
> 
> So I suggest the code like below:
> #define vlapic_x2apic_mode(vlapic) \
>     (((vlapic)->hw.apic_base_msr & MSR_IA32_APICBASE_ENABLE) && \
>      ((vlapic)->hw.apic_base_msr & MSR_IA32_APICBASE_EXTD))
> 
> #define vlapic_xapic_mode(vlapic) \
>     (((vlapic)->hw.apic_base_msr & MSR_IA32_APICBASE_ENABLE) && \
>      !((vlapic)->hw.apic_base_msr & MSR_IA32_APICBASE_EXTD))

I still don't like them not using the enabled/disabled helpers we
already have. If vlapic_{en,dis}abled() aren't correct to use
here, use vlapic_{hw,sw}_disabled(). Or alternatively we should
change or get rid of some or all of those.

> They are also symmetric. This change definitely won't break any user
> for the EN=0 and EXTD=1 is an invalid state.

Now that's a good reason to leave vlapic_x2apic_mode() alone
(but add a comment to that effect) - I did simply forget about
this aspect.

Jan

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.