On Tue, Jan 21, 2025 at 10:39 PM Michael Kelley <mhklinux@xxxxxxxxxxx> wrote: > From: Jann Horn <jannh@xxxxxxxxxx> Sent: Tuesday, January 21, 2025 9:22 AM > > > > On Thu, Jan 16, 2025 at 7:14 PM Michael Kelley <mhklinux@xxxxxxxxxxx> wrote: > > > We had an earlier thread about INVLPGB/TLBSYNC in a VM [1]. It > > > turns out that Hyper-V in the Azure public cloud enables > > > INVLPGB/TLBSYNC in Confidential VMs (CVMs, which conform to the > > > Linux concept of a CoCo VM) running on AMD processors using SEV-SNP. > > > The CPUID instruction in a such a VM reports the enablement as > > > expected. The instructions are *not* enabled in general purpose VMs > > > running on the same AMD processors. The enablement is a natural > > > outgrowth of CoCo VM's wanting to be able to avoid a dependency on > > > the untrusted hypervisor to perform TLB flushes. > > > > What is this current dependency on the untrusted hypervisor? Is it > > just the PV TLB flushing optimization for preempted vCPUs? > > On Hyper-V, the PV TLB flushing is a performance optimization to avoid > the overhead of the IPIs, and the overhead of trapping the TLB flush > instructions to the hypervisor. Both are expensive in a guest, and making Is the hypervisor even able to trap TLB flushing instructions for a CoCo VM? Looking at vc_handle_exitcode(), I don't see any support for handling #VC caused by TLB invalidation; and my understanding is that the measured guest code would need to include such handling to allow the hypervisor to emulate an instruction? But I don't know how this stuff works particularly well, I might well be totally wrong about this.
