Date: Wed, 14 Sep 2016 14:36:34 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Andriy Gapon <avg@FreeBSD.org> Cc: Slawa Olhovchenkov <slw@zxy.spb.ru>, stable@FreeBSD.org Subject: Re: X2APIC support Message-ID: <20160914113634.GF38409@kib.kiev.ua> In-Reply-To: <cb35f671-95e7-820f-6a78-ee60612cc1ad@FreeBSD.org> References: <20160912175348.GV34394@zxy.spb.ru> <b03e7fa0-b73f-de92-b783-de8be2d66107@FreeBSD.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160914113634.GF38409>