[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6977db02ebec8_1d33100f5@dwillia2-mobl4.notmuch>
Date: Mon, 26 Jan 2026 13:22:10 -0800
From: <dan.j.williams@...el.com>
To: Chao Gao <chao.gao@...el.com>, Binbin Wu <binbin.wu@...ux.intel.com>
CC: <linux-coco@...ts.linux.dev>, <linux-kernel@...r.kernel.org>,
<x86@...nel.org>, <reinette.chatre@...el.com>, <ira.weiny@...el.com>,
<kai.huang@...el.com>, <dan.j.williams@...el.com>,
<yilun.xu@...ux.intel.com>, <sagis@...gle.com>, <vannapurve@...gle.com>,
<paulmck@...nel.org>, <nik.borisov@...e.com>, Farrah Chen
<farrah.chen@...el.com>, "Kirill A. Shutemov" <kas@...nel.org>, Dave Hansen
<dave.hansen@...ux.intel.com>, Thomas Gleixner <tglx@...utronix.de>, "Ingo
Molnar" <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, "H. Peter Anvin"
<hpa@...or.com>
Subject: Re: [PATCH v2 20/21] x86/virt/tdx: Update tdx_sysinfo and check
features post-update
Chao Gao wrote:
[..]
> I think this conservative approach is appropriate for initial support. New
> features can be gradually enabled later as we prove that other components
> (e.g., KVM) are ready for new features introduced via runtime updates.
New features over updates, and revised software contracts (broken
contracts) over updates are not "compatible updates". So it is not a
"conservative approach" to start, it is more a hard barrier that updates
of that nature are out-of-scope via this interface. The Documentation
needs to be clear that the problems caused by update are the Module's
problems, not new kernel problems.
If you look at other platform mutating update mechanisms like ACPI
runtime update and CXL runtime update, the class of updates that expose
new features / contracts require reset. TDX is not special in this
regard.
Powered by blists - more mailing lists