Re: [RFC PATCH v2 02/21] RAMBlock: Add support of KVM private gmem

[Xiaoyao Li]

On 9/22/2023 3:08 PM, David Hildenbrand wrote:
> On 22.09.23 02:22, Xiaoyao Li wrote:
> > On 9/21/2023 4:55 PM, David Hildenbrand wrote:
> > > On 14.09.23 05:50, Xiaoyao Li wrote:
> > > > From: Chao Peng <chao.p.peng@linux.intel.com>
> > > >
> > > > Add KVM gmem support to RAMBlock so both normal hva based memory
> > > > and kvm gmem fd based private memory can be associated in one RAMBlock.
> > > >
> > > > Introduce new flag RAM_KVM_GMEM. It calls KVM ioctl to create private
> > > > gmem for the RAMBlock when it's set.
> > >
> > >
> > > But who sets RAM_KVM_GMEM and when?
> >
> > The answer is in the next patch. When `private` property of memory
> > backend is set to true, it will pass RAM_KVM_GMEM flag to
> > memory_region_init_ram_*()
>
> Okay, assuming that patch (and property) will go away, I assume this 
> flag can also go away, right?

If dropping the flag RAM_KVM_GMEM, it seems we need go back to the 
approach of rfc v1[1][2], that allocating gmem inside .region_add() 
callback. Is it accepted by you?

Another option is allocating gmem inside ram_block_add() by checking the 
vm_type (it looks hacky for me). What's your opinion on this option?

One more option is, we keep the RAM_KVM_GMEM as this patch, and change 
"private" property of memory backend into "need_kvm_gmem" field (make it 
not user settable) and "need_kvm_gmem" field will be set to true in 
tdx_kvm_init() specific cgs initialization function.


[1] 
https://lore.kernel.org/qemu-devel/a154c33d-b24d-b713-0dc0-027d54f2340f@redhat.com/
[2] 
https://lore.kernel.org/qemu-devel/20230731162201.271114-10-xiaoyao.li@intel.com/