Re: SEV guest regression in 4.18

[Brijesh Singh]

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