Re: Determining whether LVT_CMCI is supported

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Apologies, completely lost this in my inbox.

On Mon, Oct 07, 2019 at 12:58:16PM -0700, Nadav Amit wrote:
> > On Oct 2, 2019, at 6:22 PM, Nadav Amit <nadav.amit@xxxxxxxxx> wrote:
> > 
> > Hello Sean,
> > 
> > Sorry for keep bothering you, but I am a bit stuck with fixing one
> > kvm-unit-tests that fails on Skylake bare-metal.
> > 
> > The reason for the failure is that I assumed that APIC_CMCI (MSR 0x82f)
> > support is reported in MSR_IA32_MCG_CAP[10].
> > 
> > However, on my machine, I get:  MSR_IA32_MCG_CAP (0x179) = 0x7000816
> > 
> > And although MSR_IA32_MCG_CAP[10] is clear, APIC_CMCI is still accessible.
> > 
> > Is there a way to determine whether LVT_CMCI is supported on a CPU?

Bits 23:16 of the APIC's version register (LVR, MMIO 0x30, MSR 0x803)
report the maximum number of LVT registers, minus 1.

  Max LVT Entry Shows the number of LVT entries minus 1. For the Pentium 4 and
  Intel Xeon processors (which have 6 LVT entries), the value returned in the Max
  LVT field is 5; for the P6 family processors (which have 5 LVT entries), the
  value returned is 4; for the Pentium processor (which has 4 LVT entries), the
  value returned is 3. For processors based on the Intel microarchitecture code
  name Nehalem (which has 7 LVT entries) and onward, the value returned is 6.

I haven't found anything in the SDM that states which LVT entries are 3rd,
4th, 5th, etc..., but based on kernel code, LVT_CMCI is the 7th, i.e.
exists if APIC_LVR[23:16] >= 6.

> Sean, anyone?
> 
> Otherwise, I would just disable this test on bare-metal, which might hide
> bugs.



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux