Alexey Kardashevskiy wrote: > In order to add a PCI VF into a secure VM, the TSM module needs to > perform a "TDI bind" operation. The secure module ("PSP" for AMD) > reuqires a VM id to associate with a VM and KVM has it. Since > KVM cannot directly bind a TDI (as it does not have all necesessary > data such as host/guest PCI BDFn). QEMU and IOMMUFD do know the BDFns > but they do not have a VM id recognisable by the PSP. > > Add get_vmid() hook to KVM. Implement it for AMD SEV to return a sum > of GCTX (a private page describing secure VM context) and ASID > (required on unbind for IOMMU unfencing, when needed). > > Signed-off-by: Alexey Kardashevskiy <aik@xxxxxxx> > --- > arch/x86/include/asm/kvm-x86-ops.h | 1 + > arch/x86/include/asm/kvm_host.h | 2 ++ > include/linux/kvm_host.h | 2 ++ > arch/x86/kvm/svm/svm.c | 12 ++++++++++++ > virt/kvm/kvm_main.c | 6 ++++++ > 5 files changed, 23 insertions(+) > > diff --git a/arch/x86/include/asm/kvm-x86-ops.h b/arch/x86/include/asm/kvm-x86-ops.h > index c35550581da0..63102a224cd7 100644 > --- a/arch/x86/include/asm/kvm-x86-ops.h > +++ b/arch/x86/include/asm/kvm-x86-ops.h > @@ -144,6 +144,7 @@ KVM_X86_OP_OPTIONAL(alloc_apic_backing_page) > KVM_X86_OP_OPTIONAL_RET0(gmem_prepare) > KVM_X86_OP_OPTIONAL_RET0(private_max_mapping_level) > KVM_X86_OP_OPTIONAL(gmem_invalidate) > +KVM_X86_OP_OPTIONAL(tsm_get_vmid) > > #undef KVM_X86_OP > #undef KVM_X86_OP_OPTIONAL > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h > index b15cde0a9b5c..9330e8d4d29d 100644 > --- a/arch/x86/include/asm/kvm_host.h > +++ b/arch/x86/include/asm/kvm_host.h > @@ -1875,6 +1875,8 @@ struct kvm_x86_ops { > int (*gmem_prepare)(struct kvm *kvm, kvm_pfn_t pfn, gfn_t gfn, int max_order); > void (*gmem_invalidate)(kvm_pfn_t start, kvm_pfn_t end); > int (*private_max_mapping_level)(struct kvm *kvm, kvm_pfn_t pfn); > + > + u64 (*tsm_get_vmid)(struct kvm *kvm); > }; > > struct kvm_x86_nested_ops { > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index f34f4cfaa513..6cd351edb956 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -2571,4 +2571,6 @@ long kvm_arch_vcpu_pre_fault_memory(struct kvm_vcpu *vcpu, > struct kvm_pre_fault_memory *range); > #endif > > +u64 kvm_arch_tsm_get_vmid(struct kvm *kvm); > + > #endif > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index 7640a84e554a..0276d60c61d6 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -4998,6 +4998,16 @@ static void *svm_alloc_apic_backing_page(struct kvm_vcpu *vcpu) > return page_address(page); > } > > +static u64 svm_tsm_get_vmid(struct kvm *kvm) > +{ > + struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; > + > + if (!sev->es_active) > + return 0; > + > + return ((u64) sev->snp_context) | sev->asid; > +} > + Curious why KVM needs to be bothered by a new kvm_arch_tsm_get_vmid() and a vendor specific cookie "vmid" concept. In other words KVM never calls kvm_arch_tsm_get_vmid(), like other kvm_arch_*() support calls. Is this due to a restriction that something like tsm_tdi_bind() is disallowed from doing to_kvm_svm() on an opaque @kvm pointer? Or otherwise asking an arch/x86/kvm/svm/svm.c to do the same? Effectively low level TSM drivers are extensions of arch code that routinely performs "container_of(kvm, struct kvm_$arch, kvm)".