On 05/25/2015 11:03 PM, Aurelien Jarno wrote:
> On 2015-05-25 16:08, Richard Henderson wrote:
>> On 05/24/2015 04:47 PM, Aurelien Jarno wrote:
>>> Cc: Alexander Graf <ag...@suse.de>
>>> Cc: Richard Henderson <r...@twiddle.net>
>>> Signed-off-by: Aurelien Jarno <aurel...@aurel32.net>
>>
>> Sadly, implementing this breaks current kernels.
>> I did this about two years ago and havn't figured
>> out what to do about it.
>>
>> The silly code in head.S doesn't check for just the
>> facilities that it needs, it checks for all facilities
>> that specific processors provide.
>>
>> If we don't e.g. pretend that we have HFP, despite the
>> fact that no one uses it, the kernel won't boot.
>
> How does it breaks? This patch only enable bits corresponding to
> facility that we fully implement (that's a reason why the patchset
> doesn't enable LD facility for example). So it should not be a problem,
> at least I have been able to boot kernels successfully.
>
Unless the facilities provided are a strict superset of those required by the
kernel, it aborts the boot. Extremely early in the process. As Alex said,
it's possible to compile a kernel without this, but none of the vendor-built
kernels do so. Which raises the bar to what a user needs to do to install.
See linux/arch/s390/kernel/head.S,
# List of facilities that are required. If not all facilities are present
# the kernel will crash. Format is number of facility words with bits set,
# followed by the facility words.
#if defined(CONFIG_MARCH_Z13)
.long 3, 0xc100eff2, 0xf46ce800, 0x00400000
#elif defined(CONFIG_MARCH_ZEC12)
.long 3, 0xc100eff2, 0xf46ce800, 0x00400000
#elif defined(CONFIG_MARCH_Z196)
.long 2, 0xc100eff2, 0xf46c0000
#elif defined(CONFIG_MARCH_Z10)
.long 2, 0xc100eff2, 0xf0680000
#elif defined(CONFIG_MARCH_Z9_109)
.long 1, 0xc100efc2
#elif defined(CONFIG_MARCH_Z990)
.long 1, 0xc0002000
#elif defined(CONFIG_MARCH_Z900)
.long 1, 0xc0000000
#endif
r~
