[lkml]   [2016]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2/2] KVM: nVMX: postpone VMCS changes on MSR_IA32_APICBASE write
    2016-08-12 19:39 GMT+08:00 Radim Krčmář <>:
    > 2016-08-12 18:14+0800, Wanpeng Li:
    >> 2016-08-12 17:44 GMT+08:00 Radim Krčmář <>:
    >>> 2016-08-12 14:07+0800, Wanpeng Li:
    >>>> 2016-08-09 2:16 GMT+08:00 Radim Krčmář <>:
    >>>>> If vmcs12 does not intercept APIC_BASE writes, then KVM will handle the
    >>>>> write with vmcs02 as the current VMCS.
    >>>>> This will incorrectly apply modifications intended for vmcs01 to vmcs02
    >>>>> and L2 can use it to gain access to L0's x2APIC registers by disabling
    >>>>> virtualized x2APIC while using msr bitmap that assumes enabled.
    >>>>> Postpone execution of vmx_set_virtual_x2apic_mode until vmcs01 is the
    >>>>> current VMCS. An alternative solution would temporarily make vmcs01 the
    >>>>> current VMCS, but it requires more care.
    >>>> There is a scenario both L1 and L2 are running on x2apic mode, L1
    >>>> don't own the APIC_BASE writes, then L2 is intended to disable x2apic
    >>>> mode, however, your logic will also disable x2apic mode for L1.
    >>> You mean a case where L1 does intercept APIC_BASE?
    >>> That case is not affected, because it should cause a nested VM exit, so
    >>> vmx_set_virtual_x2apic_mode() won't be called in the first place.
    >> I mean L1 doesn't intercept APIC_BASE.
    > Then L2's write to APIC_BASE should only affect L1.
    > L2 is buggy if it intended to disable its x2APIC with the write
    > or L1 set up intercepts incorrectly for the indented L2.

    Do you mean OS disable x2APIC during its running is buggy?

    > In the non-nested case, if we didn't intercept APIC_BASE in KVM, then
    > the guest wouldn't change either; only the host would change, so I
    > think it is correct to disable x2APIC mode in L1 only.

    Agreed. :)

    Wanpeng Li

     \ /
      Last update: 2016-09-17 09:56    [W:5.689 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site