From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753113AbdK2Xbw (ORCPT ); Wed, 29 Nov 2017 18:31:52 -0500 Received: from terminus.zytor.com ([65.50.211.136]:56377 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752594AbdK2Xbu (ORCPT ); Wed, 29 Nov 2017 18:31:50 -0500 Subject: Re: [PATCHv2 0/4] x86: 5-level related changes into decompression code To: Borislav Petkov 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 References: <20171110220645.59944-1-kirill.shutemov@linux.intel.com> <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> From: "H. Peter Anvin" Message-ID: Date: Wed, 29 Nov 2017 15:24:53 -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: <20171129223103.in4qmtxbj2sawhpw@pd.tnic> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/29/17 14:31, Borislav Petkov wrote: > > A couple of points: > > * so this box here has a normal grub installation and apparently grub > jumps to some other entry point. > 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. > * I'm not convinced we need to do everything you typed because this is > only a temporary issue and once X86_5LEVEL is complete, it should work. > I mean, it needs to work otherwise forget single-system image and I > don't think we want to give that up. > >> However, if the bootloader jumps straight into the code what do you >> expect it to do? We have no real concept about what we'd need to do to >> issue a message as we really don't know what devices are available on >> the system, etc. If the screen_info field in struct boot_params has >> been initialized then we actually *do* know how to write to the screen >> -- if you are okay with including a text font etc. since modern systems >> boot in graphics mode. > > We switch to text mode and dump our message. Can we do that? 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. > I wouldn't want to do any of this back'n'forth between kernel and boot > loader because that sounds fragile, at least to me. And again, I'm > not convinced we should spend too much energy on this as the issue is > temporary AFAICT. 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'm personally OK with triple-faulting the CPU in this case. -hpa (*) And for good reason -- it is completely memory-latency-bound as you have an indirect reference for every byte you fetch. In a UMA system this sucks up an insane amount of system bandwidth, unless you are willing to burn the area of having a 16K SRAM cache. VGA hardware, additionally, has a bunch of insane operations that have to be memory-mapped. The resulting hardware screws with pretty much any sane GPU implementation, so I'm fully expecting that as soon as GPUs no longer come with a CBIOS option ROM VGA hardware will be dropped more or less immediately.