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. >> 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
