On Wed, May 15, 2024, Rick P Edgecombe wrote: > On Wed, 2024-05-15 at 11:09 -0700, Sean Christopherson wrote: > > On Wed, May 15, 2024, Rick P Edgecombe wrote: > > > On Wed, 2024-05-15 at 09:02 -0700, Sean Christopherson wrote: > > > > > 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. > > > > > > No, not matching between the private and shared mappings of the same page. > > > The > > > whole private memory will be WB, and the whole shared half will honor PAT. > > > > I'm still failing to see why that's at all interesting. The non-coherent DMA > > trainwreck is all about KVM worrying about the guest and host having different > > memtypes for the same physical page. > > Ok. The split seemed a little odd and special. I'm not sure it's the most > interesting thing in the world, but there was some debate internally about it. > > > > > If the host is accessing TDX private memory, we have far, far bigger problems > > than aliased memtypes. > > This wasn't the concern. > > > And so the fact that TDX private memory is forced WB is > > interesting only to the guest, not KVM. > > It's just another little quirk in an already complicated solution. They third > thing we discussed was somehow rejecting or not supporting non-coherent DMA. > This seemed simpler than that. Again, huh? This has _nothing_ to do with non-coherent DMA. Devices can't DMA into TDX private memory.
