From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754718AbbCIQm5 (ORCPT <rfc822;w@1wt.eu>);
	Mon, 9 Mar 2015 12:42:57 -0400
Received: from mail-wi0-f175.google.com ([209.85.212.175]:43650 "EHLO
	mail-wi0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753688AbbCIQmz (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 9 Mar 2015 12:42:55 -0400
Date: Mon, 9 Mar 2015 17:42:50 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
        Fengguang Wu <fengguang.wu@intel.com>, X86 ML <x86@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>, LKP <lkp@01.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [x86/asm/entry] BUG: unable to handle kernel paging request
Message-ID: <20150309164249.GA24910@gmail.com>
References: <20150306233033.GA3556@wfg-t540p.sh.intel.com>
 <CALCETrVvuQEu5Az4EFUr6Fhx00bFS3NCwN6MJ3gY00o4u2eWWg@mail.gmail.com>
 <CAK1hOcMrNb=RSqB92LzXRBRVZBkOdwggERSS3FLKak1EZi9gkA@mail.gmail.com>
 <CALCETrU3Ums8SnNQttoCYkdDi-T=HkhCQs-jvF21Nh6igJ3Mhw@mail.gmail.com>
 <20150309114618.GA18686@gmail.com>
 <CAK1hOcNU+8BtCN2TR6ZBh3KTTJtFKdoTe36UfVb91AYxEmeqTg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAK1hOcNU+8BtCN2TR6ZBh3KTTJtFKdoTe36UfVb91AYxEmeqTg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Denys Vlasenko <vda.linux@googlemail.com> wrote:

> On Mon, Mar 9, 2015 at 12:46 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Andy Lutomirski <luto@amacapital.net> wrote:
> >
> >> >>      */
> >> >>     unsigned long        stack[64];
> >> >>
> >> >> Last I checked, 0x100 != 64.  Also, wow, this is kind of disgusting. :)
> >> >
> >> >
> >> > Seems to be unused: I commented it out on "defconfig" build
> >> > and got no build errors.
> >>
> >> It's used.  On 32-bit, NMIs don't use task gates (I don't know why),
> >
> > So task gates were a sexy hardware acceleration feature, eons ago, and
> > we used to rely on them a lot,
> 
> IIRC task gates weren't used in Linux at first, [...]

AFAIK task gates were used to demo i386 context switching between 
tasks, a certain famous ABABABAB... pair of tasks printing to the 
console :-)

So task gates were used for context switching in Linux before it was 
called Linux! :-)

Check out the first released version:

  https://www.kernel.org/pub/linux/kernel/Historic/linux-0.01.tar.gz

It already does:

/*
 *      switch_to(n) should switch tasks to task nr n, first
 * checking that n isn't the current task, in which case it does nothing.
 * This also clears the TS-flag if the task we switched to has used
 * tha math co-processor latest.
 */
#define switch_to(n) {\
struct {long a,b;} __tmp; \
__asm__("cmpl %%ecx,_current\n\t" \
        "je 1f\n\t" \
        "xchgl %%ecx,_current\n\t" \
        "movw %%dx,%1\n\t" \
        "ljmp %0\n\t" \
        "cmpl %%ecx,%2\n\t" \
        "jne 1f\n\t" \
        "clts\n" \
        "1:" \
        ::"m" (*&__tmp.a),"m" (*&__tmp.b), \
        "m" (last_task_used_math),"d" _TSS(n),"c" ((long) task[n])); \
}

That LJMP is the TSS switch.

And in kernel/sched.c we did:

  void sched_init(void)
  {
        int i;
        struct desc_struct * p;

        set_tss_desc(gdt+FIRST_TSS_ENTRY,&(init_task.task.tss));

:-)

Thanks,

	Ingo