On 3/26/2025 2:46 AM, Daniel P. Berrangé wrote:
On Fri, Jan 24, 2025 at 08:20:48AM -0500, Xiaoyao Li wrote:
Add docs/system/i386/tdx.rst for TDX support, and add tdx in
confidential-guest-support.rst

Signed-off-by: Xiaoyao Li <xiaoyao...@intel.com>
---

---
  docs/system/confidential-guest-support.rst |   1 +
  docs/system/i386/tdx.rst                   | 156 +++++++++++++++++++++
  docs/system/target-i386.rst                |   1 +
  3 files changed, 158 insertions(+)
  create mode 100644 docs/system/i386/tdx.rst


+Launching a TD (TDX VM)
+-----------------------
+
+To launch a TD, the necessary command line options are tdx-guest object and
+split kernel-irqchip, as below:
+
+.. parsed-literal::
+
+    |qemu_system_x86| \\
+        -object tdx-guest,id=tdx0 \\
+        -machine ...,kernel-irqchip=split,confidential-guest-support=tdx0 \\
+        -bios OVMF.fd \\
+
+Restrictions
+------------
+
+ - kernel-irqchip must be split;

Is there a reason why we don't make QEMU set kernel-irqchip=split
automatically when tdx-guest is enabled ?

It feels silly to default to a configuration that is known to be
broken with TDX. I thought about making libvirt automatically
set kernel-irqchip=split, or even above that making virt-install
automatically set it. Addressing it in QEMU would seem the most
appropriate place though.

For x86, if not with machine older than machine-4.0, the default kernel_irqchip is set to split when users don't set a value explicitly:

 if (s->kernel_irqchip_split == ON_OFF_AUTO_AUTO) {
s->kernel_irqchip_split = mc->default_kernel_irqchip_split ? ON_OFF_AUTO_ON : ON_OFF_AUTO_OFF;
    }


I think QEMU should only set it to split automatically for TDX guest when users don't provide a explicit value. And current code just works as expected.

Further, I think we can at least add the check in tdx_kvm_init() like this

if (kvm_state->kernel_irqchip_split != ON_OFF_AUTO_ON) {
        error_setg(errp, "TDX VM requires kernel_irqchip to be split");
        return -EINVAL;
}

Are you OK with it?


With regards,
Daniel


Reply via email to