Message ID | 20230119173559.2517103-1-dmatlack@google.com (mailing list archive) |
---|---|
Headers | show |
Series | KVM: Add a common API for range-based TLB invalidation | expand |
On Thu, Jan 19, 2023, David Matlack wrote: > This series introduces a common API for performing range-based TLB > invalidation. This is then used to supplant > kvm_arch_flush_remote_tlbs_memslot() and pave the way for two other > patch series: > > 1. https://lore.kernel.org/kvm/20230109215347.3119271-1-rananta@google.com/ > > Adds ARM support for range-based TLB invalidation and needs a > mechanism to invoke it from common code. This series provides such a > mechanism via kvm_arch_flush_remote_tlbs_range(). > > 2. https://lore.kernel.org/kvm/20221208193857.4090582-1-dmatlack@google.com/ > > Refactors the TDP MMU into common code, which requires an API for > range-based TLB invaliation. > > This series is based on patches 29-33 from (2.), but I made some further > cleanups after looking at it a second time. > > Tested on x86_64 and ARM64 using KVM selftests. Did a quick read through, didn't see anything I disagree with. Is there any urgency to getting this merged? If not, due to the dependencies with x86 stuff queued for 6.3, and because of the cross-architecture changes, it might be easiest to plan on landing this in 6.4. That would allow Paolo to create an immutable topic branch fairly early on.
On Wed, Jan 25, 2023 at 12:46:59AM +0000, Sean Christopherson wrote: > On Thu, Jan 19, 2023, David Matlack wrote: > > This series introduces a common API for performing range-based TLB > > invalidation. This is then used to supplant > > kvm_arch_flush_remote_tlbs_memslot() and pave the way for two other > > patch series: > > > > 1. https://lore.kernel.org/kvm/20230109215347.3119271-1-rananta@google.com/ > > > > Adds ARM support for range-based TLB invalidation and needs a > > mechanism to invoke it from common code. This series provides such a > > mechanism via kvm_arch_flush_remote_tlbs_range(). > > > > 2. https://lore.kernel.org/kvm/20221208193857.4090582-1-dmatlack@google.com/ > > > > Refactors the TDP MMU into common code, which requires an API for > > range-based TLB invaliation. > > > > This series is based on patches 29-33 from (2.), but I made some further > > cleanups after looking at it a second time. > > > > Tested on x86_64 and ARM64 using KVM selftests. > > Did a quick read through, didn't see anything I disagree with. LGTM for the tiny amount of arm64 changes, though I imagine David will do a v2 to completely get rid of the affected Kconfig. > Is there any urgency to getting this merged? If not, due to the dependencies > with x86 stuff queued for 6.3, and because of the cross-architecture changes, it > might be easiest to plan on landing this in 6.4. That would allow Paolo to create > an immutable topic branch fairly early on. +1, that buys us some time to go through the rounds on the arm64 side such that we could possibly stack the TLBIRANGE work on top. -- Thanks, Oliver
On Tue, Jan 24, 2023 at 4:51 PM Oliver Upton <oliver.upton@linux.dev> wrote: > On Wed, Jan 25, 2023 at 12:46:59AM +0000, Sean Christopherson wrote: > > On Thu, Jan 19, 2023, David Matlack wrote: > > > > Did a quick read through, didn't see anything I disagree with. > > LGTM for the tiny amount of arm64 changes, though I imagine David will > do a v2 to completely get rid of the affected Kconfig. Thanks both for taking a look. > > Is there any urgency to getting this merged? If not, due to the dependencies > > with x86 stuff queued for 6.3, and because of the cross-architecture changes, it > > might be easiest to plan on landing this in 6.4. That would allow Paolo to create > > an immutable topic branch fairly early on. > > +1, that buys us some time to go through the rounds on the arm64 side > such that we could possibly stack the TLBIRANGE work on top. The main benefit of merging in 6.3 would be to make Raghavendra's life simpler/easier so he can build the next version of his arm64 TLBI series on top. But I guess he can still do that with a topic branch. I'll go ahead and send a v2 on top of the changes from Hou you queued for 6.3, Sean, and we can plan on landing that in 6.4 (barring any further feedback or conflicts).