Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCHv2 0/4] x86: 5-level related changes into decompression
 code
To:     Borislav Petkov <bp@suse.de>,
        "Kirill A. Shutemov" <kirill@shutemov.name>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Ingo Molnar <mingo@redhat.com>, x86@kernel.org,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Andy Lutomirski <luto@amacapital.net>,
        Cyrill Gorcunov <gorcunov@openvz.org>,
        Andi Kleen <ak@linux.intel.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
References: <20171110220645.59944-1-kirill.shutemov@linux.intel.com>
 <20171129154908.6y4st6xc7hbsey2v@pd.tnic>
 <20171129161349.d7ksuhwhdamloty6@node.shutemov.name>
 <alpine.DEB.2.20.1711291740050.1825@nanos>
 <20171129170831.2iqpop2u534mgrbc@node.shutemov.name>
 <20171129174851.jk2ai37uumxve6sg@pd.tnic>
From:   "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <793b9c55-e85b-97b5-c857-dd8edcda4081@zytor.com>
Date:   Wed, 29 Nov 2017 11:01:35 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20171129174851.jk2ai37uumxve6sg@pd.tnic>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 11/29/17 09:48, Borislav Petkov wrote:
> On Wed, Nov 29, 2017 at 08:08:31PM +0300, Kirill A. Shutemov wrote:
>> We're really early in the boot -- startup_64 in decompression code -- and
>> I don't know a way print a message there. Is there a way?
>>
>> no_longmode handled by just hanging the machine. Is it enough for no_la57
>> case too?
> 
> Patch pls.
> 

I don't think there is any way to get a message out here.  It's too late
to use the firmware, and too early to use anything native.

no_longmode in startup_64 is an oxymoron -- it simply can't happen,
although of course we can enter at the 32-bit entry point with that problem.

We can hang the machine, or we can triple-fault it in the hope of
triggering a reset, and that way if the bootloader has been configured
with a backup kernel there is a hope of recovery.

Triple-faulting is trivial:

	push $0
	push $0
	lidt (%rsp)		/* %esp for 32-bit mode */
	ud2
	/* WTF? */
1:	hlt
	jmp 1b

This will either hang the machine or reboot it, depending on if the
reboot-on-triple-fault logic in the chipset actually works.

	-hpa


From 1585423737146391072@xxx Wed Nov 29 17:51:38 +0000 2017
X-GM-THRID: 1583718603202818481
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread