Re: [PATCH v2 8/8] KVM: TDX: Handle TDX PV MMIO hypercall

[Binbin Wu]

On 2/14/2025 9:01 AM, Edgecombe, Rick P wrote:
> 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.
Sorry, I misunderstood it.

> > 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?
Yes. Then we are aligned. :)

> > 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.

Guest could choose to use MTRRs or other SW protocal to communicate the memtype
for devices. I just wanted to point it out that if guest chooses to use MTRRs
as the communicate channel, it will face the #VE issue caused by toggleing
CR0.CD.