[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e374e93586ff7aa4caecf856031309f5beb63b00.camel@intel.com>
Date: Thu, 18 Apr 2024 00:33:32 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
<pbonzini@...hat.com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
CC: "Li, Xiaoyao" <xiaoyao.li@...el.com>, "seanjc@...gle.com"
<seanjc@...gle.com>, "binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>,
"Yamahata, Isaku" <isaku.yamahata@...el.com>
Subject: Re: [PATCH v3 0/7] KVM: Guest Memory Pre-Population API
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.
Powered by blists - more mailing lists