On Wed, Sep 09, 2026 at 06:00:53PM +0800, Xiaoyao Li wrote: > >> The reason we could not use __TEST_ASSERT_VM_VCPU_IOCTL() directly[2] is > >> because it formats ther return value as %i (32-bit), whereas > >> __tdx_vm_ioctl might return a u64 hardware error code. > >> > > Since we cannot simply use hw_error to replace ret, there will be not 32bit > vs 64bit issue. But ... > > >> I agree with your suggestion to introduce a new > >> TEST_ASSERT_TDX_VM_VCPU_IOCTL() macro to print out u64 hardware error > >> code properly. > > ... if we want to print hw_error as well, we still need a new macro. > > >> [2]: > >> https://lore.kernel.org/all/[email protected]/ > >> > > > > Is tdx_vm_ioctl() the only place where TEST_ASSERT_TDX_VM_VCPU_IOCTL() > > is going to be used though? If so, maybe we should defer introducing > > TEST_ASSERT_TDX_VM_VCPU_IOCTL() till later. > > I think tdx_vcpu_ioctl() will use it as well?
Thanks for replying. I agree all of the other parts of your comments. Just wanted to point out one detail: tdx_vm_ioctl() is the only place that actually needs to evaluate hw_error right now. Unlike the VM-scoped ioctls in the x86 kernel code, the functions dispatched via tdx_vcpu_unlocked_ioctl() (such as tdx_vcpu_init or tdx_vcpu_init_mem_region) do not currently return the TDX SEAMCALL error codes into the hw_error field. Thus, I would prefer to inline TEST_ASSERT directly inside tdx_vm_ioctl() instead of introducing a new TEST_ASSERT_TDX_VM_VCPU_IOCTL() right now. Lisa > > I think the issue with if (ret) is just that TEST_ASSERT(!ret) already > > does that same check, and so we can drop the if (ret) part. > >
