[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YHRvchkUSIeU8tRR@google.com>
Date: Mon, 12 Apr 2021 16:04:02 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: David Edmondson <david.edmondson@...cle.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Paolo Bonzini <pbonzini@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
Thomas Gleixner <tglx@...utronix.de>,
Joerg Roedel <joro@...tes.org>,
Wanpeng Li <wanpengli@...cent.com>,
Borislav Petkov <bp@...en8.de>,
Jim Mattson <jmattson@...gle.com>,
Ingo Molnar <mingo@...hat.com>,
Joao Martins <joao.m.martins@...cle.com>,
Aaron Lewis <aaronlewis@...gle.com>
Subject: Re: [PATCH 5/6] KVM: SVM: pass a proper reason in
kvm_emulate_instruction()
+Aaron
On Mon, Apr 12, 2021, David Edmondson wrote:
> From: Joao Martins <joao.m.martins@...cle.com>
>
> Declare various causes of emulation and use them as appropriate.
>
> Signed-off-by: Joao Martins <joao.m.martins@...cle.com>
> Signed-off-by: David Edmondson <david.edmondson@...cle.com>
> ---
> arch/x86/include/asm/kvm_host.h | 6 ++++++
> arch/x86/kvm/svm/avic.c | 3 ++-
> arch/x86/kvm/svm/svm.c | 26 +++++++++++++++-----------
> 3 files changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 79e9ca756742..e1284680cbdc 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -1535,6 +1535,12 @@ enum {
> EMULREASON_IO_COMPLETE,
> EMULREASON_UD,
> EMULREASON_PF,
> + EMULREASON_SVM_NOASSIST,
> + EMULREASON_SVM_RSM,
> + EMULREASON_SVM_RDPMC,
> + EMULREASON_SVM_CR,
> + EMULREASON_SVM_DR,
> + EMULREASON_SVM_AVIC_UNACCEL,
Passing these to userspace arguably makes them ABI, i.e. they need to go into
uapi/kvm.h somewhere. That said, I don't like passing arbitrary values for what
is effectively the VM-Exit reason. Why not simply pass the exit reason, assuming
we do indeed want to dump this info to userspace?
What is the intended end usage of this information? Actual emulation? Debug?
Logging?
Depending on what you're trying to do with the info, maybe there's a better
option. E.g. Aaron is working on a series that includes passing pass the code
stream (instruction bytes) to userspace on emulation failure, though I'm not
sure if he's planning on providing the VM-Exit reason.
Powered by blists - more mailing lists