Re: [RFC PATCH v2 00/21] QEMU gmem implemention

[David Hildenbrand]

> > > This version still leave some opens to be discussed:
> > > 1. whether we need "private" propery to be user-settable?
> > >
> > >      It seems unnecessary because vm-type is determined. If the VM is
> > >      confidential-guest, then the RAM of the guest must be able to be
> > >      mapped as private, i.e., have kvm gmem backend. So QEMU can
> > >      determine the value of "private" property automatiacally based on vm
> > >      type.
> > >
> > >      This also aligns with the board internal MemoryRegion that needs to
> > >      have kvm gmem backend, e.g., TDX requires OVMF to act as private
> > >      memory so bios memory region needs to have kvm gmem fd associated.
> > >      QEMU no doubt will do it internally automatically.
> >
> > Would it make sense to have some regions without "pivate" semantics?
> > Like NVDIMMs?
>
> Of course it can have regions without "private" semantics.

I meant "RAM memory regions on such a special VM". Does it make sense to 
have !private there? I assume "for now, not".

> > > 2. hugepage support.
> > >
> > >      KVM gmem can be allocated from hugetlbfs. How does QEMU determine
> > >      when to allocate KVM gmem with KVM_GUEST_MEMFD_ALLOW_HUGEPAGE. The
> > >      easiest solution is create KVM gmem with
> > > KVM_GUEST_MEMFD_ALLOW_HUGEPAGE
> > >      only when memory backend is HostMemoryBackendFile of hugetlbfs.
> >
> > Good question.
> >
> > Probably "if the memory backend uses huge pages, also use huge pages for
> > the private gmem" makes sense.
> >
> > ... but it becomes a mess with preallocation ... which is what people
> > should actually be using with hugetlb. Andeventual double
> > memory-consumption ... but maybe that's all been taken care of already?
> >
> > Probably it's best to leave hugetlb support as future work and start
> > with something minimal.
>
> As Sean replied, I had some misunderstanding of
> KVM_GUEST_MEMFD_ALLOW_HUGEPAGE. If it's for THP, I think we can allow it
> for every gmem.

Right, just like we do a MADV_HUGEPAGE rather blindly on all memory.

--
Cheers,

David / dhildenb