On Mon, Jan 28, 2019 at 12:00:17PM +0100, Paolo Bonzini wrote: > Please do not drop the mailing list. > > On 27/01/19 16:40, Yang Weijiang wrote: > > On Fri, Jan 25, 2019 at 07:02:37PM +0100, Paolo Bonzini wrote: > >> There is no code in this series to pass these fields to and from > >> userspace, and also to save/restore U_CET, INT_SSP_TAB, PL0_SSP and > >> PL3_SSP across context switches. > >> > > In current CET implementation, these VMCS fields are not consumed by > > VMM, so now it's rather some placeholders, but in future, we may use > > them. > > If this is not a complete implementation, this should be mentioned in > the patches. KVM must support accesses to the MSRs from userspace, for > example in order to perform live migration. > OK, will do that, thanks. > >> In addition, PL1_SSP and PL2_SSP should be supported even if the guest > >> doesn't use them. It makes sense to avoid intercepting them, but they > >> should still be supported and switched (possibly only if nonzero). > >> > > In the CET spec., there's no such kind of VMCS definitions for PL1_SSP > > and PL2_SSP, so they don't appear in the patches. > > That doesn't matter. I'm not talking of the VMCS definitions, but > rather the MSRs. Currently, any guest using PL1_SSP will cause a #GP. > > >> Am I missing something, for example a dependency on host CET support? > >> If not, how was this series tested? > >> > > In current implementation, guest CET has dependency on host CET > > realization, e.g., kernel code. Right now, I tested guest CET feature > > with host CET enabled on internel virtual platform. > > Ok, please mention this in the cover letter too. > > Paolo
