Hi Kees, as a general note: With SEV-ES the guest kernel will get #VC exceptions for events that, without SEV-ES, would just cause a #VMEXIT to the hypervisor. On Wed, Jul 15, 2020 at 08:26:14AM -0700, Kees Cook wrote: > On Wed, Jul 15, 2020 at 11:26:38AM +0200, Joerg Roedel wrote: > > That MSR is Intel-only, right? The boot-path installed here is only used > > for SEV-ES guests, running on AMD systems, so this MSR is not even > > accessed during boot on those VMs. > > Oh, hrm, yes, that's true. If other x86 maintainers are comfortable with > this, then okay. My sense is that changing the early CPU startup paths > will cause trouble down the line. The AP startup path does not change for non SEV-ES guests. But under SEV-ES everything that might cause a #VC exception must be avoided until the kernel is ready to handle them. With the current patches this happens when the AP runs in 64bit long-mode and loaded TSS and IDT. Therefore a slightly different AP boot-path is needed for SEV-ES guests. > So, going back to the requirements here ... what things in verify_cpu() > can cause exceptions? AFAICT, cpuid is safely handled (i.e. it is > detected and only run in a way to avoid exceptions and the MSR > reads/writes are similarly bound by CPU family/id range checks). I must > be missing something. :) It is actually the CPUID instructions that cause #VC exceptions. The MSRs that are accessed on AMD processors are not intercepted in the hypervisors this code has been tested on, so these will not cause #VC exceptions. Regards, Joerg
