* Re: [PATCH v2 08/21] coco/tdx-host: Implement FW_UPLOAD sysfs ABI for TDX Module updates
From: Xu Yilun @ 2026-01-14 3:08 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, sagis, vannapurve, paulmck,
nik.borisov, Farrah Chen, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Kirill A. Shutemov
In-Reply-To: <20251001025442.427697-9-chao.gao@intel.com>
On Tue, Sep 30, 2025 at 07:52:52PM -0700, Chao Gao wrote:
> The firmware upload framework provides a standard mechanism for firmware
> updates by allowing device drivers to expose sysfs interfaces for
> user-initiated updates.
>
> Register with this framework to expose sysfs interfaces for TDX Module
> updates and implement operations to process data blobs supplied by
> userspace.
>
> Note that:
> 1. P-SEAMLDR processes the entire update at once rather than
> chunk-by-chunk, so .write() is called only once per update; so the
> offset should be always 0.
> 2. TDX Module Updates complete synchronously within .write(), meaning
> .poll_complete() is only called after successful updates and therefore
> always returns success
>
> Why fw_upload instead of request_firmware()?
> ============================================
> The explicit file selection capabilities of fw_upload is preferred over
> the implicit file selection of request_firmware() for the following
> reasons:
>
> a. Intel distributes all versions of the TDX Module, allowing admins to
> load any version rather than always defaulting to the latest. This
> flexibility is necessary because future extensions may require reverting to
> a previous version to clear fatal errors.
>
> b. Some module version series are platform-specific. For example, the 1.5.x
> series is for certain platform generations, while the 2.0.x series is
> intended for others.
>
> c. The update policy for TDX Module updates is non-linear at times. The
> latest TDX Module may not be compatible. For example, TDX Module 1.5.x
> may be updated to 1.5.y but not to 1.5.y+1. This policy is documented
> separately in a file released along with each TDX Module release.
>
> So, the default policy of "request_firmware()" of "always load latest", is
> not suitable for TDX. Userspace needs to deploy a more sophisticated policy
> check (e.g., latest may not be compatible), and there is potential
> operator choice to consider.
>
> Just have userspace pick rather than add kernel mechanism to change the
> default policy of request_firmware().
>
> Signed-off-by: Chao Gao <chao.gao@intel.com>
> Tested-by: Farrah Chen <farrah.chen@intel.com>
> ---
> arch/x86/Kconfig | 2 +
> arch/x86/include/asm/seamldr.h | 2 +
> arch/x86/include/asm/tdx.h | 5 ++
> arch/x86/virt/vmx/tdx/seamldr.c | 7 ++
> drivers/virt/coco/tdx-host/tdx-host.c | 122 +++++++++++++++++++++++++-
> 5 files changed, 137 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 6b47383d2958..2bf4bb3dfe71 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1908,6 +1908,8 @@ config INTEL_TDX_HOST
> config INTEL_TDX_MODULE_UPDATE
> bool "Intel TDX module runtime update"
> depends on TDX_HOST_SERVICES
> + select FW_LOADER
> + select FW_UPLOAD
> help
> This enables the kernel to support TDX module runtime update. This
> allows the admin to update the TDX module to the same or any newer
> diff --git a/arch/x86/include/asm/seamldr.h b/arch/x86/include/asm/seamldr.h
> index d1e9f6e16e8d..692bde5e9bb4 100644
> --- a/arch/x86/include/asm/seamldr.h
> +++ b/arch/x86/include/asm/seamldr.h
> @@ -20,8 +20,10 @@ struct seamldr_info {
>
> #ifdef CONFIG_INTEL_TDX_MODULE_UPDATE
> const struct seamldr_info *seamldr_get_info(void);
> +int seamldr_install_module(const u8 *data, u32 size);
> #else
> static inline const struct seamldr_info *seamldr_get_info(void) { return NULL; }
> +static inline int seamldr_install_module(const u8 *data, u32 size) { return -EOPNOTSUPP; }
> #endif
>
> #endif
> diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
> index 7ad026618a23..2422904079a3 100644
> --- a/arch/x86/include/asm/tdx.h
> +++ b/arch/x86/include/asm/tdx.h
> @@ -107,6 +107,11 @@ int tdx_enable(void);
> const char *tdx_dump_mce_info(struct mce *m);
> const struct tdx_sys_info *tdx_get_sysinfo(void);
>
> +static inline bool tdx_supports_runtime_update(const struct tdx_sys_info *sysinfo)
> +{
> + return false; /* To be enabled when kernel is ready */
> +}
> +
> int tdx_guest_keyid_alloc(void);
> u32 tdx_get_nr_guest_keyids(void);
> void tdx_guest_keyid_free(unsigned int keyid);
> diff --git a/arch/x86/virt/vmx/tdx/seamldr.c b/arch/x86/virt/vmx/tdx/seamldr.c
> index 08c2e3fe6071..69c059194c61 100644
> --- a/arch/x86/virt/vmx/tdx/seamldr.c
> +++ b/arch/x86/virt/vmx/tdx/seamldr.c
> @@ -69,3 +69,10 @@ const struct seamldr_info *seamldr_get_info(void)
> return seamldr_call(P_SEAMLDR_INFO, &args) ? NULL : &seamldr_info;
> }
> EXPORT_SYMBOL_GPL_FOR_MODULES(seamldr_get_info, "tdx-host");
> +
> +int seamldr_install_module(const u8 *data, u32 size)
> +{
> + /* TODO: Update TDX Module here */
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL_FOR_MODULES(seamldr_install_module, "tdx-host");
> diff --git a/drivers/virt/coco/tdx-host/tdx-host.c b/drivers/virt/coco/tdx-host/tdx-host.c
> index 42570c5b221b..418e90797689 100644
> --- a/drivers/virt/coco/tdx-host/tdx-host.c
> +++ b/drivers/virt/coco/tdx-host/tdx-host.c
> @@ -10,6 +10,7 @@
> #include <linux/mod_devicetable.h>
> #include <linux/sysfs.h>
> #include <linux/device/faux.h>
> +#include <linux/firmware.h>
> #include <asm/cpu_device_id.h>
> #include <asm/seamldr.h>
> #include <asm/tdx.h>
> @@ -21,6 +22,13 @@ static const struct x86_cpu_id tdx_host_ids[] = {
> };
> MODULE_DEVICE_TABLE(x86cpu, tdx_host_ids);
>
> +struct tdx_fw_upload_status {
> + bool cancel_request;
> +};
> +
> +struct fw_upload *tdx_fwl;
> +static struct tdx_fw_upload_status tdx_fw_upload_status;
> +
> static struct faux_device *fdev;
Make the fdev declaration right before tdx_host_init(), try best to keep
the update stuff in one bluk.
[...]
> +static int seamldr_init(struct device *dev)
> +{
> + const struct seamldr_info *seamldr_info = seamldr_get_info();
> + const struct tdx_sys_info *tdx_sysinfo = tdx_get_sysinfo();
> + int ret;
> +
> + if (!tdx_sysinfo || !seamldr_info)
> + return -ENXIO;
> +
> + if (!tdx_supports_runtime_update(tdx_sysinfo)) {
> + pr_info("Current TDX Module cannot be updated. Consider BIOS updates\n");
> + return -EOPNOTSUPP;
I don't think we fail out the whole tdx-host here. We should skip the
optional feature if it is not supported to allow other features work.
E.g. the TDX Module version, the P-SEAMLOAD version, TDX Connect.
> + }
> +
> + if (!seamldr_info->num_remaining_updates) {
> + pr_info("P-SEAMLDR doesn't support TDX Module updates\n");
> + return -EOPNOTSUPP;
> + }
Ditto. And keeping num_remaining_updates sysfs node visible and returning 0
is valuable, it clearly tells why update is impossible and aligns with
the situation when the user keeps on updating and exhausts the available
updates.
> +
> + tdx_fwl = firmware_upload_register(THIS_MODULE, dev, "seamldr_upload",
> + &tdx_fw_ops, &tdx_fw_upload_status);
> + ret = PTR_ERR_OR_ZERO(tdx_fwl);
> + if (ret)
> + pr_err("failed to register module uploader %d\n", ret);
> +
> + return ret;
> +}
^ permalink raw reply
* Re: [PATCH] KVM: TDX: Allow userspace to return errors to guest for MAPGPA
From: Xiaoyao Li @ 2026-01-14 2:59 UTC (permalink / raw)
To: Sagi Shahar, Sean Christopherson, Paolo Bonzini, Dave Hansen,
Kiryl Shutsemau, Rick Edgecombe
Cc: Thomas Gleixner, Borislav Petkov, H. Peter Anvin, x86, kvm,
linux-kernel, linux-coco, Vishal Annapurve
In-Reply-To: <20260114003015.1386066-1-sagis@google.com>
On 1/14/2026 8:30 AM, Sagi Shahar wrote:
> From: Vishal Annapurve <vannapurve@google.com>
>
> MAPGPA request from TDX VMs gets split into chunks by KVM using a loop
> of userspace exits until the complete range is handled.
>
> In some cases userspace VMM might decide to break the MAPGPA operation
> and continue it later. For example: in the case of intrahost migration
> userspace might decide to continue the MAPGPA operation after the
> migrration is completed.
>
> Allow userspace to signal to TDX guests that the MAPGPA operation should
> be retried the next time the guest is scheduled.
>
> Signed-off-by: Vishal Annapurve <vannapurve@google.com>
> Co-developed-by: Sagi Shahar <sagis@google.com>
> Signed-off-by: Sagi Shahar <sagis@google.com>
> ---
> arch/x86/kvm/vmx/tdx.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> index 2d7a4d52ccfb..3244064b1a04 100644
> --- a/arch/x86/kvm/vmx/tdx.c
> +++ b/arch/x86/kvm/vmx/tdx.c
> @@ -1189,7 +1189,13 @@ static int tdx_complete_vmcall_map_gpa(struct kvm_vcpu *vcpu)
> struct vcpu_tdx *tdx = to_tdx(vcpu);
>
> if (vcpu->run->hypercall.ret) {
> - tdvmcall_set_return_code(vcpu, TDVMCALL_STATUS_INVALID_OPERAND);
> + if (vcpu->run->hypercall.ret == -EBUSY)
> + tdvmcall_set_return_code(vcpu, TDVMCALL_STATUS_RETRY);
> + else if (vcpu->run->hypercall.ret == -EINVAL)
> + tdvmcall_set_return_code(vcpu, TDVMCALL_STATUS_INVALID_OPERAND);
> + else
> + return -EINVAL;
It's incorrect to return -EINVAL here. The -EINVAL will eventually be
returned to userspace for the VCPU_RUN ioctl. It certainly breaks
userspace. So it needs to be
if (vcpu->run->hypercall.ret == -EBUSY)
tdvmcall_set_return_code(vcpu, TDVMCALL_STATUS_RETRY);
else
tdvmcall_set_return_code(vcpu, TDVMCALL_STATUS_INVALID_OPERAND);
But I'm not sure if such change breaks the userspace ABI that if needs
to be opted-in.
^ permalink raw reply
* Re: [PATCH v2 07/21] coco/tdx-host: Expose P-SEAMLDR information via sysfs
From: Xu Yilun @ 2026-01-14 1:50 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, sagis, vannapurve, paulmck,
nik.borisov, Farrah Chen, Kirill A. Shutemov, Dave Hansen
In-Reply-To: <20251001025442.427697-8-chao.gao@intel.com>
On Tue, Sep 30, 2025 at 07:52:51PM -0700, Chao Gao wrote:
> TDX Module updates require userspace to select the appropriate module
> to load. Expose necessary information to facilitate this decision. Two
> values are needed:
>
> - P-SEAMLDR version: for compatibility checks between TDX Module and
> P-SEAMLDR
> - num_remaining_updates: indicates how many updates can be performed
>
> Expose them as tdx-host device attributes.
>
> Note that P-SEAMLDR sysfs nodes are hidden when INTEL_TDX_MODULE_UPDATE
> isn't enabled or when P-SEAMLDR isn't loaded by BIOS, both of which
I don't think we need to worry about whether P-SEAMLDR is loaded or not.
The tdx-host device exists only if TDX Module is loaded, and in turn
P-SEAMLDR is loaded.
> cause seamldr_get_info() to return NULL.
>
[...]
> +static ssize_t seamldr_version_show(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + const struct seamldr_info *info = seamldr_get_info();
> +
> + if (!info)
> + return -ENXIO;
> +
> + return sysfs_emit(buf, "%u.%u.%u\n", info->major_version,
> + info->minor_version,
> + info->update_version);
> +}
> +
> +static ssize_t num_remaining_updates_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + const struct seamldr_info *info = seamldr_get_info();
> +
> + if (!info)
> + return -ENXIO;
> +
> + return sysfs_emit(buf, "%u\n", info->num_remaining_updates);
> +}
> +
> +/*
> + * Open-code DEVICE_ATTR_RO to specify a different 'show' function for
> + * P-SEAMLDR version as version_show() is used for the TDX Module version.
> + */
> +static struct device_attribute dev_attr_seamldr_version =
> + __ATTR(version, 0444, seamldr_version_show, NULL);
> +static DEVICE_ATTR_RO(num_remaining_updates);
> +
> +static struct attribute *seamldr_attrs[] = {
> + &dev_attr_seamldr_version.attr,
> + &dev_attr_num_remaining_updates.attr,
> + NULL,
> +};
> +
> +static umode_t seamldr_group_is_visible(struct kobject *kobj,
> + struct attribute *attr, int n)
> +{
> + return seamldr_get_info() ? attr->mode : 0;
I feel it is a little wierd here, need some explaination why use
seamldr_get_info() for visibility. At first glance, I get the impression
that we don't expose the attributes on 1st seamldr_get_info() failure,
and if 1st read success we expose the attributes, then we return read
failure on 2nd seamldr_get_info() failure. That's the motivation I'm
trying to make the logic simpler.
As you said, the purpose of using seamldr_get_info() here is for the 2
checks:
1. If INTEL_TDX_MODULE_UPDATE is selected.
2. If P-SEAMLOAD exists.
But P-SEAMLOAD must exist in tdx-host device context. The chain of
dependency is P-SEAMLOAD->TDX Module->tdx host device.
So the logic could be simplified as "if INTEL_TDX_MODULE_UPDATE
selected, expose seamldr sysfs". A common practice maybe:
#ifdef INTEL_TDX_MODULE_UPDATE
> +static struct attribute_group seamldr_group = {
> + .name = "seamldr",
> + .attrs = seamldr_attrs,
> + .is_visible = seamldr_group_is_visible,
drop is_visible()
> +};
#endif
> +
> +static const struct attribute_group *tdx_host_groups[] = {
> + &tdx_host_group,
#ifdef INTEL_TDX_MODULE_UPDATE
> + &seamldr_group,
#endif
The #ifdef should be added for several places, which seems annoying but
may be fine for the first optional feature. Later, could solve this by
splitting the file into tdx-host/main.c tdx-host/update.c
tdx-host/connect.c ...
> + NULL,
> +};
^ permalink raw reply
* [PATCH] KVM: TDX: Allow userspace to return errors to guest for MAPGPA
From: Sagi Shahar @ 2026-01-14 0:30 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini, Dave Hansen, Kiryl Shutsemau,
Rick Edgecombe
Cc: Thomas Gleixner, Borislav Petkov, H. Peter Anvin, x86, kvm,
linux-kernel, linux-coco, Vishal Annapurve, Sagi Shahar
From: Vishal Annapurve <vannapurve@google.com>
MAPGPA request from TDX VMs gets split into chunks by KVM using a loop
of userspace exits until the complete range is handled.
In some cases userspace VMM might decide to break the MAPGPA operation
and continue it later. For example: in the case of intrahost migration
userspace might decide to continue the MAPGPA operation after the
migrration is completed.
Allow userspace to signal to TDX guests that the MAPGPA operation should
be retried the next time the guest is scheduled.
Signed-off-by: Vishal Annapurve <vannapurve@google.com>
Co-developed-by: Sagi Shahar <sagis@google.com>
Signed-off-by: Sagi Shahar <sagis@google.com>
---
arch/x86/kvm/vmx/tdx.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index 2d7a4d52ccfb..3244064b1a04 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -1189,7 +1189,13 @@ static int tdx_complete_vmcall_map_gpa(struct kvm_vcpu *vcpu)
struct vcpu_tdx *tdx = to_tdx(vcpu);
if (vcpu->run->hypercall.ret) {
- tdvmcall_set_return_code(vcpu, TDVMCALL_STATUS_INVALID_OPERAND);
+ if (vcpu->run->hypercall.ret == -EBUSY)
+ tdvmcall_set_return_code(vcpu, TDVMCALL_STATUS_RETRY);
+ else if (vcpu->run->hypercall.ret == -EINVAL)
+ tdvmcall_set_return_code(vcpu, TDVMCALL_STATUS_INVALID_OPERAND);
+ else
+ return -EINVAL;
+
tdx->vp_enter_args.r11 = tdx->map_gpa_next;
return 1;
}
--
2.52.0.457.g6b5491de43-goog
^ permalink raw reply related
* Re: [PATCH v3 6/6] KVM: guest_memfd: GUP source pages prior to populating guest memory
From: Yan Zhao @ 2026-01-14 0:04 UTC (permalink / raw)
To: Sean Christopherson
Cc: Michael Roth, kvm, linux-coco, linux-mm, linux-kernel,
thomas.lendacky, pbonzini, vbabka, ashish.kalra, liam.merwick,
david, vannapurve, ackerleytng, aik, ira.weiny, pankaj.gupta,
Kai Huang
In-Reply-To: <aWabORpkzEJygYNQ@google.com>
On Tue, Jan 13, 2026 at 11:21:29AM -0800, Sean Christopherson wrote:
> On Thu, Jan 08, 2026, Michael Roth wrote:
> > @@ -842,47 +881,38 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src, long
> > if (!file)
> > return -EFAULT;
> >
> > - filemap_invalidate_lock(file->f_mapping);
> > -
> > npages = min_t(ulong, slot->npages - (start_gfn - slot->base_gfn), npages);
> > for (i = 0; i < npages; i++) {
> > - struct folio *folio;
> > - gfn_t gfn = start_gfn + i;
> > - pgoff_t index = kvm_gmem_get_index(slot, gfn);
> > - kvm_pfn_t pfn;
> > + struct page *src_page = NULL;
> > + void __user *p;
> >
> > if (signal_pending(current)) {
> > ret = -EINTR;
> > break;
> > }
> >
> > - folio = __kvm_gmem_get_pfn(file, slot, index, &pfn, NULL);
> > - if (IS_ERR(folio)) {
> > - ret = PTR_ERR(folio);
> > - break;
> > - }
> > + p = src ? src + i * PAGE_SIZE : NULL;
> >
> > - folio_unlock(folio);
> > + if (p) {
>
> Computing 'p' when src==NULL is unnecessary and makes it hard to see that gup()
> is done if and only if src!=NULL.
>
> Anyone object to this fixup?
LGTM. I also like this change :)
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index 18ae59b92257..66afab8f08a3 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -884,17 +884,16 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src, long
> npages = min_t(ulong, slot->npages - (start_gfn - slot->base_gfn), npages);
> for (i = 0; i < npages; i++) {
> struct page *src_page = NULL;
> - void __user *p;
>
> if (signal_pending(current)) {
> ret = -EINTR;
> break;
> }
>
> - p = src ? src + i * PAGE_SIZE : NULL;
> + if (src) {
> + unsigned long uaddr = (unsigned long)src + i * PAGE_SIZE;
>
> - if (p) {
> - ret = get_user_pages_fast((unsigned long)p, 1, 0, &src_page);
> + ret = get_user_pages_fast(uaddr, 1, 0, &src_page);
> if (ret < 0)
> break;
> if (ret != 1) {
>
> To end up with:
>
> struct page *src_page = NULL;
>
> if (signal_pending(current)) {
> ret = -EINTR;
> break;
> }
>
> if (src) {
> unsigned long uaddr = (unsigned long)src + i * PAGE_SIZE;
>
> ret = get_user_pages_fast(uaddr, 1, 0, &src_page);
> if (ret < 0)
> break;
> if (ret != 1) {
> ret = -ENOMEM;
> break;
> }
> }
>
> ...
^ permalink raw reply
* Re: [PATCH v3 6/6] KVM: guest_memfd: GUP source pages prior to populating guest memory
From: Sean Christopherson @ 2026-01-13 22:06 UTC (permalink / raw)
To: Michael Roth
Cc: kvm, linux-coco, linux-mm, linux-kernel, thomas.lendacky,
pbonzini, vbabka, ashish.kalra, liam.merwick, david, vannapurve,
ackerleytng, aik, ira.weiny, yan.y.zhao, pankaj.gupta, Kai Huang
In-Reply-To: <20260113213556.rwihf3v3ek3c5kwl@amd.com>
On Tue, Jan 13, 2026, Michael Roth wrote:
> On Tue, Jan 13, 2026 at 11:21:29AM -0800, Sean Christopherson wrote:
> > On Thu, Jan 08, 2026, Michael Roth wrote:
> > > @@ -842,47 +881,38 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src, long
> > > if (!file)
> > > return -EFAULT;
> > >
> > > - filemap_invalidate_lock(file->f_mapping);
> > > -
> > > npages = min_t(ulong, slot->npages - (start_gfn - slot->base_gfn), npages);
> > > for (i = 0; i < npages; i++) {
> > > - struct folio *folio;
> > > - gfn_t gfn = start_gfn + i;
> > > - pgoff_t index = kvm_gmem_get_index(slot, gfn);
> > > - kvm_pfn_t pfn;
> > > + struct page *src_page = NULL;
> > > + void __user *p;
> > >
> > > if (signal_pending(current)) {
> > > ret = -EINTR;
> > > break;
> > > }
> > >
> > > - folio = __kvm_gmem_get_pfn(file, slot, index, &pfn, NULL);
> > > - if (IS_ERR(folio)) {
> > > - ret = PTR_ERR(folio);
> > > - break;
> > > - }
> > > + p = src ? src + i * PAGE_SIZE : NULL;
> > >
> > > - folio_unlock(folio);
> > > + if (p) {
> >
> > Computing 'p' when src==NULL is unnecessary and makes it hard to see that gup()
> > is done if and only if src!=NULL.
> >
> > Anyone object to this fixup?
>
> No objections here, and it does seem a bit more readable. Will include
> this if a new version is needed.
No need, I'll fixup when applying (already have, actually). If you want to double
check that I didn't fat finger anything, the patches are in kvm-x86/gmem.
Thanks!
^ permalink raw reply
* Re: [PATCH 1/1] PCI/IDE: Fix using wrong VF ID for RID range calculation
From: Bjorn Helgaas @ 2026-01-13 21:46 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.
s/(num_VFs - )/(num_VFs - 1)/ (I think?)
s/pci/PCI/ (or could just omit, it's obvious these are PCI devices)
s/id/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
* Re: [PATCH v3 6/6] KVM: guest_memfd: GUP source pages prior to populating guest memory
From: Michael Roth @ 2026-01-13 21:35 UTC (permalink / raw)
To: Sean Christopherson
Cc: kvm, linux-coco, linux-mm, linux-kernel, thomas.lendacky,
pbonzini, vbabka, ashish.kalra, liam.merwick, david, vannapurve,
ackerleytng, aik, ira.weiny, yan.y.zhao, pankaj.gupta, Kai Huang
In-Reply-To: <aWabORpkzEJygYNQ@google.com>
On Tue, Jan 13, 2026 at 11:21:29AM -0800, Sean Christopherson wrote:
> On Thu, Jan 08, 2026, Michael Roth wrote:
> > @@ -842,47 +881,38 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src, long
> > if (!file)
> > return -EFAULT;
> >
> > - filemap_invalidate_lock(file->f_mapping);
> > -
> > npages = min_t(ulong, slot->npages - (start_gfn - slot->base_gfn), npages);
> > for (i = 0; i < npages; i++) {
> > - struct folio *folio;
> > - gfn_t gfn = start_gfn + i;
> > - pgoff_t index = kvm_gmem_get_index(slot, gfn);
> > - kvm_pfn_t pfn;
> > + struct page *src_page = NULL;
> > + void __user *p;
> >
> > if (signal_pending(current)) {
> > ret = -EINTR;
> > break;
> > }
> >
> > - folio = __kvm_gmem_get_pfn(file, slot, index, &pfn, NULL);
> > - if (IS_ERR(folio)) {
> > - ret = PTR_ERR(folio);
> > - break;
> > - }
> > + p = src ? src + i * PAGE_SIZE : NULL;
> >
> > - folio_unlock(folio);
> > + if (p) {
>
> Computing 'p' when src==NULL is unnecessary and makes it hard to see that gup()
> is done if and only if src!=NULL.
>
> Anyone object to this fixup?
No objections here, and it does seem a bit more readable. Will include
this if a new version is needed.
Thanks,
Mike
>
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index 18ae59b92257..66afab8f08a3 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -884,17 +884,16 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src, long
> npages = min_t(ulong, slot->npages - (start_gfn - slot->base_gfn), npages);
> for (i = 0; i < npages; i++) {
> struct page *src_page = NULL;
> - void __user *p;
>
> if (signal_pending(current)) {
> ret = -EINTR;
> break;
> }
>
> - p = src ? src + i * PAGE_SIZE : NULL;
> + if (src) {
> + unsigned long uaddr = (unsigned long)src + i * PAGE_SIZE;
>
> - if (p) {
> - ret = get_user_pages_fast((unsigned long)p, 1, 0, &src_page);
> + ret = get_user_pages_fast(uaddr, 1, 0, &src_page);
> if (ret < 0)
> break;
> if (ret != 1) {
>
> To end up with:
>
> struct page *src_page = NULL;
>
> if (signal_pending(current)) {
> ret = -EINTR;
> break;
> }
>
> if (src) {
> unsigned long uaddr = (unsigned long)src + i * PAGE_SIZE;
>
> ret = get_user_pages_fast(uaddr, 1, 0, &src_page);
> if (ret < 0)
> break;
> if (ret != 1) {
> ret = -ENOMEM;
> break;
> }
> }
>
> ...
^ permalink raw reply
* Re: [PATCH v3 6/6] KVM: guest_memfd: GUP source pages prior to populating guest memory
From: Sean Christopherson @ 2026-01-13 19:21 UTC (permalink / raw)
To: Michael Roth
Cc: kvm, linux-coco, linux-mm, linux-kernel, thomas.lendacky,
pbonzini, vbabka, ashish.kalra, liam.merwick, david, vannapurve,
ackerleytng, aik, ira.weiny, yan.y.zhao, pankaj.gupta, Kai Huang
In-Reply-To: <20260108214622.1084057-7-michael.roth@amd.com>
On Thu, Jan 08, 2026, Michael Roth wrote:
> @@ -842,47 +881,38 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src, long
> if (!file)
> return -EFAULT;
>
> - filemap_invalidate_lock(file->f_mapping);
> -
> npages = min_t(ulong, slot->npages - (start_gfn - slot->base_gfn), npages);
> for (i = 0; i < npages; i++) {
> - struct folio *folio;
> - gfn_t gfn = start_gfn + i;
> - pgoff_t index = kvm_gmem_get_index(slot, gfn);
> - kvm_pfn_t pfn;
> + struct page *src_page = NULL;
> + void __user *p;
>
> if (signal_pending(current)) {
> ret = -EINTR;
> break;
> }
>
> - folio = __kvm_gmem_get_pfn(file, slot, index, &pfn, NULL);
> - if (IS_ERR(folio)) {
> - ret = PTR_ERR(folio);
> - break;
> - }
> + p = src ? src + i * PAGE_SIZE : NULL;
>
> - folio_unlock(folio);
> + if (p) {
Computing 'p' when src==NULL is unnecessary and makes it hard to see that gup()
is done if and only if src!=NULL.
Anyone object to this fixup?
diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index 18ae59b92257..66afab8f08a3 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -884,17 +884,16 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src, long
npages = min_t(ulong, slot->npages - (start_gfn - slot->base_gfn), npages);
for (i = 0; i < npages; i++) {
struct page *src_page = NULL;
- void __user *p;
if (signal_pending(current)) {
ret = -EINTR;
break;
}
- p = src ? src + i * PAGE_SIZE : NULL;
+ if (src) {
+ unsigned long uaddr = (unsigned long)src + i * PAGE_SIZE;
- if (p) {
- ret = get_user_pages_fast((unsigned long)p, 1, 0, &src_page);
+ ret = get_user_pages_fast(uaddr, 1, 0, &src_page);
if (ret < 0)
break;
if (ret != 1) {
To end up with:
struct page *src_page = NULL;
if (signal_pending(current)) {
ret = -EINTR;
break;
}
if (src) {
unsigned long uaddr = (unsigned long)src + i * PAGE_SIZE;
ret = get_user_pages_fast(uaddr, 1, 0, &src_page);
if (ret < 0)
break;
if (ret != 1) {
ret = -ENOMEM;
break;
}
}
...
^ permalink raw reply related
* Re: [PATCH 1/1] PCI/IDE: Fix reading a wrong reg for unused sel stream initialization
From: Bjorn Helgaas @ 2026-01-13 19:10 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>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Dan, I assume you'll take this? It looks like you've merged
everything to do with ide.c.
> ---
> 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
* SVSM Development Call January 14, 2026
From: Jörg Rödel @ 2026-01-13 18:30 UTC (permalink / raw)
To: coconut-svsm, linux-coco
Hi,
Here is the call for agenda items for this weeks SVSM development call. Please
send any agenda items you have in mind as a reply to this email or raise them
in the meeting.
Stefano will run the meeting tomorrow (Thanks again!) as I can not attend due
to travel.
We will use the LF Zoom instance. Details of the meeting can be found in our
governance repository at:
https://github.com/coconut-svsm/governance
The link to the COCONUT-SVSM calendar is:
https://zoom-lfx.platform.linuxfoundation.org/meetings/coconut-svsm?view=week
The meeting will be recorded and the recording eventually published.
Regards,
Jörg
^ permalink raw reply
* Re: [PATCH v2 2/2] mm/memory_hotplug: Add support to unaccept memory after hot-remove
From: Pratik R. Sampat @ 2026-01-13 18:22 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-mm, linux-coco, x86, linux-kernel, tglx, mingo, bp,
dave.hansen, ardb, akpm, david, osalvador, thomas.lendacky,
michael.roth
In-Reply-To: <aWaGBandNCLT93Tm@thinkstation>
On 1/13/26 11:53 AM, Kiryl Shutsemau wrote:
> On Tue, Jan 13, 2026 at 11:10:21AM -0600, Pratik R. Sampat wrote:
>>
>>
>> On 1/13/2026 4:28 AM, Kiryl Shutsemau wrote:
>>> On Mon, Jan 12, 2026 at 02:23:00PM -0600, Pratik R. Sampat wrote:
>>>> 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.
>>>
>>> Hm. What happens when we hot-remove memory that was there at the boot
>>> and there's bitmap space for it?
>>>
>>
>> While hotplug ranges gotten from SRAT don't seem to overlap with the
>> conventional ranges in the unaccepted table, EFI_MEMORY_HOT_PLUGGABLE
>> attribute could indicate boot time memory that could be hot-removed. I
>> could potentially unset the bitmap first, if the bit exists and then
>> unaccept.
>>
>> Similarly, I could also check if the bitmap is large enough to set the
>> bit before I call arch_accept_memory() (This may not really be needed
>> though).
>>
>>> Also, I'm not sure why it is needed. At least in TDX case, VMM can pull
>>> the memory from under guest at any time without a warning. Coverting
>>> memory to shared shouldn't make a difference as along as re-adding the
>>> same GPA range triggers accept.
>>>
>>
>> That makes sense. The only scenario where we could run into trouble on
>> SNP platforms is when we redo a qemu device_add after a device_del
>> without first removing the memory object entirely since same-state
>> transitions result in guest termination.
>>
>> This means we must always follow a device_del with an object_del on
>> removal. Otherwise, the onus would then be on the VMM to transition
>> the memory back to shared before re-adding it to the guest.
>
> This seems to be one-of-many possible ways of VMM to get guest terminated.
> DoS is not in something confidential computing aims to prevent.
>
>> However, if this flow is not a concern to begin with then I could
>> probably just drop this patch?
>
> Yes, please.
Putting more thought into it, memory unacceptance on remove may be required
after all at least for SNP platforms.
Consider a scenario:
* Guest accepts a GPA say G1, mapped to a host physical address H1.
* We attempt to hot-remove the memory. If the guest does not unaccept the memory
now then G1 to H1 mapping within the RMP will still exist.
* Then if the hypervisor later hot-adds the memory to G1, it will be now mapped
to H3 and this new mapping will be accepted.
This will essentially mean that we have 2 RMP entries: One for H1 and another
for H3 mapped for G1 which are both validated / accepted which can then be
swapped at will and compromise integrity.
--Pratik
>
^ permalink raw reply
* Re: [PATCH v2 2/2] mm/memory_hotplug: Add support to unaccept memory after hot-remove
From: Kiryl Shutsemau @ 2026-01-13 17:53 UTC (permalink / raw)
To: Pratik R. Sampat
Cc: linux-mm, linux-coco, x86, linux-kernel, tglx, mingo, bp,
dave.hansen, ardb, akpm, david, osalvador, thomas.lendacky,
michael.roth
In-Reply-To: <af3bf2ef-0231-4e75-9a80-c2bd3a7e1bf1@amd.com>
On Tue, Jan 13, 2026 at 11:10:21AM -0600, Pratik R. Sampat wrote:
>
>
> On 1/13/2026 4:28 AM, Kiryl Shutsemau wrote:
> > On Mon, Jan 12, 2026 at 02:23:00PM -0600, Pratik R. Sampat wrote:
> > > 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.
> >
> > Hm. What happens when we hot-remove memory that was there at the boot
> > and there's bitmap space for it?
> >
>
> While hotplug ranges gotten from SRAT don't seem to overlap with the
> conventional ranges in the unaccepted table, EFI_MEMORY_HOT_PLUGGABLE
> attribute could indicate boot time memory that could be hot-removed. I
> could potentially unset the bitmap first, if the bit exists and then
> unaccept.
>
> Similarly, I could also check if the bitmap is large enough to set the
> bit before I call arch_accept_memory() (This may not really be needed
> though).
>
> > Also, I'm not sure why it is needed. At least in TDX case, VMM can pull
> > the memory from under guest at any time without a warning. Coverting
> > memory to shared shouldn't make a difference as along as re-adding the
> > same GPA range triggers accept.
> >
>
> That makes sense. The only scenario where we could run into trouble on
> SNP platforms is when we redo a qemu device_add after a device_del
> without first removing the memory object entirely since same-state
> transitions result in guest termination.
>
> This means we must always follow a device_del with an object_del on
> removal. Otherwise, the onus would then be on the VMM to transition
> the memory back to shared before re-adding it to the guest.
This seems to be one-of-many possible ways of VMM to get guest terminated.
DoS is not in something confidential computing aims to prevent.
> However, if this flow is not a concern to begin with then I could
> probably just drop this patch?
Yes, please.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [RFC PATCH 0/5] Arm LFA: Improvements and interrupt support
From: Andre Przywara @ 2026-01-13 17:30 UTC (permalink / raw)
To: Vedashree Vidwans, salman.nabi, sudeep.holla, lpieralisi,
mark.rutland
Cc: ardb, chao.gao, linux-arm-kernel, linux-coco, linux-kernel,
sdonthineni, vsethi, vwadekar
In-Reply-To: <20251208221319.1524888-1-vvidwans@nvidia.com>
Hi Vedashree,
thanks for your efforts on this, and sorry for the delay on our side. We
were hold up by a combination of spec changes and non-overlapping holidays.
On 08/12/2025 22:13, Vedashree Vidwans wrote:
> Hello,
>
> The patches update the proposed Arm Live Firmware Activation (LFA)
> kernel driver [1] to incorporate review feedback [2] and refine the
> activation flow while remaining aligned with the LFA specification
> DEN0147 [3] and the SMCCC 1.2 calling convention. The series keeps
> the existing functionality but restructures and extends it to improve
> robustness, reviewability, and future extensibility.
I would propose we change that approach a bit. We have updated and
improved the driver internally, but were waiting for the new version of
the spec (BET1) to be released, which happened some weeks ago. Salman
will send out a new version of the driver in the next few days. Anything
that is a bug (like the omission of the SMCCC v1.2 interface) will be
addressed there, as there is no point to merge with a known buggy base
patch. Also we will incorporate the changes we made so far, including
adjustments for the new spec version.
Anything that can be added as independent patches should be done so, I
think for instance the interrupt support is such a candidate. Ideally
you can rebase your series on the changed base patch once this has been
posted.
For other things like the platform driver introduction we can use your
series here as a discussion base, as it allows us to reason and discuss
this easier than by looking at a from-scratch patch.
Does this make sense?
Also please note that the DT and ACPI part has changed in the latest
version of the spec. I will send a DT binding patch ASAP, to get this
part out of the way.
Cheers,
Andre
> > The SMCCC usage in the driver is updated to consistently use the
> SMCCC 1.2 register-based calling convention, consolidating arguments
> and results into a single struct to reduce stack usage and simplify
> the SMC interface. The patches also split the original changes into
> focused pieces and document the device node bindings in the commit
> messages, making it easier to follow and validate the implementation
> against the specification.
>
> The kernel driver is registered as a platform driver in accordence to
> the LFA device defined by the specification [3]. The driver now extends
> interface for interrupt-based enablement of LFA. During LFA, the
> interrupt
> thread refreshes firmware component details after each activation step
> and iterates over all activable components until no further activation
> is pending, matching the spec’s allowance for component detail changes
> after activation. This ensures that sysfs exposure of LFA components
> remains consistent with the authoritative information provided by the
> secure firmware.
>
> The handling of CPU rendezvous is adjusted so that the kernel now
> honors the rendezvous policy chosen by the firmware, instead of
> unconditionally forcing a rendezvous. This reflects experience with
> existing firmware deployments where mandatory rendezvous is not
> required, while still allowing the firmware to request it when
> needed.
>
> Thank you,
> Veda
>
> [1] https://lore.kernel.org/lkml/20250926123145.268728-1-salman.nabi@arm.com/
> [2] https://lkml.org/lkml/2025/10/8/980
> [3] https://developer.arm.com/documentation/den0147/latest/
>
> Vedashree Vidwans (5):
> firmware: smccc: LFA: use smcc 1.2
> firmware: smccc: LFA: refactor
> firmware: smccc: add timeout, touch wdt
> firmware: smccc: register as platform driver
> firmware: smccc: lfa: refresh fw details
>
> drivers/firmware/smccc/Kconfig | 3 +-
> drivers/firmware/smccc/lfa_fw.c | 478 +++++++++++++++++++++++++-------
> 2 files changed, 380 insertions(+), 101 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v2 2/2] mm/memory_hotplug: Add support to unaccept memory after hot-remove
From: Pratik R. Sampat @ 2026-01-13 17:10 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-mm, linux-coco, x86, linux-kernel, tglx, mingo, bp,
dave.hansen, ardb, akpm, david, osalvador, thomas.lendacky,
michael.roth
In-Reply-To: <aWYctexPTf-w7QT8@thinkstation>
On 1/13/2026 4:28 AM, Kiryl Shutsemau wrote:
> On Mon, Jan 12, 2026 at 02:23:00PM -0600, Pratik R. Sampat wrote:
>> 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.
>
> Hm. What happens when we hot-remove memory that was there at the boot
> and there's bitmap space for it?
>
While hotplug ranges gotten from SRAT don't seem to overlap with the
conventional ranges in the unaccepted table, EFI_MEMORY_HOT_PLUGGABLE
attribute could indicate boot time memory that could be hot-removed. I
could potentially unset the bitmap first, if the bit exists and then
unaccept.
Similarly, I could also check if the bitmap is large enough to set the
bit before I call arch_accept_memory() (This may not really be needed
though).
> Also, I'm not sure why it is needed. At least in TDX case, VMM can pull
> the memory from under guest at any time without a warning. Coverting
> memory to shared shouldn't make a difference as along as re-adding the
> same GPA range triggers accept.
>
That makes sense. The only scenario where we could run into trouble on
SNP platforms is when we redo a qemu device_add after a device_del
without first removing the memory object entirely since same-state
transitions result in guest termination.
This means we must always follow a device_del with an object_del on
removal. Otherwise, the onus would then be on the VMM to transition
the memory back to shared before re-adding it to the guest.
However, if this flow is not a concern to begin with then I could
probably just drop this patch?
--Pratik
^ permalink raw reply
* Re: [PATCH 1/1] PCI/IDE: Fix using wrong VF ID for RID range calculation
From: Li Ming @ 2026-01-13 13:44 UTC (permalink / raw)
To: Xu Yilun; +Cc: dan.j.williams, linux-pci, linux-coco, linux-kernel
In-Reply-To: <aWRctnwjEXvUyayb@yilunxu-OptiPlex-7050>
在 2026/1/12 10:30, Xu Yilun 写道:
> 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
Sure, will do that in V2, thanks for review.
Ming
^ permalink raw reply
* Re: [PATCH v7 0/2] SEV-SNP: Add KVM support for SNP certificate fetching
From: Liam Merwick @ 2026-01-13 12:23 UTC (permalink / raw)
To: Michael Roth, kvm
Cc: linux-coco, linux-kernel, pbonzini, seanjc, jroedel,
thomas.lendacky, huibo.wang, liam.merwick
In-Reply-To: <20260109231732.1160759-1-michael.roth@amd.com>
On 09/01/2026 23:17, Michael Roth wrote:
> This patchset is also available at:
>
> https://github.com/amdese/linux/commits/snp-certs-v7
>
> and is based on top of kvm/next (0499add8efd7)
>
>
> Overview
> --------
>
> The GHCB 2.0 specification defines 2 GHCB request types to allow SNP guests
> to send encrypted messages/requests to firmware: SNP Guest Requests and SNP
> Extended Guest Requests. These encrypted messages are used for things like
> servicing attestation requests issued by the guest. Implementing support for
> these is required to be fully GHCB-compliant.
>
(...)
>
> Changes since v6:
>
> * Incorporate documentation/comment suggestions from Sean, along with
> additional clarity/grammar fixups.
> * Don't define SNP_GUEST_VMM_ERR_GENERIC for general use within kernel,
> instead limit it to a KVM-specific choice of value in lieu of any
> formally-defined guest message return code for generic/undefined errors.
> * switch struct kvm_exit_snp_req_certs to using a 'gpa' argument instead
> of 'gfn' (Sean)
> * rebase to kvm/next, re-test, and collect R-b/T-b's
>
v7 also
Tested-by: Liam Merwick <liam.merwick@oracle.com>
(...)
>
> ----------------------------------------------------------------
> Michael Roth (2):
> KVM: Introduce KVM_EXIT_SNP_REQ_CERTS for SNP certificate-fetching
> KVM: SEV: Add KVM_SEV_SNP_ENABLE_REQ_CERTS command
>
> Documentation/virt/kvm/api.rst | 44 ++++++++++++
> .../virt/kvm/x86/amd-memory-encryption.rst | 52 ++++++++++++++-
> arch/x86/include/uapi/asm/kvm.h | 2 +
> arch/x86/kvm/svm/sev.c | 78 ++++++++++++++++++++--
> arch/x86/kvm/svm/svm.h | 1 +
> include/uapi/linux/kvm.h | 9 +++
> 6 files changed, 179 insertions(+), 7 deletions(-)
>
>
>
^ permalink raw reply
* Re: [PATCH v2 05/21] x86/virt/seamldr: Introduce a wrapper for P-SEAMLDR SEAMCALLs
From: Xu Yilun @ 2026-01-13 11:08 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, sagis, vannapurve, paulmck,
nik.borisov, Farrah Chen, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Kirill A. Shutemov
In-Reply-To: <20251001025442.427697-6-chao.gao@intel.com>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 58d890fe2100..6b47383d2958 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1905,6 +1905,16 @@ config INTEL_TDX_HOST
>
> If unsure, say N.
>
> +config INTEL_TDX_MODULE_UPDATE
> + bool "Intel TDX module runtime update"
> + depends on TDX_HOST_SERVICES
> + help
> + This enables the kernel to support TDX module runtime update. This
> + allows the admin to update the TDX module to the same or any newer
> + version without the need to terminate running TDX guests.
I'm wondering if it is better to put this option in
drivers/virt/coco/tdx-host. Just as TDX Connect, the
functionalities/uAPIs are exposed in /sys/devices/faux/tdx_host. Better
the 2 features could have aligned config pattern. The TDX Connect
configuration is here:
https://lore.kernel.org/all/20251117022311.2443900-4-yilun.xu@linux.intel.com/
> +
> + If unsure, say N.
> +
> config EFI
> bool "EFI runtime service support"
> depends on ACPI
> diff --git a/arch/x86/virt/vmx/tdx/Makefile b/arch/x86/virt/vmx/tdx/Makefile
> index 90da47eb85ee..26aea3531c36 100644
> --- a/arch/x86/virt/vmx/tdx/Makefile
> +++ b/arch/x86/virt/vmx/tdx/Makefile
> @@ -1,2 +1,3 @@
> # SPDX-License-Identifier: GPL-2.0-only
> obj-y += seamcall.o tdx.o
> +obj-$(CONFIG_INTEL_TDX_MODULE_UPDATE) += seamldr.o
And I'm wondering if we must disable seamldr core helpers if Update
uAPIs are not selected. TDX core now are expected to expose various
helpers for different features and is it necessary we have to mask
in/out all helpers in such a fine granularity? For example we may not
disable tdh_mem_sept_xx() helpers if KVM_INTEL is not selected.
BTW: We may finally get rid of the dependency between KVM_INTEL & TDX_HOST
-----8<-----
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 80527299f859..e3e90d1fcad3 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1898,7 +1898,6 @@ config INTEL_TDX_HOST
bool "Intel Trust Domain Extensions (TDX) host support"
depends on CPU_SUP_INTEL
depends on X86_64
- depends on KVM_INTEL
depends on X86_X2APIC
select ARCH_KEEP_MEMBLOCK
depends on CONTIG_ALLOC
[...]
> +static __maybe_unused int seamldr_call(u64 fn, struct tdx_module_args *args)
> +{
> + unsigned long flags;
> + u64 vmcs;
> + int ret;
> +
> + if (!is_seamldr_call(fn))
> + return -EINVAL;
> +
> + /*
> + * SEAMRET from P-SEAMLDR invalidates the current VMCS. Save/restore
> + * the VMCS across P-SEAMLDR SEAMCALLs to avoid clobbering KVM state.
> + * Disable interrupts as KVM is allowed to do VMREAD/VMWRITE in IRQ
> + * context (but not NMI context).
> + */
> + local_irq_save(flags);
> +
> + asm goto("1: vmptrst %0\n\t"
> + _ASM_EXTABLE(1b, %l[error])
> + : "=m" (vmcs) : : "cc" : error);
> +
> + ret = seamldr_prerr(fn, args);
As I mentioned, just use seamcall_prerr(). This perfectly illustrates the
main difference between normal seamcalls & seamldr_calls - the additional
VMCS handling.
> +
> + /*
> + * Restore the current VMCS pointer. VMPTSTR "returns" all ones if the
> + * current VMCS is invalid.
> + */
> + if (vmcs != -1ULL) {
> + asm goto("1: vmptrld %0\n\t"
> + "jna %l[error]\n\t"
> + _ASM_EXTABLE(1b, %l[error])
> + : : "m" (vmcs) : "cc" : error);
> + }
> +
> + local_irq_restore(flags);
> + return ret;
> +
> +error:
> + local_irq_restore(flags);
> +
> + WARN_ONCE(1, "Failed to save/restore the current VMCS");
> + return -EIO;
> +}
> --
> 2.47.3
>
^ permalink raw reply related
* Re: [PATCH v2 2/2] mm/memory_hotplug: Add support to unaccept memory after hot-remove
From: Kiryl Shutsemau @ 2026-01-13 10:28 UTC (permalink / raw)
To: Pratik R. Sampat
Cc: linux-mm, linux-coco, x86, linux-kernel, tglx, mingo, bp,
dave.hansen, ardb, akpm, david, osalvador, thomas.lendacky,
michael.roth
In-Reply-To: <20260112202300.43546-3-prsampat@amd.com>
On Mon, Jan 12, 2026 at 02:23:00PM -0600, Pratik R. Sampat wrote:
> 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.
Hm. What happens when we hot-remove memory that was there at the boot
and there's bitmap space for it?
Also, I'm not sure why it is needed. At least in TDX case, VMM can pull
the memory from under guest at any time without a warning. Coverting
memory to shared shouldn't make a difference as along as re-adding the
same GPA range triggers accept.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v2 04/21] x86/virt/tdx: Prepare to support P-SEAMLDR SEAMCALLs
From: Xu Yilun @ 2026-01-13 9:48 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, sagis, vannapurve, paulmck,
nik.borisov, Farrah Chen, Kirill A. Shutemov, Dave Hansen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20251001025442.427697-5-chao.gao@intel.com>
> diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
> index e872a411a359..7ad026618a23 100644
> --- a/arch/x86/include/asm/tdx.h
> +++ b/arch/x86/include/asm/tdx.h
> @@ -32,6 +32,11 @@
> #define TDX_SUCCESS 0ULL
> #define TDX_RND_NO_ENTROPY 0x8000020300000000ULL
>
> +/* P-SEAMLDR SEAMCALL leaf function error codes */
> +#define SEAMLDR_RND_NO_ENTROPY 0x8000000000030001ULL
> +
> +#define SEAMLDR_SEAMCALL_MASK _BITUL(63)
If we do want Patch #3 [*], I think no need to expose this bit in
public, define it in your newly added arch/x86/virt/vmx/tdx/seamcall.h
[*]: https://lore.kernel.org/all/20251001025442.427697-4-chao.gao@intel.com/
[...]
> +static inline bool sc_need_retry(u64 fn, u64 error_code)
> +{
> + if (is_seamldr_call(fn))
> + return error_code == SEAMLDR_RND_NO_ENTROPY;
> + else
> + return error_code == TDX_RND_NO_ENTROPY;
> +}
> +
Maybe we can remove this single-use wrapper and integrate it in
sc_retry?
> static __always_inline u64 sc_retry(sc_func_t func, u64 fn,
> struct tdx_module_args *args)
> {
u64 retry_code = TDX_RND_NO_ENTROPY;
if (is_seamldr_call(fn))
retry_code = SEAMLDR_RND_NO_ENTROPY;
> @@ -22,7 +35,7 @@ static __always_inline u64 sc_retry(sc_func_t func, u64 fn,
>
> do {
> ret = func(fn, args);
> - } while (ret == TDX_RND_NO_ENTROPY && --retry);
> + } while (sc_need_retry(fn, ret) && --retry);
} while (ret == retry_code && --retry);
Seems more straightforward to me.
>
> return ret;
> }
> @@ -48,6 +61,17 @@ static inline void seamcall_err_ret(u64 fn, u64 err,
> args->r9, args->r10, args->r11);
> }
>
> +static inline void seamldr_err(u64 fn, u64 err, struct tdx_module_args *args)
> +{
> + /*
> + * Get the actual leaf number. No need to print the bit used to
> + * differentiate between P-SEAMLDR and TDX module as the "P-SEAMLDR"
> + * string in the error message already provides that information.
> + */
> + fn &= ~SEAMLDR_SEAMCALL_MASK;
Why we must strip the bit from leaf number? See from P-seamldr SPEC [*],
all leaf definitions are with this bit, same for your C code:
+/* P-SEAMLDR SEAMCALL leaf function */
+#define P_SEAMLDR_INFO 0x8000000000000000
So my feeling is, log readability reduces without this bit. We don't
have to make all developers understand this bit, just expose the whole
leaf as magic number.
[*] https://cdrdv2.intel.com/v1/dl/getContent/733584
> + pr_err("P-SEAMLDR (%lld) failed: 0x%016llx\n", fn, err);
I see no problem we keep both "P-SEAMLDR" string & SEAMLDR bit printed.
And could we handle it the same as sc_retry(), something like:
static inline void seamcall_err(u64 fn, u64 err, struct tdx_module_args *args)
{
- pr_err("SEAMCALL (0x%016llx) failed: 0x%016llx\n", fn, err);
+ char *call = "SEAMCALL";
+
+ if (is_seamldr_call(fn))
+ call = "P-SEAMLDR";
+
+ pr_err("%s (0x%016llx) failed: 0x%016llx\n", call, fn, err);
}
And the benifit is ...
> +}
> +
> static __always_inline int sc_retry_prerr(sc_func_t func,
> sc_err_func_t err_func,
> u64 fn, struct tdx_module_args *args)
> @@ -76,4 +100,7 @@ static __always_inline int sc_retry_prerr(sc_func_t func,
> #define seamcall_prerr_ret(__fn, __args) \
> sc_retry_prerr(__seamcall_ret, seamcall_err_ret, (__fn), (__args))
>
> +#define seamldr_prerr(__fn, __args) \
> + sc_retry_prerr(__seamcall, seamldr_err, (__fn), (__args))
... we don't need this definition anymore, just use seamcall_prerr()
^ permalink raw reply
* Re: [PATCH v2 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
From: kernel test robot @ 2026-01-13 8:56 UTC (permalink / raw)
To: Pratik R. Sampat, linux-mm, linux-coco, x86, linux-kernel
Cc: llvm, oe-kbuild-all, tglx, mingo, bp, dave.hansen, kas, ardb,
akpm, david, osalvador, thomas.lendacky, michael.roth, prsampat
In-Reply-To: <20260112202300.43546-2-prsampat@amd.com>
Hi Pratik,
kernel test robot noticed the following build errors:
[auto build test ERROR on akpm-mm/mm-everything]
[also build test ERROR on tip/x86/core linus/master v6.19-rc5 next-20260109]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Pratik-R-Sampat/mm-memory_hotplug-Add-support-to-accept-memory-during-hot-add/20260113-042631
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link: https://lore.kernel.org/r/20260112202300.43546-2-prsampat%40amd.com
patch subject: [PATCH v2 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
config: s390-defconfig (https://download.01.org/0day-ci/archive/20260113/202601131632.NrQzg2Wm-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 9b8addffa70cee5b2acc5454712d9cf78ce45710)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260113/202601131632.NrQzg2Wm-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601131632.NrQzg2Wm-lkp@intel.com/
All errors (new ones prefixed by >>):
>> mm/memory_hotplug.c:41:10: fatal error: 'asm/unaccepted_memory.h' file not found
41 | #include <asm/unaccepted_memory.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
vim +41 mm/memory_hotplug.c
39
40 #include <asm/tlbflush.h>
> 41 #include <asm/unaccepted_memory.h>
42
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ 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-13 5:52 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: <20260112144314.69b850afad9ee67143f30a85@linux-foundation.org>
On 1/12/26 4:43 PM, Andrew Morton wrote:
> 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.
>
Got it. Thanks for clearing that up. I'll make sure to do it this way
in the next iteration.
--Pratik
^ permalink raw reply
* Re: [PATCH v2 1/2] x86/virt/tdx: Retrieve TDX module version
From: Xiaoyao Li @ 2026-01-13 3:58 UTC (permalink / raw)
To: Xu Yilun, Dave Hansen
Cc: 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: <aWW0TZNdWdN/C6Yi@yilunxu-OptiPlex-7050>
On 1/13/2026 10:56 AM, Xu Yilun wrote:
> 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.
I guess eventually we will introduce MACROs for these magic numbers to
make the code more readable given that the decision is no longer
auto-generate the code by the script? Though I'm not sure when that will
happen.
^ permalink raw reply
* Re: [PATCH v2 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
From: kernel test robot @ 2026-01-13 3:52 UTC (permalink / raw)
To: Pratik R. Sampat, linux-mm, linux-coco, x86, linux-kernel
Cc: oe-kbuild-all, tglx, mingo, bp, dave.hansen, kas, ardb, akpm,
david, osalvador, thomas.lendacky, michael.roth, prsampat
In-Reply-To: <20260112202300.43546-2-prsampat@amd.com>
Hi Pratik,
kernel test robot noticed the following build errors:
[auto build test ERROR on akpm-mm/mm-everything]
[also build test ERROR on tip/x86/core linus/master v6.19-rc5 next-20260109]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Pratik-R-Sampat/mm-memory_hotplug-Add-support-to-accept-memory-during-hot-add/20260113-042631
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link: https://lore.kernel.org/r/20260112202300.43546-2-prsampat%40amd.com
patch subject: [PATCH v2 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
config: s390-randconfig-001-20260113 (https://download.01.org/0day-ci/archive/20260113/202601131156.Kfi0QLIm-lkp@intel.com/config)
compiler: s390-linux-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260113/202601131156.Kfi0QLIm-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601131156.Kfi0QLIm-lkp@intel.com/
All errors (new ones prefixed by >>):
>> mm/memory_hotplug.c:41:10: fatal error: asm/unaccepted_memory.h: No such file or directory
#include <asm/unaccepted_memory.h>
^~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
vim +41 mm/memory_hotplug.c
39
40 #include <asm/tlbflush.h>
> 41 #include <asm/unaccepted_memory.h>
42
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ 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