In v0 of this patch, I mistakenly claimed that
boot_cpu_data.x86_virt_bits was not getting set to 0 in some
configurations. However, it is in fact reliably being set to 0 because
it is specified to be in the .data..read_mostly section, and .data is
initialized at this point. The boot failures that we were seeing were
actually due to the gcc 12.3 compiler exploiting the undefined
behavior to return false from __is_canonical_address when
boot_cpu_data.x86_virt_bits is 0.

This patch set applies the 2 changes posted by Dave Hansen: remove the
UB by explicily checking for 0, and remove the period of time where
x86_virt_bits may be temporarily set to the wrong value where the #VC
handler could observe it.


Adam Dunlap (2):
  x86/sev-es: Allow copy_from_kernel_nofault in earlier boot
  x86/sev-es: Only set x86_virt_bits to correct value

 arch/x86/kernel/cpu/common.c | 37 +++++++++++++++++++++---------------
 arch/x86/mm/maccess.c        | 19 +++++++++++++-----
 2 files changed, 36 insertions(+), 20 deletions(-)

-- 
2.42.0.283.g2d96d420d3-goog

* Adam Dunlap <acdunlap@google.com> wrote:

> In v0 of this patch, I mistakenly claimed that
> boot_cpu_data.x86_virt_bits was not getting set to 0 in some
> configurations. However, it is in fact reliably being set to 0 because
> it is specified to be in the .data..read_mostly section, and .data is
> initialized at this point. The boot failures that we were seeing were
> actually due to the gcc 12.3 compiler exploiting the undefined
> behavior to return false from __is_canonical_address when
> boot_cpu_data.x86_virt_bits is 0.
> 
> This patch set applies the 2 changes posted by Dave Hansen: remove the
> UB by explicily checking for 0, and remove the period of time where
> x86_virt_bits may be temporarily set to the wrong value where the #VC
> handler could observe it.
> 
> 
> Adam Dunlap (2):
>   x86/sev-es: Allow copy_from_kernel_nofault in earlier boot
>   x86/sev-es: Only set x86_virt_bits to correct value

I've applied these fixes to tip:x86/mm, thanks!

Note that I switched around the order of patches: we first want
to enhance x86_virt_bits to be reliable, only then do we want to
change copy_from_kernel_nofault_allowed() to be able to rely on it,
to fix early #VC accesses, right?

I also improved the changelogs & titles a bit.

Thanks,

	Ingo