linux-kernel - Re: [PATCH v4 07/12] KVM: VMX: drop IPAT in memtype when CD=1 for KVM_X86_QUIRK_CD_NW

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZOkgka+DX4KNm5Mp@google.com>
Date:   Fri, 25 Aug 2023 14:43:45 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Yan Zhao <yan.y.zhao@...el.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        pbonzini@...hat.com, chao.gao@...el.com, kai.huang@...el.com,
        robert.hoo.linux@...il.com, yuan.yao@...ux.intel.com
Subject: Re: [PATCH v4 07/12] KVM: VMX: drop IPAT in memtype when CD=1 for KVM_X86_QUIRK_CD_NW_CLEARED

On Fri, Jul 14, 2023, Yan Zhao wrote:
> For KVM_X86_QUIRK_CD_NW_CLEARED is on, remove the IPAT (ignore PAT) bit in
> EPT memory types when cache is disabled and non-coherent DMA are present.
> 
> To correctly emulate CR0.CD=1, UC + IPAT are required as memtype in EPT.
> However, as with commit
> fb279950ba02 ("KVM: vmx: obey KVM_QUIRK_CD_NW_CLEARED"), WB + IPAT are
> now returned to workaround a BIOS issue that guest MTRRs are enabled too
> late. Without this workaround, a super slow guest boot-up is expected
> during the pre-guest-MTRR-enabled period due to UC as the effective memory
> type for all guest memory.
> 
> Absent emulating CR0.CD=1 with UC, it makes no sense to set IPAT when KVM
> is honoring the guest memtype.
> Removing the IPAT bit in this patch allows effective memory type to honor
> PAT values as well, as WB is the weakest memtype. It means if a guest
> explicitly claims UC as the memtype in PAT, the effective memory is UC
> instead of previous WB. If, for some unknown reason, a guest meets a slow
> boot-up issue with the removal of IPAT, it's desired to fix the blamed PAT
> in the guest.
> 
> Besides, this patch is also a preparation patch for later fine-grained gfn
> zap when guest MTRRs are honored, because it allows zapping only non-WB
> ranges when CR0.CD toggles.
> 
> BTW, returning guest MTRR type as if CR0.CD=0 is also not preferred because
> it still has to hardcode the MTRR type to WB during the

Please use full names instead of prononous, I found the "it still has to hardcode"
part really hard to grok.  I think this is what you're saying?

  BTW, returning guest MTRR type as if CR0.CD=0 is also not preferred because
  KVMs ABI for the quirk also requires KVM to force WB memtype regardless of
  guest MTRRs to workaround the slow guest boot-up issue.

> pre-guest-MTRR-enabled period to workaround the slow guest boot-up issue
> (guest MTRR type when guest MTRRs are disabled is UC).
> In addition, it will make the quirk unnecessarily complexer .