From: Maxim Levitsky <mlevitsk@redhat.com>
To: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: pbonzini@redhat.com, seanjc@google.com, joro@8bytes.org,
jon.grimm@amd.com, wei.huang2@amd.com, terry.bowman@amd.com
Subject: Re: [PATCH v2 06/12] KVM: SVM: Do not support updating APIC ID when in x2APIC mode
Date: Mon, 18 Apr 2022 14:09:12 +0300 [thread overview]
Message-ID: <26b02f98e88b1097ce5823007a7bc06b25678252.camel@redhat.com> (raw)
In-Reply-To: <20220412115822.14351-7-suravee.suthikulpanit@amd.com>
On Tue, 2022-04-12 at 06:58 -0500, Suravee Suthikulpanit wrote:
> In X2APIC mode, the Logical Destination Register is read-only,
> which provides a fixed mapping between the logical and physical
> APIC IDs. Therefore, there is no Logical APIC ID table in X2AVIC
> and the processor uses the X2APIC ID in the backing page to create
> a vCPU’s logical ID.
>
> In addition, KVM does not support updating APIC ID in x2APIC mode,
> which means AVIC does not need to handle this case.
>
> Therefore, check x2APIC mode when handling physical and logical
> APIC ID update, and when invalidating logical APIC ID table.
>
> Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> ---
> arch/x86/kvm/svm/avic.c | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
> index 609dcbe52a86..22ee1098e2a5 100644
> --- a/arch/x86/kvm/svm/avic.c
> +++ b/arch/x86/kvm/svm/avic.c
> @@ -424,8 +424,13 @@ static void avic_invalidate_logical_id_entry(struct kvm_vcpu *vcpu)
> {
> struct vcpu_svm *svm = to_svm(vcpu);
> bool flat = svm->dfr_reg == APIC_DFR_FLAT;
> - u32 *entry = avic_get_logical_id_entry(vcpu, svm->ldr_reg, flat);
> + u32 *entry;
>
> + /* Note: x2AVIC does not use logical APIC ID table */
> + if (apic_x2apic_mode(vcpu->arch.apic))
> + return;
> +
> + entry = avic_get_logical_id_entry(vcpu, svm->ldr_reg, flat);
> if (entry)
> clear_bit(AVIC_LOGICAL_ID_ENTRY_VALID_BIT, (unsigned long *)entry);
> }
> @@ -437,6 +442,10 @@ static int avic_handle_ldr_update(struct kvm_vcpu *vcpu)
> u32 ldr = kvm_lapic_get_reg(vcpu->arch.apic, APIC_LDR);
> u32 id = kvm_xapic_id(vcpu->arch.apic);
>
> + /* AVIC does not support LDR update for x2APIC */
> + if (apic_x2apic_mode(vcpu->arch.apic))
> + return 0;
> +
> if (ldr == svm->ldr_reg)
> return 0;
>
> @@ -457,6 +466,14 @@ static int avic_handle_apic_id_update(struct kvm_vcpu *vcpu)
> struct vcpu_svm *svm = to_svm(vcpu);
> u32 id = kvm_xapic_id(vcpu->arch.apic);
>
> + /*
> + * KVM does not support apic ID update for x2APIC.
> + * Also, need to check if the APIC ID exceed 254.
> + */
> + if (apic_x2apic_mode(vcpu->arch.apic) ||
> + (vcpu->vcpu_id >= APIC_BROADCAST))
> + return 0;
> +
> if (vcpu->vcpu_id == id)
> return 0;
>
Honestly I won't even bother with this - avic_handle_apic_id_update
zeros the initial apic id entry, after it moves it contents to new location.
If it is called again (and it will be called next time there is avic inhibition),
it will just fail as the initial entry will be zero, or copy wrong entry
if something else was written there meanwhile.
That code just needs to be removed, and AVIC be conditional on read-only apic id.
But overall this patch doesn't make things worse, so
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Best regards,
Maxim Levitsky
next prev parent reply other threads:[~2022-04-18 11:09 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-12 11:58 [PATCH v2 00/12] Introducing AMD x2APIC Virtualization (x2AVIC) support Suravee Suthikulpanit
2022-04-12 11:58 ` [PATCH v2 01/12] x86/cpufeatures: Introduce x2AVIC CPUID bit Suravee Suthikulpanit
2022-04-12 11:58 ` [PATCH v2 02/12] KVM: x86: lapic: Rename [GET/SET]_APIC_DEST_FIELD to [GET/SET]_XAPIC_DEST_FIELD Suravee Suthikulpanit
2022-04-12 11:58 ` [PATCH v2 03/12] KVM: SVM: Detect X2APIC virtualization (x2AVIC) support Suravee Suthikulpanit
2022-04-12 11:58 ` [PATCH v2 04/12] KVM: SVM: Update max number of vCPUs supported for x2AVIC mode Suravee Suthikulpanit
2022-04-12 11:58 ` [PATCH v2 05/12] KVM: SVM: Update avic_kick_target_vcpus to support 32-bit APIC ID Suravee Suthikulpanit
2022-04-12 11:58 ` [PATCH v2 06/12] KVM: SVM: Do not support updating APIC ID when in x2APIC mode Suravee Suthikulpanit
2022-04-18 11:09 ` Maxim Levitsky [this message]
2022-04-12 11:58 ` [PATCH v2 07/12] KVM: SVM: Adding support for configuring x2APIC MSRs interception Suravee Suthikulpanit
2022-04-18 11:17 ` Maxim Levitsky
2022-04-12 11:58 ` [PATCH v2 08/12] KVM: SVM: Update AVIC settings when changing APIC mode Suravee Suthikulpanit
2022-04-18 12:55 ` Maxim Levitsky
2022-05-02 14:07 ` Suravee Suthikulpanit
2022-05-02 17:13 ` Maxim Levitsky
2022-05-03 13:04 ` Suravee Suthikulpanit
2022-05-04 11:46 ` Maxim Levitsky
2022-05-04 11:49 ` Maxim Levitsky
2022-05-04 12:38 ` Maxim Levitsky
2022-04-12 11:58 ` [PATCH v2 09/12] KVM: SVM: Introduce helper functions to (de)activate AVIC and x2AVIC Suravee Suthikulpanit
2022-04-12 11:58 ` [PATCH v2 10/12] KVM: SVM: Do not throw warning when calling avic_vcpu_load on a running vcpu Suravee Suthikulpanit
2022-04-12 11:58 ` [PATCH v2 11/12] KVM: SVM: Do not inhibit APICv when x2APIC is present Suravee Suthikulpanit
2022-04-19 13:29 ` Maxim Levitsky
2022-04-26 2:25 ` Suravee Suthikulpanit
2022-04-26 7:06 ` Maxim Levitsky
2022-04-26 9:56 ` Maxim Levitsky
2022-04-29 17:00 ` Sean Christopherson
2022-05-01 6:49 ` Maxim Levitsky
2022-04-12 11:58 ` [PATCH v2 12/12] kvm/x86: Remove APICV activate mode inconsistency check Suravee Suthikulpanit
2022-04-18 12:55 ` Maxim Levitsky
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=26b02f98e88b1097ce5823007a7bc06b25678252.camel@redhat.com \
--to=mlevitsk@redhat.com \
--cc=jon.grimm@amd.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=terry.bowman@amd.com \
--cc=wei.huang2@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;
as well as URLs for NNTP newsgroup(s).