* 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 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: [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 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: 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 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: [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 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 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 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 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 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 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 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 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 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 2/9] pci/tsm: Add tsm_tdi_status
From: Alexey Kardashevskiy @ 2026-02-25 23:42 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: <699e97d6e8be7_1cc51003c@dwillia2-mobl4.notmuch>
On 25/2/26 17:33, dan.j.williams@intel.com wrote:
> Alexey Kardashevskiy wrote:
>> Define a structure with all info about a TDI such as TDISP status,
>> bind state, used START_INTERFACE options and the report digest.
>>
>> This will be extended and shared to the userspace.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
>> ---
>>
>> Make it uapi? We might want a sysfs node per a field so probably not.
>> For now its only user is AMD SEV TIO with a plan to expose this struct
>> as a whole via sysfs.
>
> Say more about what this uapi when sysfs already has lock+accept
> indications?
>
> Or are you just talking about exporting the TDISP report as a binary
> blob?
I mean that between lock and accept the guest userspace wants to read certs/measurements/report to do the attestation. And it will want to know these blobs digests. And probably the TDI state. Although successful write to lock() is an indication of CONFIG_LOCKED, and accept == RUN.
We do not do real attestation in phase2 but the report is required anyway to enable private MMIO so I started shuffling with this structure.
> I think the kernel probably wants a generic abstraction for asserting
> that the tsm layer believes the report remains valid between fetch and
> run. In other words I am not sure arch features like intf_report_counter
> ever show up anywhere in uapi outside of debugfs.
True, this is a shorter (not shorter enough :) ) version of SEV-TIO's TDI_INFO. Thanks,
--
Alexey
^ permalink raw reply
* Re: [PATCH kernel 6/9] x86/dma-direct: Stop changing encrypted page state for TDISP devices
From: dan.j.williams @ 2026-02-25 21:35 UTC (permalink / raw)
To: Robin Murphy, 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, 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: <d8102507-e537-4e7c-8137-082a43fd270d@arm.com>
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.
^ permalink raw reply
* Re: [PATCH kernel 4/9] dma/swiotlb: Stop forcing SWIOTLB for TDISP devices
From: dan.j.williams @ 2026-02-25 20:57 UTC (permalink / raw)
To: Robin Murphy, dan.j.williams, 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,
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: <04b06a53-769c-44f1-a157-34591b9f8439@arm.com>
Robin Murphy wrote:
> On 2026-02-25 4:30 pm, dan.j.williams@intel.com wrote:
> > 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;
> >
> > I worry this further muddies the meaning of the swiotlb force option.
> > What if you want to force swiotlb operation on accepted devices?
>
> For that we'd need a whole other private SWIOTLB plus the logic to
> decide which one to use in the first place.
In this case I was still considering that swiotlb is still implicitly
only shared address bouncining. Indeed, a whole other "private_swiotlb"
mechanism would be needed for private bouncing. Not clear there is a
need for that at present.
Even for this swiotlb=force for "accepted" devices I only see a
potential kernel development use case, not a deployment use case.
> option to forcibly expose all DMA through shared memory regardless of
> TDISP and friends, that would logically want to be a higher-level CoCo
> option rather than belonging to SWIOTLB itself ;)
As I have it below, yes, CoCo opts into this bounce_unaccepted mechanism.
As to your other question:
> (since a device that's trusted to access private memory
> isn't necessarily prohibited from still also accessing shared memory as
> well), hmmm...
The specification allows it, but Linux DMA mapping core is not yet ready
for it. So the expectation to start is that the device loses access to
its original shared IOMMU mappings when converted to private operation.
So on ARM where shared addresses are high, it is future work to figure
out how an accepted device might also access shared mappings outside the
device's dma_mask.
> > For example:
> >
> > @@ -173,7 +176,13 @@ static inline bool is_swiotlb_force_bounce(struct device *dev)
> > {
> > struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> >
> > - return mem && mem->force_bounce;
> > + if (!mem)
> > + return false;
> > + if (mem->force_bounce)
> > + return true;
> > + if (mem->bounce_unaccepted && !device_cc_accepted(dev))
> > + return true;
> > + return false;
> > }
> >
> > void swiotlb_init(bool addressing_limited, unsigned int flags);
^ permalink raw reply
* Re: [PATCH] KVM: SEV: Track SNP launch state and disallow invalid userspace interactions
From: Jethro Beekman @ 2026-02-25 20:30 UTC (permalink / raw)
To: Sean Christopherson
Cc: Paolo Bonzini, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, kvm, linux-kernel, linux-coco
In-Reply-To: <aZ9Zs0laC2p5W-OL@google.com>
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 I don't believe this addresses the issues in snp_launch_update() and sev_vcpu_create().
--
Jethro Beekman | CTO | Fortanix
^ permalink raw reply
* Re: [PATCH] KVM: SEV: Track SNP launch state and disallow invalid userspace interactions
From: Sean Christopherson @ 2026-02-25 20:21 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: <928a31e1-bb6f-44d4-b1de-654d6968fd55@fortanix.com>
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;
^ permalink raw reply related
* Re: [PATCH 00/14] KVM: x86: Emulator MMIO fix and cleanups
From: Tom Lendacky @ 2026-02-25 20:19 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini, Kiryl Shutsemau
Cc: kvm, x86, linux-coco, linux-kernel, Yashu Zhang, Rick Edgecombe,
Binbin Wu, Xiaoyao Li, Michael Roth
In-Reply-To: <20260225012049.920665-1-seanjc@google.com>
On 2/24/26 19:20, Sean Christopherson wrote:
> Fix a UAF stack bug where KVM references a stack pointer around an exit to
> userspace, and then clean up the related code to try to make it easier to
> maintain (not necessarily "easy", but "easier").
>
> The SEV-ES and TDX changes are compile-tested only.
>
> Sean Christopherson (14):
> KVM: x86: Use scratch field in MMIO fragment to hold small write
> values
> KVM: x86: Open code handling of completed MMIO reads in
> emulator_read_write()
> KVM: x86: Trace unsatisfied MMIO reads on a per-page basis
> KVM: x86: Use local MMIO fragment variable to clean up
> emulator_read_write()
> KVM: x86: Open code read vs. write userspace MMIO exits in
> emulator_read_write()
> KVM: x86: Move MMIO write tracing into vcpu_mmio_write()
> KVM: x86: Harden SEV-ES MMIO against on-stack use-after-free
> KVM: x86: Dedup kvm_sev_es_mmio_{read,write}()
> KVM: x86: Consolidate SEV-ES MMIO emulation into a single public API
> KVM: x86: Bury emulator read/write ops in
> emulator_{read,write}_emulated()
> KVM: x86: Fold emulator_write_phys() into write_emulate()
> KVM: x86: Rename .read_write_emulate() to .read_write_guest()
> KVM: x86: Don't panic the kernel if completing userspace I/O / MMIO
> goes sideways
> KVM: x86: Add helpers to prepare kvm_run for userspace MMIO exit
>
> arch/x86/include/asm/kvm_host.h | 3 -
> arch/x86/kvm/emulate.c | 13 ++
> arch/x86/kvm/svm/sev.c | 20 +--
> arch/x86/kvm/vmx/tdx.c | 14 +-
> arch/x86/kvm/x86.c | 287 ++++++++++++++------------------
> arch/x86/kvm/x86.h | 30 +++-
> include/linux/kvm_host.h | 3 +-
> 7 files changed, 178 insertions(+), 192 deletions(-)
A quick boot test was fine. I'm scheduling it to run through our CI to
see if anything pops up.
Thanks,
Tom
>
>
> base-commit: 183bb0ce8c77b0fd1fb25874112bc8751a461e49
^ permalink raw reply
* Re: [PATCH] KVM: SEV: Track SNP launch state and disallow invalid userspace interactions
From: Jethro Beekman @ 2026-02-25 20:13 UTC (permalink / raw)
To: Sean Christopherson
Cc: Paolo Bonzini, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, kvm, linux-kernel, linux-coco
In-Reply-To: <aZ9V_O5SGGKa-Vdn@google.com>
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.
BUG: unable to handle page fault for address: ff1276cbfdf36000
#PF: supervisor write access in kernel mode
#PF: error_code(0x80000003) - RMP violation
PGD 5a31801067 P4D 5a31802067 PUD 40ccfb5063 PMD 40e5954063 PTE 80000040fdf36163
SEV-SNP: PFN 0x40fdf36, RMP entry: [0x6010fffffffff001 - 0x000000000000001f]
Oops: Oops: 0003 [#1] SMP NOPTI
CPU: 33 UID: 0 PID: 996180 Comm: qemu-system-x86 Tainted: G OE 6.18.0-8-generic #8-Ubuntu PREEMPT(voluntary)
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: Dell Inc. PowerEdge R7625/0H1TJT, BIOS 1.5.8 07/21/2023
RIP: 0010:sev_es_sync_vmsa+0x54/0x4c0 [kvm_amd]
Code: 89 f8 48 8d b2 00 04 00 00 48 89 e5 41 56 41 54 53 48 83 ec 30 48 8b 9f 18 1c 00 00 48 8b 8a 00 04 00 00 4c 8b 07 48 8d 7b 08 <48> 89 0b 48 89 d9 48 8b 92 e0 06 00 00 48 83 e7 f8 48 29 f9 48 89
RSP: 0018:ff42462db15fb8b8 EFLAGS: 00010286
RAX: ff1276d253008000 RBX: ff1276cbfdf36000 RCX: 0000ffff00930000
RDX: ff1276cb899e6000 RSI: ff1276cb899e6400 RDI: ff1276cbfdf36008
RBP: ff42462db15fb900 R08: ff1276cbfb1f2000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ff1276cbfb1f2000
R13: 00007fffffffdc10 R14: ff1276cbfb1f3188 R15: ff42462db15fba70
FS: 00007ffff6846f40(0000) GS:ff1276cacfaf0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ff1276cbfdf36000 CR3: 0000004628e03004 CR4: 0000000000f71ef0
PKRU: 55555554
Call Trace:
<TASK>
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]
? srso_alias_return_thunk+0x5/0xfbef5
? hook_file_ioctl+0x10/0x20
? srso_alias_return_thunk+0x5/0xfbef5
? srso_alias_return_thunk+0x5/0xfbef5
? __x64_sys_ioctl+0xbd/0x100
? srso_alias_return_thunk+0x5/0xfbef5
? kvm_vm_ioctl+0x3fd/0xcc0 [kvm]
? srso_alias_return_thunk+0x5/0xfbef5
? srso_alias_return_thunk+0x5/0xfbef5
? __x64_sys_ioctl+0xbd/0x100
? srso_alias_return_thunk+0x5/0xfbef5
? arch_exit_to_user_mode_prepare.isra.0+0xd/0xe0
? srso_alias_return_thunk+0x5/0xfbef5
? srso_alias_return_thunk+0x5/0xfbef5
? rseq_get_rseq_cs.isra.0+0x16/0x240
? srso_alias_return_thunk+0x5/0xfbef5
? kvm_vm_ioctl+0x3fd/0xcc0 [kvm]
? srso_alias_return_thunk+0x5/0xfbef5
kvm_vm_ioctl+0x3fd/0xcc0 [kvm]
? srso_alias_return_thunk+0x5/0xfbef5
? srso_alias_return_thunk+0x5/0xfbef5
? arch_exit_to_user_mode_prepare.isra.0+0xc5/0xe0
? srso_alias_return_thunk+0x5/0xfbef5
? do_syscall_64+0xb9/0x10f0
? srso_alias_return_thunk+0x5/0xfbef5
? __rseq_handle_notify_resume+0xbb/0x1c0
? srso_alias_return_thunk+0x5/0xfbef5
? hook_file_ioctl+0x10/0x20
? srso_alias_return_thunk+0x5/0xfbef5
__x64_sys_ioctl+0xa3/0x100
? arch_exit_to_user_mode_prepare.isra.0+0xc5/0xe0
x64_sys_call+0xfe0/0x2350
do_syscall_64+0x81/0x10f0
? srso_alias_return_thunk+0x5/0xfbef5
? arch_exit_to_user_mode_prepare.isra.0+0xd/0x100
? srso_alias_return_thunk+0x5/0xfbef5
? irqentry_exit_to_user_mode+0x2d/0x1d0
? srso_alias_return_thunk+0x5/0xfbef5
? irqentry_exit+0x43/0x50
? srso_alias_return_thunk+0x5/0xfbef5
? exc_page_fault+0x90/0x1b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7ffff673287d
Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
RSP: 002b:00007fffffffda80 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000c008aeba RCX: 00007ffff673287d
RDX: 00007fffffffdc10 RSI: 00000000c008aeba RDI: 0000000000000008
RBP: 00007fffffffdad0 R08: 0000000000811000 R09: 00005555562737f0
R10: 00005555576631b0 R11: 0000000000000246 R12: 00007fffffffdc10
R13: 0000555557695f80 R14: 0000000000001000 R15: 00007fff73c75000
</TASK>
Modules linked in: kvm_amd nf_conntrack_netlink veth ecdsa_generic vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd amd_atl intel_rapl_msr intel_rapl_common amd64_edac edac_mce_amd xfrm_user xfrm_algo xt_set ip_set bonding cfg80211 nft_chain_nat xt_MASQUERADE nf_nat binfmt_misc xt_addrtype xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables xfs nls_iso8859_1 ipmi_ssif platform_profile dell_wmi video spd5118 sparse_keymap kvm irqbypass dell_smbios dax_hmem dcdbas cxl_acpi rapl cxl_port dell_wmi_descriptor wmi_bmof mgag200 i2c_algo_bit acpi_power_meter cxl_core i2c_piix4 einj ipmi_si acpi_ipmi k10temp ccp i2c_smbus ipmi_devintf mlx5_fwctl joydev input_leds fwctl ipmi_msghandler mac_hid nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc br_netfilter bridge stp llc overlay efi_pstore dm_multipath nfnetlink dmi_sysfs ip_tables x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq raid1 linear mlx5_ib
ib_uverbs macsec ib_core raid0 hid_generic usbhid hid mlx5_core nvme mlxfw nvme_core psample polyval_clmulni ghash_clmulni_intel nvme_keyring tls ahci nvme_auth megaraid_sas libahci pci_hyperv_intf hkdf wmi aesni_intel [last unloaded: kvm_amd(OE)]
CR2: ff1276cbfdf36000
---[ end trace 0000000000000000 ]---
pstore: backend (erst) writing error (-22)
RIP: 0010:sev_es_sync_vmsa+0x54/0x4c0 [kvm_amd]
Code: 89 f8 48 8d b2 00 04 00 00 48 89 e5 41 56 41 54 53 48 83 ec 30 48 8b 9f 18 1c 00 00 48 8b 8a 00 04 00 00 4c 8b 07 48 8d 7b 08 <48> 89 0b 48 89 d9 48 8b 92 e0 06 00 00 48 83 e7 f8 48 29 f9 48 89
RSP: 0018:ff42462db15fb8b8 EFLAGS: 00010286
RAX: ff1276d253008000 RBX: ff1276cbfdf36000 RCX: 0000ffff00930000
RDX: ff1276cb899e6000 RSI: ff1276cb899e6400 RDI: ff1276cbfdf36008
RBP: ff42462db15fb900 R08: ff1276cbfb1f2000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ff1276cbfb1f2000
R13: 00007fffffffdc10 R14: ff1276cbfb1f3188 R15: ff42462db15fba70
FS: 00007ffff6846f40(0000) GS:ff1276cacfaf0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ff1276cbfdf36000 CR3: 0000004628e03004 CR4: 0000000000f71ef0
PKRU: 55555554
note: qemu-system-x86[996180] exited with irqs disabled
--
Jethro Beekman | CTO | Fortanix
^ permalink raw reply
* Re: [PATCH] KVM: SEV: Track SNP launch state and disallow invalid userspace interactions
From: Sean Christopherson @ 2026-02-25 20:05 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: <d98692e2-d96b-4c36-8089-4bc1e5cc3d57@fortanix.com>
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.
I ask because it's basically impossible to determine if this approach is optimal
without knowing exactly what's going wrong. Semantically it sounds reasonable,
but ideally KVM would naturally handle userspace stupidity (without exploding).
^ permalink raw reply
* Re: [PATCH 14/14] KVM: x86: Add helpers to prepare kvm_run for userspace MMIO exit
From: Sean Christopherson @ 2026-02-25 19:22 UTC (permalink / raw)
To: Rick P Edgecombe
Cc: pbonzini@redhat.com, kas@kernel.org, x86@kernel.org,
zhangjiaji1@huawei.com, binbin.wu@linux.intel.com, Xiaoyao Li,
linux-kernel@vger.kernel.org, thomas.lendacky@amd.com,
kvm@vger.kernel.org, linux-coco@lists.linux.dev,
michael.roth@amd.com
In-Reply-To: <8bed2406e9f5f30f8f01c1da731fae6e040da827.camel@intel.com>
On Wed, Feb 25, 2026, Rick P Edgecombe wrote:
> On Tue, 2026-02-24 at 17:20 -0800, Sean Christopherson wrote:
> > +static inline void __kvm_prepare_emulated_mmio_exit(struct kvm_vcpu *vcpu,
> > + gpa_t gpa, unsigned int len,
> > + const void *data,
> > + bool is_write)
> > +{
> > + struct kvm_run *run = vcpu->run;
> > +
> > + run->mmio.len = min(8u, len);
>
> I would think to extract this to a local var so it can be used twice.
Ya, either way works for me. The copy+paste is a little gross, but it's also
unlikely that anyone is going to modify this code (or if they did, that any goofs
wouldn't be immediately disastrous).
> > + run->mmio.is_write = is_write;
> > + run->exit_reason = KVM_EXIT_MMIO;
> > + run->mmio.phys_addr = gpa;
> > + if (is_write)
> > + memcpy(run->mmio.data, data, min(8u, len));
> > +}
> > +
>
^ 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