public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Vasant Hegde <vashegde@amd.com>
To: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>, kvm@vger.kernel.org
Cc: seanjc@google.com, pbonzini@redhat.com,
	linux-kernel@vger.kernel.org, joao.m.martins@oracle.com,
	boris.ostrovsky@oracle.com, mark.kanda@oracle.com,
	suravee.suthikulpanit@amd.com, mlevitsk@redhat.com
Subject: Re: [RFC 0/3] Export APICv-related state via binary stats interface
Date: Tue, 9 Apr 2024 10:39:52 +0530	[thread overview]
Message-ID: <19f634de-7d72-4abc-87ff-599d22e310bd@amd.com> (raw)
In-Reply-To: <20240215160136.1256084-1-alejandro.j.jimenez@oracle.com>

Hi Alejadnro,

On 2/15/2024 9:31 PM, Alejandro Jimenez wrote:
> The goal of this RFC is to agree on a mechanism for querying the state (and
> related stats) of APICv/AVIC. I clearly have an AVIC bias when approaching this
> topic since that is the side that I have mostly looked at, and has the greater
> number of possible inhibits, but I believe the argument applies for both
> vendor's technologies.
> 
> Currently, a user or monitoring app trying to determine if APICv is actually
> being used needs implementation-specific knowlegde in order to look for specific
> types of #VMEXIT (i.e. AVIC_INCOMPLETE_IPI/AVIC_NOACCEL), checking GALog events
> by watching /proc/interrupts for AMD-Vi*-GA, etc. There are existing tracepoints
> (e.g. kvm_apicv_accept_irq, kvm_avic_ga_log) that make this task easier, but
> tracefs is not viable in some scenarios. Adding kvm debugfs entries has similar
> downsides. Suravee has previously proposed a new IOCTL interface[0] to expose
> this information, but there has not been any development in that direction.
> Sean has mentioned a preference for using BPF to extract info from the current
> tracepoints, which would require reworking existing structs to access some
> desired data, but as far as I know there isn't any work done on that approach
> yet.
> 
> Recently Joao mentioned another alternative: the binary stats framework that is
> already supported by kernel[1] and QEMU[2]. This RFC has minimal code changes to
> expose the relevant info based on the existing data types the framework already
> supports. If there is consensus on using this approach, I can expand the fd
> stats subsystem to include other data types (e.g. a bitmap type for exposing the
> inhibit reasons), as well as adding documentation on KVM explaining which stats
> are relevant for APICv and how to query them.

Thanks for the series. IMO this approach makes sense. May be we should 
consider adding one more stat to say whether AVIC is active or not. That 
way,
  Check whether AVIC is active or not.
  If AVIC is active, then inhibited or not
  If not inhibited, then use other statistics info.


I have reviewed/tested this series on AMD Genoa platform. It looks good 
to me.

Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>

-Vasant

> 
> A basic example of retrieving the stats via qmp-shell, showing both a VM and
> per-vCPU case:
> 
> # /usr/local/bin/qmp-shell --pretty ./qmp-sock
> 
> (QEMU) query-stats target=vm providers=[{'provider':'kvm','names':['apicv_inhibited']}]
> {
>      "return": [
>          {
>              "provider": "kvm",
>              "stats": [
>                  {
>                      "name": "apicv_inhibited",
>                      "value": false
>                  }
>              ]
>          }
>      ]
> }
> 
> (QEMU) query-stats target=vcpu vcpus=['/machine/unattached/device[0]'] providers=[{'provider':'kvm','names':['apicv_accept_irq','ga_log_event']}]
> {
>      "return": [
>          {
>              "provider": "kvm",
>              "qom-path": "/machine/unattached/device[0]",
>              "stats": [
>                  {
>                      "name": "ga_log_event",
>                      "value": 98
>                  },
>                  {
>                      "name": "apicv_accept_irq",
>                      "value": 166920
>                  }
>              ]
>          }
>      ]
> }
> 
> If other alternatives are preferred, please let's use this thread to discuss and
> I can take a shot at implementing the desired solution.
> 
> Regards,
> Alejandro
> 
> [0] https://lore.kernel.org/qemu-devel/7e0d22fa-b9b0-ad1a-3a37-a450ec5d73e8@amd.com/
> [1] https://lore.kernel.org/all/20210618222709.1858088-1-jingzhangos@google.com/
> [2] https://lore.kernel.org/qemu-devel/20220530150714.756954-1-pbonzini@redhat.com/
> 
> Alejandro Jimenez (3):
>    x86: KVM: stats: Add a stat to report status of APICv inhibition
>    x86: KVM: stats: Add stat counter for IRQs injected via APICv
>    x86: KVM: stats: Add a stat counter for GALog events
> 
>   arch/x86/include/asm/kvm_host.h |  3 +++
>   arch/x86/kvm/svm/avic.c         |  4 +++-
>   arch/x86/kvm/svm/svm.c          |  3 +++
>   arch/x86/kvm/vmx/vmx.c          |  2 ++
>   arch/x86/kvm/x86.c              | 12 +++++++++++-
>   5 files changed, 22 insertions(+), 2 deletions(-)
> 
> 
> base-commit: 7455665a3521aa7b56245c0a2810f748adc5fdd4


  parent reply	other threads:[~2024-04-09  5:10 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15 16:01 [RFC 0/3] Export APICv-related state via binary stats interface Alejandro Jimenez
2024-02-15 16:01 ` [RFC 1/3] x86: KVM: stats: Add a stat to report status of APICv inhibition Alejandro Jimenez
2024-04-09 14:54   ` Suthikulpanit, Suravee
2024-04-16 18:19   ` Sean Christopherson
2024-04-16 19:53     ` Paolo Bonzini
2024-04-16 19:59     ` Alejandro Jimenez
2024-02-15 16:01 ` [RFC 2/3] x86: KVM: stats: Add stat counter for IRQs injected via APICv Alejandro Jimenez
2024-02-15 16:16   ` Dongli Zhang
2024-02-15 18:12     ` Alejandro Jimenez
2024-04-16 18:25       ` Sean Christopherson
2024-02-15 16:01 ` [RFC 3/3] x86: KVM: stats: Add a stat counter for GALog events Alejandro Jimenez
2024-04-09  6:45   ` Chao Gao
2024-04-10  1:31     ` Alejandro Jimenez
2024-04-12 10:45       ` Chao Gao
2024-04-16 18:35         ` Sean Christopherson
2024-04-24  0:50           ` Alejandro Jimenez
2024-04-09  5:09 ` Vasant Hegde [this message]
2024-04-10  1:36   ` [RFC 0/3] Export APICv-related state via binary stats interface Alejandro Jimenez
2024-04-16 18:08 ` Sean Christopherson
2024-04-16 19:51   ` Paolo Bonzini
2024-04-16 21:29     ` Alejandro Jimenez
2024-04-16 21:36       ` Paolo Bonzini
2024-04-16 22:34     ` Sean Christopherson
2024-04-17  9:48       ` Paolo Bonzini
2024-04-23 20:43         ` Alejandro Jimenez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19f634de-7d72-4abc-87ff-599d22e310bd@amd.com \
    --to=vashegde@amd.com \
    --cc=alejandro.j.jimenez@oracle.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=joao.m.martins@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.kanda@oracle.com \
    --cc=mlevitsk@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=suravee.suthikulpanit@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox