Hi Boris,
On 08/21/2018 03:39 AM, Borislav Petkov wrote:
On Mon, Aug 20, 2018 at 05:11:53PM -0500, Brijesh Singh wrote:
Hi All,
The following commit
"
x86/kvmclock: Remove memblock dependency
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=368a540e0232ad446931f5a4e8a5e06f69f21343
"
broke the SEV support in 4.18.
Since the guest physical address holding the wall_clock and
vcpu_time_info are shared with the hypervisor it must be mapped
as "decrypted" when SEV is active. To clear the C-bit we use
kernel_physical_mapping_init() to split the large pages into 4K before
changing the C-bit. Now the kernel_physical_mapping_init() is failing to
allocate the memory because its called very early.
[ 0.000000] Call Trace:
[ 0.000000] ? dump_stack+0x5c/0x80
[ 0.000000] ? panic+0xe7/0x247
[ 0.000000] ? alloc_low_pages+0x130/0x130
[ 0.000000] ? kernel_physical_mapping_init+0xe0/0x204
[ 0.000000] ? early_set_memory_enc_dec+0x123/0x174
[ 0.000000] ? 0xffffffffae000000
[ 0.000000] ? kvmclock_init+0x60/0x1ea
[ 0.000000] ? kvm_init_platform+0xa/0x16
[ 0.000000] ? setup_arch+0x434/0xce9
[ 0.000000] ? start_kernel+0x67/0x52e
[ 0.000000] ? load_ucode_bsp+0x76/0x12e
[ 0.000000] ? secondary_startup_64+0xa4/0xb0
Silly question: can we delay the call to kernel_physical_mapping_init()
to right before those variables are accessed by the guest for the first
time, assuming we can allocate memory at that point?
Those variables are accessed immediately by the tsc calibration code
path hence we will not able to delay the allocation. Before the above
patch series, kvmclock_init() and early tsc calibration was called a
bit late in setup_arch() hence it all worked fine.
-Brijesh
