From: Sean Christopherson <seanjc@google.com>
To: isaku.yamahata@intel.com
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
isaku.yamahata@gmail.com, Michael Roth <michael.roth@amd.com>,
Paolo Bonzini <pbonzini@redhat.com>,
linux-coco@lists.linux.dev,
Chao Peng <chao.p.peng@linux.intel.com>
Subject: Re: [PATCH] KVM: guest_memfd: Refactor kvm_gmem into inode->i_private
Date: Tue, 26 Sep 2023 12:31:09 -0700 [thread overview]
Message-ID: <ZRMxfTd65Ijn3RAj@google.com> (raw)
In-Reply-To: <8e57c347d6c461431e84ef4354dc076f363f3c01.1695751312.git.isaku.yamahata@intel.com>
On Tue, Sep 26, 2023, isaku.yamahata@intel.com wrote:
> From: Isaku Yamahata <isaku.yamahata@intel.com>
>
> Refactor guest_memfd to use inode->i_private to store info about kvm_gmem.
Why!?!?!? Sadly, I don't have telepathic superpowers. This changelog only
explains *what* the code is doing, what I need to know is *why* you want to make
this change.
The below kinda sorta suggests that this is to simplify the code, but it's not
at all obvious that that's the actual motivation, or the only motiviation.
> Currently it is stored in the following way.
> - flags in inode->i_private
> - struct kvm_gmem in file->private_data
> - struct kvm_gmem in linked linst in inode->i_mapping->private_list
> And this list has single entry.
>
> The relationship between struct file, struct inode and struct kvm_gmem is
> 1:1, not 1:many.
No, it's not. Or at least it won't be in the future. As I explained before[1]:
: The code is structured to allow for multiple gmem instances per inode. This isn't
: actually possible in the initial code base, but it's on the horizon[*]. I included
: the list-based infrastructure in this initial series to ensure that guest_memfd
: can actually support multiple files per inode, and to minimize the churn when the
: "link" support comes along.
: [*] https://lore.kernel.org/all/cover.1691446946.git.ackerleytng@google.com
[1] https://lore.kernel.org/all/ZQsAiGuw%2F38jIOV7@google.com
prev parent reply other threads:[~2023-09-26 19:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-26 18:03 [PATCH] KVM: guest_memfd: Refactor kvm_gmem into inode->i_private isaku.yamahata
2023-09-26 19:31 ` Sean Christopherson [this message]
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=ZRMxfTd65Ijn3RAj@google.com \
--to=seanjc@google.com \
--cc=chao.p.peng@linux.intel.com \
--cc=isaku.yamahata@gmail.com \
--cc=isaku.yamahata@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.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).