On Wed, Oct 9, 2019 at 2:40 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 09/10/19 23:29, Jim Mattson wrote: > > On Wed, Oct 9, 2019 at 12:02 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > >> > >> On 09/10/19 02:41, Aaron Lewis wrote: > >>> - /* > >>> - * The only supported bit as of Skylake is bit 8, but > >>> - * it is not supported on KVM. > >>> - */ > >>> - if (data != 0) > >>> - return 1; > >> > >> This comment is actually not true anymore; Intel supports PT (bit 8) on > >> Cascade Lake, so it could be changed to something like > >> > >> /* > >> * We do support PT (bit 8) if kvm_x86_ops->pt_supported(), but > >> * guests will have to configure it using WRMSR rather than > >> * XSAVES. > >> */ > >> > >> Paolo > > > > Isn't it necessary for the host to set IA32_XSS to a superset of the > > guest IA32_XSS for proper host-level context-switching? > > Yes, this is why we cannot allow the guest to set bit 8. But the > comment is obsolete: > > 1) of course Skylake is not the newest model > > 2) processor tracing was not supported at all when the comment was > written; but on CascadeLake, guest PT is now supported---just not the > processor tracing XSAVES component. I think we're on the same page. I was just confused by your wording; it sounded like you were saying that KVM supported bit 8. How about: /* * We do support PT if kvm_x86_ops->pt_supported(), but we do not * support IA32_XSS[bit 8]. Guests will have to use WRMSR rather than * XSAVES/XRSTORS to save/restore PT MSRs. */
