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