Re: [PATCH 10/25] KVM: TDX: Initialize KVM supported capabilities when module setup

[Nikolay Borisov]

On 12.09.24 г. 18:12 ч., Edgecombe, Rick P wrote:
> On Thu, 2024-09-12 at 17:07 +0800, Xiaoyao Li wrote:
> > > I.e if we disable SEPT_VE_DISABLE without having ATTR_DEBUG it results
> > > in a panic.
> >
> > I see now.
> >
> > It's linux TD guest's implementation, which requires SEPT_VE_DISABLE
> > must be set unless it's a debug TD.
> >
> > Yes, it can be the motivation to request KVM to add the support of
> > ATTRIBUTES.DEBUG. But the support of ATTRIBUTES.DEBUG is not just
> > allowing this bit to be set to 1. For DEBUG TD, VMM is allowed to
> > read/write the private memory content, cpu registers, and MSRs, VMM is
> > allowed to trap the exceptions in TD, VMM is allowed to manipulate the
> > VMCS of TD vcpu, etc.
> >
> > IMHO, for upstream, no need to support all the debug capability as
> > described above.
>
> I think you mean for the first upstream support. I don't see why it would not be
> suitable for upstream if we have upstream users doing it.
>
> Nikolay, is this hypothetical or something that you have been doing with some
> other TDX tree? We can factor it into the post-base support roadmap.

The real world use case here is a report comes and says " Hey, our TVM 
locks up on certain event". Turns out it happens due to the hypervisor 
not handling correctly some TD exit event caused by a SEPT violation. So 
then I can instruct the person to simply disable SEPT_VE_DISABLE so that 
instead of a TD exit we get a nice oops inside the guest which can serve 
further debugging.


> > But we need firstly define a subset of them as the
> > starter of supporting ATTRIBUTES.DEBUG. Otherwise, what is the meaning
> > of KVM to allow the DEBUG to be set without providing any debug capability?
> >
> > For debugging purpose, you can just hack guest kernel to allow
> > spet_ve_disable to be 0 without DEBUG bit set, or hack KVM to allow
> > DEBUG bit to be set.