On Tue, Apr 2, 2024 at 1:18 AM Michael Roth <michael.roth@xxxxxxx> wrote: > > On Sat, Mar 30, 2024 at 09:41:30PM +0100, Paolo Bonzini wrote: > > On 3/29/24 23:58, Michael Roth wrote: > > > > > > + /* Handle boot vCPU first to ensure consistent measurement of initial state. */ > > > + if (!boot_vcpu_handled && vcpu->vcpu_id != 0) > > > + continue; > > > + > > > + if (boot_vcpu_handled && vcpu->vcpu_id == 0) > > > + continue; > > > > Why was this not necessary for KVM_SEV_LAUNCH_UPDATE_VMSA? Do we need it > > now? > > I tried to find the original discussion for more context, but can't seem to > locate it. But AIUI, there are cases where a VMM may create AP vCPUs earlier > than it does the BSP, in which case kvm_for_each_vcpu() might return an AP > as it's first entry and cause that VMSA to get measured before, leading > to a different measurement depending on the creation ordering. I think that would be considered a bug in either the VMM or the "thing" that computes the measurement. If that hasn't been a problem for SEV-ES, I'd rather keep the code simple. > We could however limit the change to KVM_X86_SEV_ES_VM and > document that as part of KVM_SEV_INIT2, since there is similarly chance > for measurement changes their WRT to the new FPU/XSAVE sync'ing that was > added. Hmm, I need to double check that the FPU/XSAVE syncing doesn't break existing measurements, too. Paolo
