All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	 Maxim Levitsky <mlevitsk@redhat.com>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Subject: Re: [PATCH v2 03/10] KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC)
Date: Thu, 22 Aug 2024 16:10:36 -0700	[thread overview]
Message-ID: <ZsfFbMpVm9qWRVz5@google.com> (raw)
In-Reply-To: <cc9b9df6-583a-d185-0c32-6d26d0717548@amd.com>

On Thu, Aug 22, 2024, Tom Lendacky wrote:
> On 8/22/24 14:41, Sean Christopherson wrote:
> > On Thu, Aug 22, 2024, Tom Lendacky wrote:
> >> On 8/22/24 13:44, Sean Christopherson wrote:
> >>> +Tom
> >>>
> >>> Can someone from AMD confirm that this is indeed the behavior, and that for AMD
> >>> CPUs, it's the architectural behavior?
> >>
> >> In section "16.11 Accessing x2APIC Register" of APM Vol 2, there is this
> >> statement:
> >>
> >> "For 64-bit x2APIC registers, the high-order bits (bits 63:32) are
> >> mapped to EDX[31:0]"
> >>
> >> and in section "16.11.1 x2APIC Register Address Space" of APM Vol 2,
> >> there is this statement:
> >>
> >> "The two 32-bit Interrupt Command Registers in APIC mode (MMIO offsets
> >> 300h and 310h) are merged into a single 64-bit x2APIC register at MSR
> >> address 830h."
> >>
> >> So I believe this isn't necessary. @Suravee, agree?
> >>
> >> Are you seeing a bug related to this?
> > 
> > Yep.  With APICv and x2APIC enabled, Intel CPUs use a single 64-bit value at
> > offset 300h for the backing storage.  This is what KVM currently implements,
> > e.g. when pulling state out of the vAPIC page for migration, and when emulating
> > a RDMSR(ICR).
> > 
> > With AVIC and x2APIC (a.k.a. x2AVIC enabled), Genoa uses the legacy MMIO offsets
> > for storage, at least AFAICT.  I.e. the single MSR at 830h is split into separate
> > 32-bit values at 300h and 310h on WRMSR, and then reconstituted on RDMSR.
> > 
> > The APM doesn't actually clarify the layout of the backing storage, i.e. doesn't
> > explicitly say that the full 64-bit value is stored at 300h.  IIRC, Intel's SDM
> 
> Ah, for x2AVIC, yes, you have to do two writes to the backing page. One
> at offset 0x300 and one at offset 0x310 (confirmed with the hardware
> team). The order shouldn't matter since the guest vCPU isn't running
> when you're writing the values, but you should do the IRC High write
> first, followed by the ICR Low.

Thanks Tom!

  reply	other threads:[~2024-08-22 23:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-19 23:50 [PATCH v2 00/10] KVM: x86: Fix ICR handling when x2AVIC is active Sean Christopherson
2024-07-19 23:50 ` [PATCH v2 01/10] KVM: x86: Enforce x2APIC's must-be-zero reserved ICR bits Sean Christopherson
2024-11-01 18:34   ` Sean Christopherson
2024-07-19 23:50 ` [PATCH v2 02/10] KVM: x86: Move x2APIC ICR helper above kvm_apic_write_nodecode() Sean Christopherson
2024-07-19 23:51 ` [PATCH v2 03/10] KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC) Sean Christopherson
2024-08-22 18:44   ` Sean Christopherson
2024-08-22 19:16     ` Tom Lendacky
2024-08-22 19:41       ` Sean Christopherson
2024-08-22 20:29         ` Tom Lendacky
2024-08-22 23:10           ` Sean Christopherson [this message]
2024-07-19 23:51 ` [PATCH v2 04/10] KVM: selftests: Open code vcpu_run() equivalent in guest_printf test Sean Christopherson
2024-07-19 23:51 ` [PATCH v2 05/10] KVM: selftests: Report unhandled exceptions on x86 as regular guest asserts Sean Christopherson
2024-07-19 23:51 ` [PATCH v2 06/10] KVM: selftests: Add x86 helpers to play nice with x2APIC MSR #GPs Sean Christopherson
2024-07-19 23:51 ` [PATCH v2 07/10] KVM: selftests: Skip ICR.BUSY test in xapic_state_test if x2APIC is enabled Sean Christopherson
2024-07-19 23:51 ` [PATCH v2 08/10] KVM: selftests: Test x2APIC ICR reserved bits Sean Christopherson
2024-07-19 23:51 ` [PATCH v2 09/10] KVM: selftests: Verify the guest can read back the x2APIC ICR it wrote Sean Christopherson
2024-07-19 23:51 ` [PATCH v2 10/10] KVM: selftests: Play nice with AMD's AVIC errata Sean Christopherson
2024-08-31  0:20 ` [PATCH v2 00/10] KVM: x86: Fix ICR handling when x2AVIC is active Sean Christopherson

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=ZsfFbMpVm9qWRVz5@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlevitsk@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=thomas.lendacky@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 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.