All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Suthikulpanit, Suravee" <Suravee.Suthikulpanit@amd.com>
To: "Jan H. Schönherr" <jschoenh@amazon.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Cc: "joro@8bytes.org" <joro@8bytes.org>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"rkrcmar@redhat.com" <rkrcmar@redhat.com>
Subject: Re: [PATCH 6/6] svm: Temporary deactivate AVIC during ExtINT handling
Date: Mon, 3 Jun 2019 18:58:33 +0000	[thread overview]
Message-ID: <5f86b2ac-3a62-ab3d-ea00-59f1aaafa3f1@amd.com> (raw)
In-Reply-To: <a31f3f85-d94c-b139-ec69-d148dae5c67f@amazon.de>

Hi Jan,

On 5/8/19 12:37 PM, Jan H. Schönherr wrote:
> [CAUTION: External Email]
> 
> Hi Suravee.
> 
> I wonder, how this interacts with Hyper-V SynIC; see comments below.
> 
> On 22/03/2019 12.57, Suthikulpanit, Suravee wrote:
>> AMD AVIC does not support ExtINT. Therefore, AVIC must be temporary
>> deactivated and fall back to using legacy interrupt injection via
>> vINTR and interrupt window.
>>
>> Introduce svm_request_activate/deactivate_avic() helper functions,
>> which handle steps required to activate/deactivate AVIC.
>>
>> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>> ---
>>   arch/x86/kvm/svm.c | 57 +++++++++++++++++++++++++++++++++++++++++++---
>>   1 file changed, 54 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
>> index f41f34f70dde..84116e689d5f 100644
>> --- a/arch/x86/kvm/svm.c
>> +++ b/arch/x86/kvm/svm.c
>> @@ -391,6 +391,8 @@ static u8 rsm_ins_bytes[] = "\x0f\xaa";
>>   static void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0);
>>   static void svm_flush_tlb(struct kvm_vcpu *vcpu, bool invalidate_gpa);
>>   static void svm_complete_interrupts(struct vcpu_svm *svm);
>> +static void svm_request_activate_avic(struct kvm_vcpu *vcpu);
>> +static bool svm_get_enable_apicv(struct kvm_vcpu *vcpu);
>>
>>   static int nested_svm_exit_handled(struct vcpu_svm *svm);
>>   static int nested_svm_intercept(struct vcpu_svm *svm);
>> @@ -2109,6 +2111,9 @@ static void avic_set_running(struct kvm_vcpu *vcpu, bool is_run)
>>   {
>>        struct vcpu_svm *svm = to_svm(vcpu);
>>
>> +     if (!kvm_vcpu_apicv_active(vcpu))
>> +             return;
>> +
>>        svm->avic_is_running = is_run;
>>        if (is_run)
>>                avic_vcpu_load(vcpu, vcpu->cpu);
>> @@ -2356,6 +2361,10 @@ static void svm_vcpu_blocking(struct kvm_vcpu *vcpu)
>>
>>   static void svm_vcpu_unblocking(struct kvm_vcpu *vcpu)
>>   {
>> +     if (kvm_check_request(KVM_REQ_APICV_ACTIVATE, vcpu))
>> +             kvm_vcpu_activate_apicv(vcpu);
>> +     if (kvm_check_request(KVM_REQ_APICV_DEACTIVATE, vcpu))
>> +             kvm_vcpu_deactivate_apicv(vcpu);
>>        avic_set_running(vcpu, true);
>>   }
>>
>> @@ -4505,6 +4514,15 @@ static int interrupt_window_interception(struct vcpu_svm *svm)
>>   {
>>        kvm_make_request(KVM_REQ_EVENT, &svm->vcpu);
>>        svm_clear_vintr(svm);
>> +
>> +     /*
>> +      * For AVIC, the only reason to end up here is ExtINTs.
>> +      * In this case AVIC was temporarily disabled for
>> +      * requesting the IRQ window and we have to re-enable it.
>> +      */
>> +     if (svm_get_enable_apicv(&svm->vcpu))
>> +             svm_request_activate_avic(&svm->vcpu);
>> +
> 
> Are we sure, we're not accidentally re-enabling AVIC, if it was disabled via
> kvm_hv_activate_synic()?

Actually, I missed this case. Now I have a solution that I'll be send out for review in V2.

>>        svm->vmcb->control.int_ctl &= ~V_IRQ_MASK;
>>        mark_dirty(svm->vmcb, VMCB_INTR);
>>        ++svm->vcpu.stat.irq_window_exits;
>> @@ -5206,6 +5224,34 @@ static void svm_hwapic_isr_update(struct kvm_vcpu *vcpu, int max_isr)
>>   {
>>   }
>>
>> +static bool is_avic_active(struct vcpu_svm *svm)
>> +{
>> +     return (svm_get_enable_apicv(&svm->vcpu) &&
>> +             svm->vmcb->control.int_ctl & AVIC_ENABLE_MASK);
>> +}
>> +
>> +static void svm_request_activate_avic(struct kvm_vcpu *vcpu)
>> +{
>> +     struct vcpu_svm *svm = to_svm(vcpu);
>> +
>> +     if (!lapic_in_kernel(vcpu) || is_avic_active(svm))
>> +             return;
>> +
>> +     avic_setup_access_page(vcpu, false);
>> +     kvm_make_apicv_activate_request(vcpu->kvm);
>> +}
>> +
>> +static void svm_request_deactivate_avic(struct kvm_vcpu *vcpu)
>> +{
>> +     struct vcpu_svm *svm = to_svm(vcpu);
>> +
>> +     if (!lapic_in_kernel(vcpu) || !is_avic_active(svm))
>> +             return;
>> +
>> +     avic_destroy_access_page(vcpu);
> 
> Something like avic_destroy_access_page() is not called, when AVIC is
> disabled via kvm_hv_activate_synic().
> 
> Is that an oversight in the other code path, is it not needed here,
> or am I missing something?

This is an oversight. I also have a fix for this in V2.

Thanks,
Suravee

  reply	other threads:[~2019-06-03 18:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-22 11:57 [PATCH 0/6] KVM/x86: Add workaround to support ExtINT with AVIC Suthikulpanit, Suravee
2019-03-22 11:57 ` [PATCH 1/6] KVM: x86: Add callback functions for handling APIC ID, DFR and LDR update Suthikulpanit, Suravee
2019-07-03 21:16   ` Paolo Bonzini
2019-07-17 19:44     ` Suthikulpanit, Suravee
2019-03-22 11:57 ` [PATCH 2/6] svm: Add AMD AVIC handlers for " Suthikulpanit, Suravee
2019-03-22 11:57 ` [PATCH 3/6] svm: Add support for APIC_ACCESS_PAGE_PRIVATE_MEMSLOT setup/destroy Suthikulpanit, Suravee
2019-05-08 19:14   ` Jan H. Schönherr
2019-06-30 16:19     ` Suthikulpanit, Suravee
2019-03-22 11:57 ` [PATCH 4/6] kvm: lapic: Add apicv activate/deactivate helper function Suthikulpanit, Suravee
2019-05-08 22:27   ` Jan H. Schönherr
2019-07-15 22:35     ` Suthikulpanit, Suravee
2019-03-22 11:57 ` [PATCH 5/6] KVM: x86: Add interface for run-time activate/de-activate APIC virtualization Suthikulpanit, Suravee
2019-05-08 20:45   ` Jan H. Schönherr
2019-03-22 11:57 ` [PATCH 6/6] svm: Temporary deactivate AVIC during ExtINT handling Suthikulpanit, Suravee
2019-05-08 17:37   ` Jan H. Schönherr
2019-06-03 18:58     ` Suthikulpanit, Suravee [this message]
2019-04-04 21:30 ` [PATCH 0/6] KVM/x86: Add workaround to support ExtINT with AVIC rkrcmar
2019-04-04 22:06 ` rkrcmar

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=5f86b2ac-3a62-ab3d-ea00-59f1aaafa3f1@amd.com \
    --to=suravee.suthikulpanit@amd.com \
    --cc=joro@8bytes.org \
    --cc=jschoenh@amazon.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.