On Mon, Nov 6, 2023 at 4:04 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Mon, Nov 06, 2023, Fuad Tabba wrote: > > On Sun, Nov 5, 2023 at 4:34 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > > > > > From: Sean Christopherson <seanjc@xxxxxxxxxx> > > > > > > Add a "vm_shape" structure to encapsulate the selftests-defined "mode", > > > along with the KVM-defined "type" for use when creating a new VM. "mode" > > > tracks physical and virtual address properties, as well as the preferred > > > backing memory type, while "type" corresponds to the VM type. > > > > > > Taking the VM type will allow adding tests for KVM_CREATE_GUEST_MEMFD, > > > a.k.a. guest private memory, without needing an entirely separate set of > > > helpers. Guest private memory is effectively usable only by confidential > > > VM types, and it's expected that x86 will double down and require unique > > > VM types for TDX and SNP guests. > > > > > > Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx> > > > Message-Id: <20231027182217.3615211-30-seanjc@xxxxxxxxxx> > > > Signed-off-by: Paolo Bonzini <pbonzini@xxxxxxxxxx> > > > --- > > > > nit: as in a prior selftest commit messages, references in the commit > > message to guest _private_ memory. Should these be changed to just > > guest memory? > > Hmm, no, "private" is mostly appropriate here. At this point in time, only x86 > supports KVM_CREATE_GUEST_MEMFD, and x86 only supports it for private memory. > And the purpose of letting x86 selftests specify KVM_X86_SW_PROTECTED_VM, i.e. > the reason this patch exists, is purely to get private memory. > > Maybe tweak the second paragraph to this? > > Taking the VM type will allow adding tests for KVM_CREATE_GUEST_MEMFD > without needing an entirely separate set of helpers. At this time, > guest_memfd is effectively usable only by confidential VM types in the > form of guest private memory, and it's expected that x86 will double down > and require unique VM types for TDX and SNP guests. sgtm /fuad
