* Re: [PATCH kernel 1/9] pci/tsm: Add TDISP report blob and helpers to parse it
From: Alexey Kardashevskiy @ 2026-02-26 0:09 UTC (permalink / raw)
To: dan.j.williams, x86
Cc: linux-kernel, kvm, linux-pci, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Sean Christopherson,
Paolo Bonzini, Andy Lutomirski, Peter Zijlstra, Bjorn Helgaas,
Marek Szyprowski, Robin Murphy, Andrew Morton, Catalin Marinas,
Michael Ellerman, Mike Rapoport, Tom Lendacky, Ard Biesheuvel,
Neeraj Upadhyay, Ashish Kalra, Stefano Garzarella, Melody Wang,
Seongman Lee, Joerg Roedel, Nikunj A Dadhania, Michael Roth,
Suravee Suthikulpanit, Andi Kleen, Kuppuswamy Sathyanarayanan,
Tony Luck, David Woodhouse, Greg Kroah-Hartman, Denis Efremov,
Geliang Tang, Piotr Gregor, Michael S. Tsirkin, Alex Williamson,
Arnd Bergmann, Jesse Barnes, Jacob Pan, Yinghai Lu, Kevin Brodsky,
Jonathan Cameron, Aneesh Kumar K.V (Arm), Xu Yilun, Herbert Xu,
Kim Phillips, Konrad Rzeszutek Wilk, Stefano Stabellini,
Claire Chang, linux-coco, iommu
In-Reply-To: <699e93db9ad47_1cc510090@dwillia2-mobl4.notmuch>
On 25/2/26 17:16, dan.j.williams@intel.com wrote:
> Alexey Kardashevskiy wrote:
>> The TDI interface report is defined in PCIe r7.0,
>> chapter "11.3.11 DEVICE_INTERFACE_REPORT". The report enumerates
>> MMIO resources and their properties which will take effect upon
>> transitioning to the RUN state.
>>
>> Store the report in pci_tsm.
>>
>> Define macros and helpers to parse the binary blob.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
>> ---
>>
>> Probably pci_tsm::report could be struct tdi_report_header*?
> [..]
>> +struct tdi_report_header {
>> + __u16 interface_info; /* TSM_TDI_REPORT_xxx */
>> + __u16 reserved2;
>> + __u16 msi_x_message_control;
>> + __u16 lnr_control;
>> + __u32 tph_control;
>> + __u32 mmio_range_count;
>> +} __packed;
>> +
>> +/*
>> + * Each MMIO Range of the TDI is reported with the MMIO reporting offset added.
>> + * Base and size in units of 4K pages
>> + */
>> +#define TSM_TDI_REPORT_MMIO_MSIX_TABLE BIT(0)
>> +#define TSM_TDI_REPORT_MMIO_PBA BIT(1)
>> +#define TSM_TDI_REPORT_MMIO_IS_NON_TEE BIT(2)
>> +#define TSM_TDI_REPORT_MMIO_IS_UPDATABLE BIT(3)
>> +#define TSM_TDI_REPORT_MMIO_RESERVED GENMASK(15, 4)
>> +#define TSM_TDI_REPORT_MMIO_RANGE_ID GENMASK(31, 16)
>> +
>> +struct tdi_report_mmio_range {
>> + __u64 first_page; /* First 4K page with offset added */
>> + __u32 num; /* Number of 4K pages in this range */
>> + __u32 range_attributes; /* TSM_TDI_REPORT_MMIO_xxx */
>
> Those should be __le64 and le32, right?
Oh yes.
> But see below for another
> option...
>
>> +} __packed;
>> +
>> +struct tdi_report_footer {
>> + __u32 device_specific_info_len;
>> + __u8 device_specific_info[];
>> +} __packed;
>> +
>> +#define TDI_REPORT_HDR(rep) ((struct tdi_report_header *) ((rep)->data))
>> +#define TDI_REPORT_MR_NUM(rep) (TDI_REPORT_HDR(rep)->mmio_range_count)
>> +#define TDI_REPORT_MR_OFF(rep) ((struct tdi_report_mmio_range *) (TDI_REPORT_HDR(rep) + 1))
>> +#define TDI_REPORT_MR(rep, rangeid) TDI_REPORT_MR_OFF(rep)[rangeid]
>> +#define TDI_REPORT_FTR(rep) ((struct tdi_report_footer *) &TDI_REPORT_MR((rep), \
>> + TDI_REPORT_MR_NUM(rep)))
>> +
>
> So we all have a version of a patch like this and the general style
> suggestion I have is to just parse this layout with typical
> offsets+bitfield definitions.
>
> This follows the precedent, admittedly tiny, of the DOE definitions in
> pci_regs.h. See:
>
> /* DOE Data Object - note not actually registers */
>
> I have a patch that parses the TDISP report with these defines:
>
> /*
> * PCIe ECN TEE Device Interface Security Protocol (TDISP)
> *
> * Device Interface Report data object layout as defined by PCIe r7.0 section
> * 11.3.11
> */
> #define PCI_TSM_DEVIF_REPORT_INFO 0
> #define PCI_TSM_DEVIF_REPORT_MSIX 4
> #define PCI_TSM_DEVIF_REPORT_LNR 6
> #define PCI_TSM_DEVIF_REPORT_TPH 8
> #define PCI_TSM_DEVIF_REPORT_MMIO_COUNT 12
> #define PCI_TSM_DEVIF_REPORT_MMIO_PFN 0 /* An interface report 'pfn' is 4K in size */
> #define PCI_TSM_DEVIF_REPORT_MMIO_NR_PFNS 8
> #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR 12
I cannot easily see from these what the sizes are. And how many of each.
> #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_MSIX_TABLE BIT(0)
> #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_MSIX_PBA BIT(1)
> #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_IS_NON_TEE BIT(2)
> #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_IS_UPDATABLE BIT(3)
> #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_RANGE_ID GENMASK(31, 16)
> #define PCI_TSM_DEVIF_REPORT_MMIO_SIZE (16)
> #define PCI_TSM_DEVIF_REPORT_BASE_SIZE(nr_mmio) (16 + nr_mmio * PCI_TSM_DEVIF_REPORT_MMIO_SIZE)
>
> Any strong feelings one way or the other? I have a mild preference for
> this offset+bitfields approach.
My variant is just like this (may be need to put it in the comment):
tdi_report_header
tdi_report_mmio_range[]
tdi_report_footer
imho easier on eyes. I can live with either if the majority votes for it. Thanks.
--
Alexey
^ permalink raw reply
* Re: [PATCH kernel 4/9] dma/swiotlb: Stop forcing SWIOTLB for TDISP devices
From: Alexey Kardashevskiy @ 2026-02-26 0:09 UTC (permalink / raw)
To: Robin Murphy, x86
Cc: linux-kernel, kvm, linux-pci, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Sean Christopherson,
Paolo Bonzini, Andy Lutomirski, Peter Zijlstra, Bjorn Helgaas,
Dan Williams, Marek Szyprowski, Andrew Morton, Catalin Marinas,
Michael Ellerman, Mike Rapoport, Tom Lendacky, Ard Biesheuvel,
Neeraj Upadhyay, Ashish Kalra, Stefano Garzarella, Melody Wang,
Seongman Lee, Joerg Roedel, Nikunj A Dadhania, Michael Roth,
Suravee Suthikulpanit, Andi Kleen, Kuppuswamy Sathyanarayanan,
Tony Luck, David Woodhouse, Greg Kroah-Hartman, Denis Efremov,
Geliang Tang, Piotr Gregor, Michael S. Tsirkin, Alex Williamson,
Arnd Bergmann, Jesse Barnes, Jacob Pan, Yinghai Lu, Kevin Brodsky,
Jonathan Cameron, Aneesh Kumar K.V (Arm), Xu Yilun, Herbert Xu,
Kim Phillips, Konrad Rzeszutek Wilk, Stefano Stabellini,
Claire Chang, linux-coco, iommu
In-Reply-To: <5c7397b5-0368-4bd7-af5a-e513f289c775@arm.com>
On 26/2/26 03:48, Robin Murphy wrote:
> On 2026-02-25 5:37 am, Alexey Kardashevskiy wrote:
>> SWIOTLB is enforced when encrypted guest memory is detected
>> in pci_swiotlb_detect() which is required for legacy devices.
>>
>> Skip SWIOTLB for TDISP devices.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
>> ---
>> include/linux/swiotlb.h | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
>> index 3dae0f592063..119c25d639a7 100644
>> --- a/include/linux/swiotlb.h
>> +++ b/include/linux/swiotlb.h
>> @@ -173,6 +173,15 @@ static inline bool is_swiotlb_force_bounce(struct device *dev)
>> {
>> struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
>> + /*
>> + * CC_ATTR_GUEST_MEM_ENCRYPT enforces SWIOTLB_FORCE in
>> + * swiotlb_init_remap() to allow legacy devices access arbitrary
>> + * VM encrypted memory.
>> + * Skip it for TDISP devices capable of DMA-ing the encrypted memory.
>> + */
>> + if (device_cc_accepted(dev))
>> + return false;
>
> This seems backwards - how does it make sense for arch code to force SWIOTLB globally on the grounds that all DMA must be to shared memory, but then generic code override that because it claims to know better?
True. I have the itch to remove SWIOTLB_FORCE from pci_swiotlb_detect(), this may be the other way to go.
> I'd expect to see something more like:
>
> if (is_cc_platform && !device_cc_accepted)
device_cc_accepted() implies is_cc_platform.
> return true;
>
> here, and then get rid of the rest of the (ab)use of SWIOTLB_FORCE for this purpose entirely.
>
> However there is the fiddly aspect that it's not necessarily strictly enough to just un-force SWIOTLB; we really want to actively ensure that no private memory can *ever* end up getting bounced through a shared SWIOTLB buffer. The private/shared state is really a property of the individual DMA mappings, though, rather than an overall property of the device itself
At the moment it is a property of the device though, for AMD, at least.
> (since a device that's trusted to access private memory isn't necessarily prohibited from still also accessing shared memory as well), hmmm...
True. With vTOM ("everything above TopOfMemory is shared", not using it now) or secure vIOMMU all sorts of accesses is possible. Thanks,
>
> Thanks,
> Robin.
>
>> +
>> return mem && mem->force_bounce;
>> }
>
--
Alexey
^ permalink raw reply
* Re: [PATCH kernel 8/9] RFC: PCI: Avoid needless touching of Command register
From: Bjorn Helgaas @ 2026-02-26 0:24 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: x86, linux-kernel, kvm, linux-pci, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Sean Christopherson,
Paolo Bonzini, Andy Lutomirski, Peter Zijlstra, Bjorn Helgaas,
Dan Williams, Marek Szyprowski, Robin Murphy, Andrew Morton,
Catalin Marinas, Michael Ellerman, Mike Rapoport, Tom Lendacky,
Ard Biesheuvel, Neeraj Upadhyay, Ashish Kalra, Stefano Garzarella,
Melody Wang, Seongman Lee, Joerg Roedel, Nikunj A Dadhania,
Michael Roth, Suravee Suthikulpanit, Andi Kleen,
Kuppuswamy Sathyanarayanan, Tony Luck, David Woodhouse,
Greg Kroah-Hartman, Denis Efremov, Geliang Tang, Piotr Gregor,
Michael S. Tsirkin, Alex Williamson, Arnd Bergmann, Jesse Barnes,
Jacob Pan, Yinghai Lu, Kevin Brodsky, Jonathan Cameron,
Aneesh Kumar K.V (Arm), Xu Yilun, Herbert Xu, Kim Phillips,
Konrad Rzeszutek Wilk, Stefano Stabellini, Claire Chang,
linux-coco, iommu
In-Reply-To: <20260225053806.3311234-9-aik@amd.com>
On Wed, Feb 25, 2026 at 04:37:51PM +1100, Alexey Kardashevskiy wrote:
> Once locked, a TDI's MSE and BME are not allowed to be cleared.
Disallowed by hardware, by spec, by convention? Spec reference would
be helpful.
> Skip INTx test as TEE-capable PCI functions are most likely IOV VFs
> anyway and those do not support INTx at all.
"Most likely" doesn't sound like a convincing argument for skipping
something.
> Add a quirk preventing the probing code from disabling MSE when
> updating 64bit BAR (which cannot be done atomically).
Say more about this please. If there's something special about this
device, I'd like to know exactly what that is.
> Note that normally this happens too early and likely not really
> needed for the device attestation happening long after PCI probing.
I don't follow this either. Please make it meaningful for
non-TEE/TDI/whatever experts. And mention that context in the subject
line.
> @@ -1930,6 +1930,11 @@ static int pci_intx_mask_broken(struct pci_dev *dev)
> {
> u16 orig, toggle, new;
>
> + if (dev->devcap & PCI_EXP_DEVCAP_TEE) {
> + pci_warn_once(dev, "(TIO) Disable check for broken INTX");
> + return 1;
s/INTX/INTx/
Why do users need to know this? Why as a warning? What can they do
about it? "TIO"?
^ permalink raw reply
* Re: [PATCH kernel 8/9] RFC: PCI: Avoid needless touching of Command register
From: dan.j.williams @ 2026-02-26 0:34 UTC (permalink / raw)
To: Alexey Kardashevskiy, x86
Cc: linux-kernel, kvm, linux-pci, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Sean Christopherson,
Paolo Bonzini, Andy Lutomirski, Peter Zijlstra, Bjorn Helgaas,
Dan Williams, Marek Szyprowski, Robin Murphy, Andrew Morton,
Catalin Marinas, Michael Ellerman, Mike Rapoport, Tom Lendacky,
Ard Biesheuvel, Neeraj Upadhyay, Ashish Kalra, Stefano Garzarella,
Melody Wang, Seongman Lee, Joerg Roedel, Nikunj A Dadhania,
Michael Roth, Suravee Suthikulpanit, Andi Kleen,
Kuppuswamy Sathyanarayanan, Tony Luck, David Woodhouse,
Greg Kroah-Hartman, Denis Efremov, Geliang Tang, Piotr Gregor,
Michael S. Tsirkin, Alex Williamson, Arnd Bergmann, Jesse Barnes,
Jacob Pan, Yinghai Lu, Kevin Brodsky, Jonathan Cameron,
Aneesh Kumar K.V (Arm), Xu Yilun, Herbert Xu, Kim Phillips,
Konrad Rzeszutek Wilk, Stefano Stabellini, Claire Chang,
linux-coco, iommu, Alexey Kardashevskiy
In-Reply-To: <20260225053806.3311234-9-aik@amd.com>
Alexey Kardashevskiy wrote:
> Once locked, a TDI's MSE and BME are not allowed to be cleared.
>
> Skip INTx test as TEE-capable PCI functions are most likely IOV VFs
> anyway and those do not support INTx at all.
>
> Add a quirk preventing the probing code from disabling MSE when
> updating 64bit BAR (which cannot be done atomically).
>
> Note that normally this happens too early and likely not really
> needed for the device attestation happening long after PCI probing.
>
> Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
> ---
>
> This is also handled in QEMU - it will block clearing BME and MSE
> (normally happening on modprobe/rmmod) as long as the TDI is
> CONFIG_LOCKED or RUN.
>
> This only patch is not enough but reduces the number of unwanted
> writes to MSE/BME.
>
> Also, SRIOV cannot have INTx so pci_intx_mask_broken() could skip
> VFs too, should it?
Locked command register management is handled by QEMU. This patch needs
quite a bit more explanation about what use case it is trying to solve.
^ permalink raw reply
* Re: [PATCH kernel 1/9] pci/tsm: Add TDISP report blob and helpers to parse it
From: dan.j.williams @ 2026-02-26 2:34 UTC (permalink / raw)
To: Alexey Kardashevskiy, dan.j.williams, x86
Cc: linux-kernel, kvm, linux-pci, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Sean Christopherson,
Paolo Bonzini, Andy Lutomirski, Peter Zijlstra, Bjorn Helgaas,
Marek Szyprowski, Robin Murphy, Andrew Morton, Catalin Marinas,
Michael Ellerman, Mike Rapoport, Tom Lendacky, Ard Biesheuvel,
Neeraj Upadhyay, Ashish Kalra, Stefano Garzarella, Melody Wang,
Seongman Lee, Joerg Roedel, Nikunj A Dadhania, Michael Roth,
Suravee Suthikulpanit, Andi Kleen, Kuppuswamy Sathyanarayanan,
Tony Luck, David Woodhouse, Greg Kroah-Hartman, Denis Efremov,
Geliang Tang, Piotr Gregor, Michael S. Tsirkin, Alex Williamson,
Arnd Bergmann, Jesse Barnes, Jacob Pan, Yinghai Lu, Kevin Brodsky,
Jonathan Cameron, Aneesh Kumar K.V (Arm), Xu Yilun, Herbert Xu,
Kim Phillips, Konrad Rzeszutek Wilk, Stefano Stabellini,
Claire Chang, linux-coco, iommu
In-Reply-To: <d8fd6e0e-a814-4883-9e58-f1aa501e0d8c@amd.com>
Alexey Kardashevskiy wrote:
[..]
> I cannot easily see from these what the sizes are. And how many of each.
Same as any other offset+bitmask code, the size is encoded in the accessor.
Arnd caught that I misspoke when I said offset+bitfield.
> > #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_MSIX_TABLE BIT(0)
> > #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_MSIX_PBA BIT(1)
> > #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_IS_NON_TEE BIT(2)
> > #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_IS_UPDATABLE BIT(3)
> > #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_RANGE_ID GENMASK(31, 16)
> > #define PCI_TSM_DEVIF_REPORT_MMIO_SIZE (16)
> > #define PCI_TSM_DEVIF_REPORT_BASE_SIZE(nr_mmio) (16 + nr_mmio * PCI_TSM_DEVIF_REPORT_MMIO_SIZE)
> >
> > Any strong feelings one way or the other? I have a mild preference for
> > this offset+bitfields approach.
>
>
> My variant is just like this (may be need to put it in the comment):
>
> tdi_report_header
> tdi_report_mmio_range[]
> tdi_report_footer
Does the kernel have any use for the footer besides conveying it to
userspace?
> imho easier on eyes. I can live with either if the majority votes for it. Thanks.
Aneesh also already has 'structs+bitmask', I will switch to that.
^ permalink raw reply
* Re: [PATCH v4 21/24] x86/virt/tdx: Avoid updates during update-sensitive operations
From: Chao Gao @ 2026-02-26 3:02 UTC (permalink / raw)
To: Huang, Kai
Cc: kvm@vger.kernel.org, linux-coco@lists.linux.dev,
linux-kernel@vger.kernel.org, x86@kernel.org,
dave.hansen@linux.intel.com, tony.lindgren@linux.intel.com,
binbin.wu@linux.intel.com, seanjc@google.com, kas@kernel.org,
Chatre, Reinette, Verma, Vishal L, nik.borisov@suse.com,
mingo@redhat.com, Weiny, Ira, pbonzini@redhat.com, hpa@zytor.com,
Annapurve, Vishal, sagis@google.com, Duan, Zhenzhong,
Edgecombe, Rick P, paulmck@kernel.org, tglx@kernel.org,
yilun.xu@linux.intel.com, Williams, Dan J, bp@alien8.de
In-Reply-To: <a0a5301140be5a3d944b1c91914b93017af026fb.camel@intel.com>
>> int tdx_module_shutdown(void)
>> {
>> struct tdx_module_args args = {};
>> - int ret, cpu;
>> + u64 ret;
>> + int cpu;
>>
>> /*
>> * Shut down the TDX Module and prepare handoff data for the next
>> @@ -1189,9 +1192,21 @@ int tdx_module_shutdown(void)
>> * modules as new modules likely have higher handoff version.
>> */
>> args.rcx = tdx_sysinfo.handoff.module_hv;
>> - ret = seamcall_prerr(TDH_SYS_SHUTDOWN, &args);
>> - if (ret)
>> - return ret;
>> +
>> + if (tdx_supports_update_compatibility(&tdx_sysinfo))
>> + args.rcx |= TDX_SYS_SHUTDOWN_AVOID_COMPAT_SENSITIVE;
>> +
>> + ret = seamcall(TDH_SYS_SHUTDOWN, &args);
>> +
>> + /*
>> + * Return -EBUSY to signal that there is one or more ongoing flows
>> + * which may not be compatible with an updated TDX module, so that
>> + * userspace can retry on this error.
>> + */
>> + if ((ret & TDX_SEAMCALL_STATUS_MASK) == TDX_UPDATE_COMPAT_SENSITIVE)
>> + return -EBUSY;
>> + else if (ret)
>> + return -EIO;
>>
>
>The changelog says "doing nothing" isn't an option, and we need to depend on
>TDH.SYS.SHUTDOWN to catch such incompatibilities.
>
>To me this means we cannot support module update if TDH.SYS.SHUTDOWN doesn't
>support this "AVOID_COMPAT_SENSITIVE" feature, because w/o it we cannot tell
>whether the update is happening during any sensitive operation.
>
Good point.
I'm fine with disabling updates in this case. The only concern is that it would
block even perfectly compatible updates, but this only impacts a few older
modules, so it shouldn't be a big problem. And the value of supporting old
modules will also diminish over time.
But IMO, the kernel's incompatibility check is intentionally best effort, not a
guarantee. For example, the kernel doesn't verify if the module update is
compatible with the CPU or P-SEAMLDR. So non-compatible updates may slip through
anyway, and the expectation for users is "run non-compatible updates at their
own risk". Given this, allowing updates when one incompatibility check is
not supported (i.e., AVOID_COMPAT_SENSITIVE) is also acceptable. At minimum,
users can choose not to perform updates if the module lacks
AVOID_COMPAT_SENSITIVE support.
I'm fine with either approach, but slightly prefer disabling updates in
this case. Let's see if anyone has strong opinions on this.
^ permalink raw reply
* Re: [PATCH kernel 7/9] coco/sev-guest: Implement the guest support for SEV TIO (phase2)
From: Alexey Kardashevskiy @ 2026-02-26 3:39 UTC (permalink / raw)
To: Borislav Petkov, x86
Cc: linux-kernel, kvm, linux-pci, Thomas Gleixner, Ingo Molnar,
Dave Hansen, H. Peter Anvin, Sean Christopherson, Paolo Bonzini,
Andy Lutomirski, Peter Zijlstra, Bjorn Helgaas, Dan Williams,
Marek Szyprowski, Robin Murphy, Andrew Morton, Catalin Marinas,
Michael Ellerman, Mike Rapoport, Tom Lendacky, Ard Biesheuvel,
Neeraj Upadhyay, Ashish Kalra, Stefano Garzarella, Melody Wang,
Seongman Lee, Joerg Roedel, Nikunj A Dadhania, Michael Roth,
Suravee Suthikulpanit, Andi Kleen, Kuppuswamy Sathyanarayanan,
Tony Luck, David Woodhouse, Greg Kroah-Hartman, Denis Efremov,
Geliang Tang, Piotr Gregor, Michael S. Tsirkin, Alex Williamson,
Arnd Bergmann, Jesse Barnes, Jacob Pan, Yinghai Lu, Kevin Brodsky,
Jonathan Cameron, Aneesh Kumar K.V (Arm), Xu Yilun, Herbert Xu,
Kim Phillips, Konrad Rzeszutek Wilk, Stefano Stabellini,
Claire Chang, linux-coco, iommu
In-Reply-To: <ABE746F3-53E9-4730-BBFC-52111166A7B9@alien8.de>
On 25/2/26 17:00, Borislav Petkov wrote:
> On February 25, 2026 5:37:50 AM UTC, Alexey Kardashevskiy <aik@amd.com> wrote:
>> Implement the SEV-TIO (Trusted I/O) support in for AMD SEV-SNP guests.
>>
>> The implementation includes Device Security Manager (DSM) operations
>> for:
>> - binding a PCI function (GHCB extension) to a VM and locking
>> the device configuration;
>> - receiving TDI report and configuring MMIO and DMA/sDTE;
>> - accepting the device into the guest TCB.
>>
>> Detect the SEV-TIO support (reported via GHCB HV features) and install
>> the SEV-TIO TSM ops.
>>
>> Implement lock/accept/unlock TSM ops.
>>
>> Define 2 new VMGEXIT codes for GHCB:
>> - TIO Guest Request to provide secure communication between a VM and
>> the FW (for configuring MMIO and DMA);
>> - TIO Op for requesting the HV to bind a TDI to the VM and for
>> starting/stopping a TDI.
>
> Just from staring at that huuuge diff, those bullets and things above are basically begging to be separate patches...
I struggle to separate these more without making individual patches useless for any purpose, even splitting between maintainership area. People often define things in separate patches and then use them and I dislike such approach for reviewing purposes - hard to follow. I can ditch more stuff (like TIO_GUID_CERTIFICATES - just noticed) but it is not much :-/
--
Alexey
^ permalink raw reply
* Re: [PATCH kernel 1/9] pci/tsm: Add TDISP report blob and helpers to parse it
From: Alexey Kardashevskiy @ 2026-02-26 3:49 UTC (permalink / raw)
To: dan.j.williams, x86
Cc: linux-kernel, kvm, linux-pci, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Sean Christopherson,
Paolo Bonzini, Andy Lutomirski, Peter Zijlstra, Bjorn Helgaas,
Marek Szyprowski, Robin Murphy, Andrew Morton, Catalin Marinas,
Michael Ellerman, Mike Rapoport, Tom Lendacky, Ard Biesheuvel,
Neeraj Upadhyay, Ashish Kalra, Stefano Garzarella, Melody Wang,
Seongman Lee, Joerg Roedel, Nikunj A Dadhania, Michael Roth,
Suravee Suthikulpanit, Andi Kleen, Kuppuswamy Sathyanarayanan,
Tony Luck, David Woodhouse, Greg Kroah-Hartman, Denis Efremov,
Geliang Tang, Piotr Gregor, Michael S. Tsirkin, Alex Williamson,
Arnd Bergmann, Jesse Barnes, Jacob Pan, Yinghai Lu, Kevin Brodsky,
Jonathan Cameron, Aneesh Kumar K.V (Arm), Xu Yilun, Herbert Xu,
Kim Phillips, Konrad Rzeszutek Wilk, Stefano Stabellini,
Claire Chang, linux-coco, iommu
In-Reply-To: <699fb11e94082_2f4a1007d@dwillia2-mobl4.notmuch>
On 26/2/26 13:34, dan.j.williams@intel.com wrote:
> Alexey Kardashevskiy wrote:
> [..]
>> I cannot easily see from these what the sizes are. And how many of each.
>
> Same as any other offset+bitmask code, the size is encoded in the accessor.
>
> Arnd caught that I misspoke when I said offset+bitfield.
>>>> #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_MSIX_TABLE BIT(0)
>>> #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_MSIX_PBA BIT(1)
>>> #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_IS_NON_TEE BIT(2)
>>> #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_IS_UPDATABLE BIT(3)
>>> #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_RANGE_ID GENMASK(31, 16)
>>> #define PCI_TSM_DEVIF_REPORT_MMIO_SIZE (16)
>>> #define PCI_TSM_DEVIF_REPORT_BASE_SIZE(nr_mmio) (16 + nr_mmio * PCI_TSM_DEVIF_REPORT_MMIO_SIZE)
>>>
>>> Any strong feelings one way or the other? I have a mild preference for
>>> this offset+bitfields approach.
>>
>>
>> My variant is just like this (may be need to put it in the comment):
>>
>> tdi_report_header
>> tdi_report_mmio_range[]
>> tdi_report_footer
>
> Does the kernel have any use for the footer besides conveying it to
> userspace?
PCIe says:
Example of such device specific information include:
• A network device may include receive-side scaling (RSS) related information such as the RSS hash and
mappings to the virtual station interface (VSI) queues, etc.
• A NVMe device may include information about the associated name spaces, mapping of name space to
command queue-pair mappings, etc.
• Accelerators may report capabilities such as algorithms supported, queue depths, etc
Sounds to me like something the device driver would be interested in.
>
>> imho easier on eyes. I can live with either if the majority votes for it. Thanks.
>
> Aneesh also already has 'structs+bitmask', I will switch to that.
oh I just found it, more or less my version :) I can add pci_tdisp_ prefixes, should I? Thanks,
--
Alexey
^ permalink raw reply
* Re: [PATCH kernel 8/9] RFC: PCI: Avoid needless touching of Command register
From: Alexey Kardashevskiy @ 2026-02-26 5:58 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: x86, linux-kernel, kvm, linux-pci, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Sean Christopherson,
Paolo Bonzini, Andy Lutomirski, Peter Zijlstra, Bjorn Helgaas,
Dan Williams, Marek Szyprowski, Robin Murphy, Andrew Morton,
Catalin Marinas, Michael Ellerman, Mike Rapoport, Tom Lendacky,
Ard Biesheuvel, Neeraj Upadhyay, Ashish Kalra, Stefano Garzarella,
Melody Wang, Seongman Lee, Joerg Roedel, Nikunj A Dadhania,
Michael Roth, Suravee Suthikulpanit, Andi Kleen,
Kuppuswamy Sathyanarayanan, Tony Luck, David Woodhouse,
Greg Kroah-Hartman, Denis Efremov, Geliang Tang, Piotr Gregor,
Michael S. Tsirkin, Alex Williamson, Arnd Bergmann, Jesse Barnes,
Jacob Pan, Yinghai Lu, Kevin Brodsky, Jonathan Cameron,
Aneesh Kumar K.V (Arm), Xu Yilun, Herbert Xu, Kim Phillips,
Konrad Rzeszutek Wilk, Stefano Stabellini, Claire Chang,
linux-coco, iommu
In-Reply-To: <20260226002459.GA3795172@bhelgaas>
On 26/2/26 11:24, Bjorn Helgaas wrote:
> On Wed, Feb 25, 2026 at 04:37:51PM +1100, Alexey Kardashevskiy wrote:
>> Once locked, a TDI's MSE and BME are not allowed to be cleared.
>
> Disallowed by hardware, by spec, by convention? Spec reference would
> be helpful.
By the PCIe spec, the TDISP part. Once the device in CONFIG_LOCKED or RUN, clearing MSE or BME will destroy this state == will go to the ERROR state. PCIe r7, "Figure 11-5 TDISP State Machine".
Then, if it was CONFIG_LOCKED - the device won't be able to go to the RUN state which allows DMA to/from encrypted memory and encrypted MMIO. If it was RUN - the device will lose those encrypted DMA/MMIO abilities.
>> Skip INTx test as TEE-capable PCI functions are most likely IOV VFs
>> anyway and those do not support INTx at all.
>
> "Most likely" doesn't sound like a convincing argument for skipping
> something.
>
>> Add a quirk preventing the probing code from disabling MSE when
>> updating 64bit BAR (which cannot be done atomically).
>
> Say more about this please. If there's something special about this
> device, I'd like to know exactly what that is.
>
>> Note that normally this happens too early and likely not really
>> needed for the device attestation happening long after PCI probing.
>
> I don't follow this either. Please make it meaningful for
> non-TEE/TDI/whatever experts. And mention that context in the subject
> line.
Well, frankly, I have this patch for ages and originally QEMU did not intercept zeroing of BME/MSE and just by having this patch, I could get my prototype working without that QEMU hack.
Then, even though the QEMU hack works, it is kind of muddy as when a device driver wants to clear BME to, say, stop DMA - and in reality it won't stop. So I suspect the QEMU hack won't always be enough and we will have to teach the PCI subsystem to not clear BME/MSE in some cases.
Hence the patch, to highlight rather unexpected writes to the PCI command register which are not that harmless anymore.
I'll drop it if it is no use to anyone even with the above.
>> @@ -1930,6 +1930,11 @@ static int pci_intx_mask_broken(struct pci_dev *dev)
>> {
>> u16 orig, toggle, new;
>>
>> + if (dev->devcap & PCI_EXP_DEVCAP_TEE) {
>> + pci_warn_once(dev, "(TIO) Disable check for broken INTX");
>> + return 1;
>
> s/INTX/INTx/
>
> Why do users need to know this? Why as a warning? What can they do
> about it? "TIO"?
ah, sorry, a leftover. Thanks,
--
Alexey
^ permalink raw reply
* Re: [PATCH kernel 6/9] x86/dma-direct: Stop changing encrypted page state for TDISP devices
From: Alexey Kardashevskiy @ 2026-02-26 6:22 UTC (permalink / raw)
To: dan.j.williams, Robin Murphy, x86
Cc: linux-kernel, kvm, linux-pci, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Sean Christopherson,
Paolo Bonzini, Andy Lutomirski, Peter Zijlstra, Bjorn Helgaas,
Marek Szyprowski, Andrew Morton, Catalin Marinas,
Michael Ellerman, Mike Rapoport, Tom Lendacky, Ard Biesheuvel,
Neeraj Upadhyay, Ashish Kalra, Stefano Garzarella, Melody Wang,
Seongman Lee, Joerg Roedel, Nikunj A Dadhania, Michael Roth,
Suravee Suthikulpanit, Andi Kleen, Kuppuswamy Sathyanarayanan,
Tony Luck, David Woodhouse, Greg Kroah-Hartman, Denis Efremov,
Geliang Tang, Piotr Gregor, Michael S. Tsirkin, Alex Williamson,
Arnd Bergmann, Jesse Barnes, Jacob Pan, Yinghai Lu, Kevin Brodsky,
Jonathan Cameron, Aneesh Kumar K.V (Arm), Xu Yilun, Herbert Xu,
Kim Phillips, Konrad Rzeszutek Wilk, Stefano Stabellini,
Claire Chang, linux-coco, iommu
In-Reply-To: <699f6b1ad77cd_1cc51005d@dwillia2-mobl4.notmuch>
On 26/2/26 08:35, dan.j.williams@intel.com wrote:
> Robin Murphy wrote:
>> On 2026-02-25 5:37 am, Alexey Kardashevskiy wrote:
>>> TDISP devices operate in CoCo VMs only and capable of accessing
>>> encrypted guest memory.
>>>
>>> Currently when SME is on, the DMA subsystem forces the SME mask in
>>> DMA handles in phys_to_dma() which assumes IOMMU pass through
>>> which is never the case with CoCoVM running with a TDISP device.
>>>
>>> Define X86's version of phys_to_dma() to skip leaking SME mask to
>>> the device.
>>>
>>> Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
>>> ---
>>>
>>> Doing this in the generic version breaks ARM which uses
>>> the SME mask in DMA handles, hence ARCH_HAS_PHYS_TO_DMA.
>>
>> That smells a bit off... In CCA we should be in the same boat, wherein a
>> trusted device can access memory at a DMA address based on its "normal"
>> (private) GPA, rather than having to be redirected to the shared alias
>> (it's really not an "SME mask" in that sense at all).
>
> Not quite, no, CCA *is* in the same boat as TDX, not SEV-SNP. Only
> SEV-SNP has this concept that the DMA handle for private memory is the
> dma_addr_unencrypted() conversion (C-bit masked) of the CPU physical
> address. For CCA and TDX the typical expectation of dma_addr_encrypted()
> for accepted devices holds. It just so happens that dma_addr_encrypted()
> does not munge the address on is a nop conversion for CCA and TDX.
OTOH TDX and SNP do not leak SME mask to DMA handles, and ARM does.
Sounds like what, we need sme_dma_me_mask in addition to sme_me_mask? Scary.
--
Alexey
^ permalink raw reply
* Re: [PATCH v4 21/24] x86/virt/tdx: Avoid updates during update-sensitive operations
From: dan.j.williams @ 2026-02-26 6:34 UTC (permalink / raw)
To: Chao Gao, Huang, Kai
Cc: kvm@vger.kernel.org, linux-coco@lists.linux.dev,
linux-kernel@vger.kernel.org, x86@kernel.org,
dave.hansen@linux.intel.com, tony.lindgren@linux.intel.com,
binbin.wu@linux.intel.com, seanjc@google.com, kas@kernel.org,
Chatre, Reinette, Verma, Vishal L, nik.borisov@suse.com,
mingo@redhat.com, Weiny, Ira, pbonzini@redhat.com, hpa@zytor.com,
Annapurve, Vishal, sagis@google.com, Duan, Zhenzhong,
Edgecombe, Rick P, paulmck@kernel.org, tglx@kernel.org,
yilun.xu@linux.intel.com, Williams, Dan J, bp@alien8.de
In-Reply-To: <aZ+31DJr0cI7v8C9@intel.com>
Chao Gao wrote:
> >> int tdx_module_shutdown(void)
> >> {
> >> struct tdx_module_args args = {};
> >> - int ret, cpu;
> >> + u64 ret;
> >> + int cpu;
> >>
> >> /*
> >> * Shut down the TDX Module and prepare handoff data for the next
> >> @@ -1189,9 +1192,21 @@ int tdx_module_shutdown(void)
> >> * modules as new modules likely have higher handoff version.
> >> */
> >> args.rcx = tdx_sysinfo.handoff.module_hv;
> >> - ret = seamcall_prerr(TDH_SYS_SHUTDOWN, &args);
> >> - if (ret)
> >> - return ret;
> >> +
> >> + if (tdx_supports_update_compatibility(&tdx_sysinfo))
> >> + args.rcx |= TDX_SYS_SHUTDOWN_AVOID_COMPAT_SENSITIVE;
> >> +
> >> + ret = seamcall(TDH_SYS_SHUTDOWN, &args);
> >> +
> >> + /*
> >> + * Return -EBUSY to signal that there is one or more ongoing flows
> >> + * which may not be compatible with an updated TDX module, so that
> >> + * userspace can retry on this error.
> >> + */
> >> + if ((ret & TDX_SEAMCALL_STATUS_MASK) == TDX_UPDATE_COMPAT_SENSITIVE)
> >> + return -EBUSY;
> >> + else if (ret)
> >> + return -EIO;
> >>
> >
> >The changelog says "doing nothing" isn't an option, and we need to depend on
> >TDH.SYS.SHUTDOWN to catch such incompatibilities.
Doing nothing in the kernel is fine. This is a tooling problem.
> >To me this means we cannot support module update if TDH.SYS.SHUTDOWN doesn't
> >support this "AVOID_COMPAT_SENSITIVE" feature, because w/o it we cannot tell
> >whether the update is happening during any sensitive operation.
> >
>
> Good point.
>
> I'm fine with disabling updates in this case. The only concern is that it would
> block even perfectly compatible updates, but this only impacts a few older
> modules, so it shouldn't be a big problem. And the value of supporting old
> modules will also diminish over time.
>
> But IMO, the kernel's incompatibility check is intentionally best effort, not a
> guarantee. For example, the kernel doesn't verify if the module update is
> compatible with the CPU or P-SEAMLDR. So non-compatible updates may slip through
> anyway, and the expectation for users is "run non-compatible updates at their
> own risk". Given this, allowing updates when one incompatibility check is
> not supported (i.e., AVOID_COMPAT_SENSITIVE) is also acceptable. At minimum,
> users can choose not to perform updates if the module lacks
> AVOID_COMPAT_SENSITIVE support.
>
> I'm fine with either approach, but slightly prefer disabling updates in
> this case. Let's see if anyone has strong opinions on this.
Do not make Linux carry short lived one-off complexity. Make userspace
do a "if $module_version < $min_module_version_for_compat_detect" and
tell the user to update at their own risk if that minimum version is not
met. Linux should be encouraging the module to be better, not
accommodate every early generation miss like this with permanent hacks.
^ permalink raw reply
* Re: [RFC PATCH kernel] iommufd: Allow mapping from KVM's guest_memfd
From: Alexey Kardashevskiy @ 2026-02-26 6:47 UTC (permalink / raw)
To: Sean Christopherson
Cc: linux-kernel, kvm, Jason Gunthorpe, Kevin Tian, Joerg Roedel,
Will Deacon, Robin Murphy, Paolo Bonzini, Steve Sistare,
Nicolin Chen, iommu, linux-coco, Dan Williams, Santosh Shukla,
Pratik R . Sampat, Ackerley Tng, Fuad Tabba, Xu Yilun,
Aneesh Kumar K . V
In-Reply-To: <aZ7-tTpobKiCFT5L@google.com>
On 26/2/26 00:55, Sean Christopherson wrote:
> On Wed, Feb 25, 2026, Alexey Kardashevskiy wrote:
>> For the new guest_memfd type, no additional reference is taken as
>> pinning is guaranteed by the KVM guest_memfd library.
>>
>> There is no KVM-GMEMFD->IOMMUFD direct notification mechanism as
>> the assumption is that:
>> 1) page stage change events will be handled by VMM which is going
>> to call IOMMUFD to remap pages;
>> 2) shrinking GMEMFD equals to VM memory unplug and VMM is going to
>> handle it.
>
> The VMM is outside of the kernel's effective TCB. Assuming the VMM will always
> do the right thing is a non-starter.
Right.
But, say, for 1), VMM does not the right thing and skips on PSC - the AMD host will observe IOMMU fault events - noisy but harmless. I wonder if it is different for others though.
Truncating gmemfd is bad, is having gmemfd->iommufd notification going to be enough for a starter? Thanks,
--
Alexey
^ permalink raw reply
* Re: [PATCH v3 07/16] KVM: SVM: Move core EFER.SVME enablement to kernel
From: Chao Gao @ 2026-02-26 7:40 UTC (permalink / raw)
To: Sean Christopherson
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Kiryl Shutsemau, Peter Zijlstra, Arnaldo Carvalho de Melo,
Namhyung Kim, Paolo Bonzini, linux-kernel, linux-coco, kvm,
linux-perf-users, Xu Yilun, Dan Williams
In-Reply-To: <20260214012702.2368778-8-seanjc@google.com>
>-static inline void kvm_cpu_svm_disable(void)
>-{
>- uint64_t efer;
>-
>- wrmsrq(MSR_VM_HSAVE_PA, 0);
>- rdmsrq(MSR_EFER, efer);
>- if (efer & EFER_SVME) {
>- /*
>- * Force GIF=1 prior to disabling SVM, e.g. to ensure INIT and
>- * NMI aren't blocked.
>- */
>- stgi();
>- wrmsrq(MSR_EFER, efer & ~EFER_SVME);
>- }
>-}
>-
> static void svm_emergency_disable_virtualization_cpu(void)
> {
>- virt_rebooting = true;
>-
>- kvm_cpu_svm_disable();
>+ wrmsrq(MSR_VM_HSAVE_PA, 0);
> }
>
> static void svm_disable_virtualization_cpu(void)
>@@ -507,7 +489,7 @@ static void svm_disable_virtualization_cpu(void)
> if (tsc_scaling)
> __svm_write_tsc_multiplier(SVM_TSC_RATIO_DEFAULT);
>
>- kvm_cpu_svm_disable();
>+ x86_svm_disable_virtualization_cpu();
There's a functional change here. The new x86_svm_disable_virtualization_cpu()
doesn't reset MSR_VM_HSAVE_PA, but the old kvm_cpu_svm_disable() does.
>+int x86_svm_disable_virtualization_cpu(void)
>+{
>+ int r = -EIO;
>+ u64 efer;
>+
>+ /*
>+ * Force GIF=1 prior to disabling SVM, e.g. to ensure INIT and
>+ * NMI aren't blocked.
>+ */
>+ asm goto("1: stgi\n\t"
>+ _ASM_EXTABLE(1b, %l[fault])
>+ ::: "memory" : fault);
>+ r = 0;
>+
>+fault:
>+ rdmsrq(MSR_EFER, efer);
>+ wrmsrq(MSR_EFER, efer & ~EFER_SVME);
>+ return r;
>+}
>+EXPORT_SYMBOL_FOR_KVM(x86_svm_disable_virtualization_cpu);
^ permalink raw reply
* Re: [RFC PATCH kernel] iommufd: Allow mapping from KVM's guest_memfd
From: Ackerley Tng @ 2026-02-26 8:19 UTC (permalink / raw)
To: Sean Christopherson, Alexey Kardashevskiy
Cc: linux-kernel, kvm, Jason Gunthorpe, Kevin Tian, Joerg Roedel,
Will Deacon, Robin Murphy, Paolo Bonzini, Steve Sistare,
Nicolin Chen, iommu, linux-coco, Dan Williams, Santosh Shukla,
Pratik R . Sampat, Fuad Tabba, Xu Yilun, Aneesh Kumar K . V,
michael.roth, vannapurve
In-Reply-To: <aZ7-tTpobKiCFT5L@google.com>
Sean Christopherson <seanjc@google.com> writes:
> On Wed, Feb 25, 2026, Alexey Kardashevskiy wrote:
>> For the new guest_memfd type, no additional reference is taken as
>> pinning is guaranteed by the KVM guest_memfd library.
>>
>> There is no KVM-GMEMFD->IOMMUFD direct notification mechanism as
>> the assumption is that:
>> 1) page stage change events will be handled by VMM which is going
>> to call IOMMUFD to remap pages;
>> 2) shrinking GMEMFD equals to VM memory unplug and VMM is going to
>> handle it.
>
> The VMM is outside of the kernel's effective TCB. Assuming the VMM will always
> do the right thing is a non-starter.
I think looking up the guest_memfd file from the userspace address
(uptr) is a good start, and in order not to assume much of the userspace
VMM, we could register the mapping with guest_memfd, so that when
there's a conversion or truncation, guest_memfd will invalidate the
registered mapping in addition to the rest of the mappings being
invalidated.
At LPC (2025) [1][2], people pointed out that needing to force unmapping during
page state changes (aka conversions) are a TDX-only issue. It seems like
on SNP and ARM, the faults generated due to the host accessing guest
private memory can be caught and handled, so it's not super terrible if
there's no unmapping during conversions. Perhaps Alexey and Aneesh can
explain more :)
Will said pKVM actually would rather not unmap from the IOMMU on
conversions.
I didn't think of this before LPC but forcing unmapping during
truncation (aka shrinking guest_memfd) is probably necessary for overall
system stability and correctness, so notifying and having guest_memfd
track where its pages were mapped in the IOMMU is necessary. Whether or
not to unmap during conversions could be a arch-specific thing, but all
architectures would want the memory unmapped if the memory is removed
from guest_memfd ownership.
[1] Slides: https://lpc.events/event/19/contributions/2184/attachments/1752/3816/2025-12-12-lpc-coco-mc-optimizing-guest-memfd-conversions.pdf
[2] Notes: https://github.com/joergroedel/coco-microconference/blob/main/2025/optimizing_guest_memfd_shared_private_conversions.md
^ permalink raw reply
* Re: [PATCH v3 08/16] KVM: x86: Move bulk of emergency virtualizaton logic to virt subsystem
From: Chao Gao @ 2026-02-26 8:55 UTC (permalink / raw)
To: Sean Christopherson
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Kiryl Shutsemau, Peter Zijlstra, Arnaldo Carvalho de Melo,
Namhyung Kim, Paolo Bonzini, linux-kernel, linux-coco, kvm,
linux-perf-users, Xu Yilun, Dan Williams
In-Reply-To: <20260214012702.2368778-9-seanjc@google.com>
On Fri, Feb 13, 2026 at 05:26:54PM -0800, Sean Christopherson wrote:
>Move the majority of the code related to disabling hardware virtualization
>in emergency from KVM into the virt subsystem so that virt can take full
>ownership of the state of SVM/VMX. This will allow refcounting usage of
>SVM/VMX so that KVM and the TDX subsystem can enable VMX without stomping
>on each other.
>
>To route the emergency callback to the "right" vendor code, add to avoid
^^^ and
>-void cpu_emergency_disable_virtualization(void)
>-{
>- cpu_emergency_virt_cb *callback;
>-
>- /*
>- * IRQs must be disabled as KVM enables virtualization in hardware via
>- * function call IPIs, i.e. IRQs need to be disabled to guarantee
>- * virtualization stays disabled.
>- */
>- lockdep_assert_irqs_disabled();
>-
>- rcu_read_lock();
>- callback = rcu_dereference(cpu_emergency_virt_callback);
>- if (callback)
>- callback();
>- rcu_read_unlock();
...
>+static void x86_virt_invoke_kvm_emergency_callback(void)
>+{
>+ cpu_emergency_virt_cb *kvm_callback;
>+
>+ kvm_callback = rcu_dereference(kvm_emergency_callback);
>+ if (kvm_callback)
>+ kvm_callback();
The RCU lock is dropped here. I assume this is intentional since the function
is only called with IRQs disabled, in which case the RCU lock isn't needed.
<snip>
>+int x86_virt_emergency_disable_virtualization_cpu(void)
>+{
>+ /* Ensure the !feature check can't get false positives. */
>+ BUILD_BUG_ON(!X86_FEATURE_SVM || !X86_FEATURE_VMX);
>+
>+ if (!virt_ops.feature)
>+ return -EOPNOTSUPP;
>+
>+ /*
>+ * IRQs must be disabled as virtualization is enabled in hardware via
>+ * function call IPIs, i.e. IRQs need to be disabled to guarantee
>+ * virtualization stays disabled.
>+ */
The comment is stale. Since this patch just moves the comment, it should be
fine to keep it as-is and fix it in a separate series.
>+ lockdep_assert_irqs_disabled();
>+
>+ /*
>+ * Do the NMI shootdown even if virtualization is off on _this_ CPU, as
>+ * other CPUs may have virtualization enabled.
>+ *
>+ * TODO: Track whether or not virtualization might be enabled on other
>+ * CPUs? May not be worth avoiding the NMI shootdown...
>+ */
>+ virt_ops.emergency_disable_virtualization_cpu();
>+ return 0;
>+}
>+
> void __init x86_virt_init(void)
> {
>- x86_vmx_init();
>+ /*
>+ * Attempt to initialize both SVM and VMX, and simply use whichever one
>+ * is present. Rsefuse to enable/use SVM or VMX if both are somehow
^^^^^^^ Refuse
LGTM aside from the two typos above.
Reviewed-by: Chao Gao <chao.gao@intel.com>
^ permalink raw reply
* Re: SVSM Development Call February 25, 2026
From: Jörg Rödel @ 2026-02-26 9:49 UTC (permalink / raw)
To: coconut-svsm, linux-coco
In-Reply-To: <hul66wdlddkhriko6gb7po5nstadfjvou7lbzsfbvlyrpl4ybw@gkpc22ppgsxo>
Meeting minutes are ready in this PR:
https://github.com/coconut-svsm/governance/pull/97
-Joerg
^ permalink raw reply
* Re: [PATCH v4 21/24] x86/virt/tdx: Avoid updates during update-sensitive operations
From: Chao Gao @ 2026-02-26 15:32 UTC (permalink / raw)
To: dan.j.williams
Cc: Huang, Kai, kvm@vger.kernel.org, linux-coco@lists.linux.dev,
linux-kernel@vger.kernel.org, x86@kernel.org,
dave.hansen@linux.intel.com, tony.lindgren@linux.intel.com,
binbin.wu@linux.intel.com, seanjc@google.com, kas@kernel.org,
Chatre, Reinette, Verma, Vishal L, nik.borisov@suse.com,
mingo@redhat.com, Weiny, Ira, pbonzini@redhat.com, hpa@zytor.com,
Annapurve, Vishal, sagis@google.com, Duan, Zhenzhong,
Edgecombe, Rick P, paulmck@kernel.org, tglx@kernel.org,
yilun.xu@linux.intel.com, bp@alien8.de
In-Reply-To: <699fe97dc212f_2f4a100b@dwillia2-mobl4.notmuch>
>> >The changelog says "doing nothing" isn't an option, and we need to depend on
>> >TDH.SYS.SHUTDOWN to catch such incompatibilities.
>
>Doing nothing in the kernel is fine. This is a tooling problem.
>
>> >To me this means we cannot support module update if TDH.SYS.SHUTDOWN doesn't
>> >support this "AVOID_COMPAT_SENSITIVE" feature, because w/o it we cannot tell
>> >whether the update is happening during any sensitive operation.
>> >
>>
>> Good point.
>>
>> I'm fine with disabling updates in this case. The only concern is that it would
>> block even perfectly compatible updates, but this only impacts a few older
>> modules, so it shouldn't be a big problem. And the value of supporting old
>> modules will also diminish over time.
>>
>> But IMO, the kernel's incompatibility check is intentionally best effort, not a
>> guarantee. For example, the kernel doesn't verify if the module update is
>> compatible with the CPU or P-SEAMLDR. So non-compatible updates may slip through
>> anyway, and the expectation for users is "run non-compatible updates at their
>> own risk". Given this, allowing updates when one incompatibility check is
>> not supported (i.e., AVOID_COMPAT_SENSITIVE) is also acceptable. At minimum,
>> users can choose not to perform updates if the module lacks
>> AVOID_COMPAT_SENSITIVE support.
>>
>> I'm fine with either approach, but slightly prefer disabling updates in
>> this case. Let's see if anyone has strong opinions on this.
>
>Do not make Linux carry short lived one-off complexity. Make userspace
>do a "if $module_version < $min_module_version_for_compat_detect" and
>tell the user to update at their own risk if that minimum version is not
>met. Linux should be encouraging the module to be better, not
>accommodate every early generation miss like this with permanent hacks.
I realize there's a potential issue with this update sequence:
old module (no compat detection) -> newer module (has compat detection) -> latest module
The problem arises during the second update. Userspace checks the currently
loaded module version and sees it supports compatibility detection, so it
expects the kernel to perform these checks. However, the kernel still thinks
the module lacks this capability because it never refreshes the module's
features after the first update.
Regarding disabling updates, I was thinking of an approach like the one below.
Do you think this is a workaround/hack?
diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
index 2cf3a01d0b9c..50fe6373984d 100644
--- a/arch/x86/virt/vmx/tdx/tdx.c
+++ b/arch/x86/virt/vmx/tdx/tdx.c
@@ -1192,9 +1192,7 @@ int tdx_module_shutdown(void)
* modules as new modules likely have higher handoff version.
*/
args.rcx = tdx_sysinfo.handoff.module_hv;
-
- if (tdx_supports_update_compatibility(&tdx_sysinfo))
- args.rcx |= TDX_SYS_SHUTDOWN_AVOID_COMPAT_SENSITIVE;
+ args.rcx |= TDX_SYS_SHUTDOWN_AVOID_COMPAT_SENSITIVE;
ret = seamcall(TDH_SYS_SHUTDOWN, &args);
diff --git a/drivers/virt/coco/tdx-host/tdx-host.c b/drivers/virt/coco/tdx-host/tdx-host.c
index 9ade3028a5bd..c7f0853e8ce5 100644
--- a/drivers/virt/coco/tdx-host/tdx-host.c
+++ b/drivers/virt/coco/tdx-host/tdx-host.c
@@ -181,6 +181,11 @@ static void seamldr_init(struct device *dev)
return;
}
+ if (!tdx_supports_update_compatibility(tdx_sysinfo)) {
+ pr_info("Current TDX Module does not support update compatibility\n");
+ return;
+ }
+
tdx_fwl = firmware_upload_register(THIS_MODULE, dev, "tdx_module",
&tdx_fw_ops, NULL);
ret = PTR_ERR_OR_ZERO(tdx_fwl);
^ permalink raw reply related
* Re: [RFC PATCH kernel] iommufd: Allow mapping from KVM's guest_memfd
From: Jason Gunthorpe @ 2026-02-26 19:07 UTC (permalink / raw)
To: Ackerley Tng
Cc: Sean Christopherson, Alexey Kardashevskiy, linux-kernel, kvm,
Kevin Tian, Joerg Roedel, Will Deacon, Robin Murphy,
Paolo Bonzini, Steve Sistare, Nicolin Chen, iommu, linux-coco,
Dan Williams, Santosh Shukla, Pratik R . Sampat, Fuad Tabba,
Xu Yilun, Aneesh Kumar K . V, michael.roth, vannapurve
In-Reply-To: <CAEvNRgEiod74cRoVQVC5LUbWDZf6Wwz1ssjQN0fveN=RBAjsTw@mail.gmail.com>
On Thu, Feb 26, 2026 at 12:19:52AM -0800, Ackerley Tng wrote:
> Sean Christopherson <seanjc@google.com> writes:
>
> > On Wed, Feb 25, 2026, Alexey Kardashevskiy wrote:
> >> For the new guest_memfd type, no additional reference is taken as
> >> pinning is guaranteed by the KVM guest_memfd library.
> >>
> >> There is no KVM-GMEMFD->IOMMUFD direct notification mechanism as
> >> the assumption is that:
> >> 1) page stage change events will be handled by VMM which is going
> >> to call IOMMUFD to remap pages;
> >> 2) shrinking GMEMFD equals to VM memory unplug and VMM is going to
> >> handle it.
> >
> > The VMM is outside of the kernel's effective TCB. Assuming the VMM will always
> > do the right thing is a non-starter.
>
> I think looking up the guest_memfd file from the userspace address
> (uptr) is a good start
Please no, if we need complicated things like notifiers then it is
better to start directly with the struct file interface and get
immediately into some guestmemfd API instead of trying to get their
from a VMA. A VMA doesn't help in any way and just complicates things.
> I didn't think of this before LPC but forcing unmapping during
> truncation (aka shrinking guest_memfd) is probably necessary for overall
> system stability and correctness, so notifying and having guest_memfd
> track where its pages were mapped in the IOMMU is necessary. Whether or
> not to unmap during conversions could be a arch-specific thing, but all
> architectures would want the memory unmapped if the memory is removed
> from guest_memfd ownership.
Things like truncate are a bit easier to handle, you do need a
protective notifier, but if it detects truncate while an iommufd area
still covers the truncated region it can just revoke the whole
area. Userspace made a mistake and gets burned but the kernel is
safe. We don't need something complicated kernel side to automatically
handle removing just the slice of truncated guestmemfd, for example.
If guestmemfd is fully pinned and cannot free memory outside of
truncate that may be good enough (though somehow I think that is not
the case) - and I don't understand what issues Intel has with iommu
access.
Jason
^ permalink raw reply
* Re: [RFC PATCH kernel] iommufd: Allow mapping from KVM's guest_memfd
From: Jason Gunthorpe @ 2026-02-26 19:27 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Sean Christopherson, linux-kernel, kvm, Kevin Tian, Joerg Roedel,
Will Deacon, Robin Murphy, Paolo Bonzini, Steve Sistare,
Nicolin Chen, iommu, linux-coco, Dan Williams, Santosh Shukla,
Pratik R . Sampat, Ackerley Tng, Fuad Tabba, Xu Yilun,
Aneesh Kumar K . V
In-Reply-To: <fb10affb-40d5-4558-b64b-0ab22659ccf2@amd.com>
On Thu, Feb 26, 2026 at 05:47:50PM +1100, Alexey Kardashevskiy wrote:
>
>
> On 26/2/26 00:55, Sean Christopherson wrote:
> > On Wed, Feb 25, 2026, Alexey Kardashevskiy wrote:
> > > For the new guest_memfd type, no additional reference is taken as
> > > pinning is guaranteed by the KVM guest_memfd library.
> > >
> > > There is no KVM-GMEMFD->IOMMUFD direct notification mechanism as
> > > the assumption is that:
> > > 1) page stage change events will be handled by VMM which is going
> > > to call IOMMUFD to remap pages;
> > > 2) shrinking GMEMFD equals to VM memory unplug and VMM is going to
> > > handle it.
> >
> > The VMM is outside of the kernel's effective TCB. Assuming the VMM will always
> > do the right thing is a non-starter.
>
> Right.
>
> But, say, for 1), VMM does not the right thing and skips on PSC -
> the AMD host will observe IOMMU fault events - noisy but harmless. I
> wonder if it is different for others though.
ARM is also supposed to be safe as GPT faults are contained, IIRC.
However, it is not like AMD in many important ways here. Critically ARM
has a split guest physical space where the low addresses are all
private and the upper addresses are all shared.
Thus on Linux the iommu should be programed with the shared pages
mapped into the shared address range. It would be wasteful to program
it with large amounts of IOPTEs that are already know to be private.
I think if you are fully doing in-place conversion then you could
program the entire shared address range to point to the memory pool
(eg with 1G huge pages) and rely entirely on the GPT to arbitrate
access. I don't think that is implemented in Linux though?
While on AMD, IIRC, the iommu should be programed with both the shared
and private pages in the respective GPA locations, but due to the RMP
matching insanity you have to keep restructuring the IOPTEs to exactly
match the RMP layout.
I have no idea what Intel needs.
Jason
^ permalink raw reply
* Re: [PATCH] KVM: SEV: Track SNP launch state and disallow invalid userspace interactions
From: Sean Christopherson @ 2026-02-26 19:30 UTC (permalink / raw)
To: Jethro Beekman
Cc: Paolo Bonzini, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, kvm, linux-kernel, linux-coco
In-Reply-To: <64a01647-2f99-44a8-a183-702d6eb6fd81@fortanix.com>
On Wed, Feb 25, 2026, Jethro Beekman wrote:
> On 2026-02-25 12:21, Sean Christopherson wrote:
> > On Wed, Feb 25, 2026, Jethro Beekman wrote:
> >> On 2026-02-25 12:05, Sean Christopherson wrote:
> >>> On Mon, Jan 19, 2026, Jethro Beekman wrote:
> >>>> Calling any of the SNP_LAUNCH_ ioctls after SNP_LAUNCH_FINISH results in a
> >>>> kernel page fault due to RMP violation. Track SNP launch state and exit early.
> >>>
> >>> What exactly trips the RMP #PF? A backtrace would be especially helpful for
> >>> posterity.
> >>
> >> Here's a backtrace for calling ioctl(KVM_SEV_SNP_LAUNCH_FINISH) twice. Note this is with a modified version of QEMU.
> >
> >> RIP: 0010:sev_es_sync_vmsa+0x54/0x4c0 [kvm_amd]
> >> snp_launch_update_vmsa+0x19d/0x290 [kvm_amd]
> >> snp_launch_finish+0xb6/0x380 [kvm_amd]
> >> sev_mem_enc_ioctl+0x14e/0x720 [kvm_amd]
> >> kvm_arch_vm_ioctl+0x837/0xcf0 [kvm]
> >
> > Ah, it's the VMSA that's being accessed. Can't we just do?
> >
> > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> > index 723f4452302a..1e40ae592c93 100644
> > --- a/arch/x86/kvm/svm/sev.c
> > +++ b/arch/x86/kvm/svm/sev.c
> > @@ -882,6 +882,9 @@ static int sev_es_sync_vmsa(struct vcpu_svm *svm)
> > u8 *d;
> > int i;
> >
> > + if (vcpu->arch.guest_state_protected)
> > + return -EINVAL;
> > +
> > /* Check some debug related fields before encrypting the VMSA */
> > if (svm->vcpu.guest_debug || (svm->vmcb->save.dr7 & ~DR7_FIXED_1))
> > return -EINVAL;
>
> I tried relying on guest_state_protected instead of creating new state but I
> don't think it's sufficient. In particular, your proposal may fix
> snp_launch_finish()
But it does fix that case, correct? I don't want to complicate one fix just
because there are other bugs that are similar but yet distinct.
> but I don't believe this addresses the issues in snp_launch_update() and
Do you mean snp_launch_update_vmsa() here? Or am I missing an interaction with
vCPUs in snp_launch_update()?
> sev_vcpu_create().
There are a pile of SEV lifecycle and locking issues, i.e. this is just one of
several flaws. Fixing the locking has been on my todo list for a few months (we
found some "fun" bugs with an internal run of syzkaller), and I'm finally getting
to it. Hopefully I'll post a series early next week.
Somewhat off the cuff, but I think the easiest way to close the race between
KVM_CREATE_VCPU and KVM_SEV_SNP_LAUNCH_FINISH is to reject KVM_SEV_SNP_LAUNCH_FINISH
if a vCPU is being created. Or did I misunderstand the race you're pointing out?
Though unless there's a strong reason not to, I'd prefer to get greedy and block
all of sev_mem_enc_ioctl(), e.g.
11:23:23 ✔ ~/go/src/kernel.org/linux $ gdd
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index ea515cf41168..2b1033c0ec54 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -2047,8 +2047,8 @@ static int sev_check_source_vcpus(struct kvm *dst, struct kvm *src)
struct kvm_vcpu *src_vcpu;
unsigned long i;
- if (src->created_vcpus != atomic_read(&src->online_vcpus) ||
- dst->created_vcpus != atomic_read(&dst->online_vcpus))
+ if (kvm_is_vcpu_creation_in_progress(src) ||
+ kvm_is_vcpu_creation_in_progress(dst))
return -EBUSY;
if (!sev_es_guest(src))
@@ -2596,6 +2596,11 @@ int sev_mem_enc_ioctl(struct kvm *kvm, void __user *argp)
goto out;
}
+ if (kvm_is_vcpu_creation_in_progress(kvm)) {
+ r = -EBUSY;
+ goto out;
+ }
+
/*
* Once KVM_SEV_INIT2 initializes a KVM instance as an SNP guest, only
* allow the use of SNP-specific commands.
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 2c7d76262898..60ca5222e1e5 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1032,6 +1032,13 @@ static inline struct kvm_vcpu *kvm_get_vcpu_by_id(struct kvm *kvm, int id)
return NULL;
}
+static inline bool kvm_is_vcpu_creation_in_progress(struct kvm *kvm)
+{
+ lockdep_assert_held(&kvm->lock);
+
+ return kvm->created_vcpus != atomic_read(&kvm->online_vcpus);
+}
+
void kvm_destroy_vcpus(struct kvm *kvm);
int kvm_trylock_all_vcpus(struct kvm *kvm);
^ permalink raw reply related
* Re: [PATCH kernel 7/9] coco/sev-guest: Implement the guest support for SEV TIO (phase2)
From: Borislav Petkov @ 2026-02-26 19:52 UTC (permalink / raw)
To: Alexey Kardashevskiy, x86
Cc: linux-kernel, kvm, linux-pci, Thomas Gleixner, Ingo Molnar,
Dave Hansen, H. Peter Anvin, Sean Christopherson, Paolo Bonzini,
Andy Lutomirski, Peter Zijlstra, Bjorn Helgaas, Dan Williams,
Marek Szyprowski, Robin Murphy, Andrew Morton, Catalin Marinas,
Michael Ellerman, Mike Rapoport, Tom Lendacky, Ard Biesheuvel,
Neeraj Upadhyay, Ashish Kalra, Stefano Garzarella, Melody Wang,
Seongman Lee, Joerg Roedel, Nikunj A Dadhania, Michael Roth,
Suravee Suthikulpanit, Andi Kleen, Kuppuswamy Sathyanarayanan,
Tony Luck, David Woodhouse, Greg Kroah-Hartman, Denis Efremov,
Geliang Tang, Piotr Gregor, Michael S. Tsirkin, Alex Williamson,
Arnd Bergmann, Jesse Barnes, Jacob Pan, Yinghai Lu, Kevin Brodsky,
Jonathan Cameron, Aneesh Kumar K.V (Arm), Xu Yilun, Herbert Xu,
Kim Phillips, Konrad Rzeszutek Wilk, Stefano Stabellini,
Claire Chang, linux-coco, iommu
In-Reply-To: <428d4373-1b78-4882-baf9-1df563f66a86@amd.com>
On February 26, 2026 3:39:37 AM UTC, Alexey Kardashevskiy <aik@amd.com> wrote:
>I struggle to separate these more without making individual patches useless for any purpose
You sound like someone who hasn't been reviewing patches and scratching his head how to approach such a conglomerate as yours which does many things at once...
The rule is very simple actually: a patch should do one logical thing only. And no more. It doesn't matter whether the patch is "useless" by itself. It matters only whether it is reviewable and one can to a certain degree see that the transformation it contains is relatively bugfree.
And I'm very sure that when you start reviewing patches, you'll be pretty much asking people sending conglomerates like yours, to split them.
Thx.
--
Small device. Typos and formatting crap
^ permalink raw reply
* Re: [PATCH kernel 1/9] pci/tsm: Add TDISP report blob and helpers to parse it
From: dan.j.williams @ 2026-02-26 21:08 UTC (permalink / raw)
To: Alexey Kardashevskiy, dan.j.williams, x86
Cc: linux-kernel, kvm, linux-pci, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Sean Christopherson,
Paolo Bonzini, Andy Lutomirski, Peter Zijlstra, Bjorn Helgaas,
Marek Szyprowski, Robin Murphy, Andrew Morton, Catalin Marinas,
Michael Ellerman, Mike Rapoport, Tom Lendacky, Ard Biesheuvel,
Neeraj Upadhyay, Ashish Kalra, Stefano Garzarella, Melody Wang,
Seongman Lee, Joerg Roedel, Nikunj A Dadhania, Michael Roth,
Suravee Suthikulpanit, Andi Kleen, Kuppuswamy Sathyanarayanan,
Tony Luck, David Woodhouse, Greg Kroah-Hartman, Denis Efremov,
Geliang Tang, Piotr Gregor, Michael S. Tsirkin, Alex Williamson,
Arnd Bergmann, Jesse Barnes, Jacob Pan, Yinghai Lu, Kevin Brodsky,
Jonathan Cameron, Aneesh Kumar K.V (Arm), Xu Yilun, Herbert Xu,
Kim Phillips, Konrad Rzeszutek Wilk, Stefano Stabellini,
Claire Chang, linux-coco, iommu
In-Reply-To: <06aa8d10-766f-45d4-8205-0ffc2f26bfb4@amd.com>
Alexey Kardashevskiy wrote:
[..]
> > Does the kernel have any use for the footer besides conveying it to
> > userspace?
>
> PCIe says:
>
> Example of such device specific information include:
> • A network device may include receive-side scaling (RSS) related information such as the RSS hash and
> mappings to the virtual station interface (VSI) queues, etc.
> • A NVMe device may include information about the associated name spaces, mapping of name space to
> command queue-pair mappings, etc.
> • Accelerators may report capabilities such as algorithms supported, queue depths, etc
>
>
> Sounds to me like something the device driver would be interested in.
That is not the concern. The concern is how does Linux maintain a
convention around these use case so that common semantics converge on a
common implementation expectations.
> >> imho easier on eyes. I can live with either if the majority votes for it. Thanks.
> >
> > Aneesh also already has 'structs+bitmask', I will switch to that.
>
> oh I just found it, more or less my version :) I can add pci_tdisp_ prefixes, should I? Thanks,
I have a patch brewing that moves interface report consumption into
encrypted resource population for ioremap() to consider. I will send
that out shortly.
^ permalink raw reply
* Re: [PATCH v4 21/24] x86/virt/tdx: Avoid updates during update-sensitive operations
From: dan.j.williams @ 2026-02-26 22:06 UTC (permalink / raw)
To: Chao Gao, dan.j.williams
Cc: Huang, Kai, kvm@vger.kernel.org, linux-coco@lists.linux.dev,
linux-kernel@vger.kernel.org, x86@kernel.org,
dave.hansen@linux.intel.com, tony.lindgren@linux.intel.com,
binbin.wu@linux.intel.com, seanjc@google.com, kas@kernel.org,
Chatre, Reinette, Verma, Vishal L, nik.borisov@suse.com,
mingo@redhat.com, Weiny, Ira, pbonzini@redhat.com, hpa@zytor.com,
Annapurve, Vishal, sagis@google.com, Duan, Zhenzhong,
Edgecombe, Rick P, paulmck@kernel.org, tglx@kernel.org,
yilun.xu@linux.intel.com, bp@alien8.de
In-Reply-To: <aaBndinjh51R2wQU@intel.com>
Chao Gao wrote:
[..]
> >Do not make Linux carry short lived one-off complexity. Make userspace
> >do a "if $module_version < $min_module_version_for_compat_detect" and
> >tell the user to update at their own risk if that minimum version is not
> >met. Linux should be encouraging the module to be better, not
> >accommodate every early generation miss like this with permanent hacks.
>
> I realize there's a potential issue with this update sequence:
>
> old module (no compat detection) -> newer module (has compat detection) -> latest module
>
> The problem arises during the second update. Userspace checks the currently
> loaded module version and sees it supports compatibility detection, so it
> expects the kernel to perform these checks. However, the kernel still thinks
> the module lacks this capability because it never refreshes the module's
> features after the first update.
>
> Regarding disabling updates, I was thinking of an approach like the one below.
> Do you think this is a workaround/hack?
Do not include logic to disable updates, document the expectation in the
tool. The general Linux expectation is administrator does not need to be
protected from themselves. The tool documentation can communicate best
practices that "time begins with module version X, only loading a
version X+ module from boot enables the safety protocol, runtime update
to X is insufficient". Administrator always has the option to proceed
and does not need the kernel to do extra hand holding.
Presumably this gap in the ecosystem is short lived and the deployment
of module versions < X drops precipitously and kernel does not need to
carry "disable updates" logic in perpetuity.
^ permalink raw reply
* Re: [PATCH v3 06/16] KVM: VMX: Move core VMXON enablement to kernel
From: Dave Hansen @ 2026-02-26 22:32 UTC (permalink / raw)
To: Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Kiryl Shutsemau,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Paolo Bonzini
Cc: linux-kernel, linux-coco, kvm, linux-perf-users, Chao Gao,
Xu Yilun, Dan Williams
In-Reply-To: <20260214012702.2368778-7-seanjc@google.com>
On 2/13/26 17:26, Sean Christopherson wrote:
> Move the innermost VMXON+VMXOFF logic out of KVM and into to core x86 so
> that TDX can (eventually) force VMXON without having to rely on KVM being
> loaded, e.g. to do SEAMCALLs during initialization.
>
> Opportunistically update the comment regarding emergency disabling via NMI
> to clarify that virt_rebooting will be set by _another_ emergency callback,
> i.e. that virt_rebooting doesn't need to be set before VMCLEAR, only
> before _this_ invocation does VMXOFF.
For the x86 side:
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
I'm also very much OK with this going through the KVM tree.
^ permalink raw reply
* Re: [PATCH v3 11/16] KVM: x86/tdx: Do VMXON and TDX-Module initialization during subsys init
From: Dave Hansen @ 2026-02-26 22:35 UTC (permalink / raw)
To: Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Kiryl Shutsemau,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Paolo Bonzini
Cc: linux-kernel, linux-coco, kvm, linux-perf-users, Chao Gao,
Xu Yilun, Dan Williams
In-Reply-To: <20260214012702.2368778-12-seanjc@google.com>
On 2/13/26 17:26, Sean Christopherson wrote:
> Now that VMXON can be done without bouncing through KVM, do TDX-Module
> initialization during subsys init (specifically before module_init() so
> that it runs before KVM when both are built-in). Aside from the obvious
> benefits of separating core TDX code from KVM, this will allow tagging a
> pile of TDX functions and globals as being __init and __ro_after_init.
...
> Documentation/arch/x86/tdx.rst | 36 +------
> arch/x86/include/asm/tdx.h | 4 -
> arch/x86/kvm/vmx/tdx.c | 148 ++++++-----------------------
> arch/x86/virt/vmx/tdx/tdx.c | 168 +++++++++++++++++++--------------
> arch/x86/virt/vmx/tdx/tdx.h | 8 --
> 5 files changed, 130 insertions(+), 234 deletions(-)
It's hard to argue with a diffstat like that.
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
^ 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