Re: [PATCH v5 15/19] KVM: Provide common implementation for generic dirty log functions
On Mon, Feb 17, 2020 at 04:39:39PM +0100, Vitaly Kuznetsov wrote: > Sean Christopherson writes: > > Unless it's functionally incorrect (Vitaly?), going with option (2) and > > naming the hook kvm_arch_flush_remote_tlbs_memslot() seems like the obvious > > choice, e.g. the final cleanup gives this diff stat: > > (I apologize again for not replying in time) No worries, didn't hinder me in the slightest as I was buried in other stuff last week anyways. > I think this is a valid approach and your option (2) would also be my > choice. I also don't think there's going to be a problem when (if) > Hyper-V adds support for PML (eVMCSv2?). Cool, thanks! ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v5 15/19] KVM: Provide common implementation for generic dirty log functions
Sean Christopherson writes: > On Fri, Feb 07, 2020 at 07:53:34PM -0500, Peter Xu wrote: >> On Fri, Feb 07, 2020 at 04:42:33PM -0800, Sean Christopherson wrote: >> > On Fri, Feb 07, 2020 at 07:18:32PM -0500, Peter Xu wrote: >> > > On Fri, Feb 07, 2020 at 11:45:32AM -0800, Sean Christopherson wrote: >> > > > +Vitaly for HyperV >> > > > >> > > > On Thu, Feb 06, 2020 at 04:41:06PM -0500, Peter Xu wrote: >> > > > > On Thu, Feb 06, 2020 at 01:21:20PM -0800, Sean Christopherson wrote: >> > > > > > On Thu, Feb 06, 2020 at 03:02:00PM -0500, Peter Xu wrote: >> > > > > > > But that matters to this patch because if MIPS can use >> > > > > > > kvm_flush_remote_tlbs(), then we probably don't need this >> > > > > > > arch-specific hook any more and we can directly call >> > > > > > > kvm_flush_remote_tlbs() after sync dirty log when flush==true. >> > > > > > >> > > > > > Ya, the asid_flush_mask in kvm_vz_flush_shadow_all() is the only >> > > > > > thing >> > > > > > that prevents calling kvm_flush_remote_tlbs() directly, but I have >> > > > > > no >> > > > > > clue as to the important of that code. >> > > > > >> > > > > As said above I think the x86 lockdep is really not necessary, then >> > > > > considering MIPS could be the only one that will use the new hook >> > > > > introduced in this patch... Shall we figure that out first? >> > > > >> > > > So I prepped a follow-up patch to make kvm_arch_dirty_log_tlb_flush() a >> > > > MIPS-only hook and use kvm_flush_remote_tlbs() directly for arm and >> > > > x86, >> > > > but then I realized x86 *has* a hook to do a precise remote TLB flush. >> > > > There's even an existing kvm_flush_remote_tlbs_with_address() call on a >> > > > memslot, i.e. this exact scenario. So arguably, x86 should be using >> > > > the >> > > > more precise flush and should keep kvm_arch_dirty_log_tlb_flush(). >> > > > >> > > > But, the hook is only used when KVM is running as an L1 on top of >> > > > HyperV, >> > > > and I assume dirty logging isn't used much, if at all, for L1 KVM on >> > > > HyperV? >> > > > >> > > > I see three options: >> > > > >> > > > 1. Make kvm_arch_dirty_log_tlb_flush() MIPS-only and call >> > > > kvm_flush_remote_tlbs() directly for arm and x86. Add comments to >> > > > explain when an arch should implement >> > > > kvm_arch_dirty_log_tlb_flush(). >> > > > >> > > > 2. Change x86 to use kvm_flush_remote_tlbs_with_address() when >> > > > flushing >> > > > a memslot after the dirty log is grabbed by userspace. >> > > > >> > > > 3. Keep the resulting code as is, but add a comment in x86's >> > > > kvm_arch_dirty_log_tlb_flush() to explain why it uses >> > > > kvm_flush_remote_tlbs() instead of the with_address() variant. >> > > > >> > > > I strongly prefer to (2) or (3), but I'll defer to Vitaly as to which >> > > > of >> > > > those is preferable. >> > > > >> > > > I don't like (1) because (a) it requires more lines code (well >> > > > comments), >> > > > to explain why kvm_flush_remote_tlbs() is the default, and (b) it would >> > > > require even more comments, which would be x86-specific in generic KVM, >> > > > to explain why x86 doesn't use its with_address() flush, or we'd lost >> > > > that >> > > > info altogether. >> > > > >> > > >> > > I proposed the 4th solution here: >> > > >> > > https://lore.kernel.org/kvm/20200207223520.735523-1-pet...@redhat.com/ >> > > >> > > I'm not sure whether that's acceptable, but if it can, then we can >> > > drop the kvm_arch_dirty_log_tlb_flush() hook, or even move on to >> > > per-slot tlb flushing. >> > >> > This effectively is per-slot TLB flushing, it just has a different name. >> > I.e. s/kvm_arch_dirty_log_tlb_flush/kvm_arch_flush_remote_tlbs_memslot. >> > I'm not opposed to that name change. And on second and third glance, I >> > probably prefer it. That would more or less follow the naming of >> > kvm_arch_flush_shadow_all() and kvm_arch_flush_shadow_memslot(). >> >> Note that the major point of the above patchset is not about doing tlb >> flush per-memslot or globally. It's more about whether we can provide >> a common entrance for TLB flushing. Say, after that series, we should >> be able to flush TLB on all archs (majorly, including MIPS) as: >> >> kvm_flush_remote_tlbs(kvm); >> >> And with the same idea we can also introduce the ranged version. >> >> > >> > I don't want to go straight to kvm_arch_flush_remote_tlb_with_address() >> > because that loses the important distinction (on x86) that slots_lock is >> > expected to be held. >> >> Sorry I'm still puzzled on why that lockdep is so important and >> special for x86... For example, what if we move that lockdep to the >> callers of the kvm_arch_dirty_log_tlb_flush() calls so it protects >> even more arch (where we do get/clear dirty log)? IMHO the callers >> must be with the slots_lock held anyways no matter for x86 or not. > > > Following the breadcrumbs leads to the comment in >
Re: [PATCH v5 15/19] KVM: Provide common implementation for generic dirty log functions
Sean Christopherson writes: > +Vitaly for HyperV > > On Thu, Feb 06, 2020 at 04:41:06PM -0500, Peter Xu wrote: >> On Thu, Feb 06, 2020 at 01:21:20PM -0800, Sean Christopherson wrote: >> > On Thu, Feb 06, 2020 at 03:02:00PM -0500, Peter Xu wrote: >> > > But that matters to this patch because if MIPS can use >> > > kvm_flush_remote_tlbs(), then we probably don't need this >> > > arch-specific hook any more and we can directly call >> > > kvm_flush_remote_tlbs() after sync dirty log when flush==true. >> > >> > Ya, the asid_flush_mask in kvm_vz_flush_shadow_all() is the only thing >> > that prevents calling kvm_flush_remote_tlbs() directly, but I have no >> > clue as to the important of that code. >> >> As said above I think the x86 lockdep is really not necessary, then >> considering MIPS could be the only one that will use the new hook >> introduced in this patch... Shall we figure that out first? > > So I prepped a follow-up patch to make kvm_arch_dirty_log_tlb_flush() a > MIPS-only hook and use kvm_flush_remote_tlbs() directly for arm and x86, > but then I realized x86 *has* a hook to do a precise remote TLB flush. > There's even an existing kvm_flush_remote_tlbs_with_address() call on a > memslot, i.e. this exact scenario. So arguably, x86 should be using the > more precise flush and should keep kvm_arch_dirty_log_tlb_flush(). > > But, the hook is only used when KVM is running as an L1 on top of HyperV, > and I assume dirty logging isn't used much, if at all, for L1 KVM on > HyperV? (Sorry for the delayed reply, was traveling last week) When KVM runs as an L1 on top of Hyper-V it uses eVMCS by default and eVMCSv1 doesn't support PML. I've also just checked Hyper-V 2019 and it hides SECONDARY_EXEC_ENABLE_PML from guests (this was expected). > > I see three options: > > 1. Make kvm_arch_dirty_log_tlb_flush() MIPS-only and call > kvm_flush_remote_tlbs() directly for arm and x86. Add comments to > explain when an arch should implement kvm_arch_dirty_log_tlb_flush(). > > 2. Change x86 to use kvm_flush_remote_tlbs_with_address() when flushing > a memslot after the dirty log is grabbed by userspace. > > 3. Keep the resulting code as is, but add a comment in x86's > kvm_arch_dirty_log_tlb_flush() to explain why it uses > kvm_flush_remote_tlbs() instead of the with_address() variant. > > I strongly prefer to (2) or (3), but I'll defer to Vitaly as to which of > those is preferable. I'd vote for (2): while this will effectively be kvm_flush_remote_tlbs() for now, we may think of something smarter in the future (e.g. PV interface for KVM-on-KVM). > > I don't like (1) because (a) it requires more lines code (well comments), > to explain why kvm_flush_remote_tlbs() is the default, and (b) it would > require even more comments, which would be x86-specific in generic KVM, > to explain why x86 doesn't use its with_address() flush, or we'd lost that > info altogether. > -- Vitaly ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v5 15/19] KVM: Provide common implementation for generic dirty log functions
On Fri, Feb 07, 2020 at 07:53:34PM -0500, Peter Xu wrote: > On Fri, Feb 07, 2020 at 04:42:33PM -0800, Sean Christopherson wrote: > > On Fri, Feb 07, 2020 at 07:18:32PM -0500, Peter Xu wrote: > > > On Fri, Feb 07, 2020 at 11:45:32AM -0800, Sean Christopherson wrote: > > > > +Vitaly for HyperV > > > > > > > > On Thu, Feb 06, 2020 at 04:41:06PM -0500, Peter Xu wrote: > > > > > On Thu, Feb 06, 2020 at 01:21:20PM -0800, Sean Christopherson wrote: > > > > > > On Thu, Feb 06, 2020 at 03:02:00PM -0500, Peter Xu wrote: > > > > > > > But that matters to this patch because if MIPS can use > > > > > > > kvm_flush_remote_tlbs(), then we probably don't need this > > > > > > > arch-specific hook any more and we can directly call > > > > > > > kvm_flush_remote_tlbs() after sync dirty log when flush==true. > > > > > > > > > > > > Ya, the asid_flush_mask in kvm_vz_flush_shadow_all() is the only > > > > > > thing > > > > > > that prevents calling kvm_flush_remote_tlbs() directly, but I have > > > > > > no > > > > > > clue as to the important of that code. > > > > > > > > > > As said above I think the x86 lockdep is really not necessary, then > > > > > considering MIPS could be the only one that will use the new hook > > > > > introduced in this patch... Shall we figure that out first? > > > > > > > > So I prepped a follow-up patch to make kvm_arch_dirty_log_tlb_flush() a > > > > MIPS-only hook and use kvm_flush_remote_tlbs() directly for arm and x86, > > > > but then I realized x86 *has* a hook to do a precise remote TLB flush. > > > > There's even an existing kvm_flush_remote_tlbs_with_address() call on a > > > > memslot, i.e. this exact scenario. So arguably, x86 should be using the > > > > more precise flush and should keep kvm_arch_dirty_log_tlb_flush(). > > > > > > > > But, the hook is only used when KVM is running as an L1 on top of > > > > HyperV, > > > > and I assume dirty logging isn't used much, if at all, for L1 KVM on > > > > HyperV? > > > > > > > > I see three options: > > > > > > > > 1. Make kvm_arch_dirty_log_tlb_flush() MIPS-only and call > > > > kvm_flush_remote_tlbs() directly for arm and x86. Add comments to > > > > explain when an arch should implement > > > > kvm_arch_dirty_log_tlb_flush(). > > > > > > > > 2. Change x86 to use kvm_flush_remote_tlbs_with_address() when > > > > flushing > > > > a memslot after the dirty log is grabbed by userspace. > > > > > > > > 3. Keep the resulting code as is, but add a comment in x86's > > > > kvm_arch_dirty_log_tlb_flush() to explain why it uses > > > > kvm_flush_remote_tlbs() instead of the with_address() variant. > > > > > > > > I strongly prefer to (2) or (3), but I'll defer to Vitaly as to which of > > > > those is preferable. > > > > > > > > I don't like (1) because (a) it requires more lines code (well > > > > comments), > > > > to explain why kvm_flush_remote_tlbs() is the default, and (b) it would > > > > require even more comments, which would be x86-specific in generic KVM, > > > > to explain why x86 doesn't use its with_address() flush, or we'd lost > > > > that > > > > info altogether. > > > > > > > > > > I proposed the 4th solution here: > > > > > > https://lore.kernel.org/kvm/20200207223520.735523-1-pet...@redhat.com/ > > > > > > I'm not sure whether that's acceptable, but if it can, then we can > > > drop the kvm_arch_dirty_log_tlb_flush() hook, or even move on to > > > per-slot tlb flushing. > > > > This effectively is per-slot TLB flushing, it just has a different name. > > I.e. s/kvm_arch_dirty_log_tlb_flush/kvm_arch_flush_remote_tlbs_memslot. > > I'm not opposed to that name change. And on second and third glance, I > > probably prefer it. That would more or less follow the naming of > > kvm_arch_flush_shadow_all() and kvm_arch_flush_shadow_memslot(). > > Note that the major point of the above patchset is not about doing tlb > flush per-memslot or globally. It's more about whether we can provide > a common entrance for TLB flushing. Say, after that series, we should > be able to flush TLB on all archs (majorly, including MIPS) as: > > kvm_flush_remote_tlbs(kvm); > > And with the same idea we can also introduce the ranged version. > > > > > I don't want to go straight to kvm_arch_flush_remote_tlb_with_address() > > because that loses the important distinction (on x86) that slots_lock is > > expected to be held. > > Sorry I'm still puzzled on why that lockdep is so important and > special for x86... For example, what if we move that lockdep to the > callers of the kvm_arch_dirty_log_tlb_flush() calls so it protects > even more arch (where we do get/clear dirty log)? IMHO the callers > must be with the slots_lock held anyways no matter for x86 or not. Following the breadcrumbs leads to the comment in kvm_mmu_slot_remove_write_access(), which says: /* * kvm_mmu_slot_remove_write_access() and kvm_vm_ioctl_get_dirty_log() * which do tlb flush out of
Re: [PATCH v5 15/19] KVM: Provide common implementation for generic dirty log functions
On Fri, Feb 07, 2020 at 04:42:33PM -0800, Sean Christopherson wrote: > On Fri, Feb 07, 2020 at 07:18:32PM -0500, Peter Xu wrote: > > On Fri, Feb 07, 2020 at 11:45:32AM -0800, Sean Christopherson wrote: > > > +Vitaly for HyperV > > > > > > On Thu, Feb 06, 2020 at 04:41:06PM -0500, Peter Xu wrote: > > > > On Thu, Feb 06, 2020 at 01:21:20PM -0800, Sean Christopherson wrote: > > > > > On Thu, Feb 06, 2020 at 03:02:00PM -0500, Peter Xu wrote: > > > > > > But that matters to this patch because if MIPS can use > > > > > > kvm_flush_remote_tlbs(), then we probably don't need this > > > > > > arch-specific hook any more and we can directly call > > > > > > kvm_flush_remote_tlbs() after sync dirty log when flush==true. > > > > > > > > > > Ya, the asid_flush_mask in kvm_vz_flush_shadow_all() is the only thing > > > > > that prevents calling kvm_flush_remote_tlbs() directly, but I have no > > > > > clue as to the important of that code. > > > > > > > > As said above I think the x86 lockdep is really not necessary, then > > > > considering MIPS could be the only one that will use the new hook > > > > introduced in this patch... Shall we figure that out first? > > > > > > So I prepped a follow-up patch to make kvm_arch_dirty_log_tlb_flush() a > > > MIPS-only hook and use kvm_flush_remote_tlbs() directly for arm and x86, > > > but then I realized x86 *has* a hook to do a precise remote TLB flush. > > > There's even an existing kvm_flush_remote_tlbs_with_address() call on a > > > memslot, i.e. this exact scenario. So arguably, x86 should be using the > > > more precise flush and should keep kvm_arch_dirty_log_tlb_flush(). > > > > > > But, the hook is only used when KVM is running as an L1 on top of HyperV, > > > and I assume dirty logging isn't used much, if at all, for L1 KVM on > > > HyperV? > > > > > > I see three options: > > > > > > 1. Make kvm_arch_dirty_log_tlb_flush() MIPS-only and call > > > kvm_flush_remote_tlbs() directly for arm and x86. Add comments to > > > explain when an arch should implement kvm_arch_dirty_log_tlb_flush(). > > > > > > 2. Change x86 to use kvm_flush_remote_tlbs_with_address() when flushing > > > a memslot after the dirty log is grabbed by userspace. > > > > > > 3. Keep the resulting code as is, but add a comment in x86's > > > kvm_arch_dirty_log_tlb_flush() to explain why it uses > > > kvm_flush_remote_tlbs() instead of the with_address() variant. > > > > > > I strongly prefer to (2) or (3), but I'll defer to Vitaly as to which of > > > those is preferable. > > > > > > I don't like (1) because (a) it requires more lines code (well comments), > > > to explain why kvm_flush_remote_tlbs() is the default, and (b) it would > > > require even more comments, which would be x86-specific in generic KVM, > > > to explain why x86 doesn't use its with_address() flush, or we'd lost that > > > info altogether. > > > > > > > I proposed the 4th solution here: > > > > https://lore.kernel.org/kvm/20200207223520.735523-1-pet...@redhat.com/ > > > > I'm not sure whether that's acceptable, but if it can, then we can > > drop the kvm_arch_dirty_log_tlb_flush() hook, or even move on to > > per-slot tlb flushing. > > This effectively is per-slot TLB flushing, it just has a different name. > I.e. s/kvm_arch_dirty_log_tlb_flush/kvm_arch_flush_remote_tlbs_memslot. > I'm not opposed to that name change. And on second and third glance, I > probably prefer it. That would more or less follow the naming of > kvm_arch_flush_shadow_all() and kvm_arch_flush_shadow_memslot(). Note that the major point of the above patchset is not about doing tlb flush per-memslot or globally. It's more about whether we can provide a common entrance for TLB flushing. Say, after that series, we should be able to flush TLB on all archs (majorly, including MIPS) as: kvm_flush_remote_tlbs(kvm); And with the same idea we can also introduce the ranged version. > > I don't want to go straight to kvm_arch_flush_remote_tlb_with_address() > because that loses the important distinction (on x86) that slots_lock is > expected to be held. Sorry I'm still puzzled on why that lockdep is so important and special for x86... For example, what if we move that lockdep to the callers of the kvm_arch_dirty_log_tlb_flush() calls so it protects even more arch (where we do get/clear dirty log)? IMHO the callers must be with the slots_lock held anyways no matter for x86 or not. Thanks, -- Peter Xu ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v5 15/19] KVM: Provide common implementation for generic dirty log functions
On Fri, Feb 07, 2020 at 07:18:32PM -0500, Peter Xu wrote: > On Fri, Feb 07, 2020 at 11:45:32AM -0800, Sean Christopherson wrote: > > +Vitaly for HyperV > > > > On Thu, Feb 06, 2020 at 04:41:06PM -0500, Peter Xu wrote: > > > On Thu, Feb 06, 2020 at 01:21:20PM -0800, Sean Christopherson wrote: > > > > On Thu, Feb 06, 2020 at 03:02:00PM -0500, Peter Xu wrote: > > > > > But that matters to this patch because if MIPS can use > > > > > kvm_flush_remote_tlbs(), then we probably don't need this > > > > > arch-specific hook any more and we can directly call > > > > > kvm_flush_remote_tlbs() after sync dirty log when flush==true. > > > > > > > > Ya, the asid_flush_mask in kvm_vz_flush_shadow_all() is the only thing > > > > that prevents calling kvm_flush_remote_tlbs() directly, but I have no > > > > clue as to the important of that code. > > > > > > As said above I think the x86 lockdep is really not necessary, then > > > considering MIPS could be the only one that will use the new hook > > > introduced in this patch... Shall we figure that out first? > > > > So I prepped a follow-up patch to make kvm_arch_dirty_log_tlb_flush() a > > MIPS-only hook and use kvm_flush_remote_tlbs() directly for arm and x86, > > but then I realized x86 *has* a hook to do a precise remote TLB flush. > > There's even an existing kvm_flush_remote_tlbs_with_address() call on a > > memslot, i.e. this exact scenario. So arguably, x86 should be using the > > more precise flush and should keep kvm_arch_dirty_log_tlb_flush(). > > > > But, the hook is only used when KVM is running as an L1 on top of HyperV, > > and I assume dirty logging isn't used much, if at all, for L1 KVM on > > HyperV? > > > > I see three options: > > > > 1. Make kvm_arch_dirty_log_tlb_flush() MIPS-only and call > > kvm_flush_remote_tlbs() directly for arm and x86. Add comments to > > explain when an arch should implement kvm_arch_dirty_log_tlb_flush(). > > > > 2. Change x86 to use kvm_flush_remote_tlbs_with_address() when flushing > > a memslot after the dirty log is grabbed by userspace. > > > > 3. Keep the resulting code as is, but add a comment in x86's > > kvm_arch_dirty_log_tlb_flush() to explain why it uses > > kvm_flush_remote_tlbs() instead of the with_address() variant. > > > > I strongly prefer to (2) or (3), but I'll defer to Vitaly as to which of > > those is preferable. > > > > I don't like (1) because (a) it requires more lines code (well comments), > > to explain why kvm_flush_remote_tlbs() is the default, and (b) it would > > require even more comments, which would be x86-specific in generic KVM, > > to explain why x86 doesn't use its with_address() flush, or we'd lost that > > info altogether. > > > > I proposed the 4th solution here: > > https://lore.kernel.org/kvm/20200207223520.735523-1-pet...@redhat.com/ > > I'm not sure whether that's acceptable, but if it can, then we can > drop the kvm_arch_dirty_log_tlb_flush() hook, or even move on to > per-slot tlb flushing. This effectively is per-slot TLB flushing, it just has a different name. I.e. s/kvm_arch_dirty_log_tlb_flush/kvm_arch_flush_remote_tlbs_memslot. I'm not opposed to that name change. And on second and third glance, I probably prefer it. That would more or less follow the naming of kvm_arch_flush_shadow_all() and kvm_arch_flush_shadow_memslot(). I don't want to go straight to kvm_arch_flush_remote_tlb_with_address() because that loses the important distinction (on x86) that slots_lock is expected to be held. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v5 15/19] KVM: Provide common implementation for generic dirty log functions
On Fri, Feb 07, 2020 at 11:45:32AM -0800, Sean Christopherson wrote: > +Vitaly for HyperV > > On Thu, Feb 06, 2020 at 04:41:06PM -0500, Peter Xu wrote: > > On Thu, Feb 06, 2020 at 01:21:20PM -0800, Sean Christopherson wrote: > > > On Thu, Feb 06, 2020 at 03:02:00PM -0500, Peter Xu wrote: > > > > But that matters to this patch because if MIPS can use > > > > kvm_flush_remote_tlbs(), then we probably don't need this > > > > arch-specific hook any more and we can directly call > > > > kvm_flush_remote_tlbs() after sync dirty log when flush==true. > > > > > > Ya, the asid_flush_mask in kvm_vz_flush_shadow_all() is the only thing > > > that prevents calling kvm_flush_remote_tlbs() directly, but I have no > > > clue as to the important of that code. > > > > As said above I think the x86 lockdep is really not necessary, then > > considering MIPS could be the only one that will use the new hook > > introduced in this patch... Shall we figure that out first? > > So I prepped a follow-up patch to make kvm_arch_dirty_log_tlb_flush() a > MIPS-only hook and use kvm_flush_remote_tlbs() directly for arm and x86, > but then I realized x86 *has* a hook to do a precise remote TLB flush. > There's even an existing kvm_flush_remote_tlbs_with_address() call on a > memslot, i.e. this exact scenario. So arguably, x86 should be using the > more precise flush and should keep kvm_arch_dirty_log_tlb_flush(). > > But, the hook is only used when KVM is running as an L1 on top of HyperV, > and I assume dirty logging isn't used much, if at all, for L1 KVM on > HyperV? > > I see three options: > > 1. Make kvm_arch_dirty_log_tlb_flush() MIPS-only and call > kvm_flush_remote_tlbs() directly for arm and x86. Add comments to > explain when an arch should implement kvm_arch_dirty_log_tlb_flush(). > > 2. Change x86 to use kvm_flush_remote_tlbs_with_address() when flushing > a memslot after the dirty log is grabbed by userspace. > > 3. Keep the resulting code as is, but add a comment in x86's > kvm_arch_dirty_log_tlb_flush() to explain why it uses > kvm_flush_remote_tlbs() instead of the with_address() variant. > > I strongly prefer to (2) or (3), but I'll defer to Vitaly as to which of > those is preferable. > > I don't like (1) because (a) it requires more lines code (well comments), > to explain why kvm_flush_remote_tlbs() is the default, and (b) it would > require even more comments, which would be x86-specific in generic KVM, > to explain why x86 doesn't use its with_address() flush, or we'd lost that > info altogether. > I proposed the 4th solution here: https://lore.kernel.org/kvm/20200207223520.735523-1-pet...@redhat.com/ I'm not sure whether that's acceptable, but if it can, then we can drop the kvm_arch_dirty_log_tlb_flush() hook, or even move on to per-slot tlb flushing. Thanks, -- Peter Xu ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v5 15/19] KVM: Provide common implementation for generic dirty log functions
+Vitaly for HyperV On Thu, Feb 06, 2020 at 04:41:06PM -0500, Peter Xu wrote: > On Thu, Feb 06, 2020 at 01:21:20PM -0800, Sean Christopherson wrote: > > On Thu, Feb 06, 2020 at 03:02:00PM -0500, Peter Xu wrote: > > > But that matters to this patch because if MIPS can use > > > kvm_flush_remote_tlbs(), then we probably don't need this > > > arch-specific hook any more and we can directly call > > > kvm_flush_remote_tlbs() after sync dirty log when flush==true. > > > > Ya, the asid_flush_mask in kvm_vz_flush_shadow_all() is the only thing > > that prevents calling kvm_flush_remote_tlbs() directly, but I have no > > clue as to the important of that code. > > As said above I think the x86 lockdep is really not necessary, then > considering MIPS could be the only one that will use the new hook > introduced in this patch... Shall we figure that out first? So I prepped a follow-up patch to make kvm_arch_dirty_log_tlb_flush() a MIPS-only hook and use kvm_flush_remote_tlbs() directly for arm and x86, but then I realized x86 *has* a hook to do a precise remote TLB flush. There's even an existing kvm_flush_remote_tlbs_with_address() call on a memslot, i.e. this exact scenario. So arguably, x86 should be using the more precise flush and should keep kvm_arch_dirty_log_tlb_flush(). But, the hook is only used when KVM is running as an L1 on top of HyperV, and I assume dirty logging isn't used much, if at all, for L1 KVM on HyperV? I see three options: 1. Make kvm_arch_dirty_log_tlb_flush() MIPS-only and call kvm_flush_remote_tlbs() directly for arm and x86. Add comments to explain when an arch should implement kvm_arch_dirty_log_tlb_flush(). 2. Change x86 to use kvm_flush_remote_tlbs_with_address() when flushing a memslot after the dirty log is grabbed by userspace. 3. Keep the resulting code as is, but add a comment in x86's kvm_arch_dirty_log_tlb_flush() to explain why it uses kvm_flush_remote_tlbs() instead of the with_address() variant. I strongly prefer to (2) or (3), but I'll defer to Vitaly as to which of those is preferable. I don't like (1) because (a) it requires more lines code (well comments), to explain why kvm_flush_remote_tlbs() is the default, and (b) it would require even more comments, which would be x86-specific in generic KVM, to explain why x86 doesn't use its with_address() flush, or we'd lost that info altogether. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v5 15/19] KVM: Provide common implementation for generic dirty log functions
On Thu, Feb 06, 2020 at 01:21:20PM -0800, Sean Christopherson wrote:
> On Thu, Feb 06, 2020 at 03:02:00PM -0500, Peter Xu wrote:
> > On Tue, Jan 21, 2020 at 02:31:53PM -0800, Sean Christopherson wrote:
> >
> > [...]
> >
> > > -int kvm_vm_ioctl_clear_dirty_log(struct kvm *kvm, struct
> > > kvm_clear_dirty_log *log)
> > > +void kvm_arch_dirty_log_tlb_flush(struct kvm *kvm,
> > > + struct kvm_memory_slot *memslot)
> >
> > If it's to flush TLB for a memslot, shall we remove the "dirty_log" in
> > the name of the function, because it has nothing to do with dirty
> > logging any more? And...
>
> I kept the "dirty_log" to allow arch code to implement logic specific to a
> TLB flush during dirty logging, e.g. x86's lockdep assert on slots_lock.
> And similar to the issue with MIPS below, to deter usage of the hook for
> anything else, i.e. to nudge people to using kvm_flush_remote_tlbs()
> directly.
The x86's lockdep assert is not that important afaict, since the two
callers of the new tlb_flush() hook will be with slots_lock for sure.
>
> > > {
> > > - struct kvm_memslots *slots;
> > > - struct kvm_memory_slot *memslot;
> > > - bool flush = false;
> > > - int r;
> > > -
> > > - mutex_lock(>slots_lock);
> > > -
> > > - r = kvm_clear_dirty_log_protect(kvm, log, );
> > > -
> > > - if (flush) {
> > > - slots = kvm_memslots(kvm);
> > > - memslot = id_to_memslot(slots, log->slot);
> > > -
> > > - /* Let implementation handle TLB/GVA invalidation */
> > > - kvm_mips_callbacks->flush_shadow_memslot(kvm, memslot);
> > > - }
> > > -
> > > - mutex_unlock(>slots_lock);
> > > - return r;
> > > + /* Let implementation handle TLB/GVA invalidation */
> > > + kvm_mips_callbacks->flush_shadow_memslot(kvm, memslot);
> >
> > ... This may not directly related to the current patch, but I'm
> > confused on why MIPS cannot use kvm_flush_remote_tlbs() to flush TLBs.
> > I know nothing about MIPS code, but IIUC here flush_shadow_memslot()
> > is a heavier operation that will also invalidate the shadow pages.
> > Seems to be an overkill here when we only changed write permission of
> > the PTEs? I tried to check the first occurance (2a31b9db15353) but I
> > didn't find out any clue of it so far.
> >
> > But that matters to this patch because if MIPS can use
> > kvm_flush_remote_tlbs(), then we probably don't need this
> > arch-specific hook any more and we can directly call
> > kvm_flush_remote_tlbs() after sync dirty log when flush==true.
>
> Ya, the asid_flush_mask in kvm_vz_flush_shadow_all() is the only thing
> that prevents calling kvm_flush_remote_tlbs() directly, but I have no
> clue as to the important of that code.
As said above I think the x86 lockdep is really not necessary, then
considering MIPS could be the only one that will use the new hook
introduced in this patch... Shall we figure that out first?
Thanks,
--
Peter Xu
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v5 15/19] KVM: Provide common implementation for generic dirty log functions
On Tue, Jan 21, 2020 at 02:31:53PM -0800, Sean Christopherson wrote: [...] > @@ -1333,6 +1369,7 @@ int kvm_clear_dirty_log_protect(struct kvm *kvm, > unsigned long i, n; > unsigned long *dirty_bitmap; > unsigned long *dirty_bitmap_buffer; > + bool flush; > > as_id = log->slot >> 16; > id = (u16)log->slot; > @@ -1356,7 +1393,9 @@ int kvm_clear_dirty_log_protect(struct kvm *kvm, > (log->num_pages < memslot->npages - log->first_page && > (log->num_pages & 63))) > return -EINVAL; > > - *flush = false; > + kvm_arch_sync_dirty_log(kvm, memslot); Do we need this even for clear dirty log? > + > + flush = false; > dirty_bitmap_buffer = kvm_second_dirty_bitmap(memslot); > if (copy_from_user(dirty_bitmap_buffer, log->dirty_bitmap, n)) > return -EFAULT; -- Peter Xu ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v5 15/19] KVM: Provide common implementation for generic dirty log functions
On Thu, Feb 06, 2020 at 03:02:00PM -0500, Peter Xu wrote:
> On Tue, Jan 21, 2020 at 02:31:53PM -0800, Sean Christopherson wrote:
>
> [...]
>
> > -int kvm_vm_ioctl_clear_dirty_log(struct kvm *kvm, struct
> > kvm_clear_dirty_log *log)
> > +void kvm_arch_dirty_log_tlb_flush(struct kvm *kvm,
> > + struct kvm_memory_slot *memslot)
>
> If it's to flush TLB for a memslot, shall we remove the "dirty_log" in
> the name of the function, because it has nothing to do with dirty
> logging any more? And...
I kept the "dirty_log" to allow arch code to implement logic specific to a
TLB flush during dirty logging, e.g. x86's lockdep assert on slots_lock.
And similar to the issue with MIPS below, to deter usage of the hook for
anything else, i.e. to nudge people to using kvm_flush_remote_tlbs()
directly.
> > {
> > - struct kvm_memslots *slots;
> > - struct kvm_memory_slot *memslot;
> > - bool flush = false;
> > - int r;
> > -
> > - mutex_lock(>slots_lock);
> > -
> > - r = kvm_clear_dirty_log_protect(kvm, log, );
> > -
> > - if (flush) {
> > - slots = kvm_memslots(kvm);
> > - memslot = id_to_memslot(slots, log->slot);
> > -
> > - /* Let implementation handle TLB/GVA invalidation */
> > - kvm_mips_callbacks->flush_shadow_memslot(kvm, memslot);
> > - }
> > -
> > - mutex_unlock(>slots_lock);
> > - return r;
> > + /* Let implementation handle TLB/GVA invalidation */
> > + kvm_mips_callbacks->flush_shadow_memslot(kvm, memslot);
>
> ... This may not directly related to the current patch, but I'm
> confused on why MIPS cannot use kvm_flush_remote_tlbs() to flush TLBs.
> I know nothing about MIPS code, but IIUC here flush_shadow_memslot()
> is a heavier operation that will also invalidate the shadow pages.
> Seems to be an overkill here when we only changed write permission of
> the PTEs? I tried to check the first occurance (2a31b9db15353) but I
> didn't find out any clue of it so far.
>
> But that matters to this patch because if MIPS can use
> kvm_flush_remote_tlbs(), then we probably don't need this
> arch-specific hook any more and we can directly call
> kvm_flush_remote_tlbs() after sync dirty log when flush==true.
Ya, the asid_flush_mask in kvm_vz_flush_shadow_all() is the only thing
that prevents calling kvm_flush_remote_tlbs() directly, but I have no
clue as to the important of that code.
> > }
> >
> > long kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned
> > long arg)
> > diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> > index 97ce6c4f7b48..0adaf4791a6d 100644
> > --- a/arch/powerpc/kvm/book3s.c
> > +++ b/arch/powerpc/kvm/book3s.c
> > @@ -799,6 +799,11 @@ int kvmppc_core_check_requests(struct kvm_vcpu *vcpu)
> > return vcpu->kvm->arch.kvm_ops->check_requests(vcpu);
> > }
> >
> > +void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot
> > *memslot)
>
> Since at it, maybe we can start to use __weak attribute for new hooks
> especially when it's empty for most archs?
>
> E.g., define:
>
> void __weak kvm_arch_sync_dirty_log(...) {}
>
> In the common code, then only define it again in arch that has
> non-empty implementation of this method?
I defer to Paolo, I'm indifferent at this stage.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v5 15/19] KVM: Provide common implementation for generic dirty log functions
On Tue, Jan 21, 2020 at 02:31:53PM -0800, Sean Christopherson wrote:
[...]
> -int kvm_vm_ioctl_clear_dirty_log(struct kvm *kvm, struct kvm_clear_dirty_log
> *log)
> +void kvm_arch_dirty_log_tlb_flush(struct kvm *kvm,
> + struct kvm_memory_slot *memslot)
If it's to flush TLB for a memslot, shall we remove the "dirty_log" in
the name of the function, because it has nothing to do with dirty
logging any more? And...
> {
> - struct kvm_memslots *slots;
> - struct kvm_memory_slot *memslot;
> - bool flush = false;
> - int r;
> -
> - mutex_lock(>slots_lock);
> -
> - r = kvm_clear_dirty_log_protect(kvm, log, );
> -
> - if (flush) {
> - slots = kvm_memslots(kvm);
> - memslot = id_to_memslot(slots, log->slot);
> -
> - /* Let implementation handle TLB/GVA invalidation */
> - kvm_mips_callbacks->flush_shadow_memslot(kvm, memslot);
> - }
> -
> - mutex_unlock(>slots_lock);
> - return r;
> + /* Let implementation handle TLB/GVA invalidation */
> + kvm_mips_callbacks->flush_shadow_memslot(kvm, memslot);
... This may not directly related to the current patch, but I'm
confused on why MIPS cannot use kvm_flush_remote_tlbs() to flush TLBs.
I know nothing about MIPS code, but IIUC here flush_shadow_memslot()
is a heavier operation that will also invalidate the shadow pages.
Seems to be an overkill here when we only changed write permission of
the PTEs? I tried to check the first occurance (2a31b9db15353) but I
didn't find out any clue of it so far.
But that matters to this patch because if MIPS can use
kvm_flush_remote_tlbs(), then we probably don't need this
arch-specific hook any more and we can directly call
kvm_flush_remote_tlbs() after sync dirty log when flush==true.
> }
>
> long kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long
> arg)
> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> index 97ce6c4f7b48..0adaf4791a6d 100644
> --- a/arch/powerpc/kvm/book3s.c
> +++ b/arch/powerpc/kvm/book3s.c
> @@ -799,6 +799,11 @@ int kvmppc_core_check_requests(struct kvm_vcpu *vcpu)
> return vcpu->kvm->arch.kvm_ops->check_requests(vcpu);
> }
>
> +void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot
> *memslot)
Since at it, maybe we can start to use __weak attribute for new hooks
especially when it's empty for most archs?
E.g., define:
void __weak kvm_arch_sync_dirty_log(...) {}
In the common code, then only define it again in arch that has
non-empty implementation of this method?
--
Peter Xu
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
