* [PATCH v7 2/2] KVM: SEV: Add KVM_SEV_SNP_ENABLE_REQ_CERTS command
From: Michael Roth @ 2026-01-09 23:17 UTC (permalink / raw)
To: kvm
Cc: linux-coco, linux-kernel, pbonzini, seanjc, jroedel,
thomas.lendacky, liam.merwick, huibo.wang
In-Reply-To: <20260109231732.1160759-1-michael.roth@amd.com>
Introduce a new command for KVM_MEMORY_ENCRYPT_OP ioctl that can be used
to enable fetching of endorsement key certificates from userspace via
the new KVM_EXIT_SNP_REQ_CERTS exit type. Also introduce a new
KVM_X86_SEV_SNP_REQ_CERTS KVM device attribute so that userspace can
query whether the kernel supports the new command/exit.
Suggested-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
Tested-by: Liam Merwick <liam.merwick@oracle.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
---
.../virt/kvm/x86/amd-memory-encryption.rst | 52 ++++++++++++++++++-
arch/x86/include/uapi/asm/kvm.h | 2 +
arch/x86/kvm/svm/sev.c | 16 ++++++
3 files changed, 69 insertions(+), 1 deletion(-)
diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
index 1ddb6a86ce7f..543b5e5dd8d4 100644
--- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst
+++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
@@ -572,6 +572,52 @@ Returns: 0 on success, -negative on error
See SNP_LAUNCH_FINISH in the SEV-SNP specification [snp-fw-abi]_ for further
details on the input parameters in ``struct kvm_sev_snp_launch_finish``.
+21. KVM_SEV_SNP_ENABLE_REQ_CERTS
+--------------------------------
+
+The KVM_SEV_SNP_ENABLE_REQ_CERTS command will configure KVM to exit to
+userspace with a ``KVM_EXIT_SNP_REQ_CERTS`` exit type as part of handling
+a guest attestation report, which will to allow userspace to provide a
+certificate corresponding to the endorsement key used by firmware to sign
+that attestation report.
+
+Returns: 0 on success, -negative on error
+
+NOTE: The endorsement key used by firmware may change as a result of
+management activities like updating SEV-SNP firmware or loading new
+endorsement keys, so some care should be taken to keep the returned
+certificate data in sync with the actual endorsement key in use by
+firmware at the time the attestation request is sent to SNP firmware. The
+recommended scheme to do this is to use file locking (e.g. via fcntl()'s
+F_OFD_SETLK) in the following manner:
+
+ - Prior to obtaining/providing certificate data as part of servicing an
+ exit type of ``KVM_EXIT_SNP_REQ_CERTS``, the VMM should obtain a
+ shared/read or exclusive/write lock on the certificate blob file before
+ reading it and returning it to KVM, and continue to hold the lock until
+ the attestation request is actually sent to firmware. To facilitate
+ this, the VMM can set the ``immediate_exit`` flag of kvm_run just after
+ supplying the certificate data, and just before resuming the vCPU.
+ This will ensure the vCPU will exit again to userspace with ``-EINTR``
+ after it finishes fetching the attestation request from firmware, at
+ which point the VMM can safely drop the file lock.
+
+ - Tools/libraries that perform updates to SNP firmware TCB values or
+ endorsement keys (e.g. via /dev/sev interfaces such as ``SNP_COMMIT``,
+ ``SNP_SET_CONFIG``, or ``SNP_VLEK_LOAD``, see
+ Documentation/virt/coco/sev-guest.rst for more details) in such a way
+ that the certificate blob needs to be updated, should similarly take an
+ exclusive lock on the certificate blob for the duration of any updates
+ to endorsement keys or the certificate blob contents to ensure that
+ VMMs using the above scheme will not return certificate blob data that
+ is out of sync with the endorsement key used by firmware at the time
+ the attestation request is actually issued.
+
+This scheme is recommended so that tools can use a fairly generic/natural
+approach to synchronizing firmware/certificate updates via file-locking,
+which should make it easier to maintain interoperability across
+tools/VMMs/vendors.
+
Device attribute API
====================
@@ -579,11 +625,15 @@ Attributes of the SEV implementation can be retrieved through the
``KVM_HAS_DEVICE_ATTR`` and ``KVM_GET_DEVICE_ATTR`` ioctls on the ``/dev/kvm``
device node, using group ``KVM_X86_GRP_SEV``.
-Currently only one attribute is implemented:
+The following attributes are currently implemented:
* ``KVM_X86_SEV_VMSA_FEATURES``: return the set of all bits that
are accepted in the ``vmsa_features`` of ``KVM_SEV_INIT2``.
+* ``KVM_X86_SEV_SNP_REQ_CERTS``: return a value of 1 if the kernel supports the
+ ``KVM_EXIT_SNP_REQ_CERTS`` exit, which allows for fetching endorsement key
+ certificates from userspace for each SNP attestation request the guest issues.
+
Firmware Management
===================
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index 7ceff6583652..b2c928c5965d 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -503,6 +503,7 @@ struct kvm_sync_regs {
#define KVM_X86_GRP_SEV 1
# define KVM_X86_SEV_VMSA_FEATURES 0
# define KVM_X86_SNP_POLICY_BITS 1
+# define KVM_X86_SEV_SNP_REQ_CERTS 2
struct kvm_vmx_nested_state_data {
__u8 vmcs12[KVM_STATE_NESTED_VMX_VMCS_SIZE];
@@ -743,6 +744,7 @@ enum sev_cmd_id {
KVM_SEV_SNP_LAUNCH_START = 100,
KVM_SEV_SNP_LAUNCH_UPDATE,
KVM_SEV_SNP_LAUNCH_FINISH,
+ KVM_SEV_SNP_ENABLE_REQ_CERTS,
KVM_SEV_NR_MAX,
};
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 2405c6fad95c..695463bc6c5b 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -2161,6 +2161,9 @@ int sev_dev_get_attr(u32 group, u64 attr, u64 *val)
*val = snp_supported_policy_bits;
return 0;
+ case KVM_X86_SEV_SNP_REQ_CERTS:
+ *val = sev_snp_enabled ? 1 : 0;
+ return 0;
default:
return -ENXIO;
}
@@ -2577,6 +2580,16 @@ static int snp_launch_finish(struct kvm *kvm, struct kvm_sev_cmd *argp)
return ret;
}
+static int snp_enable_certs(struct kvm *kvm)
+{
+ if (kvm->created_vcpus || !sev_snp_guest(kvm))
+ return -EINVAL;
+
+ to_kvm_sev_info(kvm)->snp_certs_enabled = true;
+
+ return 0;
+}
+
int sev_mem_enc_ioctl(struct kvm *kvm, void __user *argp)
{
struct kvm_sev_cmd sev_cmd;
@@ -2682,6 +2695,9 @@ int sev_mem_enc_ioctl(struct kvm *kvm, void __user *argp)
case KVM_SEV_SNP_LAUNCH_FINISH:
r = snp_launch_finish(kvm, &sev_cmd);
break;
+ case KVM_SEV_SNP_ENABLE_REQ_CERTS:
+ r = snp_enable_certs(kvm);
+ break;
default:
r = -EINVAL;
goto out;
--
2.25.1
^ permalink raw reply related
* [PATCH 1/1] PCI/IDE: Fix reading a wrong reg for unused sel stream initialization
From: Li Ming @ 2026-01-11 7:38 UTC (permalink / raw)
To: dan.j.williams; +Cc: linux-pci, linux-coco, linux-kernel, Li Ming
During pci_ide_init(), it will write PCI_ID_RESERVED_STREAM_ID into all
unused selective IDE stream blocks. In a selective IDE stream block, IDE
stream ID field is in selective IDE stream control register instead of
selective IDE stream capability register.
Fixes: 079115370d00 ("PCI/IDE: Initialize an ID for all IDE streams")
Signed-off-by: Li Ming <ming.li@zohomail.com>
---
drivers/pci/ide.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/ide.c b/drivers/pci/ide.c
index f0ef474e1a0d..26f7cc94ec31 100644
--- a/drivers/pci/ide.c
+++ b/drivers/pci/ide.c
@@ -168,7 +168,7 @@ void pci_ide_init(struct pci_dev *pdev)
for (u16 i = 0; i < nr_streams; i++) {
int pos = __sel_ide_offset(ide_cap, nr_link_ide, i, nr_ide_mem);
- pci_read_config_dword(pdev, pos + PCI_IDE_SEL_CAP, &val);
+ pci_read_config_dword(pdev, pos + PCI_IDE_SEL_CTL, &val);
if (val & PCI_IDE_SEL_CTL_EN)
continue;
val &= ~PCI_IDE_SEL_CTL_ID;
--
2.34.1
^ permalink raw reply related
* [PATCH 1/1] PCI/IDE: Fix using wrong VF ID for RID range calculation
From: Li Ming @ 2026-01-11 8:06 UTC (permalink / raw)
To: dan.j.williams; +Cc: linux-pci, linux-coco, linux-kernel, Li Ming
When allocate a new IDE stream for a pci device in SR-IOV case, the RID
range of the new IDE stream should cover all VFs of the device. VF id
range of a pci device is [0 - (num_VFs - 1)], so should use (num_VFs - )
as the last VF's ID.
Fixes: 1e4d2ff3ae45 ("PCI/IDE: Add IDE establishment helpers")
Signed-off-by: Li Ming <ming.li@zohomail.com>
---
drivers/pci/ide.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/ide.c b/drivers/pci/ide.c
index 26f7cc94ec31..9629f3ceb213 100644
--- a/drivers/pci/ide.c
+++ b/drivers/pci/ide.c
@@ -283,8 +283,8 @@ struct pci_ide *pci_ide_stream_alloc(struct pci_dev *pdev)
/* for SR-IOV case, cover all VFs */
num_vf = pci_num_vf(pdev);
if (num_vf)
- rid_end = PCI_DEVID(pci_iov_virtfn_bus(pdev, num_vf),
- pci_iov_virtfn_devfn(pdev, num_vf));
+ rid_end = PCI_DEVID(pci_iov_virtfn_bus(pdev, num_vf - 1),
+ pci_iov_virtfn_devfn(pdev, num_vf - 1));
else
rid_end = pci_dev_id(pdev);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 0/2] x86/virt/tdx: Print TDX module version to dmesg
From: Huang, Kai @ 2026-01-11 22:15 UTC (permalink / raw)
To: kvm@vger.kernel.org, linux-coco@lists.linux.dev, Verma, Vishal L,
linux-kernel@vger.kernel.org
Cc: Gao, Chao, Edgecombe, Rick P, bp@alien8.de, x86@kernel.org,
kas@kernel.org, hpa@zytor.com, mingo@redhat.com, Williams, Dan J,
tglx@linutronix.de, dave.hansen@linux.intel.com
In-Reply-To: <20260109-tdx_print_module_version-v2-0-e10e4ca5b450@intel.com>
On Fri, 2026-01-09 at 12:14 -0700, Verma, Vishal L wrote:
> === Problem & Solution ===
>
> Currently, there is neither an ABI, nor any other way to determine from
> the host system, what version of the TDX module is running. A sysfs ABI
> for this has been proposed in [1], but it may need additional discussion.
>
> Many/most TDX developers already carry patches like this in their
> development branches. It can be tricky to know which TDX module is
> actually loaded on a system, and so this functionality has been needed
> regularly for development and processing bug reports. Hence, it is
> prudent to break out the patches to retrieve and print the TDX module
> version, as those parts are very straightforward, and get some level of
> debugability and traceability for TDX host systems.
Big thanks for picking this up:
Reviewed-by: Kai Huang <kai.huang@intel.com>
^ permalink raw reply
* Re: [PATCH v4 04/16] x86/virt/tdx: Allocate page bitmap for Dynamic PAMT
From: Xu Yilun @ 2026-01-12 0:24 UTC (permalink / raw)
To: Edgecombe, Rick P
Cc: kvm@vger.kernel.org, linux-coco@lists.linux.dev, Huang, Kai,
Li, Xiaoyao, Hansen, Dave, Zhao, Yan Y, Wu, Binbin,
kas@kernel.org, seanjc@google.com, mingo@redhat.com,
pbonzini@redhat.com, tglx@linutronix.de, Yamahata, Isaku,
linux-kernel@vger.kernel.org, kirill.shutemov@linux.intel.com,
Annapurve, Vishal, Gao, Chao, bp@alien8.de, x86@kernel.org
In-Reply-To: <4b75ddb133d35d133725ba270a9dfcb9acda38b4.camel@intel.com>
On Fri, Jan 09, 2026 at 04:05:30PM +0000, Edgecombe, Rick P wrote:
> On Fri, 2026-01-09 at 10:18 +0800, Xu Yilun wrote:
> > On the other hand, the cost of a newly designed firmware interface
> > for an already online functionality is not low, especially when you
> > want backward compatibility to old TDX Module. The worst case is we
> > keep both sets of the code...
>
> I think TDX module changes are something to consider long term. We
> already discussed not overhauling the metadata reading again ahead of
> the current work, so I don't think there is anything else to discuss
> here.
I agree. We don't have to introduce new interfaces for optional feature
checking. That's another topic.
^ permalink raw reply
* Re: [PATCH v2 1/2] x86/virt/tdx: Retrieve TDX module version
From: Xiaoyao Li @ 2026-01-12 2:25 UTC (permalink / raw)
To: Vishal Verma, linux-kernel, linux-coco, kvm
Cc: x86, Chao Gao, Dan Williams, Kai Huang, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
Kiryl Shutsemau, Rick Edgecombe
In-Reply-To: <20260109-tdx_print_module_version-v2-1-e10e4ca5b450@intel.com>
On 1/10/2026 3:14 AM, Vishal Verma wrote:
> From: Chao Gao <chao.gao@intel.com>
>
> Each TDX module has several bits of metadata about which specific TDX
> module it is. The primary bit of info is the version, which has an x.y.z
> format. These represent the major version, minor version, and update
> version respectively. Knowing the running TDX Module version is valuable
> for bug reporting and debugging. Note that the module does expose other
> pieces of version-related metadata, such as build number and date. Those
> aren't retrieved for now, that can be added if needed in the future.
>
> Retrieve the TDX Module version using the existing metadata reading
> interface. Later changes will expose this information. The metadata
> reading interfaces have existed for quite some time, so this will work
> with older versions of the TDX module as well - i.e. this isn't a new
> interface.
>
> As a side note, the global metadata reading code was originally set up
> to be auto-generated from a JSON definition [1]. However, later [2] this
> was found to be unsustainable, and the autogeneration approach was
> dropped in favor of just manually adding fields as needed (e.g. as in
> this patch).
>
> Signed-off-by: Chao Gao <chao.gao@intel.com>
> Link: https://lore.kernel.org/kvm/CABgObfYXUxqQV_FoxKjC8U3t5DnyM45nz5DpTxYZv2x_uFK_Kw@mail.gmail.com/ # [1]
> Link: https://lore.kernel.org/all/1e7bcbad-eb26-44b7-97ca-88ab53467212@intel.com/ # [2]
> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Cc: Kai Huang <kai.huang@intel.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Reviewed-by: Kiryl Shutsemau <kas@kernel.org>
> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Though one nit below,
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
> ---
> arch/x86/include/asm/tdx_global_metadata.h | 7 +++++++
> arch/x86/virt/vmx/tdx/tdx_global_metadata.c | 16 ++++++++++++++++
> 2 files changed, 23 insertions(+)
>
> diff --git a/arch/x86/include/asm/tdx_global_metadata.h b/arch/x86/include/asm/tdx_global_metadata.h
> index 060a2ad744bff..40689c8dc67eb 100644
> --- a/arch/x86/include/asm/tdx_global_metadata.h
> +++ b/arch/x86/include/asm/tdx_global_metadata.h
> @@ -5,6 +5,12 @@
>
> #include <linux/types.h>
>
> +struct tdx_sys_info_version {
> + u16 minor_version;
> + u16 major_version;
Nit, not sure if better to move major_version before minor_version.
and ...
> +static int get_tdx_sys_info_version(struct tdx_sys_info_version *sysinfo_version)
> +{
> + int ret = 0;
> + u64 val;
> +
> + if (!ret && !(ret = read_sys_metadata_field(0x0800000100000003, &val)))
> + sysinfo_version->minor_version = val;
> + if (!ret && !(ret = read_sys_metadata_field(0x0800000100000004, &val)))
> + sysinfo_version->major_version = val;
> + if (!ret && !(ret = read_sys_metadata_field(0x0800000100000005, &val)))
> + sysinfo_version->update_version = val;
... I know it's because minor_version has the least field ID among the
three. But the order of the field IDs doesn't stand for the order of the
reading. Reading the middle part y of x.y.z as first step looks a bit odd.
^ permalink raw reply
* Re: [PATCH v2 2/2] x86/virt/tdx: Print TDX module version during init
From: Xiaoyao Li @ 2026-01-12 2:31 UTC (permalink / raw)
To: Vishal Verma, linux-kernel, linux-coco, kvm
Cc: x86, Chao Gao, Dan Williams, Kai Huang, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
Kiryl Shutsemau, Rick Edgecombe
In-Reply-To: <20260109-tdx_print_module_version-v2-2-e10e4ca5b450@intel.com>
On 1/10/2026 3:14 AM, Vishal Verma wrote:
> It is useful to print the TDX module version in dmesg logs. This is
> currently the only way to determine the module version from the host. It
> also creates a record for any future problems being investigated. This
> was also requested in [1].
>
> Include the version in the log messages during init, e.g.:
>
> virt/tdx: TDX module version: 1.5.24
> virt/tdx: 1034220 KB allocated for PAMT
> virt/tdx: module initialized
>
> Print the version in get_tdx_sys_info(), right after the version
> metadata is read, which makes it available even if there are subsequent
> initialization failures.
>
> Based on a patch by Kai Huang <kai.huang@intel.com> [2]
>
> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> Reviewed-by: Chao Gao <chao.gao@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
> Cc: Chao Gao <chao.gao@intel.com>
> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Cc: Kai Huang <kai.huang@intel.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Link: https://lore.kernel.org/all/CAGtprH8eXwi-TcH2+-Fo5YdbEwGmgLBh9ggcDvd6N=bsKEJ_WQ@mail.gmail.com/ # [1]
> Link: https://lore.kernel.org/all/6b5553756f56a8e3222bfc36d0bdb3e5192137b7.1731318868.git.kai.huang@intel.com # [2]
> ---
> arch/x86/virt/vmx/tdx/tdx_global_metadata.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/x86/virt/vmx/tdx/tdx_global_metadata.c b/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
> index 0454124803f3..4c9917a9c2c3 100644
> --- a/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
> +++ b/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
> @@ -105,6 +105,12 @@ static int get_tdx_sys_info(struct tdx_sys_info *sysinfo)
> int ret = 0;
>
> ret = ret ?: get_tdx_sys_info_version(&sysinfo->version);
> +
> + pr_info("Module version: %u.%u.%02u\n",
> + sysinfo->version.major_version,
> + sysinfo->version.minor_version,
> + sysinfo->version.update_version);
> +
> ret = ret ?: get_tdx_sys_info_features(&sysinfo->features);
> ret = ret ?: get_tdx_sys_info_tdmr(&sysinfo->tdmr);
> ret = ret ?: get_tdx_sys_info_td_ctrl(&sysinfo->td_ctrl);
>
^ permalink raw reply
* Re: [PATCH 1/1] PCI/IDE: Fix using wrong VF ID for RID range calculation
From: Xu Yilun @ 2026-01-12 2:30 UTC (permalink / raw)
To: Li Ming; +Cc: dan.j.williams, linux-pci, linux-coco, linux-kernel
In-Reply-To: <20260111080631.506487-1-ming.li@zohomail.com>
On Sun, Jan 11, 2026 at 04:06:31PM +0800, Li Ming wrote:
> When allocate a new IDE stream for a pci device in SR-IOV case, the RID
> range of the new IDE stream should cover all VFs of the device. VF id
> range of a pci device is [0 - (num_VFs - 1)], so should use (num_VFs - )
> as the last VF's ID.
>
> Fixes: 1e4d2ff3ae45 ("PCI/IDE: Add IDE establishment helpers")
> Signed-off-by: Li Ming <ming.li@zohomail.com>
> ---
> drivers/pci/ide.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/ide.c b/drivers/pci/ide.c
> index 26f7cc94ec31..9629f3ceb213 100644
> --- a/drivers/pci/ide.c
> +++ b/drivers/pci/ide.c
> @@ -283,8 +283,8 @@ struct pci_ide *pci_ide_stream_alloc(struct pci_dev *pdev)
> /* for SR-IOV case, cover all VFs */
> num_vf = pci_num_vf(pdev);
> if (num_vf)
> - rid_end = PCI_DEVID(pci_iov_virtfn_bus(pdev, num_vf),
> - pci_iov_virtfn_devfn(pdev, num_vf));
> + rid_end = PCI_DEVID(pci_iov_virtfn_bus(pdev, num_vf - 1),
> + pci_iov_virtfn_devfn(pdev, num_vf - 1));
I don't have VF for test but I believe the change is correct.
The calculated rid_end will be passed to IDE RID association register values,
which is inclusive according to IDE SPEC.
void pci_ide_stream_to_regs(...)
{
...
regs->rid1 = FIELD_PREP(PCI_IDE_SEL_RID_1_LIMIT, settings->rid_end);
...
}
Is it better we clarify the kernel-doc a little bit:
--------8<--------
diff --git a/include/linux/pci-ide.h b/include/linux/pci-ide.h
index 2521a2914294..f0c6975fd429 100644
--- a/include/linux/pci-ide.h
+++ b/include/linux/pci-ide.h
@@ -26,7 +26,7 @@ enum pci_ide_partner_select {
/**
* struct pci_ide_partner - Per port pair Selective IDE Stream settings
* @rid_start: Partner Port Requester ID range start
- * @rid_end: Partner Port Requester ID range end
+ * @rid_end: Partner Port Requester ID range end (inclusive)
* @stream_index: Selective IDE Stream Register Block selection
* @mem_assoc: PCI bus memory address association for targeting peer partner
* @pref_assoc: PCI bus prefetchable memory address association for
^ permalink raw reply related
* Re: [PATCH 1/1] PCI/IDE: Fix reading a wrong reg for unused sel stream initialization
From: Xu Yilun @ 2026-01-12 2:54 UTC (permalink / raw)
To: Li Ming; +Cc: dan.j.williams, linux-pci, linux-coco, linux-kernel
In-Reply-To: <20260111073823.486665-1-ming.li@zohomail.com>
On Sun, Jan 11, 2026 at 03:38:23PM +0800, Li Ming wrote:
> During pci_ide_init(), it will write PCI_ID_RESERVED_STREAM_ID into all
> unused selective IDE stream blocks. In a selective IDE stream block, IDE
> stream ID field is in selective IDE stream control register instead of
> selective IDE stream capability register.
>
> Fixes: 079115370d00 ("PCI/IDE: Initialize an ID for all IDE streams")
> Signed-off-by: Li Ming <ming.li@zohomail.com>
> ---
> drivers/pci/ide.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/ide.c b/drivers/pci/ide.c
> index f0ef474e1a0d..26f7cc94ec31 100644
> --- a/drivers/pci/ide.c
> +++ b/drivers/pci/ide.c
> @@ -168,7 +168,7 @@ void pci_ide_init(struct pci_dev *pdev)
> for (u16 i = 0; i < nr_streams; i++) {
> int pos = __sel_ide_offset(ide_cap, nr_link_ide, i, nr_ide_mem);
>
> - pci_read_config_dword(pdev, pos + PCI_IDE_SEL_CAP, &val);
> + pci_read_config_dword(pdev, pos + PCI_IDE_SEL_CTL, &val);
Reviewed-by: Xu Yilun <yilun.xu@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v2 1/2] x86/virt/tdx: Retrieve TDX module version
From: Binbin Wu @ 2026-01-12 8:30 UTC (permalink / raw)
To: Vishal Verma
Cc: linux-kernel, linux-coco, kvm, x86, Chao Gao, Dan Williams,
Kai Huang, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Kiryl Shutsemau, Rick Edgecombe
In-Reply-To: <20260109-tdx_print_module_version-v2-1-e10e4ca5b450@intel.com>
On 1/10/2026 3:14 AM, Vishal Verma wrote:
> From: Chao Gao <chao.gao@intel.com>
>
> Each TDX module has several bits of metadata about which specific TDX
> module it is. The primary bit of info is the version, which has an x.y.z
> format. These represent the major version, minor version, and update
> version respectively. Knowing the running TDX Module version is valuable
> for bug reporting and debugging. Note that the module does expose other
> pieces of version-related metadata, such as build number and date. Those
> aren't retrieved for now, that can be added if needed in the future.
>
> Retrieve the TDX Module version using the existing metadata reading
> interface. Later changes will expose this information. The metadata
> reading interfaces have existed for quite some time, so this will work
> with older versions of the TDX module as well - i.e. this isn't a new
> interface.
>
> As a side note, the global metadata reading code was originally set up
> to be auto-generated from a JSON definition [1]. However, later [2] this
> was found to be unsustainable, and the autogeneration approach was
> dropped in favor of just manually adding fields as needed (e.g. as in
> this patch).
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
>
> Signed-off-by: Chao Gao <chao.gao@intel.com>
> Link: https://lore.kernel.org/kvm/CABgObfYXUxqQV_FoxKjC8U3t5DnyM45nz5DpTxYZv2x_uFK_Kw@mail.gmail.com/ # [1]
> Link: https://lore.kernel.org/all/1e7bcbad-eb26-44b7-97ca-88ab53467212@intel.com/ # [2]
> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Cc: Kai Huang <kai.huang@intel.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Reviewed-by: Kiryl Shutsemau <kas@kernel.org>
> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> ---
> arch/x86/include/asm/tdx_global_metadata.h | 7 +++++++
> arch/x86/virt/vmx/tdx/tdx_global_metadata.c | 16 ++++++++++++++++
> 2 files changed, 23 insertions(+)
>
> diff --git a/arch/x86/include/asm/tdx_global_metadata.h b/arch/x86/include/asm/tdx_global_metadata.h
> index 060a2ad744bff..40689c8dc67eb 100644
> --- a/arch/x86/include/asm/tdx_global_metadata.h
> +++ b/arch/x86/include/asm/tdx_global_metadata.h
> @@ -5,6 +5,12 @@
>
> #include <linux/types.h>
>
> +struct tdx_sys_info_version {
> + u16 minor_version;
> + u16 major_version;
> + u16 update_version;
> +};
> +
> struct tdx_sys_info_features {
> u64 tdx_features0;
> };
> @@ -35,6 +41,7 @@ struct tdx_sys_info_td_conf {
> };
>
> struct tdx_sys_info {
> + struct tdx_sys_info_version version;
> struct tdx_sys_info_features features;
> struct tdx_sys_info_tdmr tdmr;
> struct tdx_sys_info_td_ctrl td_ctrl;
> diff --git a/arch/x86/virt/vmx/tdx/tdx_global_metadata.c b/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
> index 13ad2663488b1..0454124803f36 100644
> --- a/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
> +++ b/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
> @@ -7,6 +7,21 @@
> * Include this file to other C file instead.
> */
>
> +static int get_tdx_sys_info_version(struct tdx_sys_info_version *sysinfo_version)
> +{
> + int ret = 0;
> + u64 val;
> +
> + if (!ret && !(ret = read_sys_metadata_field(0x0800000100000003, &val)))
> + sysinfo_version->minor_version = val;
> + if (!ret && !(ret = read_sys_metadata_field(0x0800000100000004, &val)))
> + sysinfo_version->major_version = val;
> + if (!ret && !(ret = read_sys_metadata_field(0x0800000100000005, &val)))
> + sysinfo_version->update_version = val;
> +
> + return ret;
> +}
> +
> static int get_tdx_sys_info_features(struct tdx_sys_info_features *sysinfo_features)
> {
> int ret = 0;
> @@ -89,6 +104,7 @@ static int get_tdx_sys_info(struct tdx_sys_info *sysinfo)
> {
> int ret = 0;
>
> + ret = ret ?: get_tdx_sys_info_version(&sysinfo->version);
> ret = ret ?: get_tdx_sys_info_features(&sysinfo->features);
> ret = ret ?: get_tdx_sys_info_tdmr(&sysinfo->tdmr);
> ret = ret ?: get_tdx_sys_info_td_ctrl(&sysinfo->td_ctrl);
>
^ permalink raw reply
* Re: [PATCH v2 2/2] x86/virt/tdx: Print TDX module version during init
From: Binbin Wu @ 2026-01-12 8:32 UTC (permalink / raw)
To: Vishal Verma
Cc: linux-kernel, linux-coco, kvm, x86, Chao Gao, Dan Williams,
Kai Huang, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Kiryl Shutsemau, Rick Edgecombe
In-Reply-To: <20260109-tdx_print_module_version-v2-2-e10e4ca5b450@intel.com>
On 1/10/2026 3:14 AM, Vishal Verma wrote:
> It is useful to print the TDX module version in dmesg logs. This is
> currently the only way to determine the module version from the host. It
> also creates a record for any future problems being investigated. This
> was also requested in [1].
>
> Include the version in the log messages during init, e.g.:
>
> virt/tdx: TDX module version: 1.5.24
> virt/tdx: 1034220 KB allocated for PAMT
> virt/tdx: module initialized
>
> Print the version in get_tdx_sys_info(), right after the version
> metadata is read, which makes it available even if there are subsequent
> initialization failures.
>
> Based on a patch by Kai Huang <kai.huang@intel.com> [2]
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
One nit below.
>
> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> Reviewed-by: Chao Gao <chao.gao@intel.com>
> Cc: Chao Gao <chao.gao@intel.com>
> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Cc: Kai Huang <kai.huang@intel.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Link: https://lore.kernel.org/all/CAGtprH8eXwi-TcH2+-Fo5YdbEwGmgLBh9ggcDvd6N=bsKEJ_WQ@mail.gmail.com/ # [1]
> Link: https://lore.kernel.org/all/6b5553756f56a8e3222bfc36d0bdb3e5192137b7.1731318868.git.kai.huang@intel.com # [2]
> ---
> arch/x86/virt/vmx/tdx/tdx_global_metadata.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/x86/virt/vmx/tdx/tdx_global_metadata.c b/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
> index 0454124803f3..4c9917a9c2c3 100644
> --- a/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
> +++ b/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
> @@ -105,6 +105,12 @@ static int get_tdx_sys_info(struct tdx_sys_info *sysinfo)
> int ret = 0;
>
> ret = ret ?: get_tdx_sys_info_version(&sysinfo->version);
> +
> + pr_info("Module version: %u.%u.%02u\n",
> + sysinfo->version.major_version,
> + sysinfo->version.minor_version,
> + sysinfo->version.update_version);
> +
Nit:
There is a mismatch b/t the change log and the code.
The printed message will be
virt/tdx: Module version: x.x.xx
instead of the format in the change log
virt/tdx: TDX module version: x.x.xx
> ret = ret ?: get_tdx_sys_info_features(&sysinfo->features);
> ret = ret ?: get_tdx_sys_info_tdmr(&sysinfo->tdmr);
> ret = ret ?: get_tdx_sys_info_td_ctrl(&sysinfo->td_ctrl);
>
^ permalink raw reply
* Re: [PATCH v3 2/6] KVM: guest_memfd: Remove partial hugepage handling from kvm_gmem_populate()
From: Yan Zhao @ 2026-01-12 9:39 UTC (permalink / raw)
To: Michael Roth
Cc: kvm, linux-coco, linux-mm, linux-kernel, thomas.lendacky,
pbonzini, seanjc, vbabka, ashish.kalra, liam.merwick, david,
vannapurve, ackerleytng, aik, ira.weiny, pankaj.gupta, Kai Huang
In-Reply-To: <20260108214622.1084057-3-michael.roth@amd.com>
Tested-by: Yan Zhao <yan.y.zhao@intel.com>
Reviewed-by: Yan Zhao <yan.y.zhao@intel.com>
> @@ -848,7 +857,7 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src, long
> filemap_invalidate_lock(file->f_mapping);
>
> npages = min_t(ulong, slot->npages - (start_gfn - slot->base_gfn), npages);
> - for (i = 0; i < npages; i += (1 << max_order)) {
> + for (i = 0; i < npages; i++) {
> struct folio *folio;
> gfn_t gfn = start_gfn + i;
> pgoff_t index = kvm_gmem_get_index(slot, gfn);
> @@ -860,7 +869,7 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src, long
> break;
> }
>
> - folio = __kvm_gmem_get_pfn(file, slot, index, &pfn, &is_prepared, &max_order);
> + folio = __kvm_gmem_get_pfn(file, slot, index, &pfn, &is_prepared, NULL);
> if (IS_ERR(folio)) {
> ret = PTR_ERR(folio);
> break;
> @@ -874,20 +883,15 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src, long
> }
>
> folio_unlock(folio);
> - WARN_ON(!IS_ALIGNED(gfn, 1 << max_order) ||
> - (npages - i) < (1 << max_order));
>
> ret = -EINVAL;
Nit: Can move this "ret = -EINVAL" to inside the "if". i.e.,
if (!kvm_gmem_range_is_private(gi, index, 1, kvm, gfn)) {
ret = -EINVAL;
goto put_folio_and_exit;
}
> - while (!kvm_range_has_memory_attributes(kvm, gfn, gfn + (1 << max_order),
> - KVM_MEMORY_ATTRIBUTE_PRIVATE,
> - KVM_MEMORY_ATTRIBUTE_PRIVATE)) {
> - if (!max_order)
> - goto put_folio_and_exit;
> - max_order--;
> - }
> + if (!kvm_range_has_memory_attributes(kvm, gfn, gfn + 1,
> + KVM_MEMORY_ATTRIBUTE_PRIVATE,
> + KVM_MEMORY_ATTRIBUTE_PRIVATE))
> + goto put_folio_and_exit;
>
> p = src ? src + i * PAGE_SIZE : NULL;
> - ret = post_populate(kvm, gfn, pfn, p, max_order, opaque);
> + ret = post_populate(kvm, gfn, pfn, p, opaque);
> if (!ret)
> kvm_gmem_mark_prepared(folio);
>
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v3 5/6] KVM: TDX: Document alignment requirements for KVM_TDX_INIT_MEM_REGION
From: Yan Zhao @ 2026-01-12 9:40 UTC (permalink / raw)
To: Michael Roth
Cc: kvm, linux-coco, linux-mm, linux-kernel, thomas.lendacky,
pbonzini, seanjc, vbabka, ashish.kalra, liam.merwick, david,
vannapurve, ackerleytng, aik, ira.weiny, pankaj.gupta, Kai Huang
In-Reply-To: <20260108214622.1084057-6-michael.roth@amd.com>
Reviewed-by: Yan Zhao <yan.y.zhao@intel.com>
On Thu, Jan 08, 2026 at 03:46:21PM -0600, Michael Roth wrote:
> Since it was never possible to use a non-PAGE_SIZE-aligned @source_addr,
> go ahead and document this as a requirement. This is in preparation for
> enforcing page-aligned @source_addr for all architectures in
> guest_memfd.
>
> Reviewed-by: Vishal Annapurve <vannapurve@google.com>
> Tested-by: Kai Huang <kai.huang@intel.com>
> Signed-off-by: Michael Roth <michael.roth@amd.com>
> ---
> Documentation/virt/kvm/x86/intel-tdx.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/virt/kvm/x86/intel-tdx.rst b/Documentation/virt/kvm/x86/intel-tdx.rst
> index 5efac62c92c7..6a222e9d0954 100644
> --- a/Documentation/virt/kvm/x86/intel-tdx.rst
> +++ b/Documentation/virt/kvm/x86/intel-tdx.rst
> @@ -156,7 +156,7 @@ KVM_TDX_INIT_MEM_REGION
> :Returns: 0 on success, <0 on error
>
> Initialize @nr_pages TDX guest private memory starting from @gpa with userspace
> -provided data from @source_addr.
> +provided data from @source_addr. @source_addr must be PAGE_SIZE-aligned.
>
> Note, before calling this sub command, memory attribute of the range
> [gpa, gpa + nr_pages] needs to be private. Userspace can use
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v3 6/6] KVM: guest_memfd: GUP source pages prior to populating guest memory
From: Yan Zhao @ 2026-01-12 9:41 UTC (permalink / raw)
To: Michael Roth
Cc: kvm, linux-coco, linux-mm, linux-kernel, thomas.lendacky,
pbonzini, seanjc, vbabka, ashish.kalra, liam.merwick, david,
vannapurve, ackerleytng, aik, ira.weiny, pankaj.gupta, Kai Huang
In-Reply-To: <20260108214622.1084057-7-michael.roth@amd.com>
Tested-by: Yan Zhao <yan.y.zhao@intel.com>
Reviewed-by: Yan Zhao <yan.y.zhao@intel.com>
^ permalink raw reply
* Re: [PATCH v2 2/2] x86/virt/tdx: Print TDX module version during init
From: Kiryl Shutsemau @ 2026-01-12 11:23 UTC (permalink / raw)
To: Vishal Verma
Cc: linux-kernel, linux-coco, kvm, x86, Chao Gao, Dan Williams,
Kai Huang, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Rick Edgecombe
In-Reply-To: <20260109-tdx_print_module_version-v2-2-e10e4ca5b450@intel.com>
On Fri, Jan 09, 2026 at 12:14:31PM -0700, Vishal Verma wrote:
> It is useful to print the TDX module version in dmesg logs. This is
> currently the only way to determine the module version from the host. It
> also creates a record for any future problems being investigated. This
> was also requested in [1].
>
> Include the version in the log messages during init, e.g.:
>
> virt/tdx: TDX module version: 1.5.24
> virt/tdx: 1034220 KB allocated for PAMT
> virt/tdx: module initialized
>
> Print the version in get_tdx_sys_info(), right after the version
> metadata is read, which makes it available even if there are subsequent
> initialization failures.
>
> Based on a patch by Kai Huang <kai.huang@intel.com> [2]
>
> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> Reviewed-by: Chao Gao <chao.gao@intel.com>
> Cc: Chao Gao <chao.gao@intel.com>
> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Cc: Kai Huang <kai.huang@intel.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Link: https://lore.kernel.org/all/CAGtprH8eXwi-TcH2+-Fo5YdbEwGmgLBh9ggcDvd6N=bsKEJ_WQ@mail.gmail.com/ # [1]
> Link: https://lore.kernel.org/all/6b5553756f56a8e3222bfc36d0bdb3e5192137b7.1731318868.git.kai.huang@intel.com # [2]
Reviewed-by: Kiryl Shutsemau <kas@kernel.org>
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH] dma-direct: swiotlb: Skip encryption toggles for swiotlb allocations
From: Robin Murphy @ 2026-01-12 13:25 UTC (permalink / raw)
To: Aneesh Kumar K.V, iommu, linux-kernel, linux-coco
Cc: Marek Szyprowski, steven.price, Suzuki K Poulose
In-Reply-To: <yq5a7btr5wii.fsf@kernel.org>
On 2026-01-09 2:51 am, Aneesh Kumar K.V wrote:
> Robin Murphy <robin.murphy@arm.com> writes:
>
>> On 2026-01-02 3:54 pm, Aneesh Kumar K.V (Arm) wrote:
>>> Swiotlb backing pages are already mapped decrypted via
>>> swiotlb_update_mem_attributes(), so dma-direct does not need to call
>>> set_memory_decrypted() during allocation or re-encrypt the memory on
>>> free.
>>>
>>> Handle swiotlb-backed buffers explicitly: obtain the DMA address and
>>> zero the linear mapping for lowmem pages, and bypass the decrypt/encrypt
>>> transitions when allocating/freeing from the swiotlb pool (detected via
>>> swiotlb_find_pool()).
>>
>> swiotlb_update_mem_attributes() only applies to the default SWIOTLB
>> buffer, while the dma_direct_alloc_swiotlb() path is only for private
>> restricted pools (because the whole point is that restricted DMA devices
>> cannot use the regular allocator/default pools). There is no redundancy
>> here AFAICS.
>>
>
> But rmem_swiotlb_device_init() is also marking the entire pool decrypted
>
> set_memory_decrypted((unsigned long)phys_to_virt(rmem->base),
> rmem->size >> PAGE_SHIFT);
OK, so why doesn't the commit message mention that instead of saying
something which fails to justify the patch at all? ;)
Furthermore, how much does this actually matter? The "real" restricted
DMA use-case is on systems where dma_set_decrypted() is a no-op anyway.
I know we used restricted DMA as a hack in the early days of CCA
prototyping, but is it intended to actually deploy that as a supported
and recommended mechanism now?
Note also that the swiotlb_alloc path is essentially an emergency
fallback, which doesn't work for all situations anyway - any restricted
device that actually needs to make significant coherent allocations (or
rather, that firmware cannot assume won't want to do so) should really
have a proper coherent pool alongside its restricted one. The expected
use-case here is for something like a wifi driver that only needs to
allocate one or two small coherent buffers once at startup, then do
everything else with streaming DMA.
Thanks,
Robin.
>
> -aneesh
>
>>
>> Thanks,
>> Robin.
>>
>>> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>>> ---
>>> kernel/dma/direct.c | 56 +++++++++++++++++++++++++++++++++++++--------
>>> 1 file changed, 46 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
>>> index faf1e41afde8..c4ef4457bd74 100644
>>> --- a/kernel/dma/direct.c
>>> +++ b/kernel/dma/direct.c
>>> @@ -104,15 +104,27 @@ static void __dma_direct_free_pages(struct device *dev, struct page *page,
>>> dma_free_contiguous(dev, page, size);
>>> }
>>>
>>> -static struct page *dma_direct_alloc_swiotlb(struct device *dev, size_t size)
>>> +static struct page *dma_direct_alloc_swiotlb(struct device *dev, size_t size,
>>> + dma_addr_t *dma_handle)
>>> {
>>> - struct page *page = swiotlb_alloc(dev, size);
>>> + void *lm_addr;
>>> + struct page *page;
>>> +
>>> + page = swiotlb_alloc(dev, size);
>>> + if (!page)
>>> + return NULL;
>>>
>>> - if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
>>> + if (!dma_coherent_ok(dev, page_to_phys(page), size)) {
>>> swiotlb_free(dev, page, size);
>>> return NULL;
>>> }
>>> + /* If HighMem let caller take care of creating a mapping */
>>> + if (PageHighMem(page))
>>> + return page;
>>>
>>> + lm_addr = page_address(page);
>>> + memset(lm_addr, 0, size);
>>> + *dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
>>> return page;
>>> }
>>>
>>> @@ -125,9 +137,6 @@ static struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
>>>
>>> WARN_ON_ONCE(!PAGE_ALIGNED(size));
>>>
>>> - if (is_swiotlb_for_alloc(dev))
>>> - return dma_direct_alloc_swiotlb(dev, size);
>>> -
>>> gfp |= dma_direct_optimal_gfp_mask(dev, &phys_limit);
>>> page = dma_alloc_contiguous(dev, size, gfp);
>>> if (page) {
>>> @@ -204,6 +213,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>>> dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
>>> {
>>> bool remap = false, set_uncached = false;
>>> + bool mark_mem_decrypt = true;
>>> bool allow_highmem = true;
>>> struct page *page;
>>> void *ret;
>>> @@ -251,6 +261,14 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>>> dma_direct_use_pool(dev, gfp))
>>> return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
>>>
>>> + if (is_swiotlb_for_alloc(dev)) {
>>> + page = dma_direct_alloc_swiotlb(dev, size, dma_handle);
>>> + if (page) {
>>> + mark_mem_decrypt = false;
>>> + goto setup_page;
>>> + }
>>> + return NULL;
>>> + }
>>>
>>> if (force_dma_unencrypted(dev))
>>> /*
>>> @@ -266,6 +284,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>>> if (!page)
>>> return NULL;
>>>
>>> +setup_page:
>>> /*
>>> * dma_alloc_contiguous can return highmem pages depending on a
>>> * combination the cma= arguments and per-arch setup. These need to be
>>> @@ -295,7 +314,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>>> ret = page_address(page);
>>> }
>>>
>>> - if (force_dma_unencrypted(dev)) {
>>> + if (mark_mem_decrypt && force_dma_unencrypted(dev)) {
>>> void *lm_addr;
>>>
>>> lm_addr = page_address(page);
>>> @@ -316,7 +335,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>>> return ret;
>>>
>>> out_encrypt_pages:
>>> - if (dma_set_encrypted(dev, page_address(page), size))
>>> + if (mark_mem_decrypt && dma_set_encrypted(dev, page_address(page), size))
>>> return NULL;
>>> out_free_pages:
>>> __dma_direct_free_pages(dev, page, size);
>>> @@ -328,6 +347,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>>> void dma_direct_free(struct device *dev, size_t size,
>>> void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs)
>>> {
>>> + bool mark_mem_encrypted = true;
>>> unsigned int page_order = get_order(size);
>>>
>>> if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
>>> @@ -356,6 +376,9 @@ void dma_direct_free(struct device *dev, size_t size,
>>> dma_free_from_pool(dev, cpu_addr, PAGE_ALIGN(size)))
>>> return;
>>>
>>> + if (swiotlb_find_pool(dev, dma_to_phys(dev, dma_addr)))
>>> + mark_mem_encrypted = false;
>>> +
>>> if (is_vmalloc_addr(cpu_addr)) {
>>> vunmap(cpu_addr);
>>> } else {
>>> @@ -363,7 +386,7 @@ void dma_direct_free(struct device *dev, size_t size,
>>> arch_dma_clear_uncached(cpu_addr, size);
>>> }
>>>
>>> - if (force_dma_unencrypted(dev)) {
>>> + if (mark_mem_encrypted && force_dma_unencrypted(dev)) {
>>> void *lm_addr;
>>>
>>> lm_addr = phys_to_virt(dma_to_phys(dev, dma_addr));
>>> @@ -385,6 +408,15 @@ struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
>>> if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp))
>>> return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
>>>
>>> + if (is_swiotlb_for_alloc(dev)) {
>>> + page = dma_direct_alloc_swiotlb(dev, size, dma_handle);
>>> + if (page && PageHighMem(page)) {
>>> + swiotlb_free(dev, page, size);
>>> + return NULL;
>>> + }
>>> + return page;
>>> + }
>>> +
>>> page = __dma_direct_alloc_pages(dev, size, gfp, false);
>>> if (!page)
>>> return NULL;
>>> @@ -404,13 +436,17 @@ void dma_direct_free_pages(struct device *dev, size_t size,
>>> enum dma_data_direction dir)
>>> {
>>> void *vaddr = page_address(page);
>>> + bool mark_mem_encrypted = true;
>>>
>>> /* If cpu_addr is not from an atomic pool, dma_free_from_pool() fails */
>>> if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
>>> dma_free_from_pool(dev, vaddr, size))
>>> return;
>>>
>>> - if (dma_set_encrypted(dev, vaddr, size))
>>> + if (swiotlb_find_pool(dev, page_to_phys(page)))
>>> + mark_mem_encrypted = false;
>>> +
>>> + if (mark_mem_encrypted && dma_set_encrypted(dev, vaddr, size))
>>> return;
>>> __dma_direct_free_pages(dev, page, size);
>>> }
^ permalink raw reply
* Re: [PATCH v2 1/2] x86/virt/tdx: Retrieve TDX module version
From: Dave Hansen @ 2026-01-12 14:56 UTC (permalink / raw)
To: Xiaoyao Li, Vishal Verma, linux-kernel, linux-coco, kvm
Cc: x86, Chao Gao, Dan Williams, Kai Huang, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
Kiryl Shutsemau, Rick Edgecombe
In-Reply-To: <93ab41bc-91bf-405a-84c4-6355a556596d@intel.com>
On 1/11/26 18:25, Xiaoyao Li wrote:
> ... I know it's because minor_version has the least field ID among the
> three. But the order of the field IDs doesn't stand for the order of the
> reading. Reading the middle part y of x.y.z as first step looks a bit odd.
I wouldn't sweat it either way. Reading 4, 3, 5 would also look odd. I'm
fine with it as-is in the patch.
^ permalink raw reply
* Re: [PATCH] dma-direct: swiotlb: Skip encryption toggles for swiotlb allocations
From: Aneesh Kumar K.V @ 2026-01-12 15:42 UTC (permalink / raw)
To: Robin Murphy, iommu, linux-kernel, linux-coco
Cc: Marek Szyprowski, steven.price, Suzuki K Poulose, Claire Chang
In-Reply-To: <1290fd7e-bfaf-47ce-b12f-cca0b938b293@arm.com>
Robin Murphy <robin.murphy@arm.com> writes:
> On 2026-01-09 2:51 am, Aneesh Kumar K.V wrote:
>> Robin Murphy <robin.murphy@arm.com> writes:
>>
>>> On 2026-01-02 3:54 pm, Aneesh Kumar K.V (Arm) wrote:
>>>> Swiotlb backing pages are already mapped decrypted via
>>>> swiotlb_update_mem_attributes(), so dma-direct does not need to call
>>>> set_memory_decrypted() during allocation or re-encrypt the memory on
>>>> free.
>>>>
>>>> Handle swiotlb-backed buffers explicitly: obtain the DMA address and
>>>> zero the linear mapping for lowmem pages, and bypass the decrypt/encrypt
>>>> transitions when allocating/freeing from the swiotlb pool (detected via
>>>> swiotlb_find_pool()).
>>>
>>> swiotlb_update_mem_attributes() only applies to the default SWIOTLB
>>> buffer, while the dma_direct_alloc_swiotlb() path is only for private
>>> restricted pools (because the whole point is that restricted DMA devices
>>> cannot use the regular allocator/default pools). There is no redundancy
>>> here AFAICS.
>>>
>>
>> But rmem_swiotlb_device_init() is also marking the entire pool decrypted
>>
>> set_memory_decrypted((unsigned long)phys_to_virt(rmem->base),
>> rmem->size >> PAGE_SHIFT);
>
> OK, so why doesn't the commit message mention that instead of saying
> something which fails to justify the patch at all? ;)
>
> Furthermore, how much does this actually matter? The "real" restricted
> DMA use-case is on systems where dma_set_decrypted() is a no-op anyway.
> I know we used restricted DMA as a hack in the early days of CCA
> prototyping, but is it intended to actually deploy that as a supported
> and recommended mechanism now?
>
> Note also that the swiotlb_alloc path is essentially an emergency
> fallback, which doesn't work for all situations anyway - any restricted
> device that actually needs to make significant coherent allocations (or
> rather, that firmware cannot assume won't want to do so) should really
> have a proper coherent pool alongside its restricted one. The expected
> use-case here is for something like a wifi driver that only needs to
> allocate one or two small coherent buffers once at startup, then do
> everything else with streaming DMA.
>
I was aiming to bring more consistency in how swiotlb buffers are
handled, specifically by treating all swiotlb memory as decrypted
buffers, which is also how the current code behaves.
If we are concluding that restricted DMA is not used in conjunction with
memory encryption, then we could, in fact, remove the
set_memory_decrypted() call from rmem_swiotlb_device_init() and
instead add failure conditions for force_dma_unencrypted(dev) in
is_swiotlb_for_alloc(). However, it’s worth noting that the initial
commit did take the memory encryption feature into account
(0b84e4f8b793eb4045fd64f6f514165a7974cd16).
Please let me know if you think this needs to be fixed.
-aneesh
^ permalink raw reply
* [PATCH v2 0/2] SEV-SNP Unaccepted Memory Hotplug
From: Pratik R. Sampat @ 2026-01-12 20:22 UTC (permalink / raw)
To: linux-mm, linux-coco, x86, linux-kernel
Cc: tglx, mingo, bp, dave.hansen, kas, ardb, akpm, david, osalvador,
thomas.lendacky, michael.roth, prsampat
Guest memory hot-plug/remove via the QEMU monitor is used by virtual
machines to dynamically scale the memory capacity of a system with
virtually zero downtime to the guest. For confidential VMs, memory has
to be first accepted before it can be used. Add support to accept
memory that has been hot-added and revert back it's state for
hypervisors to be able to use the pages during hot-remove.
Usage (for SNP guests)
----------------------
Step1: Spawn a QEMU SNP guest with the additional parameter of slots and
maximum possible memory, along with the initial memory as below:
"-m X,slots=Y,maxmem=Z".
Step2: Once the guest is booted, launch the qemu monitor and hotplug
the memory as follows:
(qemu) object_add memory-backend-memfd,id=mem1,size=1G
(qemu) device_add pc-dimm,id=dimm1,memdev=mem1
Memory is accepted up-front when added to the guest.
If using auto-onlining by either:
a) echo online > /sys/devices/system/memory/auto_online_blocks, OR
b) enable CONFIG_MHP_DEFAULT_ONLINE_TYPE_* while compiling kernel
Memory should show up automatically.
Otherwise, memory can also be onlined by echoing 1 to the newly added
blocks in: /sys/devices/system/memory/memoryXX/online
Step3: memory can be hot-removed using the qemu monitor using:
(qemu) device_remove dimm1
(qemu) object_remove mem1
Tip: Enable the kvm_convert_memory event in QEMU to observe memory
conversions between private and shared during hotplug/remove.
The series is based on
git.kernel.org/pub/scm/virt/kvm/kvm.git next
Comments and feedback appreciated!
Changelog RFC..Patch v2:
------------------------
https://lore.kernel.org/all/20251125175753.1428857-1-prsampat@amd.com/
Based on feedback from the RFC, reworked the series to accept memory
upfront on hotplug. This is done for two reasons:
1. Avoids modifying the unaccepted bitmap. Extending the bitmap would
require either:
* Dynamically allocating the bitmap, which would need changes to EFI
struct definitions, or
* Pre-allocating a larger bitmap to accommodate hotpluggable memory.
This poses challenges since e820 is parsed before SRAT, which
contains the actual memory ranges information.
2. There are currently no known use-cases that would benefit from lazy
acceptance of hotplugged ranges which warrants this additional
complexity.
Pratik R. Sampat (2):
mm/memory_hotplug: Add support to accept memory during hot-add
mm/memory_hotplug: Add support to unaccept memory after hot-remove
arch/x86/coco/sev/core.c | 13 +++++++++++++
arch/x86/include/asm/sev.h | 2 ++
arch/x86/include/asm/unaccepted_memory.h | 9 +++++++++
mm/memory_hotplug.c | 7 +++++++
4 files changed, 31 insertions(+)
--
2.52.0
^ permalink raw reply
* [PATCH v2 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
From: Pratik R. Sampat @ 2026-01-12 20:22 UTC (permalink / raw)
To: linux-mm, linux-coco, x86, linux-kernel
Cc: tglx, mingo, bp, dave.hansen, kas, ardb, akpm, david, osalvador,
thomas.lendacky, michael.roth, prsampat
In-Reply-To: <20260112202300.43546-1-prsampat@amd.com>
Confidential computing guests require memory to be accepted before use.
The unaccepted memory bitmap maintained by firmware does not track
hotplugged memory ranges.
Call arch_accept_memory() during the hot-add path to explicitly validate
and transition the newly added memory to a private state, making it
usable by the guest.
Signed-off-by: Pratik R. Sampat <prsampat@amd.com>
---
mm/memory_hotplug.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index a63ec679d861..8cfbf0541430 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -38,6 +38,7 @@
#include <linux/node.h>
#include <asm/tlbflush.h>
+#include <asm/unaccepted_memory.h>
#include "internal.h"
#include "shuffle.h"
@@ -1567,6 +1568,9 @@ int add_memory_resource(int nid, struct resource *res, mhp_t mhp_flags)
if (!strcmp(res->name, "System RAM"))
firmware_map_add_hotplug(start, start + size, "System RAM");
+ if (IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
+ arch_accept_memory(start, start + size);
+
/* device_online() will take the lock when calling online_pages() */
mem_hotplug_done();
--
2.52.0
^ permalink raw reply related
* [PATCH v2 2/2] mm/memory_hotplug: Add support to unaccept memory after hot-remove
From: Pratik R. Sampat @ 2026-01-12 20:23 UTC (permalink / raw)
To: linux-mm, linux-coco, x86, linux-kernel
Cc: tglx, mingo, bp, dave.hansen, kas, ardb, akpm, david, osalvador,
thomas.lendacky, michael.roth, prsampat
In-Reply-To: <20260112202300.43546-1-prsampat@amd.com>
Transition memory to the shared state during a hot-remove operation so
that it can be re-used by the hypervisor. This also applies when memory
is intended to be hotplugged back in later, as those pages will need to
be re-accepted after crossing the trust boundary.
Signed-off-by: Pratik R. Sampat <prsampat@amd.com>
---
arch/x86/coco/sev/core.c | 13 +++++++++++++
arch/x86/include/asm/sev.h | 2 ++
arch/x86/include/asm/unaccepted_memory.h | 9 +++++++++
mm/memory_hotplug.c | 3 +++
4 files changed, 27 insertions(+)
diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index 9ae3b11754e6..63d8f44b76eb 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -703,6 +703,19 @@ void snp_accept_memory(phys_addr_t start, phys_addr_t end)
set_pages_state(vaddr, npages, SNP_PAGE_STATE_PRIVATE);
}
+void snp_unaccept_memory(phys_addr_t start, phys_addr_t end)
+{
+ unsigned long vaddr, npages;
+
+ if (!cc_platform_has(CC_ATTR_GUEST_SEV_SNP))
+ return;
+
+ vaddr = (unsigned long)__va(start);
+ npages = (end - start) >> PAGE_SHIFT;
+
+ set_pages_state(vaddr, npages, SNP_PAGE_STATE_SHARED);
+}
+
static int vmgexit_ap_control(u64 event, struct sev_es_save_area *vmsa, u32 apic_id)
{
bool create = event != SVM_VMGEXIT_AP_DESTROY;
diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index 0e6c0940100f..3327de663793 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -514,6 +514,7 @@ bool snp_init(struct boot_params *bp);
void snp_dmi_setup(void);
int snp_issue_svsm_attest_req(u64 call_id, struct svsm_call *call, struct svsm_attest_call *input);
void snp_accept_memory(phys_addr_t start, phys_addr_t end);
+void snp_unaccept_memory(phys_addr_t start, phys_addr_t end);
u64 snp_get_unsupported_features(u64 status);
u64 sev_get_status(void);
void sev_show_status(void);
@@ -623,6 +624,7 @@ static inline int snp_issue_svsm_attest_req(u64 call_id, struct svsm_call *call,
return -ENOTTY;
}
static inline void snp_accept_memory(phys_addr_t start, phys_addr_t end) { }
+static inline void snp_unaccept_memory(phys_addr_t start, phys_addr_t end) { }
static inline u64 snp_get_unsupported_features(u64 status) { return 0; }
static inline u64 sev_get_status(void) { return 0; }
static inline void sev_show_status(void) { }
diff --git a/arch/x86/include/asm/unaccepted_memory.h b/arch/x86/include/asm/unaccepted_memory.h
index f5937e9866ac..8715be843e65 100644
--- a/arch/x86/include/asm/unaccepted_memory.h
+++ b/arch/x86/include/asm/unaccepted_memory.h
@@ -18,6 +18,15 @@ static inline void arch_accept_memory(phys_addr_t start, phys_addr_t end)
}
}
+static inline void arch_unaccept_memory(phys_addr_t start, phys_addr_t end)
+{
+ if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP)) {
+ snp_unaccept_memory(start, end);
+ } else {
+ panic("Cannot unaccept memory: unknown platform\n");
+ }
+}
+
static inline struct efi_unaccepted_memory *efi_get_unaccepted_table(void)
{
if (efi.unaccepted == EFI_INVALID_TABLE_ADDR)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 8cfbf0541430..718f729cf687 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -2242,6 +2242,9 @@ static int try_remove_memory(u64 start, u64 size)
mem_hotplug_begin();
+ if (IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
+ arch_unaccept_memory(start, start + size);
+
rc = memory_blocks_have_altmaps(start, size);
if (rc < 0) {
mem_hotplug_done();
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v2 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
From: Andrew Morton @ 2026-01-12 21:04 UTC (permalink / raw)
To: Pratik R. Sampat
Cc: linux-mm, linux-coco, x86, linux-kernel, tglx, mingo, bp,
dave.hansen, kas, ardb, david, osalvador, thomas.lendacky,
michael.roth
In-Reply-To: <20260112202300.43546-2-prsampat@amd.com>
On Mon, 12 Jan 2026 14:22:59 -0600 "Pratik R. Sampat" <prsampat@amd.com> wrote:
> Confidential computing guests require memory to be accepted before use.
> The unaccepted memory bitmap maintained by firmware does not track
> hotplugged memory ranges.
>
> Call arch_accept_memory() during the hot-add path to explicitly validate
> and transition the newly added memory to a private state, making it
> usable by the guest.
>
> Signed-off-by: Pratik R. Sampat <prsampat@amd.com>
> ---
> mm/memory_hotplug.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index a63ec679d861..8cfbf0541430 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -38,6 +38,7 @@
> #include <linux/node.h>
>
> #include <asm/tlbflush.h>
> +#include <asm/unaccepted_memory.h>
This only exists for x86!
Otherwise, the mm/ changes are minimal so I volunteer this patchset
for the x86 tree ;)
^ permalink raw reply
* Re: [PATCH v2 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
From: Pratik R. Sampat @ 2026-01-12 22:23 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, linux-coco, x86, linux-kernel, tglx, mingo, bp,
dave.hansen, kas, ardb, david, osalvador, thomas.lendacky,
michael.roth
In-Reply-To: <20260112130401.a857fac6abcf104ea9bb5c68@linux-foundation.org>
On 1/12/26 3:04 PM, Andrew Morton wrote:
> On Mon, 12 Jan 2026 14:22:59 -0600 "Pratik R. Sampat" <prsampat@amd.com> wrote:
>
>> Confidential computing guests require memory to be accepted before use.
>> The unaccepted memory bitmap maintained by firmware does not track
>> hotplugged memory ranges.
>>
>> Call arch_accept_memory() during the hot-add path to explicitly validate
>> and transition the newly added memory to a private state, making it
>> usable by the guest.
>>
>> Signed-off-by: Pratik R. Sampat <prsampat@amd.com>
>> ---
>> mm/memory_hotplug.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index a63ec679d861..8cfbf0541430 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -38,6 +38,7 @@
>> #include <linux/node.h>
>>
>> #include <asm/tlbflush.h>
>> +#include <asm/unaccepted_memory.h>
>
> This only exists for x86!
Ah, I missed that entirely. Thanks for catching that.
Probably not the best option to have a generic unaccepted_memory.h as well.
Maybe, I should have arch_[un]accept_memory() definitions within mm.h wrapped
within CONFIG_UNACCEPTED_MEMORY instead so that its cleaner.
>
> Otherwise, the mm/ changes are minimal so I volunteer this patchset
> for the x86 tree ;)
Ack!
--Pratik
^ permalink raw reply
* Re: [PATCH v2 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
From: Andrew Morton @ 2026-01-12 22:43 UTC (permalink / raw)
To: Pratik R. Sampat
Cc: linux-mm, linux-coco, x86, linux-kernel, tglx, mingo, bp,
dave.hansen, kas, ardb, david, osalvador, thomas.lendacky,
michael.roth
In-Reply-To: <2f9b180b-c221-4631-93d0-c131332ef178@amd.com>
On Mon, 12 Jan 2026 16:23:37 -0600 "Pratik R. Sampat" <prsampat@amd.com> wrote:
>
>
> On 1/12/26 3:04 PM, Andrew Morton wrote:
> > On Mon, 12 Jan 2026 14:22:59 -0600 "Pratik R. Sampat" <prsampat@amd.com> wrote:
> >
> >> Confidential computing guests require memory to be accepted before use.
> >> The unaccepted memory bitmap maintained by firmware does not track
> >> hotplugged memory ranges.
> >>
> >> Call arch_accept_memory() during the hot-add path to explicitly validate
> >> and transition the newly added memory to a private state, making it
> >> usable by the guest.
> >>
> >> Signed-off-by: Pratik R. Sampat <prsampat@amd.com>
> >> ---
> >> mm/memory_hotplug.c | 4 ++++
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> >> index a63ec679d861..8cfbf0541430 100644
> >> --- a/mm/memory_hotplug.c
> >> +++ b/mm/memory_hotplug.c
> >> @@ -38,6 +38,7 @@
> >> #include <linux/node.h>
> >>
> >> #include <asm/tlbflush.h>
> >> +#include <asm/unaccepted_memory.h>
> >
> > This only exists for x86!
>
> Ah, I missed that entirely. Thanks for catching that.
>
> Probably not the best option to have a generic unaccepted_memory.h as well.
> Maybe, I should have arch_[un]accept_memory() definitions within mm.h wrapped
> within CONFIG_UNACCEPTED_MEMORY instead so that its cleaner.
Something like that.
The idiomatic Linus way is to use
#ifndef arch_accept_memory
#define arch_accept_memory ...
#endif
Lots of prior art here:
grep -r include/linux "ifndef arch_"
Oh, arch_get_idle_state_flags() got it all wrong.
#ifdef CONFIG_ACPI_PROCESSOR_IDLE
#ifndef arch_get_idle_state_flags
static inline unsigned int arch_get_idle_state_flags(u32 arch_flags)
{
return 0;
}
#endif
#endif /* CONFIG_ACPI_PROCESSOR_IDLE */
- shouldn't have needed "ifdef CONFIG_ACPI_PROCESSOR_IDLE"
- should have appended
#define arch_get_idle_state_flags arch_get_idle_state_flags
in case cpp hit the same lines a second time.
^ permalink raw reply
* Re: [PATCH v2 1/2] x86/virt/tdx: Retrieve TDX module version
From: Xu Yilun @ 2026-01-13 2:56 UTC (permalink / raw)
To: Dave Hansen
Cc: Xiaoyao Li, Vishal Verma, linux-kernel, linux-coco, kvm, x86,
Chao Gao, Dan Williams, Kai Huang, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Kiryl Shutsemau,
Rick Edgecombe
In-Reply-To: <f0cc6afe-0f58-4314-9a77-34c5b005b677@intel.com>
On Mon, Jan 12, 2026 at 06:56:58AM -0800, Dave Hansen wrote:
> On 1/11/26 18:25, Xiaoyao Li wrote:
> > ... I know it's because minor_version has the least field ID among the
> > three. But the order of the field IDs doesn't stand for the order of the
> > reading. Reading the middle part y of x.y.z as first step looks a bit odd.
>
> I wouldn't sweat it either way. Reading 4, 3, 5 would also look odd. I'm
> fine with it as-is in the patch.
I prefer 3, 4, 5. The field IDs are not human readable hex magic so
should take extra care when copying from excel file to C file manually,
A different list order would make the code adding & reviewing even
harder.
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox