From owner-freebsd-stable@freebsd.org Wed Sep 14 12:23:17 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C41CBD9217 for ; Wed, 14 Sep 2016 12:23:17 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 55ACC1618 for ; Wed, 14 Sep 2016 12:23:17 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 51077BD9214; Wed, 14 Sep 2016 12:23:17 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50AE0BD9211 for ; Wed, 14 Sep 2016 12:23:17 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 83EAE1616 for ; Wed, 14 Sep 2016 12:23:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA25631; Wed, 14 Sep 2016 15:23:14 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bk9Dd-0005hq-Uy; Wed, 14 Sep 2016 15:23:13 +0300 Subject: Re: X2APIC support To: Konstantin Belousov References: <20160912175348.GV34394@zxy.spb.ru> <20160913121133.GX34394@zxy.spb.ru> <71a1f864-66de-0010-5024-e8e985f422f4@FreeBSD.org> <20160913124239.GZ34394@zxy.spb.ru> <20160913142118.GA34394@zxy.spb.ru> <37f5cebc-3fa1-9e95-5123-f3d8daa3130a@FreeBSD.org> <20160913152240.GE38409@kib.kiev.ua> <20160914113634.GF38409@kib.kiev.ua> Cc: Slawa Olhovchenkov , stable@FreeBSD.org From: Andriy Gapon Message-ID: <763df55a-4b69-9f7a-1042-0f631a729881@FreeBSD.org> Date: Wed, 14 Sep 2016 15:22:17 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20160914113634.GF38409@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 12:23:17 -0000 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. 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