[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFypaeWzKh=wmwdw0PmMsVyP98hts5doC7CMtAH4095KTA@mail.gmail.com>
Date: Sat, 23 Dec 2017 19:30:21 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Alexandru Chirvasitu <achirvasub@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
kernel list <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...nel.org>,
Borislav Petkov <bp@...en8.de>,
Brian Gerst <brgerst@...il.com>,
Denys Vlasenko <dvlasenk@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot
On Sat, Dec 23, 2017 at 5:44 PM, Alexandru Chirvasitu
<achirvasub@...il.com> wrote:
>
> For testing purposes, I've altered machine_kexec_32.c making the
> following toy commit. It naively undoes part of e802a51, solely to
> confirm that's where it goes awry in my setup.
That's really funky.
The idt_invalidate() seems to do *exactly* the same thing. It uses
"load_idt()" on an IDT with size 0, and the supplied address.
Can you disassemble your "set_idt()" code vs the "idt_invalidate()"?
> Is this expected behaviour?
No. The code literally seems identical. The only difference is
(a) where the 0 limit comes from
(b) perhaps build flags and whether it is inlined or not due to being
in a different file
and neither of those should matter, but maybe they do.
Which is why I'd like you to actually look at the generated code and
see if you can see any difference..
Linus
Powered by blists - more mailing lists