From: Sean Christopherson <seanjc@google.com>
To: Ackerley Tng <ackerleytng@google.com>
Cc: pbonzini@redhat.com, tglx@linutronix.de, x86@kernel.org,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, hpa@zytor.com, shuah@kernel.org,
andrew.jones@linux.dev, ricarkol@google.com,
chao.p.peng@linux.intel.com, tabba@google.com, jarkko@kernel.org,
yu.c.zhang@linux.intel.com, vannapurve@google.com,
erdemaktas@google.com, mail@maciej.szmigiero.name,
vbabka@suse.cz, david@redhat.com, qperret@google.com,
michael.roth@amd.com, wei.w.wang@intel.com,
liam.merwick@oracle.com, isaku.yamahata@gmail.com,
kirill.shutemov@linux.intel.com
Subject: Re: [RFC PATCH 02/11] KVM: guest_mem: Add ioctl KVM_LINK_GUEST_MEMFD
Date: Fri, 18 Aug 2023 16:20:52 -0700 [thread overview]
Message-ID: <ZN/81KNAWofRCaQK@google.com> (raw)
In-Reply-To: <053b45023744f62bd97cd4f87f048ab514f42b9d.1691446946.git.ackerleytng@google.com>
On Mon, Aug 07, 2023, Ackerley Tng wrote:
> KVM_LINK_GUEST_MEMFD will link a gmem fd's underlying inode to a new
> file (and fd).
>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> ---
> include/uapi/linux/kvm.h | 8 +++++
> virt/kvm/guest_mem.c | 73 ++++++++++++++++++++++++++++++++++++++++
> virt/kvm/kvm_main.c | 10 ++++++
> virt/kvm/kvm_mm.h | 7 ++++
> 4 files changed, 98 insertions(+)
>
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index eb900344a054..d0e2a2ce0df2 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -2299,4 +2299,12 @@ struct kvm_create_guest_memfd {
> __u64 reserved[6];
> };
>
> +#define KVM_LINK_GUEST_MEMFD _IOWR(KVMIO, 0xd5, struct kvm_link_guest_memfd)
> +
> +struct kvm_link_guest_memfd {
> + __u64 fd;
> + __u64 flags;
> + __u64 reserved[6];
> +};
> +
> #endif /* __LINUX_KVM_H */
> diff --git a/virt/kvm/guest_mem.c b/virt/kvm/guest_mem.c
> index 30d0ab8745ee..1b3df273f785 100644
> --- a/virt/kvm/guest_mem.c
> +++ b/virt/kvm/guest_mem.c
> @@ -477,6 +477,79 @@ int kvm_gmem_create(struct kvm *kvm, struct kvm_create_guest_memfd *args)
> return __kvm_gmem_create(kvm, size, flags, kvm_gmem_mnt);
> }
>
> +static inline void __kvm_gmem_do_link(struct inode *inode)
> +{
> + /* Refer to simple_link() */
> +
> + inode->i_ctime = current_time(inode);
> + inc_nlink(inode);
> +
> + /*
> + * ihold() to add additional reference to inode for reference in dentry,
> + * created in kvm_gmem_alloc_file() -> alloc_file_pseudo(). This is not
> + * necessary when creating a new file because alloc_inode() creates
> + * inodes with i_count = 1, which is the refcount for the dentry in the
> + * file.
> + */
> + ihold(inode);
> +
> + /*
> + * dget() and d_instantiate() complete the setup of a dentry, but those
> + * have already been done in kvm_gmem_alloc_file() ->
> + * alloc_file_pseudo()
> + */
> +}
Does this have to be done before the fd is exposed to userspace, or can it be
done after? If it can be done after, I'd prefer to have the allocation helper
also install the fd, and also rename it to something that better conveys that
it's allocating more than just the file, e.g. that it allocates and initialize
kvm_gmem too.
Completely untested, but this is what I'm thinkin/hoping.
static int kvm_gmem_alloc_view(struct kvm *kvm, struct inode *inode,
struct vfsmount *mnt)
{
struct file *file;
struct kvm_gmem *gmem;
gmem = kzalloc(sizeof(*gmem), GFP_KERNEL);
if (!gmem)
return -ENOMEM;
fd = get_unused_fd_flags(0);
if (fd < 0) {
r = fd;
goto err_fd;
}
file = alloc_file_pseudo(inode, mnt, "kvm-gmem", O_RDWR, &kvm_gmem_fops);
if (IS_ERR(file)) {
r = PTR_ERR(file);
goto err_file;
}
file->f_flags |= O_LARGEFILE;
file->f_mapping = inode->i_mapping;
kvm_get_kvm(kvm);
gmem->kvm = kvm;
xa_init(&gmem->bindings);
file->private_data = gmem;
list_add(&gmem->entry, &inode->i_mapping->private_list);
fd_install(fd, file);
return 0;
err:
put_unused_fd(fd);
err_fd:
kfree(gmem);
return r;
}
static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags,
struct vfsmount *mnt)
{
const char *anon_name = "[kvm-gmem]";
const struct qstr qname = QSTR_INIT(anon_name, strlen(anon_name));
struct inode *inode;
struct file *file;
int fd, err;
inode = alloc_anon_inode(mnt->mnt_sb);
if (IS_ERR(inode))
return PTR_ERR(inode);
err = security_inode_init_security_anon(inode, &qname, NULL);
if (err)
goto err;
inode->i_private = (void *)(unsigned long)flags;
inode->i_op = &kvm_gmem_iops;
inode->i_mapping->a_ops = &kvm_gmem_aops;
inode->i_mode |= S_IFREG;
inode->i_size = size;
mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER);
mapping_set_large_folios(inode->i_mapping);
mapping_set_unevictable(inode->i_mapping);
mapping_set_unmovable(inode->i_mapping);
fd = kvm_gmem_alloc_view(kvm, inode, mnt);
if (fd < 0) {
err = fd;
goto err;
}
return fd;
err:
iput(inode);
return err;
}
next prev parent reply other threads:[~2023-08-18 23:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-07 23:01 [RFC PATCH 00/11] New KVM ioctl to link a gmem inode to a new gmem file Ackerley Tng
2023-08-07 23:01 ` [RFC PATCH 01/11] KVM: guest_mem: Refactor out kvm_gmem_alloc_file() Ackerley Tng
2023-08-07 23:01 ` [RFC PATCH 02/11] KVM: guest_mem: Add ioctl KVM_LINK_GUEST_MEMFD Ackerley Tng
2023-08-18 23:20 ` Sean Christopherson [this message]
2025-05-06 16:05 ` Ackerley Tng
2023-08-07 23:01 ` [RFC PATCH 03/11] KVM: selftests: Add tests for KVM_LINK_GUEST_MEMFD ioctl Ackerley Tng
2023-08-07 23:01 ` [RFC PATCH 04/11] KVM: selftests: Test transferring private memory to another VM Ackerley Tng
2023-08-07 23:01 ` [RFC PATCH 05/11] KVM: x86: Refactor sev's flag migration_in_progress to kvm struct Ackerley Tng
2023-08-07 23:01 ` [RFC PATCH 06/11] KVM: x86: Refactor common code out of sev.c Ackerley Tng
2023-08-07 23:01 ` [RFC PATCH 07/11] KVM: x86: Refactor common migration preparation code out of sev_vm_move_enc_context_from Ackerley Tng
2023-08-07 23:01 ` [RFC PATCH 08/11] KVM: x86: Let moving encryption context be configurable Ackerley Tng
2023-08-10 14:03 ` Paolo Bonzini
2023-08-17 16:53 ` Ackerley Tng
2023-08-07 23:01 ` [RFC PATCH 09/11] KVM: x86: Handle moving of memory context for intra-host migration Ackerley Tng
2023-08-07 23:01 ` [RFC PATCH 10/11] KVM: selftests: Generalize migration functions from sev_migrate_tests.c Ackerley Tng
2023-08-07 23:01 ` [RFC PATCH 11/11] KVM: selftests: Add tests for migration of private mem Ackerley Tng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZN/81KNAWofRCaQK@google.com \
--to=seanjc@google.com \
--cc=ackerleytng@google.com \
--cc=andrew.jones@linux.dev \
--cc=bp@alien8.de \
--cc=chao.p.peng@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=erdemaktas@google.com \
--cc=hpa@zytor.com \
--cc=isaku.yamahata@gmail.com \
--cc=jarkko@kernel.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=liam.merwick@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mail@maciej.szmigiero.name \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qperret@google.com \
--cc=ricarkol@google.com \
--cc=shuah@kernel.org \
--cc=tabba@google.com \
--cc=tglx@linutronix.de \
--cc=vannapurve@google.com \
--cc=vbabka@suse.cz \
--cc=wei.w.wang@intel.com \
--cc=x86@kernel.org \
--cc=yu.c.zhang@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).