Suzuki K Poulose <[email protected]> writes: > On 04/08/2026 22:35, Sean Christopherson wrote: >> On Tue, Aug 04, 2026, Ackerley Tng wrote: >>> "David Hildenbrand (Arm)" <[email protected]> writes: >>>> Andrew wants to give it some more time in -next, so I'm expecting it to >>>> land for 7.3. >>>> >>>>> 7.2 or 7.3, then I would strongly prefer to base v10 on linux-next (where >>>>> the fix will presumably land soonish), and target 7.4 for in-place >>>>> conversion. Then v10 can be applied against an early 7.3-rcN and we don't >>>>> need to juggle branches (assuming Andrew is ok taking the proposed patch >>>>> through the KVM tree). >>>> >>>> Agreed. We'd also have to get the actual preparation patch into 7.3. I can >>>> send it out and coordinate with Andrew. >>>> >>> >>> Thank you! >>> >>> When we were discussing this earlier at guest_memfd biweekly, before >>> deciding to refactor out a function like lru_cache_drain_for_folio(), we >>> did say that the likelihood of actually draining in practice is low, >>> especially on a machine with heavy load making allocations all the time. >>> >>> I think the threads with Xiaoyao have resolved, I can put v10 out >>> tomorrow. Would it be okay to go with the following from v8, and then >>> clean up later when lru_cache_drain_for_folio() is available? >> >> No. >> >>> I'm hoping not to push this back by a full cycle to 7.4, >> >> Sorry, but we've missed 7.3, irrespective of the lru_cache_drain_for_folio() >> fix. >> Even if v10 is perfect, applying tomorrow means it will get ~3 business days >> in >> linux-next before I send pull requests to Paolo. That's just not enough soak >> time for land a 40+ patch series, even if half of those patches are >> selftests. >> >>> and also hold back other series dependent on this one. >> >> Eh, I don't think there will be meaningful impact in practice. If v10 is >> good >> to go, I'll get it applied on 7.3-r1, and will also get an early pull request >> over to Paolo (probably around 7.3-rc4). I.e. folks can start posting >> against >> the landed series shortly after rc1, and I'll have a set-in-stone base on >> which >> to apply more stuff around rc4/rc5. > > For the record, Arm CCA KVM support depends on this series and that > being a big series (around 40+ patches), it is an inconvenience for the > Maintainers to make an effort to review the series. That said, we are > happy with the way this is progressing and next cycle merge for this > series would be perfect for us. >
I saw the exchange on v16 of the ARM CCA series. I'm going to make every effort for the conversions series to get into 7.3-rc1!! Sean, for the two attachments you left, did you intend 0001 to be the first patch in the conversions series, or separately handled? and 0002 will replace these 2 patches (in-place, in terms of order), right? + "KVM: guest_memfd: Introduce function to check GFN private/shared status" + "KVM: guest_memfd: Wire up core private/shared attribute interfaces" > >> >> And if v10 has issues, then *not* rushing it into 7.3 will likely be the >> fastest >> path forward. > > Absolutely !Like any work, if it is not ready to merge, it is not. > > Cheers > Suzuki
