linux-kernel - Re: [PATCH v5] KVM: SVM: Allow AVIC support on system w/ physical APIC ID

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 11 Feb 2022 07:10:30 +0700
From:   "Suthikulpanit, Suravee" <suravee.suthikulpanit@....com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org, x86@...nel.org,
        mlevitsk@...hat.com, pbonzini@...hat.com, joro@...tes.org,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        peterz@...radead.org, hpa@...or.com, jon.grimm@....com,
        wei.huang2@....com, terry.bowman@....com
Subject: Re: [PATCH v5] KVM: SVM: Allow AVIC support on system w/ physical
 APIC ID > 255



On 2/10/2022 12:54 AM, Sean Christopherson wrote:
> E.g.
> 
>    Expand KVM's mask for the AVIC host physical ID to the full 12 bits defined
>    by the architecture.  The number of bits consumed by hardware is model
>    specific, e.g. early CPUs ignored bits 11:8, but there is no way for KVM
>    to enumerate the "true" size.  So, KVM must allow using all bits, else it
>    risks rejecting completely legal x2APIC IDs on newer CPUs.
>   
>    This means KVM relies on hardware to not assign x2APIC IDs that exceed the
>    "true" width of the field, but presmuably hardware is smart enough to tie
>    the width to the max x2APIC ID.  KVM also relies on hardware to support at
>    least 8 bits, as the legacy xAPIC ID is writable by software.  But, those
>    assumptions are unavoidable due to the lack of any way to enumerate the
>    "true" width.
> 
>    Note, older versions of the APM state that bits 11:8 are reserved for
>    legacy xAPIC, but consumed for x2APIC.  Revision 3.38 corrected this to
>    state that bits 11:8 are "should be zero" on older hardware.

This last paragraph is incorrect. The APM revision 3.38 and prior states

Reserved/SBZ for legacy APIC; extension of Host Physical APIC ID when
x2APIC is enabled.

Here, "SBZ" means Should Be Zero.

Therefore, I will remove the last paragraph in V6.

Suravee