On Wed, Jul 16, 2025 at 01:57:55PM -0700, Ackerley Tng wrote: > Yan Zhao <yan.y.zhao@xxxxxxxxx> writes: > > > On Thu, Jun 05, 2025 at 03:35:50PM -0700, Ackerley Tng wrote: > >> Yan Zhao <yan.y.zhao@xxxxxxxxx> writes: > >> > >> > On Wed, Jun 04, 2025 at 01:02:54PM -0700, Ackerley Tng wrote: > >> >> Hi Yan, > >> >> > >> >> While working on the 1G (aka HugeTLB) page support for guest_memfd > >> >> series [1], we took into account conversion failures too. The steps are > >> >> in kvm_gmem_convert_range(). (It might be easier to pull the entire > >> >> series from GitHub [2] because the steps for conversion changed in two > >> >> separate patches.) > >> > ... > >> >> [2] https://github.com/googleprodkernel/linux-cc/tree/gmem-1g-page-support-rfc-v2 > >> > > >> > Hi Ackerley, > >> > Thanks for providing this branch. > >> > >> Here's the WIP branch [1], which I initially wasn't intending to make > >> super public since it's not even RFC standard yet and I didn't want to > >> add to the many guest_memfd in-flight series, but since you referred to > >> it, [2] is a v2 of the WIP branch :) > >> > >> [1] https://github.com/googleprodkernel/linux-cc/commits/wip-tdx-gmem-conversions-hugetlb-2mept > >> [2] https://github.com/googleprodkernel/linux-cc/commits/wip-tdx-gmem-conversions-hugetlb-2mept-v2 > > Hi Ackerley, > > > > I'm working on preparing TDX huge page v2 based on [2] from you. The current > > decision is that the code base of TDX huge page v2 needs to include DPAMT > > and VM shutdown optimization as well. > > > > So, we think kvm-x86/next is a good candidate for us. > > (It is in repo https://github.com/kvm-x86/linux.git > > commit 87198fb0208a (tag: kvm-x86-next-2025.07.15, kvm-x86/next) Merge branch 'vmx', > > which already includes code for VM shutdown optimization). > > I still need to port DPAMT + gmem 1G + TDX huge page v2 on top it. > > > > Therefore, I'm wondering if the rebase of [2] onto kvm-x86/next can be done > > from your side. A straightforward rebase is sufficient, with no need for > > any code modification. And it's better to be completed by the end of next > > week. > > > > We thought it might be easier for you to do that (but depending on your > > bandwidth), allowing me to work on the DPAMT part for TDX huge page v2 in > > parallel. > > > > I'm a little tied up with some internal work, is it okay if, for the No problem. > next RFC, you base the changes that you need to make for TDX huge page > v2 and DPAMT on the base of [2]? > That will save both of us the rebasing. [2] was also based on (some > other version of) kvm/next. > > I think it's okay since the main goal is to show that it works. I'll > let you know when I can get to a guest_memfd_HugeTLB v3 (and all the > other patches that go into [2]). Hmm, the upstream practice is to post code based on latest version, and there're lots TDX relates fixes in latest kvm-x86/next. > [2] https://github.com/googleprodkernel/linux-cc/commits/wip-tdx-gmem-conversions-hugetlb-2mept-v2 > > > However, if it's difficult for you, please feel free to let us know. > > > > Thanks > > Yan
