I would strongly prefer we taret 6.10, not 6.9. The TDX and SNP folks don't need any of this code to be in Linus' tree, they just need it in _a_ KVM tree so that they can develop on top. And I will have limited availability the rest of this week (potentially very limited), and I obviously have strong opinions about some of this code. But even if I had cycles to review this properly, I just don't see a reason to rush it in. For the guest_memfd changes in particular, they're impossible to review in this series. Rather than prematurely shove them into mainline, we should create a volatile topic branch and use that to enable TDX/SNP development. That way we can fixup patches if things need to change. On Tue, Feb 27, 2024, Paolo Bonzini wrote: > This is a first set of, hopefully non-controversial patches from the > SNP and TDX series. They cover mostly changes to generic code and new > gmem APIs, and in general have already been reviewed when posted by > Isaku and Michael. > > One important change is that the gmem hook for initializing memory > is designed to return -EEXIST if the page already exists in the > guestmemfd filemap. The idea is that the special case of > KVM_SEV_SNP_LAUNCH_UPDATE, where __kvm_gmem_get_pfn() is used to > return an uninitialized page and make it guest-owned, can be be done at > most once per page unless the ioctl fails. > > Of course these patches add a bunch of dead code. This is intentional > because it's the only way to trim the large TDX (and to some extent SNP) > series to the point that it's possible to discuss them. The next step is > probably going to be the private<->shared page logic from the TDX series.