From: "H. Peter Anvin" <hpa@zytor.com>
To: Borislav Petkov <bp@suse.de>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>,
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
Subject: Re: [PATCHv2 0/4] x86: 5-level related changes into decompression code
Date: Wed, 29 Nov 2017 15:24:53 -0800 [thread overview]
Message-ID: <f0c0db4a-6196-d36d-cd1e-8dfc9c09767a@zytor.com> (raw)
In-Reply-To: <20171129223103.in4qmtxbj2sawhpw@pd.tnic>
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.
next prev parent reply other threads:[~2017-11-29 23:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-10 22:06 [PATCHv2 0/4] x86: 5-level related changes into decompression code Kirill A. Shutemov
2017-11-10 22:06 ` [PATCHv2 1/4] x86/boot/compressed/64: Rename pagetable.c to kaslr_64.c Kirill A. Shutemov
2017-11-10 22:06 ` [PATCHv2 2/4] x86/boot/compressed/64: Detect and handle 5-level paging at boot-time Kirill A. Shutemov
2017-11-10 22:06 ` [PATCHv2 3/4] x86/boot/compressed/64: Introduce place_trampoline() Kirill A. Shutemov
2017-11-10 22:06 ` [PATCHv2 4/4] x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G Kirill A. Shutemov
2017-11-22 8:09 ` [PATCHv2 0/4] x86: 5-level related changes into decompression code Kirill A. Shutemov
2017-11-29 15:49 ` Borislav Petkov
2017-11-29 16:13 ` Kirill A. Shutemov
2017-11-29 16:40 ` Thomas Gleixner
2017-11-29 17:08 ` Kirill A. Shutemov
2017-11-29 17:48 ` Borislav Petkov
2017-11-29 19:01 ` H. Peter Anvin
2017-11-29 19:19 ` Borislav Petkov
2017-11-29 21:33 ` H. Peter Anvin
2017-11-29 22:31 ` Borislav Petkov
2017-11-29 23:24 ` H. Peter Anvin [this message]
2017-11-30 1:27 ` Konrad Rzeszutek Wilk
2017-11-30 10:12 ` Borislav Petkov
2017-11-30 7:31 ` Kirill A. Shutemov
2017-11-30 10:14 ` Borislav Petkov
2017-11-30 15:45 ` Joe Perches
2017-11-29 20:58 ` Andi Kleen
2017-11-29 21:03 ` hpa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f0c0db4a-6196-d36d-cd1e-8dfc9c09767a@zytor.com \
--to=hpa@zytor.com \
--cc=ak@linux.intel.com \
--cc=bp@suse.de \
--cc=gorcunov@openvz.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).