Date: Wed, 14 Sep 2016 15:33:13 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Andriy Gapon <avg@FreeBSD.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, stable@FreeBSD.org Subject: Re: X2APIC support Message-ID: <20160914123313.GC2840@zxy.spb.ru> In-Reply-To: <763df55a-4b69-9f7a-1042-0f631a729881@FreeBSD.org> References: <20160913121133.GX34394@zxy.spb.ru> <71a1f864-66de-0010-5024-e8e985f422f4@FreeBSD.org> <20160913124239.GZ34394@zxy.spb.ru> <c6e1a647-344b-a6d7-9f48-65092533ed21@FreeBSD.org> <20160913142118.GA34394@zxy.spb.ru> <37f5cebc-3fa1-9e95-5123-f3d8daa3130a@FreeBSD.org> <20160913152240.GE38409@kib.kiev.ua> <cb35f671-95e7-820f-6a78-ee60612cc1ad@FreeBSD.org> <20160914113634.GF38409@kib.kiev.ua> <763df55a-4b69-9f7a-1042-0f631a729881@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 14, 2016 at 03:22:17PM +0300, Andriy Gapon wrote:
> On 14/09/2016 14:36, Konstantin Belousov wrote:
> > On Tue, Sep 13, 2016 at 06:52:19PM +0300, Andriy Gapon wrote:
> >> On 13/09/2016 18:22, Konstantin Belousov wrote:
> >>> Any access
> >>> to the LAPIC registers page in x2APIC mode faults.
> >>
> >> Is this a fact?
> >> I read the following in the specification:
> >>
> >> In x2APIC mode, the memory mapped interface is not available and any
> >> access to the MMIO interface will behave similar to that of a legacy xAPIC
> >> in globally disabled state.
> >>
> >> But I couldn't find what actually happens for the legacy xAPIC in globally
> >> disabled state. For AMD processors it is documented that if xAPIC is disabled
> >> then accessing the APIC memory range works the same as accessing the regular
> >> memory. That can be different for Intel processors, of course.
> >
> > Look at the native_lapic_init(), very beginning of the function. If
> > x2apic_mode is non-zero, lapic_map is cleared after DMAP page cache
> > attributes are changed.
>
> Right, but we are talking about the case where x2apic_mode *is zero* while the
> hardware in x2APIC mode.
>
> > Right now, if BIOS pass control to OS in x2APIC mode, thinks just work
> > because no LAPIC accesses are done until native_lapic_enable_x2apic() is
> > called. This just happens, I thought about more organized receipt of the
> > current LAPIC mode. Issue is that decision for LAPIC mode is performed
> > by madt enumerator which pref. should not read LAPIC config (too early).
> > And it is not clear at all, what to do if there is reason to use xAPIC,
> > as checked by madt_setup_local(), but we are in x2APIC mode already.
>
> Yes. As I mentioned earlier we should at least panic with an informative
> message. Maybe we could add some code to so something smarter later.
>
> > Anyway, returning to the original issue, I do not believe that the
> > hand-off on that machine occured in the x2APIC mode when X2APIC_OPT_OUT
> > is specified. Kernel would fault in that case.
>
> I think that it should be easy to check that if Slawa is still willing to try
> another diagnostic patch.
What combination of BIOS setting need?
> diff --git a/sys/x86/x86/local_apic.c b/sys/x86/x86/local_apic.c
> index 203e9d00e8acc..37ac03fb9d811 100644
> --- a/sys/x86/x86/local_apic.c
> +++ b/sys/x86/x86/local_apic.c
> @@ -429,6 +429,12 @@ native_lapic_init(vm_paddr_t addr)
> if (x2apic_mode) {
> native_lapic_enable_x2apic();
> lapic_map = NULL;
> + } else if ((cpu_feature2 & CPUID2_X2APIC) != 0) {
> + r = rdmsr(MSR_APICBASE);
> + printf("MSR_APICBASE = 0x%16jx\n", (uintmax_t)r);
> + if ((r & (APICBASE_X2APIC | APICBASE_ENABLED)) ==
> + (APICBASE_X2APIC | APICBASE_ENABLED))
> + printf("x2APIC is prohibited but turned on by BIOS\n");
> }
>
> /* Setup the spurious interrupt handler. */
>
>
>
> --
> Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160914123313.GC2840>