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.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
