On Mon, 2024-07-15 at 16:47 -0500, Michael Roth wrote: > Makes sense. > > If we document mutual exclusion between ranges touched by > gmem_populate() vs ranges touched by actual userspace issuance of > KVM_PRE_FAULT_MEMORY (and make sure nothing too crazy happens if users > don't abide by the documentation), then I think most problems go away... > > But there is still at least one awkward constraint for SNP: > KVM_PRE_FAULT_MEMORY cannot be called for private GPA ranges until after > SNP_LAUNCH_START is called. This is true even if the GPA range is not > one of the ranges that will get passed to > gmem_populate()/SNP_LAUNCH_UPDATE. The reason for this is that when > binding the ASID to the SNP context as part of SNP_LAUNCH_START, firmware > will perform checks to make sure that ASID is not already being used in > the RMP table, and that check will fail if KVM_PRE_FAULT_MEMORY triggered > for a private page before calling SNP_LAUNCH_START. > > So we have this constraint that KVM_PRE_FAULT_MEMORY can't be issued > before SNP_LAUNCH_START. So it makes me wonder if we should just broaden > that constraint and for now just disallow KVM_PRE_FAULT_MEMORY prior to > finalizing a guest, since it'll be easier to lift that restriction later > versus discovering some other sort of edge case and need to > retroactively place restrictions. > > I've taken Isaku's original pre_fault_memory_test and added a new > x86-specific coco_pre_fault_memory_test to try to better document and > exercise these corner cases for SEV and SNP, but I'm hoping it could > also be useful for TDX (hence the generic name). These are based on > Pratik's initial SNP selftests (which are in turn based on kvm/queue + > these patches): > > https://github.com/mdroth/linux/commits/snp-uptodate0-kst/ > > https://github.com/mdroth/linux/commit/dd7d4b1983ceeb653132cfd54ad63f597db85f74 > >
