Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Zhao Liu <zhao1.liu@intel.com>
To: Anderson Nascimento <anderson@allelesecurity.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, pbonzini@redhat.com,
	mtosatti@redhat.com
Subject: Re: [PATCH v2 1/1] target/i386: Add support for KVM APERF/MPERF passthrough
Date: Thu, 23 Jul 2026 16:48:14 +0800	[thread overview]
Message-ID: <amHVTvcDeQXdrIbg@intel.com> (raw)
In-Reply-To: <20260602140348.774203-2-anderson@allelesecurity.com>

Hi Anderson,

> +    [FEAT_6_ECX] = {
> +        .type = CPUID_FEATURE_WORD,
> +        .feat_names = {
> +            "aperfmperf", NULL, NULL, NULL,
> +            NULL, NULL, NULL, NULL,
> +            NULL, NULL, NULL, NULL,
> +            NULL, NULL, NULL, NULL,
> +            NULL, NULL, NULL, NULL,
> +            NULL, NULL, NULL, NULL,
> +            NULL, NULL, NULL, NULL,
> +            NULL, NULL, NULL, NULL,
> +        },
> +        .cpuid = { .eax = 6, .reg = R_ECX, },
> +        .tcg_features = 0,
> +        .unmigratable_flags = CPUID_6_ECX_APERFMPERF,

Considerring APER/MPERF passthrough have many specific restrictions
(listed in KVM's api.rst, "7.13 KVM_CAP_X86_DISABLE_EXITS"), I think
we also need not to enable it by default for max/host CPUs:

.no_autoenable_flags = CPUID_6_ECX_APERFMPERF

This indicates that users must manually enable this feature, and it is
assumed that they are aware of its limitations and have implemented
appropriate policies (such as no preemption, vCPU affinity, no idle or
C state in the guest, etc.).

> +    },

...

>  /* CPUID[0x80000007].EDX flags: */
>  #define CPUID_APM_INVTSC       (1U << 8)
> diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
> index 9e352882c8..ca722ff9e9 100644
> --- a/target/i386/kvm/kvm.c
> +++ b/target/i386/kvm/kvm.c
> @@ -498,6 +498,8 @@ uint32_t kvm_arch_get_supported_cpuid(KVMState *s, uint32_t function,
>          }
>      } else if (function == 6 && reg == R_EAX) {
>          ret |= CPUID_6_EAX_ARAT; /* safe to allow because of emulated APIC */
> +    } else if (function == 6 && reg == R_ECX) {
> +        ret |= CPUID_6_ECX_APERFMPERF;

if we bind this feature to cpu-pm, then we should check enable_cpu_pm
before setting CPUID. Otherwise, if this CPUID is present but
cpu-pm=off, Guest may try to access related MSRs and triggers #GP.

        if (enable_cpu_pm) {
            int disable_exits = kvm_check_extension(s,
                                                    KVM_CAP_X86_DISABLE_EXITS);

            if (disable_exits & KVM_X86_DISABLE_EXITS_APERFMPERF) {
                ret |= CPUID_6_ECX_APERFMPERF;
            }
        }

But on the other hande, maybe we don't need to bind this feature to
cpu-pm?

For example, a compute-intensive workload doesn't allow the Guest to
enter idle, then it still seems make sense to estimate performance
using aperf and mperf?

Thanks,
Zhao


      parent reply	other threads:[~2026-07-23  8:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-02 14:03 [PATCH v2 0/1] target/i386: Add support for KVM APERF/MPERF passthrough Anderson Nascimento
2026-06-02 14:03 ` [PATCH v2 1/1] " Anderson Nascimento
2026-06-26  0:50   ` Anderson Nascimento
2026-07-15 15:59     ` Anderson Nascimento
2026-07-23  8:48   ` Zhao Liu [this message]

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=amHVTvcDeQXdrIbg@intel.com \
    --to=zhao1.liu@intel.com \
    --cc=anderson@allelesecurity.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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