[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABgObfYPT8yLvCDdc0B+4t4xCbk8deZg_G0_QVY_DcR_7--xSw@mail.gmail.com>
Date: Wed, 3 Apr 2024 14:56:25 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Michael Roth <michael.roth@....com>
Cc: kvm@...r.kernel.org, linux-coco@...ts.linux.dev, linux-mm@...ck.org,
linux-crypto@...r.kernel.org, x86@...nel.org, linux-kernel@...r.kernel.org,
tglx@...utronix.de, mingo@...hat.com, jroedel@...e.de,
thomas.lendacky@....com, hpa@...or.com, ardb@...nel.org, seanjc@...gle.com,
vkuznets@...hat.com, jmattson@...gle.com, luto@...nel.org,
dave.hansen@...ux.intel.com, slp@...hat.com, pgonda@...gle.com,
peterz@...radead.org, srinivas.pandruvada@...ux.intel.com,
rientjes@...gle.com, dovmurik@...ux.ibm.com, tobin@....com, bp@...en8.de,
vbabka@...e.cz, kirill@...temov.name, ak@...ux.intel.com, tony.luck@...el.com,
sathyanarayanan.kuppuswamy@...ux.intel.com, alpergun@...gle.com,
jarkko@...nel.org, ashish.kalra@....com, nikunj.dadhania@....com,
pankaj.gupta@....com, liam.merwick@...cle.com,
Brijesh Singh <brijesh.singh@....com>, Harald Hoyer <harald@...fian.com>
Subject: Re: [PATCH v12 12/29] KVM: SEV: Add KVM_SEV_SNP_LAUNCH_FINISH command
On Tue, Apr 2, 2024 at 1:18 AM Michael Roth <michael.roth@....com> 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
Powered by blists - more mailing lists