On Wed, May 15, 2024, Rick P Edgecombe wrote: > On Wed, 2024-05-15 at 08:49 -0700, Rick Edgecombe wrote: > > On Wed, 2024-05-15 at 08:34 -0700, Sean Christopherson wrote: > > > On Tue, May 14, 2024, Rick Edgecombe wrote: > > > > When virtualizing some CPU features, KVM uses kvm_zap_gfn_range() to zap > > > > guest mappings so they can be faulted in with different PTE properties. > > > > > > > > For TDX private memory this technique is fundamentally not possible. > > > > Remapping private memory requires the guest to "accept" it, and also the > > > > needed PTE properties are not currently supported by TDX for private > > > > memory. > > > > > > > > These CPU features are: > > > > 1) MTRR update > > > > 2) CR0.CD update > > > > 3) Non-coherent DMA status update > > > > > > Please go review the series that removes these disaster[*], I suspect it > > > would > > > literally have taken less time than writing this changelog :-) > > > > > > [*] https://lore.kernel.org/all/20240309010929.1403984-1-seanjc@xxxxxxxxxx > > > > We have one additional detail for TDX in that KVM will have different cache > > attributes between private and shared. Although implementation is in a later > > patch, that detail has an affect on whether we need to support zapping in the > > basic MMU support. > > Or most specifically, we only need this zapping if we *try* to have consistent > cache attributes between private and shared. In the non-coherent DMA case we > can't have them be consistent because TDX doesn't support changing the private > memory in this way. Huh? That makes no sense. A physical page can't be simultaneously mapped SHARED and PRIVATE, so there can't be meaningful cache attribute aliasing between private and shared EPT entries. Trying to provide consistency for the GPA is like worrying about having matching PAT entires for the virtual address in two different processes.
