Message ID | 20240417153450.3608097-1-pbonzini@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | KVM: Guest Memory Pre-Population API | expand |
On Wed, 2024-04-17 at 11:34 -0400, Paolo Bonzini wrote: > > Compared to Isaku's v2, I have reduced the scope as much as possible: > > - no vendor-specific hooks The TDX patches build on this, with the vendor callback looking like: " int tdx_pre_mmu_map_page(struct kvm_vcpu *vcpu, struct kvm_map_memory *mapping, u64 *error_code) { struct kvm_tdx *kvm_tdx = to_kvm_tdx(vcpu->kvm); struct kvm *kvm = vcpu->kvm; if (!to_tdx(vcpu)->initialized) return -EINVAL; /* Shared-EPT case */ if (!(kvm_is_private_gpa(kvm, mapping->base_address))) return 0; /* Once TD is finalized, the initial guest memory is fixed. */ if (is_td_finalized(kvm_tdx)) return -EINVAL; *error_code = TDX_SEPT_PFERR; return 0; } " kvm_is_private_gpa() check is already handled in this series. The initialized and finalized checks are nice guard rails for userspace, but shouldn't be strictly required. The TDX_SEPT_PFERR is (PFERR_WRITE_MASK | PFERR_PRIVATE_ACCESS). The PFERR_WRITE_MASK doesn't seem to be required. Isaku, what was the intention? But, I think maybe we should add a hook back in the TDX series for the guard rails.
Il 18 aprile 2024 02:01:03 CEST, "Edgecombe, Rick P" <rick.p.edgecombe@intel.com> ha scritto: >On Wed, 2024-04-17 at 11:34 -0400, Paolo Bonzini wrote: >> >> Compared to Isaku's v2, I have reduced the scope as much as possible: >> >> - no vendor-specific hooks > >The TDX patches build on this, with the vendor callback looking like: > >" >int tdx_pre_mmu_map_page(struct kvm_vcpu *vcpu, > struct kvm_map_memory *mapping, > u64 *error_code) >{ > struct kvm_tdx *kvm_tdx = to_kvm_tdx(vcpu->kvm); > struct kvm *kvm = vcpu->kvm; > > if (!to_tdx(vcpu)->initialized) > return -EINVAL; > > /* Shared-EPT case */ > if (!(kvm_is_private_gpa(kvm, mapping->base_address))) > return 0; > > /* Once TD is finalized, the initial guest memory is fixed. */ > if (is_td_finalized(kvm_tdx)) > return -EINVAL; This is wrong, KVM_MAP_MEMORY should be idempotent. But anyway, you can post what you have on to of kvm-coco-queue (i.e., adding the hook in your patches) and we will sort it out a piece at a time. Paolo > > *error_code = TDX_SEPT_PFERR; > return 0; >} >" > >kvm_is_private_gpa() check is already handled in this series. > >The initialized and finalized checks are nice guard rails for userspace, but >shouldn't be strictly required. > >The TDX_SEPT_PFERR is (PFERR_WRITE_MASK | PFERR_PRIVATE_ACCESS). The >PFERR_WRITE_MASK doesn't seem to be required. Isaku, what was the intention? > >But, I think maybe we should add a hook back in the TDX series for the guard >rails. Paolo
On Thu, 2024-04-18 at 02:31 +0200, Paolo Bonzini wrote: > > The TDX patches build on this, with the vendor callback looking like: > > > > " > > int tdx_pre_mmu_map_page(struct kvm_vcpu *vcpu, > > struct kvm_map_memory *mapping, > > u64 *error_code) > > { > > struct kvm_tdx *kvm_tdx = to_kvm_tdx(vcpu->kvm); > > struct kvm *kvm = vcpu->kvm; > > > > if (!to_tdx(vcpu)->initialized) > > return -EINVAL; > > > > /* Shared-EPT case */ > > if (!(kvm_is_private_gpa(kvm, mapping->base_address))) > > return 0; > > > > /* Once TD is finalized, the initial guest memory is fixed. */ > > if (is_td_finalized(kvm_tdx)) > > return -EINVAL; > > This is wrong, KVM_MAP_MEMORY should be idempotent. But anyway, you can post > what you have on to of kvm-coco-queue (i.e., adding the hook in your patches) > and we will sort it out a piece at a time. Hmm, I see your point.