From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752270AbdK3KMi (ORCPT ); Thu, 30 Nov 2017 05:12:38 -0500 Received: from mx2.suse.de ([195.135.220.15]:50643 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750761AbdK3KMh (ORCPT ); Thu, 30 Nov 2017 05:12:37 -0500 Date: Thu, 30 Nov 2017 11:12:29 +0100 From: Borislav Petkov To: "H. Peter Anvin" Cc: "Kirill A. Shutemov" , Thomas Gleixner , "Kirill A. Shutemov" , Ingo Molnar , x86@kernel.org, Linus Torvalds , Andy Lutomirski , Cyrill Gorcunov , Andi Kleen , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv2 0/4] x86: 5-level related changes into decompression code Message-ID: <20171130101229.b6wqlesgwvx7xg6e@pd.tnic> References: <20171129154908.6y4st6xc7hbsey2v@pd.tnic> <20171129161349.d7ksuhwhdamloty6@node.shutemov.name> <20171129170831.2iqpop2u534mgrbc@node.shutemov.name> <20171129174851.jk2ai37uumxve6sg@pd.tnic> <793b9c55-e85b-97b5-c857-dd8edcda4081@zytor.com> <20171129191902.2iamm3m23e3gwnj4@pd.tnic> <20171129223103.in4qmtxbj2sawhpw@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 29, 2017 at 03:24:53PM -0800, H. Peter Anvin wrote: > Yes, Grub as a matter of policy(!) does everything in the most braindead > way possible. You have to use "linux16" or "linuxefi" to make it do > something sane. Good to know, thx. > What is text mode? It is hardware that is going away(*), and you don't > even know if you have a display screen on your system at all, or how > you'd have to configure your display hardware even if it is "mostly" VGA. Ok, let me take a stab completely in the dark here: can we ask FW to switch to some mode which is "suitable" for printing messages? It would mean we'd have to switch back to real mode where we could do something ala arch/x86/boot/bioscall.S After we've printed something, we halt. If there's no screen, we only halt - it's not like we can magically get a fairy to connect a screen to the system. > Well, it's not just limited to 5-level mode; it's kind a general issue. > We have had this issue for a very, very long time -- all the way back to > i386 PAE at the very least. I realize that, judging by your reaction. And yes, we should try to find a proper solution here in the long run. > I'm personally OK with triple-faulting the CPU in this case. Except that is not really user-friendly, as I mentioned already, and could save other users a bunch of time looking for why TF the kernel doesn't boot only to realize they enabled an option which is not ready yet. Which should have depended on BROKEN when it went upstream, btw. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --