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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux