* Re: [PATCH kernel 6/9] x86/dma-direct: Stop changing encrypted page state for TDISP devices
From: Jason Gunthorpe @ 2026-02-28 0:06 UTC (permalink / raw)
To: Robin Murphy
Cc: Alexey Kardashevskiy, 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, 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, Jiri Pirko
In-Reply-To: <d8102507-e537-4e7c-8137-082a43fd270d@arm.com>
On Wed, Feb 25, 2026 at 05:08:37PM +0000, Robin Murphy wrote:
> I guess this comes back to the point I just raised on the previous patch -
> the current assumption is that devices cannot access private memory at all,
> and thus phys_to_dma() is implicitly only dealing with the mechanics of how
> the given device accesses shared memory. Once that no longer holds, I don't
> see how we can find the right answer without also consulting the relevant
> state of paddr itself, and that really *should* be able to be commonly
> abstracted across CoCo environments.
Definately, I think building on this is a good place to start
https://lore.kernel.org/all/20260223095136.225277-2-jiri@resnulli.us/
Probably this series needs to take DMA_ATTR_CC_DECRYPTED and push it
down into the phys_to_dma() and make the swiotlb shared allocation
code force set it.
But what value is stored in the phys_addr_t for shared pages on the
three arches? Does ARM and Intel set the high GPA/IPA bit in the
phys_addr or do they set it through the pgprot? What does AMD do?
ie can we test a bit in the phys_addr_t to reliably determine if it is
shared or private?
> > pci_device_add() enforces the FFFF_FFFF coherent DMA mask so
> > dma_alloc_coherent() fails when SME=on, this is how I ended up fixing
> > phys_to_dma() and not quite sure it is the right fix.
Does AMD have the shared/private GPA split like ARM and Intel do? Ie
shared is always at a high GPA? What is the SME mask?
Jason
^ permalink raw reply
* Re: [PATCH 00/14] KVM: x86: Emulator MMIO fix and cleanups
From: Tom Lendacky @ 2026-02-27 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: <3bf56d54-a459-48e4-b1c8-4b2630ec8714@amd.com>
On 2/25/26 14:19, Tom Lendacky wrote:
> 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.
Nothing popped up in our SEV CI, so...
Tested-by: Tom Lendacky <thomas.lendacky@gmail.com>
Thanks,
Tom
>
> Thanks,
> Tom
>
>>
>>
>> base-commit: 183bb0ce8c77b0fd1fb25874112bc8751a461e49
>
^ permalink raw reply
* Re: [RFC PATCH kernel] iommufd: Allow mapping from KVM's guest_memfd
From: Jason Gunthorpe @ 2026-02-27 13:18 UTC (permalink / raw)
To: Xu Yilun
Cc: Sean Christopherson, Ackerley Tng, 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, Aneesh Kumar K . V, michael.roth, vannapurve
In-Reply-To: <aaFzgGTpZI0eZWdD@yilunxu-OptiPlex-7050>
On Fri, Feb 27, 2026 at 06:35:44PM +0800, Xu Yilun wrote:
> Will cause host machine check and host restart, same as host CPU
> accessing encrypted memory. Intel TDX has no lower level privilege
> protection table so the wrong accessing will actually impact the
> memory encryption engine.
Blah, of course it does.
So Intel needs a two step synchronization to wipe the IOPTEs before
any shared private conversions and restore the right ones after.
AMD needs a nasty HW synchronization with RMP changes, but otherwise
wants to map the entire physical space.
ARM doesn't care much, I think it could safely do either approach?
These are very different behaviors so I would expect that userspace
needs to signal which of the two it wants.
It feels like we need a fairly complex dedicated synchronization logic
in iommufd coupled to the shared/private machinery in guestmemfd
Not really sure how to implement the Intel version right now, it is
sort of like a nasty version of SVA..
Jason
^ permalink raw reply
* Re: [PATCH v3 11/16] KVM: x86/tdx: Do VMXON and TDX-Module initialization during subsys init
From: Chao Gao @ 2026-02-27 11:28 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-12-seanjc@google.com>
On Fri, Feb 13, 2026 at 05:26:57PM -0800, 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.
>
>Reviewed-by: Dan Williams <dan.j.williams@intel.com>
>Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Chao Gao <chao.gao@intel.com>
^ permalink raw reply
* Re: [PATCH v3 09/16] x86/virt: Add refcounting of VMX/SVM usage to support multiple in-kernel users
From: Chao Gao @ 2026-02-27 11:26 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-10-seanjc@google.com>
On Fri, Feb 13, 2026 at 05:26:55PM -0800, Sean Christopherson wrote:
>Implement a per-CPU refcounting scheme so that "users" of hardware
>virtualization, e.g. KVM and the future TDX code, can co-exist without
>pulling the rug out from under each other. E.g. if KVM were to disable
>VMX on module unload or when the last KVM VM was destroyed, SEAMCALLs from
>the TDX subsystem would #UD and panic the kernel.
>
>Disable preemption in the get/put APIs to ensure virtualization is fully
>enabled/disabled before returning to the caller. E.g. if the task were
>preempted after a 0=>1 transition, the new task would see a 1=>2 and thus
>return without enabling virtualization. Explicitly disable preemption
>instead of requiring the caller to do so, because the need to disable
>preemption is an artifact of the implementation. E.g. from KVM's
>perspective there is no _need_ to disable preemption as KVM guarantees the
>pCPU on which it is running is stable (but preemption is enabled).
>
>Opportunistically abstract away SVM vs. VMX in the public APIs by using
>X86_FEATURE_{SVM,VMX} to communicate what technology the caller wants to
>enable and use.
>
>Cc: Xu Yilun <yilun.xu@linux.intel.com>
>Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Chao Gao <chao.gao@intel.com>
^ permalink raw reply
* Re: [RFC PATCH kernel] iommufd: Allow mapping from KVM's guest_memfd
From: Xu Yilun @ 2026-02-27 11:03 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Alexey Kardashevskiy, 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, Aneesh Kumar K . V
In-Reply-To: <20260226192700.GB44359@ziepe.ca>
On Thu, Feb 26, 2026 at 03:27:00PM -0400, Jason Gunthorpe wrote:
> 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.
Intel TDX will cause host machine check and restart, which are not
contained.
>
> 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.
This is same as Intel TDX, the GPA shared bit are used by IOMMU to
target shared/private. You can imagine for T=1, there are 2 IOPTs, or
1 IOPT with all private at lower address & all shared at higher address.
>
> 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.
For Intel TDX, it is not just a waste, the redundant IOMMU mappings are
dangerous.
>
> 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.
Secure part of IOPT (lower address) reuses KVM MMU (S-EPT) so needs no
extra update but needs a global IOTLB flush. The Shared part of IOPT
for T=1 needs update based on GPA.
>
> Jason
^ permalink raw reply
* Re: [RFC PATCH kernel] iommufd: Allow mapping from KVM's guest_memfd
From: Xu Yilun @ 2026-02-27 10:35 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Sean Christopherson, Ackerley Tng, 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, Aneesh Kumar K . V, michael.roth, vannapurve
In-Reply-To: <20260227010902.GE44359@ziepe.ca>
On Thu, Feb 26, 2026 at 09:09:02PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 26, 2026 at 04:28:53PM -0800, Sean Christopherson wrote:
> > > I'm confused though - I thought in-place conversion ment that
> > > private<->shared re-used the existing memory allocation? Why does it
> > > "remove" memory?
> > >
> > > Or perhaps more broadly, where is the shared memory kept/accessed in
> > > these guest memfd systems?
> >
> > Oh, the physical memory doesn't change, but the IOMMU might care that memory is
> > being converted from private<=>shared. AMD IOMMU probably doesn't? But unless
> > Intel IOMMU reuses S-EPT from the VM itself, the IOMMU page tables will need to
Intel secure IOMMU does reuse S-EPT, but that doesn't mean IOMMU mapping
stay still, at least IOTLB needs flush.
> > be updated.
>
> Okay, so then it is probably OK for AMD and ARM to just let
> shared/private happen and whatever userspace does or doesn't do is not
> important. The IOPTE will point at guaranteed allocated memory and any
> faults caused by imporerly putting private in a shared slot will be
> contained.
>
> I have no idea what happens to Intel if the shared IOMMU points to a
> private page? The machine catches fire and daemons spawn from a
> fissure?
Will cause host machine check and host restart, same as host CPU
accessing encrypted memory. Intel TDX has no lower level privilege
protection table so the wrong accessing will actually impact the
memory encryption engine.
>
> Or maybe we are lucky and it generates a nice contained fault like the
> other two so we don't need to build something elaborate and special to
> make up for horrible hardware? Pretty please?
>
> Jason
^ permalink raw reply
* COCONUT-SVSM Development Release v2026.02-devel
From: Jörg Rödel @ 2026-02-27 8:31 UTC (permalink / raw)
To: coconut-svsm, linux-coco
Hi,
The COCONUT-SVSM development release for February is tagged and ready for
testing and wider use. The release includes 65 non-merge commits which bring
several improvements to COCONUT-SVSM.
There are no new features this time, but a lot of improvements around CI and
the core infrastructure. Highlights are:
- CI improvements. GitHub CI is now able to optionally run formal
verification on PRs.
- Fix of unsound behavior in the per-cpu code.
- Update to OpenSSL 3.5.5 for the TPM.
- Switch to Rust 1.88 as the minimal version to build COCONUT-SVSM.
- A lot of rework and improvements in the boot flow, an important step
towards a minimal stage2 loader.
Again a big THANKs to the COCONUT-SVSM community for all the contributions. The
first two releases of 2026 mark a strong start into the year for COCONUT-SVSM.
For all the nitty details of what changes the shortlog is attached.
Happy testing and hacking.
Regards,
Joerg
Full shortlog:
Carlos López (16):
mm/guestmem: fix GuestPtr trait bounds
mm/guestmem: introduce GuestPtr::try_read()
mm/guestmem: introduce UserPtr::try_read()
cpu/percpu: do not expose raw runqueue
cpu/percpu: do not expose vranges directly
cpu/percpu: fully harden against reentrancy
mm/page_visibility: add Sync for SharedBox
cpu/apic: require Sync as part of ApicAccess
cpu/irq_state: make IrqState Sync
cpu/percpu: ensure PerCpu is reentrancy-safe at compile time
repo: update packit to latest commit
insn_decode: make InsnMachineMem generic over T
insn_decode: remove dynamic dispatch from InsnMachineCtx
kernel/insn_decode: tests: fix Miri errors
kernel/mm/guestmem: tests: ignore invalid bit pattern test under Miri
fuzz: insn: provide valid pointer in TestCtx
Joerg Roedel (3):
kernel/sev: Check physical address of VMSA for 2MiB alignemnt
kernel/platform: Use PageSize conditionally
COCONUT-SVSM Release 2026.02-devel
Jon Lange (22):
stage2: allocate kernel page tables from kernel heap
svsm: remove duplicate construction of kernel page tables
kernel: simplify stage2 layout
svsm: create transition page tables for AP startup
kernel: limit low memory page tables to AP startup code
Merge pull request #928 from msft-jlange/page_tables
igvmbuilder: require tdx-stage1 for TDP
Merge pull request #881 from MelodyHuibo/reinject_irq_clear_busy
kernel: defer page validation out of stage2
kernel: allocate CPUID/secrets pages on all platforms
kernel_launch: remove platform type from launch struct
kernel: reclaim VMSA heap space when unused
kernel: remove `SvsmConfig`
igvm_params: rename `igvm_params`
boot: move boot definition crate
bootimg: implement boot image loader library
stage2: consume boot image library
svsm: move kernel initialization arguments onto the stack
Merge pull request #968 from stefano-garzarella/rust-1.88.0
Cargo.toml: add `cpudefs` to `members`
sev/ghcb: calculate page state chage page size directly
global_asm: ensure code is marked as `.text`
Jörg Rödel (14):
Merge pull request #920 from 00xc/cpu/percpu/sync-v2
Merge pull request #954 from joergroedel/boot-fix
Merge pull request #922 from 00xc/mm/guestmem/bounds
Merge pull request #952 from 00xc/repo/update-packit
Merge pull request #955 from stefano-garzarella/update-cargo-lock-zerocopy
Merge pull request #974 from 00xc/tests/miri
Merge pull request #973 from msft-jlange/ghcb_psc
Merge pull request #969 from luigix25/cleanup_launch_guest
Merge pull request #972 from msft-jlange/cargo_members
Merge pull request #959 from stefano-garzarella/cargo-hack
Merge pull request #964 from stefano-garzarella/ci-fix-cargo-v-check
Merge pull request #965 from stefano-garzarella/verification-label
Merge pull request #977 from 00xc/tests/miri
Merge pull request #978 from msft-jlange/gloabl_asm
Luigi Leonardi (2):
block: remove unnecessary Box wrapper
scripts/launch_guest: require QEMU 10.1 as minimum version
Melody Wang (1):
cpu: Make sure interrupts do not disappear
Oliver Steffen (4):
libtcgtpm/libcrt: Add stub for strpbrk()
libtcgtpm: Update OpenSSL to 3.5.5
libtcgtpm: Disable more unused algorithms for OpenSSL
libtcgtpm: Remove deprecated OpenSSL build option
Peter Fang (2):
Merge pull request #957 from msft-jlange/igvm_stage1
Merge pull request #953 from msft-jlange/bootlib
Stefano Garzarella (26):
Cargo.lock: refresh after packit zerocopy update
Merge pull request #958 from 00xc/mm/guestmem/bounds
verification: add NonNull<T> specification for Verus
github/manual-verify: check cargo-v output for errors
Add `test` crate in the workspace
verification/verus_stub: fix unresolved import
virtio-drivers: use std crates in FakeHal
virtio-drivers: fix unused variable
kernel/block: make BLOCK_DEVICE publicly visible
Makefile: add CARGO_HACK env variable to run clippy with cargo-hack
Documentation: add `Linting` section in CONTRIBUTING.md
libtcgtpm: update TPM reference implementation to fix the license
Merge pull request #960 from luigix25/cleanup_blk
Merge pull request #961 from osteffenrh/openssl-3.5.5
Merge pull request #962 from stefano-garzarella/fix-verification
Merge pull request #966 from stefano-garzarella/update-tcg-tpm-license
kernel/gdt: fix UB in GDT::drop()
Fix `uninlined_format_args` lint for Rust 1.88.0
kernel: fix `borrow_as_ptr` lint for Rust 1.88.0
kernel/vtpm: fix `manual_dangling_ptr` lint for Rust 1.88.0
Cargo.toml: remove deprecated `clippy::match_on_vec_items` lint
Update Rust toolchain to 1.88.0
Update bytes to 1.11.1
Update time to 0.3.47
Merge pull request #956 from stefano-garzarella/fix-cargo-audit-bytes
github/manual-verify: trigger on verification label
^ permalink raw reply
* Re: [PATCH v4 07/24] coco/tdx-host: Implement firmware upload sysfs ABI for TDX Module updates
From: Xu Yilun @ 2026-02-27 4:36 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, binbin.wu, tony.lindgren,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260212143606.534586-8-chao.gao@intel.com>
> +static void seamldr_init(struct device *dev)
> +{
> + const struct tdx_sys_info *tdx_sysinfo = tdx_get_sysinfo();
> + int ret;
> +
> + if (WARN_ON_ONCE(!tdx_sysinfo))
> + return;
> +
> + if (!tdx_supports_runtime_update(tdx_sysinfo)) {
> + pr_info("Current TDX Module cannot be updated. Consider BIOS updates\n");
> + return;
> + }
> +
> + tdx_fwl = firmware_upload_register(THIS_MODULE, dev, "tdx_module",
> + &tdx_fw_ops, NULL);
> + ret = PTR_ERR_OR_ZERO(tdx_fwl);
> + if (ret)
> + pr_err("failed to register module uploader %d\n", ret);
> +}
> +
> +static void seamldr_deinit(void)
> +{
> + if (tdx_fwl)
> + firmware_upload_unregister(tdx_fwl);
> +}
You could use devm_add_action_or_reset() in seamldr_init():
1. to delete tdx_host_remove().
2. to delete the global tdx_fwl;
> +
> +static int tdx_host_probe(struct faux_device *fdev)
> +{
> + /*
> + * P-SEAMLDR capabilities are optional. Don't fail the entire
> + * device probe if initialization fails.
> + */
> + seamldr_init(&fdev->dev);
> +
> + return 0;
> +}
> +
> +static void tdx_host_remove(struct faux_device *fdev)
> +{
> + seamldr_deinit();
> +}
^ permalink raw reply
* Re: [PATCH v4 07/24] coco/tdx-host: Implement firmware upload sysfs ABI for TDX Module updates
From: Xu Yilun @ 2026-02-27 3:30 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, binbin.wu, tony.lindgren,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260212143606.534586-8-chao.gao@intel.com>
> v3:
> - clear "cancel_request" in the "prepare" phase [Binbin]
> - Don't fail the whole tdx-host device if seamldr_init() met an error
> [Yilun]
Sorry I didn't continue the discussion in that thread, but I meant to
just skip -EOPNOTSUPP, but not hide real problems.
Not sure if it makes sense to other people, if yes, some changes below:
...
> +static void seamldr_init(struct device *dev)
> +{
> + const struct tdx_sys_info *tdx_sysinfo = tdx_get_sysinfo();
> + int ret;
> +
> + if (WARN_ON_ONCE(!tdx_sysinfo))
> + return;
return -ENXIO;
> +
> + if (!tdx_supports_runtime_update(tdx_sysinfo)) {
> + pr_info("Current TDX Module cannot be updated. Consider BIOS updates\n");
> + return;
return -EOPNOTSUPP;
> + }
> +
> + tdx_fwl = firmware_upload_register(THIS_MODULE, dev, "tdx_module",
> + &tdx_fw_ops, NULL);
> + ret = PTR_ERR_OR_ZERO(tdx_fwl);
> + if (ret)
> + pr_err("failed to register module uploader %d\n", ret);
return ret;
> +}
...
> +
> +static int tdx_host_probe(struct faux_device *fdev)
> +{
> + /*
> + * P-SEAMLDR capabilities are optional. Don't fail the entire
> + * device probe if initialization fails.
I think no need the comments, all features are optional unless
explicitly required. So only exceptions need comments. Instead the code
may explain better.
> + */
> + seamldr_init(&fdev->dev);
ret = seamldr_init(&fdev->dev);
if (ret && ret != -EOPNOTSUPP)
return ret;
I imagine TDX Connect could follow the same pattern right below.
> +
> + return 0;
> +}
^ permalink raw reply
* Re: [RFC PATCH kernel] iommufd: Allow mapping from KVM's guest_memfd
From: Jason Gunthorpe @ 2026-02-27 1:09 UTC (permalink / raw)
To: Sean Christopherson
Cc: Ackerley Tng, 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: <aaDlRdnhIqRXEbPZ@google.com>
On Thu, Feb 26, 2026 at 04:28:53PM -0800, Sean Christopherson wrote:
> > I'm confused though - I thought in-place conversion ment that
> > private<->shared re-used the existing memory allocation? Why does it
> > "remove" memory?
> >
> > Or perhaps more broadly, where is the shared memory kept/accessed in
> > these guest memfd systems?
>
> Oh, the physical memory doesn't change, but the IOMMU might care that memory is
> being converted from private<=>shared. AMD IOMMU probably doesn't? But unless
> Intel IOMMU reuses S-EPT from the VM itself, the IOMMU page tables will need to
> be updated.
Okay, so then it is probably OK for AMD and ARM to just let
shared/private happen and whatever userspace does or doesn't do is not
important. The IOPTE will point at guaranteed allocated memory and any
faults caused by imporerly putting private in a shared slot will be
contained.
I have no idea what happens to Intel if the shared IOMMU points to a
private page? The machine catches fire and daemons spawn from a
fissure?
Or maybe we are lucky and it generates a nice contained fault like the
other two so we don't need to build something elaborate and special to
make up for horrible hardware? Pretty please?
Jason
^ permalink raw reply
* Re: [RFC PATCH kernel] iommufd: Allow mapping from KVM's guest_memfd
From: Sean Christopherson @ 2026-02-27 0:28 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Ackerley Tng, 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: <20260227002105.GC44359@ziepe.ca>
On Thu, Feb 26, 2026, Jason Gunthorpe wrote:
> On Thu, Feb 26, 2026 at 02:40:50PM -0800, Sean Christopherson wrote:
>
> > > 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)
> >
> > With in-place conversion, PUNCH_HOLE and private=>shared conversions are the only
> > two ways to partial "remove" memory from guest_memfd, so it may really be that
> > simple.
>
> PUNCH_HOLE can be treated like truncate right?
Yep. Tomato, tomato. I called out PUNCH_HOLE because guest_memfd doesn't support
a pure truncate, the size is immutable (ignoring that destroying the inode is kinda
sorta a truncate).
> I'm confused though - I thought in-place conversion ment that
> private<->shared re-used the existing memory allocation? Why does it
> "remove" memory?
>
> Or perhaps more broadly, where is the shared memory kept/accessed in
> these guest memfd systems?
Oh, the physical memory doesn't change, but the IOMMU might care that memory is
being converted from private<=>shared. AMD IOMMU probably doesn't? But unless
Intel IOMMU reuses S-EPT from the VM itself, the IOMMU page tables will need to
be updated.
FWIW, conceptually, we're basically treating private=>shared in particular as
"free() + alloc()" that just so happens to guarantee the allocated page is the same.
^ permalink raw reply
* Re: [RFC PATCH kernel] iommufd: Allow mapping from KVM's guest_memfd
From: Jason Gunthorpe @ 2026-02-27 0:21 UTC (permalink / raw)
To: Sean Christopherson
Cc: Ackerley Tng, 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: <aaDL8tYrVCWlQg79@google.com>
On Thu, Feb 26, 2026 at 02:40:50PM -0800, Sean Christopherson wrote:
> > 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)
>
> With in-place conversion, PUNCH_HOLE and private=>shared conversions are the only
> two ways to partial "remove" memory from guest_memfd, so it may really be that
> simple.
PUNCH_HOLE can be treated like truncate right?
I'm confused though - I thought in-place conversion ment that
private<->shared re-used the existing memory allocation? Why does it
"remove" memory?
Or perhaps more broadly, where is the shared memory kept/accessed in
these guest memfd systems?
Jason
^ permalink raw reply
* Re: [PATCH v3 07/16] KVM: SVM: Move core EFER.SVME enablement to kernel
From: Sean Christopherson @ 2026-02-26 23:43 UTC (permalink / raw)
To: Chao Gao
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: <aZ/5CDmCa8O5vrFZ@intel.com>
On Thu, Feb 26, 2026, Chao Gao wrote:
> >-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.
Doh. I'll squash this as fixup, assuming there are no other goofs:
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 5f033bf3ba83..fc08450cb4b7 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -490,6 +490,7 @@ static void svm_disable_virtualization_cpu(void)
__svm_write_tsc_multiplier(SVM_TSC_RATIO_DEFAULT);
x86_svm_disable_virtualization_cpu();
+ wrmsrq(MSR_VM_HSAVE_PA, 0);
amd_pmu_disable_virt();
}
Very nice catch!
P.S. This reminded me that there's a lurking wart with __sev_snp_init_locked()
where it forces MSR_VM_HSAVE_PA to '0' on all CPUs. That's firmly a "hypervisor"
thing so it doesn't really fit here (and code wise it's also kludgy), just thought
I'd mention it in case someone has a brilliant idea and/or runs into problems with
it. IIRC, we ran into a problem where __sev_snp_init_locked() clobbered KVM's
value, but I think the underlying problem was effectively fixed by commit
6f1d5a3513c2 ("KVM: SVM: Add support to initialize SEV/SNP functionality in KVM").
^ permalink raw reply related
* Re: [RFC PATCH kernel] iommufd: Allow mapping from KVM's guest_memfd
From: Sean Christopherson @ 2026-02-26 22:40 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Ackerley Tng, 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: <20260226190757.GA44359@ziepe.ca>
On Thu, Feb 26, 2026, Jason Gunthorpe wrote:
> 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.
+1000. Anything that _requires_ a VMA to do something with guest_memfd is broken
by design.
> > 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.
Yeah, as long as the behavior is well-documented from time zero, we can probably
get away with fairly draconian behavior.
> 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)
With in-place conversion, PUNCH_HOLE and private=>shared conversions are the only
two ways to partial "remove" memory from guest_memfd, so it may really be that
simple.
^ 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
* 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 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 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 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] 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: [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: [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: [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: 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
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