On Fri, 2025-02-14 at 08:47 +0800, Binbin Wu wrote: > > On 2/14/2025 5:41 AM, Edgecombe, Rick P wrote: > > On Wed, 2025-02-12 at 10:39 +0800, Binbin Wu wrote: > > > > IIRC, a TD-exit may occur due to an EPT MISCONFIG. Do you need to > > > > distinguish > > > > between a genuine EPT MISCONFIG and a morphed one, and handle them > > > > differently? > > > It will be handled separately, which will be in the last section of the KVM > > > basic support. But the v2 of "the rest" section is on hold because there is > > > a discussion related to MTRR MSR handling: > > > https://lore.kernel.org/all/20250201005048.657470-1-seanjc@xxxxxxxxxx/ > > > Want to send the v2 of "the rest" section after the MTRR discussion is > > > finalized. > > I think we can just put back the original MTRR code (post KVM MTRR removal > > version) for the next posting of the rest. The reason being Sean was pointing > > that it is more architecturally correct given that the CPUID bit is exposed. So > > we will need that regardless of the guest solution. > The original MTRR code before removing is: > https://lore.kernel.org/kvm/81119d66392bc9446340a16f8a532c7e1b2665a2.1708933498.git.isaku.yamahata@xxxxxxxxx/ > > It enforces WB as default memtype and disables fixed/variable range MTRRs. > That means this solution doesn't allow guest to use MTRRs as a communication > channel if the guest firmware wants to program some ranges to UC for legacy > devices. I'm talking about the internal version that existed after KVM removed MTRRs for normal VMs. We are not talking about adding back KVM MTRRs. > > > How about to allow TDX guests to access MTRR MSRs as what KVM does for > normal VMs? > > Guest kernels may use MTRRs as a crutch to get the desired memtype for devices. > E.g., in most KVM-based setups, legacy devices such as the HPET and TPM are > enumerated via ACPI. And in Linux kernel, for unknown reasons, ACPI auto-maps > such devices as WB, whereas the dedicated device drivers map memory as WC or > UC. The ACPI mappings rely on firmware to configure PCI hole (and other device > memory) to be UC in the MTRRs to end up UC-, which is compatible with the > drivers' requested WC/UC-. > > So KVM needs to allow guests to program the desired value in MTRRs in case > guests want to use MTRRs as a communication channel between guest firmware > and the kernel. > > Allow TDX guests to access MTRR MSRs as what KVM does for normal VMs, i.e., > KVM emulates accesses to MTRR MSRs, but doesn't virtualize guest MTRR memory > types. One open is whether enforce the value of default MTRR memtype as WB. This is basically what we had previously (internally), right? > > However, TDX disallows toggling CR0.CD. If a TDX guest wants to use MTRRs > as the communication channel, it should skip toggling CR0.CD when it > programs MTRRs both in guest firmware and guest kernel. For a guest, there > is no reason to disable caches because it's in a virtual environment. It > makes sense for guest firmware/kernel to skip toggling CR0.CD when it > detects it's running as a TDX guest. I don't see why we have to tie exposing MTRR to a particular solution for the guest and bios. Let's focus on the work we know we need regardless for KVM.
