Sean Christopherson <seanjc@xxxxxxxxxx> writes: > On Thu, Apr 07, 2022, Vitaly Kuznetsov wrote: >> Handle Direct TLB flush requests from L2 by going through all vCPUs > > What is a "Direct TLB flush request" in this context? I can't tell if "direct" > refers to the MMU being direct, or if it has some other Hyper-V specific meaning. > > Ewww, it looks to be Hyper-V terminology. Now I see that @direct=true is getting > L2's ring, not L1's ring. That's all kinds of evil. That confusion goes away with > my suggestion below, but this shortlog and changelog (and the ones for nVMX and > nSVM enabling) absolutely need to clarify "direct" since it conflicts mightily > with KVM's "direct" terminology. > > In fact, unless I'm missing a patch where "Direct" doesn't mean "From L2", I vote > to not use the "Direct TLB flush" terminology in any of the shortlogs or changelogs > and only add a footnote to this first changelog to call out that the TLFS (or > wherever this terminology came from) calls these types of flushes > "Direct". In soon-to-be-sent-out v3 I got rid of 'Direct TLB flush' completely. Note, in addition to what gets introduced in this series, there are two other Hyper-V specific places which overload 'direct' already: - Direct TLB flush for KVM-on-Hyper-V (enable_direct_tlbflush()). I'm getting rid of it too. - Direct synthetic timers. 'Direct' in this case means that the timer signal is delivered via dedicated IRQ 'directly' and not through Vmbus message. This stays as I can't think of how we can rename it (and if we should, in the first place). -- Vitaly
