From: Borislav Petkov <bp@suse.de>
To: "H. Peter Anvin" <hpa@zytor.com>
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: Thu, 30 Nov 2017 11:12:29 +0100 [thread overview]
Message-ID: <20171130101229.b6wqlesgwvx7xg6e@pd.tnic> (raw)
In-Reply-To: <f0c0db4a-6196-d36d-cd1e-8dfc9c09767a@zytor.com>
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 ImendA?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG NA 1/4 rnberg)
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-11-30 10:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-10 22:06 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
2017-11-30 1:27 ` Konrad Rzeszutek Wilk
2017-11-30 10:12 ` Borislav Petkov [this message]
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=20171130101229.b6wqlesgwvx7xg6e@pd.tnic \
--to=bp@suse.de \
--cc=ak@linux.intel.com \
--cc=gorcunov@openvz.org \
--cc=hpa@zytor.com \
--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