From: Manali Shukla <manali.shukla@amd.com>
To: Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kselftest@vger.kernel.org,
shuah@kernel.org, nikunj@amd.com, thomas.lendacky@amd.com,
vkuznets@redhat.com, bp@alien8.de, ajones@ventanamicro.com,
manali.shukla@amd.com
Subject: Re: [PATCH v3 0/5] Add support for the Idle HLT intercept feature
Date: Tue, 4 Jun 2024 18:51:08 +0530 [thread overview]
Message-ID: <fb7aeac0-ea8c-40f0-969a-c21020b823be@amd.com> (raw)
In-Reply-To: <Zl5kNh8znAYHHYuC@google.com>
On 6/4/2024 6:17 AM, Sean Christopherson wrote:
> On Tue, May 28, 2024, Paolo Bonzini wrote:
>> On Tue, May 28, 2024 at 6:19 AM Manali Shukla <manali.shukla@amd.com> wrote:
>>>
>>> The upcoming new Idle HLT Intercept feature allows for the HLT
>>> instruction execution by a vCPU to be intercepted by the hypervisor
>>> only if there are no pending V_INTR and V_NMI events for the vCPU.
>>> When the vCPU is expected to service the pending V_INTR and V_NMI
>>> events, the Idle HLT intercept won’t trigger. The feature allows the
>>> hypervisor to determine if the vCPU is actually idle and reduces
>>> wasteful VMEXITs.
>>
>> Does this have an effect on the number of vmexits for KVM, unless AVIC
>> is enabled? Can you write a testcase for kvm-unit-tests' vmexit.flat
>> that shows an improvement?
>>
>> The reason I am wondering is because KVM does not really use V_INTR
>> injection. The "idle HLT" intercept basically differs from the basic
>> HLT trigger only in how it handles an STI;HLT sequence, as in that
>> case the interrupt can be injected directly and the HLT vmexit is
>> suppressed. But in that circumstance KVM would anyway use a V_INTR
>> intercept to detect the opening of the interrupt injection window (and
>> then the interrupt uses event injection rather than V_INTR). Again,
>> this is only true if AVIC is disabled, but that is the default.
>>
>> So unless I'm wrong in my analysis above, I'm not sure this series,
>> albeit small, is really worth it.
>
> But aren't we hoping to enable x2AVIC by default sooner than later?
The idle halt intercept feature not only suppresses HLT exit when a V_INTR
event is pending during the execution of halt instruction, but it also
suppresses HLT exit when a V_NMI event is pending during the execution of
halt instruction. This capability will be advantageous in IBS virtualization
and PMC virtualization functionalities, as both rely on VNMI for delivering
virtualized interrupts from IBS and PMC hardware.
>
>> As things stand, it would be more interesting to enable this for nested VMs,
>> especially Hyper-V which does use V_INTR and V_TPL; even better, _emulating_
>> it on older processors would reduce the L2->L0->L1->L0->L2 path to a
>> less-expensive L2->L0->L2 vmexit.
next prev parent reply other threads:[~2024-06-04 13:21 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-28 4:19 [PATCH v3 0/5] Add support for the Idle HLT intercept feature Manali Shukla
2024-05-28 4:19 ` [PATCH v3 1/5] x86/cpufeatures: Add CPUID feature bit for Idle HLT intercept Manali Shukla
2024-05-28 7:42 ` Borislav Petkov
2024-05-28 4:19 ` [PATCH v3 2/5] KVM: SVM: Add Idle HLT intercept support Manali Shukla
2024-05-28 4:19 ` [PATCH v3 3/5] KVM: selftests: Add safe_halt() and cli() helpers to common code Manali Shukla
2024-05-28 4:19 ` [PATCH v3 4/5] KVM: selftests: Add an interface to read the data of named vcpu stat Manali Shukla
2024-08-13 16:37 ` Sean Christopherson
2024-10-22 5:49 ` Manali Shukla
2024-05-28 4:19 ` [PATCH v3 5/5] KVM: selftests: KVM: SVM: Add Idle HLT intercept test Manali Shukla
2024-05-28 7:46 ` Chao Gao
2024-05-30 13:19 ` Manali Shukla
2024-05-31 6:49 ` Chao Gao
2024-06-19 17:09 ` Manali Shukla
2024-08-13 15:38 ` Sean Christopherson
2024-08-13 16:03 ` Sean Christopherson
2024-05-28 10:22 ` [PATCH v3 0/5] Add support for the Idle HLT intercept feature Paolo Bonzini
2024-06-04 0:47 ` Sean Christopherson
2024-06-04 13:21 ` Manali Shukla [this message]
2024-06-04 12:23 ` Manali Shukla
2024-08-13 16:19 ` Sean Christopherson
2024-10-22 10:35 ` Manali Shukla
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=fb7aeac0-ea8c-40f0-969a-c21020b823be@amd.com \
--to=manali.shukla@amd.com \
--cc=ajones@ventanamicro.com \
--cc=bp@alien8.de \
--cc=kvm@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=shuah@kernel.org \
--cc=thomas.lendacky@amd.com \
--cc=vkuznets@redhat.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