> From: Jeremi Piotrowski <jpiotrowski@xxxxxxxxxxxxxxxxxxx> > Sent: Friday, February 17, 2023 4:51 AM > To: Dexuan Cui <decui@xxxxxxxxxxxxx> > > [...] > > The comment before the first branch says: > > On 4-level paging, p4d_offset(top_level_pgt, 0) is equal to 'top_level_pgt'. > > > > IIUC this means 'top_level_pgt' is equal to '_pgtable'? i.e. without > > CONFIG_RANDOMIZE_BASE, pgt_data.pgt_buf_size should be 0. > > > > Not sure why it's not getting into the first branch for you. > > Sorry, I got two things confused here. The relevant part of the comment is this: > "If we came here via startup_32(), cr3 will be _pgtable already". > > Booting a (non-SNP) guest via BIOS I end up in the first branch. Upstream SNP > support requires OVMF (UEFI) so we'll always reach the kernel in 64-bit mode > (startup_64?), and end up in the second branch. > > Jeremi Here I'm running a C-bit mode SNP guest on Hyper-V via "direct-boot" (i.e. I run Set-VMFirmware to tell Hyper-V to boot the kernel directly without UEFI). Looks like arch/x86/boot/compressed/head_64.S: startup_32 runs first and calls startup_64 later (?) This might explain why I'm getting into the first branch, which I hope could be fixed by someone...
