We may need to backport this commit: commit 48b74865c63840b288bd85b4d8743533b73b339b Author: H.J. Lu <hjl.tools> Date: Tue Jan 3 13:06:48 2023 -0800 x86: Check minimum/maximum of non_temporal_threshold [BZ #29953] The minimum non_temporal_threshold is 0x4040. non_temporal_threshold may be set to less than the minimum value when the shared cache size isn't available (e.g., in an emulator) or by the tunable. Add checks for minimum and maximum of non_temporal_threshold. This fixes BZ #29953. to avoid problems in specific deployment scenarios.
*** Bug 2196271 has been marked as a duplicate of this bug. ***
*** Bug 2214488 has been marked as a duplicate of this bug. ***
Our TDX host environment includes a RHEL8 based host OS and qemu built according to Linux Stack for Intel TDX (https://github.com/intel/tdx-tools), run on a TDX supported and enabled Intel Sapphire Rapids platform. All our previous grub mode (meaning to boot a guest image, not directly boot kernel files) TDX boot failed until the glibc fix in this BZ was merged into RHEL9.3. "Linux Stack for Intel TDX" is still in development/experimental phase, but it should be the base of all future TDX host solutions, and currently the only available TDX host software environment, on Linux. RHEL8.8/9.2 has included TDX guest support in the kernel and grub. (Mentioned only in "6.1. New drivers" of the release note) To boot the official guest image is the most direct and natural way to experience TDX guest, I feel it's a pity that Linux users are blocked by a known issue here.
(In reply to Florian Weimer from comment #26) > (In reply to pusethi from comment #25) > > Can we please request this for 9.2 z-stream? It impacts ID guest boot with > > RHEL as a guest. Details in Partnerbz2214488 > > No z-stream update is planned for this issue while TDX enablement is > ongoing. We will likely need to incorporate other fixes. In particular, in > our testing with a cloud partner, the cache line sizes reported via CPUID > are zero, not just the cache sizes, and this may cause divide-by-zero > exceptions or endless loops. This may need a kernel/hypervisor level fix, > though, especially if applications bypass glibc and execute the CPUID > instruction directly. Just for this "obsoleted CPUID return value" issue, as consensus from key stakeholders, glibc has legitimate upstreamed fix for the issue, for it's the affected glibc version interpreted the CPUID return value in a wrong way. Kernel and VMM are innocent.
Red Hat, have you gotten any result if this fix can go into RHEL9.2-z?
(In reply to Xiaolong Wong from comment #36) > Red Hat, have you gotten any result if this fix can go into RHEL9.2-z? You should be able to view comment 26. As I said, the fix is incomplete. I started an upstream discussion: Missing cache information on x86-64 under Intel TDX (glibc bug 30643) <https://inbox.sourceware.org/libc-alpha/87mszv7x0l.fsf@oldenburg.str.redhat.com/> I filed bug 2223287 for tracking downstream inclusion. We can consider z-stream backporting once we have a complete fix (but as I wrote, I think this needs to be fixed on the TDX side for maximum application compatibility).