From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 13:29:16 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75C511065675; Thu, 22 Jan 2009 13:29:16 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5E0E68FC14; Thu, 22 Jan 2009 13:29:15 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA26865; Thu, 22 Jan 2009 15:29:13 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <497874A8.3070205@icyb.net.ua> Date: Thu, 22 Jan 2009 15:29:12 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: John Baldwin References: <4947AA3C.4040005@icyb.net.ua> <200901211407.44021.jhb@freebsd.org> In-Reply-To: <200901211407.44021.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: usb keyboard vs btx: an SMI theory X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 13:29:16 -0000 on 21/01/2009 21:07 John Baldwin said the following: > On Tuesday 16 December 2008 8:16:44 am Andriy Gapon wrote: >> Again, I am very fuzzy about the exact details, but I think that this is >> something that could be happening and I think that SMI is of primary >> interest here. I also think that this might explain to a certain degree >> the difference in behavior between "older" btx and "newer" btx. > > One thing to keep in mind is that when an SMI# is delivered, the processor > enters System Management Mode (SMM). In SMM, the CPU actually uses a > different set of memory for its RAM. It also runs in a sort of weird 32-bit > real mode. It is not going to call the stock IRQ 1 handler. Instead, it > passes data back to "normal" mode by changing the values restored into > registers when exiting SMM. Typically doing an I/O port access to the ports > backing the keyboard (0x60 and 0x64) cause an SMI# and the SMM handler > emulates the inb/outb request by storing the resulting data for an inb in > the %ax register the "normal" mode sees once it resumes execution after > the 'inb' instruction. > I've been thinking about that and also decided that my SMI theory is rubbish. On the other hand, I still suspect that there could be some race in protected<->real transition, but from looking at the code I can not imagine how it could happen. -- Andriy Gapon