On Fri, Dec 01, 2023, Mingwei Zhang wrote: > On Fri, Dec 1, 2023 at 2:13 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > On Fri, Dec 01, 2023, Mingwei Zhang wrote: > > > On Fri, Dec 1, 2023 at 1:30 PM Kalra, Ashish <ashish.kalra@xxxxxxx> wrote: > > > > For SNP + gmem, where the HVA ranges covered by the MMU notifiers are > > > > not acting on encrypted pages, we are ignoring MMU invalidation > > > > notifiers for SNP guests as part of the SNP host patches being posted > > > > upstream and instead relying on gmem own invalidation stuff to clean > > > > them up on a per-folio basis. > > > > > > > > Thanks, > > > > Ashish > > > > > > oh, I have no question about that. This series only applies to > > > SEV/SEV-ES type of VMs. > > > > > > For SNP + guest_memfd, I don't see the implementation details, but I > > > doubt you can ignore mmu_notifiers if the request does cover some > > > encrypted memory in error cases or corner cases. Does the SNP enforce > > > the usage of guest_memfd? How do we prevent exceptional cases? I am > > > sure you guys already figured out the answers, so I don't plan to dig > > > deeper until SNP host pages are accepted. > > > > KVM will not allow SNP guests to map VMA-based memory as encrypted/private, full > > stop. Any invalidations initiated by mmu_notifiers will therefore apply only to > > shared memory. > > Remind me. If I (as a SEV-SNP guest) flip the C-bit in my own x86 page > table and write to some of the pages, am I generating encrypted dirty > cache lines? No. See Table 15-39. "RMP Memory Access Checks" in the APM (my attempts to copy it to plain test failed miserably). For accesses with effective C-bit == 0, the page must be Hypervisor-Owned. For effective C-bit == 1, the page must be fully assigned to the guest. Violation of those rules generates #VMEXIT. A missing Validated attribute causes a #VC, but that case has lower priority than the about checks.
