On Thu, Sep 12, 2024, Paolo Bonzini wrote: > On Thu, Sep 12, 2024 at 6:42 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > On Thu, Sep 12, 2024, Paolo Bonzini wrote: > > > On Thu, Sep 12, 2024 at 4:45 PM Xiaoyao Li <xiaoyao.li@xxxxxxxxx> wrote: > > > > > KVM is not going to have any checks, it's only going to pass the > > > > > CPUID to the TDX module and return an error if the check fails > > > > > in the TDX module. > > > > > > > > If so, new feature can be enabled for TDs out of KVM's control. > > > > > > > > Is it acceptable? > > > > > > It's the same as for non-TDX VMs, I think it's acceptable. > > > > No? IIUC, it's not the same. > > > > E.g. KVM doesn't yet support CET, and while userspace can enumerate CET support > > to VMs all it wants, guests will never be able to set CR4.CET and thus can't > > actually enable CET. > > > > IIUC, the proposal here is to allow userspace to configure the features that are > > exposed _and enabled_ for a TDX VM without any enforcement from KVM. > > Yeah, that's correct, on the other hand a lot of features are just > new instructions and no new registers. Those pass under the radar > and in fact you can even use them if the CPUID bit is 0 (of course). > Others are just data, and again you can pass any crap you'd like. Right, I don't care about those precisely because there's nothing KVM can or _needs_ to do for features that don't have interception controls. > And for SNP we had the case where we are forced to leave features > enabled if their state is in the VMSA, because we cannot block > writes to XCR0 and XSS that we'd like to be invalid. Oh, I'm well aware :-) > > CET might be a bad example because it looks like it's controlled by TDCS.XFAM, but > > presumably there are other CPUID-based features that would actively enable some > > feature for a TDX VM. > > XFAM is controlled by userspace though, not KVM, so we've got no > control on that either. I assume it's plain text though? I.e. whatever ioctl() sets TDCS.XFAM can be rejected by KVM if it attempts to enable unsupported features? I don't expect that we'll want KVM to gatekeep many, if any features, but I do think we should require explicit enabling in KVM whenever possible, even if the enabling is boring and largely ceremonial.
