On Thu, Sep 15, 2022 at 10:29:07PM +0800, Chao Peng wrote:
> This new extension, indicated by the new flag KVM_MEM_PRIVATE, adds two
> additional KVM memslot fields private_fd/private_offset to allow
> userspace to specify that guest private memory provided from the
> private_fd and guest_phys_addr mapped at the private_offset of the
> private_fd, spanning a range of memory_size.
>
> The extended memslot can still have the userspace_addr(hva). When use, a
> single memslot can maintain both private memory through private
> fd(private_fd/private_offset) and shared memory through
> hva(userspace_addr). Whether the private or shared part is visible to
> guest is maintained by other KVM code.
What is anyway the appeal of private_offset field, instead of having just
1:1 association between regions and files, i.e. one memfd per region?
If this was the case, then an extended struct would not be needed in the
first place. A simple union inside the existing struct would do:
union {
__u64 userspace_addr,
__u64 private_fd,
};
BR, Jarkko
