Messages in this thread | | | Date | Wed, 16 Aug 2023 15:55:32 +0800 | Subject | Re: [PATCH v2 4/8] KVM: x86: Add X86EMUL_F_INVTLB and pass it in em_invlpg() | From | Binbin Wu <> |
| |
On 8/16/2023 7:11 AM, Sean Christopherson wrote: > On Wed, Jul 19, 2023, Zeng Guang wrote: >> From: Binbin Wu <binbin.wu@linux.intel.com> >> >> Add an emulation flag X86EMUL_F_INVTLB, which is used to identify an >> instruction that does TLB invalidation without true memory access. >> >> Only invlpg & invlpga implemented in emulator belong to this kind. >> invlpga doesn't need additional information for emulation. Just pass >> the flag to em_invlpg(). > Please add a paragraph explaining *why* this flag is being added. Ideally, the > previous patch would also explain the need for an IMPLICIT flag, but that one > doesn't bug me all that much because implicit accesses are known to be special > snowflakes, i.e. it's easy to imagine that KVM would need to identify such > accesses. But for INVLPG, without already knowing the details of LASS (or LAM), > it's harder to think of why it needs to exist. OK, will add the reason for this case and for IMPLICIT as well. Thanks.
> >> Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com> >> Signed-off-by: Zeng Guang <guang.zeng@intel.com> >> --- >> arch/x86/kvm/emulate.c | 4 +++- >> arch/x86/kvm/kvm_emulate.h | 1 + >> 2 files changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c >> index 8e706d19ae45..9b4b3ce6d52a 100644 >> --- a/arch/x86/kvm/emulate.c >> +++ b/arch/x86/kvm/emulate.c >> @@ -3443,8 +3443,10 @@ static int em_invlpg(struct x86_emulate_ctxt *ctxt) >> { >> int rc; >> ulong linear; >> + unsigned max_size; > unsigned int Let me think why I use 'unsigned'... It's because the exist code uses 'unsigned'. I suppose it is considered bad practice? I will cleanup the exist code as well. Is it OK to cleanup it opportunistically inside this patch?
>> - rc = linearize(ctxt, ctxt->src.addr.mem, 1, false, &linear); >> + rc = __linearize(ctxt, ctxt->src.addr.mem, &max_size, 1, ctxt->mode, >> + &linear, X86EMUL_F_INVTLB); > Align indentation: Will update it.
> > rc = __linearize(ctxt, ctxt->src.addr.mem, &max_size, 1, ctxt->mode, > &linear, X86EMUL_F_INVTLB); > >> if (rc == X86EMUL_CONTINUE) >> ctxt->ops->invlpg(ctxt, linear); >> /* Disable writeback. */ >> diff --git a/arch/x86/kvm/kvm_emulate.h b/arch/x86/kvm/kvm_emulate.h >> index c0e48f4fa7c4..c944055091e1 100644 >> --- a/arch/x86/kvm/kvm_emulate.h >> +++ b/arch/x86/kvm/kvm_emulate.h >> @@ -93,6 +93,7 @@ struct x86_instruction_info { >> #define X86EMUL_F_FETCH BIT(1) >> #define X86EMUL_F_BRANCH BIT(2) >> #define X86EMUL_F_IMPLICIT BIT(3) >> +#define X86EMUL_F_INVTLB BIT(4) > Why F_INVTLB instead of X86EMUL_F_INVLPG? Ah, because LAM is ignored for the > linear address in the INVPCID and INVVPID descriptors. Hrm. > > I think my vote is to call this X86EMUL_F_INVLPG even though *in theory* it's not > strictly limited to INVLPG. Odds are good KVM's emulator will never support > INVPCID or INVVPID, One case is kvm_handle_invpcid() is in the common kvm x86 code. LAM doesn't apply to the address in descriptor of invpcid though, but I am not sure if there will be the need for SVM in the future. But for now, F_INVLPG is OK if you think F_INVTLB brings confusion.
> and IMO even though F_INVLPG would be somewhat of a misnomer, > it's much more intuitive even for INVPCID and INVVPID descriptors. F_INVTLB makes > me think more of the actual act of invalidating the TLB. > > I'm not dead set against INVTLB if someone really likes it, but I did scratch my > head for a second when I saw it.
| |