mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
To: Vasant Hegde <vashegde@amd.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 21:36:19 -0400	[thread overview]
Message-ID: <11081a6a-b61e-4b10-9792-55c8731c2897@oracle.com> (raw)
In-Reply-To: <19f634de-7d72-4abc-87ff-599d22e310bd@amd.com>



On 4/9/24 01:09, Vasant Hegde wrote:
> 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.

Hi Vasant,

Thank you for reviewing/testing. I'll implement your suggestion and send it on the next revision.

Alejandro

> 
> 
> 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
> 
> 

  reply	other threads:[~2024-04-10  1:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15 16:01 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 ` [RFC 0/3] Export APICv-related state via binary stats interface Vasant Hegde
2024-04-10  1:36   ` Alejandro Jimenez [this message]
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=11081a6a-b61e-4b10-9792-55c8731c2897@oracle.com \
    --to=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 \
    --cc=vashegde@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

all inboxes | Powered by JetHome®