From owner-freebsd-stable@freebsd.org Wed Sep 14 11:36:41 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 ADCB3AC4B06 for ; Wed, 14 Sep 2016 11:36:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 939B51A67 for ; Wed, 14 Sep 2016 11:36:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8F439AC4B04; Wed, 14 Sep 2016 11:36:41 +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 8EE76AC4B02 for ; Wed, 14 Sep 2016 11:36:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0712E1A65; Wed, 14 Sep 2016 11:36:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u8EBaZRZ067574 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Sep 2016 14:36:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u8EBaZRZ067574 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u8EBaYuN067573; Wed, 14 Sep 2016 14:36:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 14 Sep 2016 14:36:34 +0300 From: Konstantin Belousov To: Andriy Gapon Cc: Slawa Olhovchenkov , stable@FreeBSD.org Subject: Re: X2APIC support Message-ID: <20160914113634.GF38409@kib.kiev.ua> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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 11:36:41 -0000 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.