Re: [PATCH kvm-next V11 4/7] KVM: guest_memfd: Use guest mem inodes instead of anonymous inodes
Sean Christopherson <[email protected]> Thu, 25 Sep 2025 08:06:44 -0700
| Newsgroups | org.kernel.vger.linux-bcachefs,dev.linux.lists.linux-coco,net.sourceforge.lists.linux-f2fs-devel,org.kernel.vger.kvm,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-security-module,org.kvack.linux-mm,org.ozlabs.lists.linux-erofs |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Sep 25, 2025, David Hildenbrand wrote: > On 25.09.25 15:41, Sean Christopherson wrote: > > Regarding timing, how much do people care about getting this into 6.18 in > > particular? > > I think it will be beneficial if we start getting stuff upstream. But > waiting a bit longer probably doesn't hurt. > > > AFAICT, this hasn't gotten any coverage in -next, which makes me a > > little nervous. > > Right. > > If we agree, then Shivank can just respin a new version after the merge > window. Actually, if Shivank is ok with it, I'd be happy to post the next version(s). I'll be focusing on the in-place conversion support for the next 1-2 weeks, and have some (half-baked) refactoring changes to better leverage the inode support from this series. I can also plop the first three patches (the non-KVM changes) in a topic branch straightaway, but not feed it into -next until the merge window closes. The 0-day bots scrapes kvm-x86, so that'd get us some early build-bot exposure, and we can stop bugging the non-KVM folks. Then when the dust settles on the KVM changes, I can throw them into the same topic branch.