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.
