* 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: [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 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: 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: [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 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: [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: [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
* 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: [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
* 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: [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: [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: [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 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: [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 kernel 4/9] dma/swiotlb: Stop forcing SWIOTLB for TDISP devices
From: Jason Gunthorpe @ 2026-02-28 0:28 UTC (permalink / raw)
To: dan.j.williams
Cc: Robin Murphy, 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, 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: <699f621daab02_2f4a1008f@dwillia2-mobl4.notmuch>
On Wed, Feb 25, 2026 at 12:57:01PM -0800, dan.j.williams@intel.com wrote:
> > (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.
Yes, the underlying translation changes, but no, it doesn't loose DMA
access to any shared pages, it just goes through the T=1 IOMMU now.
The T=1 IOMMU will still have them mapped on all three platforms
AFAIK. On TDX/CCA the CPU and IOMMU S2 tables are identical, so of
course the shared pages are mapped. On AMD there is only one IOMMU so
the page must also be mapped or non-TDISP is broken.
When this TDISP awareness is put in the DMA API it needs to be done in
a way that allows DMA_ATTR_CC_DECRYPTED to keep working for TDISP
devices.
This is important because we are expecting these sorts of things to
work as part of integrating non-TDISP RDMA devices into CC guests. We
can't loose access to the shared pages that are shared with the
non-TDISP devices...
> 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.
ARM has a "solution" right now. The location of the high bit is
controlled by the VMM and the VMM cannot create a CC VM where the IPA
space exceeds the dma_mask of any assigned device.
Thus the VMM must limit the total available DRAM to fit within the HW
restrictions.
Hopefully TDX can do the same.
Jason
^ permalink raw reply
* Re: [RFC PATCH kernel] iommufd: Allow mapping from KVM's guest_memfd
From: Xu Yilun @ 2026-02-28 4:14 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: <20260227131815.GG44359@ziepe.ca>
On Fri, Feb 27, 2026 at 09:18:15AM -0400, Jason Gunthorpe wrote:
> 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.
Mainly about shared IOPTE (for both T=0 table & T=1 table): "unmap
before conversion to private" & "map after conversion to shared"
I see there are already some consideration in QEMU to support in-place
conversion + shared passthrough [*], using uptr, but seems that's
exactly what you are objecting to.
[*]: https://lore.kernel.org/all/18f64464-2ead-42d4-aeaa-f781020dca05@intel.com/
For Intel, T=1 private IOPTE reuses S-EPT, this is the real CC business
and the correctness is managed by KVM & firmware, no notification
needed.
Further more, I think "unmap shared IOPTE before conversion to private"
may be the only concern to ensure kernel safety, other steps could be
fully left to userspace. Hope the downgrading from "remap" to
"invalidate" simplifies the notification.
>
> 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] crypto: ccp - allow callers to use HV-Fixed page API when SEV is disabled
From: Herbert Xu @ 2026-02-28 8:43 UTC (permalink / raw)
To: Ashish Kalra
Cc: thomas.lendacky, john.allen, davem, bp, linux-crypto,
linux-kernel, linux-coco
In-Reply-To: <20260206212645.125485-1-Ashish.Kalra@amd.com>
On Fri, Feb 06, 2026 at 09:26:45PM +0000, Ashish Kalra wrote:
> From: Ashish Kalra <ashish.kalra@amd.com>
>
> When SEV is disabled, the HV-Fixed page allocation call fails, which in
> turn causes SFS initialization to fail.
>
> Fix the HV-Fixed API so callers (for example, SFS) can use it even when
> SEV is disabled by performing normal page allocation and freeing.
>
> Fixes: e09701dcdd9c ("crypto: ccp - Add new HV-Fixed page allocation/free API")
> Cc: stable@vger.kernel.org
> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
> ---
> drivers/crypto/ccp/sev-dev.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 2/3] KVM: SEV: Add support for IBPB-on-Entry
From: Borislav Petkov @ 2026-02-28 16:55 UTC (permalink / raw)
To: Sean Christopherson
Cc: Kim Phillips, linux-kernel, kvm, linux-coco, x86, Paolo Bonzini,
K Prateek Nayak, Nikunj A Dadhania, Tom Lendacky, Michael Roth,
Naveen Rao, David Kaplan
In-Reply-To: <20260203222405.4065706-3-kim.phillips@amd.com>
Sean, ack for the KVM bits and me taking them thru tip?
On Tue, Feb 03, 2026 at 04:24:04PM -0600, Kim Phillips wrote:
> AMD EPYC 5th generation and above processors support IBPB-on-Entry
> for SNP guests. By invoking an Indirect Branch Prediction Barrier
> (IBPB) on VMRUN, old indirect branch predictions are prevented
> from influencing indirect branches within the guest.
>
> SNP guests may choose to enable IBPB-on-Entry by setting
> SEV_FEATURES bit 21 (IbpbOnEntry).
>
> Host support for IBPB on Entry is indicated by CPUID
> Fn8000_001F[IbpbOnEntry], bit 31.
>
> If supported, indicate support for IBPB on Entry in
> sev_supported_vmsa_features bit 23 (IbpbOnEntry).
>
> For more info, refer to page 615, Section 15.36.17 "Side-Channel
> Protection", AMD64 Architecture Programmer's Manual Volume 2: System
> Programming Part 2, Pub. 24593 Rev. 3.42 - March 2024 (see Link).
>
> Link: https://bugzilla.kernel.org/attachment.cgi?id=306250
> Signed-off-by: Kim Phillips <kim.phillips@amd.com>
> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> v2: Added Tom's Reviewed-by.
> v1: https://lore.kernel.org/kvm/20260126224205.1442196-3-kim.phillips@amd.com/
>
> arch/x86/include/asm/cpufeatures.h | 1 +
> arch/x86/include/asm/svm.h | 1 +
> arch/x86/kvm/svm/sev.c | 9 ++++++++-
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index c01fdde465de..3ce5dff36f78 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -459,6 +459,7 @@
> #define X86_FEATURE_ALLOWED_SEV_FEATURES (19*32+27) /* Allowed SEV Features */
> #define X86_FEATURE_SVSM (19*32+28) /* "svsm" SVSM present */
> #define X86_FEATURE_HV_INUSE_WR_ALLOWED (19*32+30) /* Allow Write to in-use hypervisor-owned pages */
> +#define X86_FEATURE_IBPB_ON_ENTRY (19*32+31) /* SEV-SNP IBPB on VM Entry */
>
> /* AMD-defined Extended Feature 2 EAX, CPUID level 0x80000021 (EAX), word 20 */
> #define X86_FEATURE_NO_NESTED_DATA_BP (20*32+ 0) /* No Nested Data Breakpoints */
> diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
> index edde36097ddc..eebc65ec948f 100644
> --- a/arch/x86/include/asm/svm.h
> +++ b/arch/x86/include/asm/svm.h
> @@ -306,6 +306,7 @@ static_assert((X2AVIC_4K_MAX_PHYSICAL_ID & AVIC_PHYSICAL_MAX_INDEX_MASK) == X2AV
> #define SVM_SEV_FEAT_ALTERNATE_INJECTION BIT(4)
> #define SVM_SEV_FEAT_DEBUG_SWAP BIT(5)
> #define SVM_SEV_FEAT_SECURE_TSC BIT(9)
> +#define SVM_SEV_FEAT_IBPB_ON_ENTRY BIT(21)
>
> #define VMCB_ALLOWED_SEV_FEATURES_VALID BIT_ULL(63)
>
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index ea515cf41168..8a6d25db0c00 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -3165,8 +3165,15 @@ void __init sev_hardware_setup(void)
> cpu_feature_enabled(X86_FEATURE_NO_NESTED_DATA_BP))
> sev_supported_vmsa_features |= SVM_SEV_FEAT_DEBUG_SWAP;
>
> - if (sev_snp_enabled && tsc_khz && cpu_feature_enabled(X86_FEATURE_SNP_SECURE_TSC))
> + if (!sev_snp_enabled)
> + return;
> + /* the following feature bit checks are SNP specific */
> +
> + if (tsc_khz && cpu_feature_enabled(X86_FEATURE_SNP_SECURE_TSC))
> sev_supported_vmsa_features |= SVM_SEV_FEAT_SECURE_TSC;
> +
> + if (cpu_feature_enabled(X86_FEATURE_IBPB_ON_ENTRY))
> + sev_supported_vmsa_features |= SVM_SEV_FEAT_IBPB_ON_ENTRY;
> }
>
> void sev_hardware_unsetup(void)
> --
> 2.43.0
>
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [RFC PATCH kernel] iommufd: Allow mapping from KVM's guest_memfd
From: Jason Gunthorpe @ 2026-02-28 18:29 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: <aaJroUzTZXZfbRAl@yilunxu-OptiPlex-7050>
On Sat, Feb 28, 2026 at 12:14:25PM +0800, Xu Yilun wrote:
> On Fri, Feb 27, 2026 at 09:18:15AM -0400, Jason Gunthorpe wrote:
> > 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.
>
> Mainly about shared IOPTE (for both T=0 table & T=1 table): "unmap
> before conversion to private" & "map after conversion to shared"
>
> I see there are already some consideration in QEMU to support in-place
> conversion + shared passthrough [*], using uptr, but seems that's
> exactly what you are objecting to
There is some ugly stuff in qemu trying to make this work with VFIO..
> Further more, I think "unmap shared IOPTE before conversion to private"
> may be the only concern to ensure kernel safety, other steps could be
> fully left to userspace. Hope the downgrading from "remap" to
> "invalidate" simplifies the notification.
Maybe, but there is still the large issue of how to deal with
fragmenting the mapping and breaking/re-consolidating huge pages,
which is not trivial..
To really make this work well we may need iommufd to actively mirror
the guestmemfd into IOPTEs and dynamically track changes.
I will think about it..
Jason
^ permalink raw reply
* Re: [PATCH kernel 6/9] x86/dma-direct: Stop changing encrypted page state for TDISP devices
From: Alexey Kardashevskiy @ 2026-03-02 0:01 UTC (permalink / raw)
To: Jason Gunthorpe, Robin Murphy
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, 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: <20260228000630.GN44359@ziepe.ca>
On 28/2/26 11:06, Jason Gunthorpe wrote:
> 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/
cool, thanks for the pointer.
> 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?
Without secure vIOMMU, no Cbit in the S2 table (==host) for any VM. SDTE (==IOMMU) decides on shared/private for the device, i.e. (device_cc_accepted()?private:shared).
With secure vIOMMU, PTEs in VM will or won't have the SME mask.
>>> 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?
sorry but I do not follow this entirely.
In general, GPA != DMA handle. Cbit (bit51) is not an address bit in a GPA but it is a DMA handle so I mask it there.
With one exception - 1) host 2) mem_encrypt=on 3) iommu=pt, but we default to IOMMU in the case of host+mem_encrypt=on and don't have Cbit in host's DMA handles.
For CoCoVM, I could map everything again at the 1<<51 offset in the same S2 table to leak Cbit to the bus (useless though).
There is vTOM in SDTE which is "every phys_addr_t above vTOM is no Cbit, below - with Cbit" (and there is the same thing for the CPU side in SEV) but this not it, right?
AMD's SME mask for shared is 0, for private - 1<<51.
Thanks,
--
Alexey
^ permalink raw reply
* Re: [PATCH kernel 6/9] x86/dma-direct: Stop changing encrypted page state for TDISP devices
From: Jason Gunthorpe @ 2026-03-02 0:35 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Robin Murphy, 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: <2a5b2d8c-7359-42bd-9e8e-2c3efacee747@amd.com>
On Mon, Mar 02, 2026 at 11:01:24AM +1100, Alexey Kardashevskiy wrote:
>
>
> On 28/2/26 11:06, Jason Gunthorpe wrote:
> > 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/
>
> cool, thanks for the pointer.
>
> > 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?
>
> Without secure vIOMMU, no Cbit in the S2 table (==host) for any
> VM. SDTE (==IOMMU) decides on shared/private for the device,
> i.e. (device_cc_accepted()?private:shared).
Is this "Cbit" part of the CPU S2 page table address space or is it
actually some PTE bit that says it is "encrypted" ?
It is confusing when you say it would start working with a vIOMMU.
If 1<<51 is a valid IOPTE, and it is an actually address, then it
should be mapped into the IOMMU S2, shouldn't it? If it is in the
IOMMU S2 then shouldn't it work as a dma_addr_t?
If the HW is treating 1<<51 special in some way and not reflecting it
into a S2 lookup then it isn't an address bit but an IOPTE flag.
IMHO is really dangerous to intermix PTE flags into phys_addr_t, I
hope that is not what is happening.
> > 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?
>
> sorry but I do not follow this entirely.
>
> In general, GPA != DMA handle. Cbit (bit51) is not an address bit in a GPA but it is a DMA handle so I mask it there.
>
> With one exception - 1) host 2) mem_encrypt=on 3) iommu=pt, but we default to IOMMU in the case of host+mem_encrypt=on and don't have Cbit in host's DMA handles.
>
> For CoCoVM, I could map everything again at the 1<<51 offset in the same S2 table to leak Cbit to the bus (useless though).
Double map is what ARM does at least. I don't know it is a good
choice, but it means that phys_addr_t can have a shared/private bit
(eg your Cbit at 51) and both the CPU and IOMMU S2 have legitimate
mappings. ie it is a *true* address bit.
Given AMD has only a single IOMMO for T=0 and 1 it would make sense to
me if AMD always remove the C bit and there is always a uniform IOVA
mapping from 0 -> vTOM.
But in this case I would expect the vIOMMU to also use the same GPA
space starting from 0 and also remove the C bit, as the S2 shouldn't
have mappings starting at 1<<51.
> There is vTOM in SDTE which is "every phys_addr_t above vTOM is no
> Cbit, below - with Cbit" (and there is the same thing for the CPU
> side in SEV) but this not it, right?
That seems like the IOMMU HW is specially handling the address bits in
some way? At least ARM doesn't have anything like that, address bits
are address bits, they don't get overloaded with secondary mechanisms.
> AMD's SME mask for shared is 0, for private - 1<<51.
ARM is the inverse of this (private is at 0), but the same idea.
Jason
^ permalink raw reply
* Re: [PATCH kernel 6/9] x86/dma-direct: Stop changing encrypted page state for TDISP devices
From: Alexey Kardashevskiy @ 2026-03-02 5:26 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Robin Murphy, 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: <20260302003535.GU44359@ziepe.ca>
On 2/3/26 11:35, Jason Gunthorpe wrote:
> On Mon, Mar 02, 2026 at 11:01:24AM +1100, Alexey Kardashevskiy wrote:
>>
>>
>> On 28/2/26 11:06, Jason Gunthorpe wrote:
>>> 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/
>>
>> cool, thanks for the pointer.
>>
>>> 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?
>>
>> Without secure vIOMMU, no Cbit in the S2 table (==host) for any
>> VM. SDTE (==IOMMU) decides on shared/private for the device,
>> i.e. (device_cc_accepted()?private:shared).
>
> Is this "Cbit" part of the CPU S2 page table address space or is it
> actually some PTE bit that says it is "encrypted" ?
>
> It is confusing when you say it would start working with a vIOMMU.
When I mention vIOMMU, I mean the S1 table which is guest owned and which has Cbit in PTEs.
> If 1<<51 is a valid IOPTE, and it is an actually address, then it
> should be mapped into the IOMMU S2, shouldn't it? If it is in the
> IOMMU S2 then shouldn't it work as a dma_addr_t?
It should (and checked with the HW folks), I just have not tried it as, like, whyyy.
> If the HW is treating 1<<51 special in some way and not reflecting it
> into a S2 lookup then it isn't an address bit but an IOPTE flag.
> IMHO is really dangerous to intermix PTE flags into phys_addr_t, I
> hope that is not what is happening.
Sounds like what you hope for is how it works now.
>>> 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?
>>
>> sorry but I do not follow this entirely.
>>
>> In general, GPA != DMA handle. Cbit (bit51) is not an address bit in a GPA but it is a DMA handle so I mask it there.
>>
>> With one exception - 1) host 2) mem_encrypt=on 3) iommu=pt, but we default to IOMMU in the case of host+mem_encrypt=on and don't have Cbit in host's DMA handles.
>>
>> For CoCoVM, I could map everything again at the 1<<51 offset in the same S2 table to leak Cbit to the bus (useless though).
>
> Double map is what ARM does at least. I don't know it is a good
> choice, but it means that phys_addr_t can have a shared/private bit
> (eg your Cbit at 51) and both the CPU and IOMMU S2 have legitimate
> mappings. ie it is a *true* address bit.
>
> Given AMD has only a single IOMMO for T=0 and 1 it would make sense to
> me if AMD always remove the C bit and there is always a uniform IOVA
> mapping from 0 -> vTOM.
>
> But in this case I would expect the vIOMMU to also use the same GPA
> space starting from 0 and also remove the C bit, as the S2 shouldn't
> have mappings starting at 1<<51.
How would then IOMMU know if DMA targets private or shared memory? The Cbit does not participate in the S2 translation as an address bit but IOMMU still knows what it is.
>> There is vTOM in SDTE which is "every phys_addr_t above vTOM is no
>> Cbit, below - with Cbit" (and there is the same thing for the CPU
>> side in SEV) but this not it, right?
>
> That seems like the IOMMU HW is specially handling the address bits in
> some way?
Yeah there is this capability. Except everything below vTOM is private and every above is shared so SME mask for it would be reverse than the CPU SME mask :) Not using this thing though (not sure why we have it). Thanks,
> At least ARM doesn't have anything like that, address bits
> are address bits, they don't get overloaded with secondary mechanisms.
>>> AMD's SME mask for shared is 0, for private - 1<<51.
>
> ARM is the inverse of this (private is at 0), but the same idea.
>
> Jason
--
Alexey
^ permalink raw reply
* Re: [PATCH kernel 2/9] pci/tsm: Add tsm_tdi_status
From: Aneesh Kumar K.V @ 2026-03-02 6:58 UTC (permalink / raw)
To: 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,
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, Xu Yilun,
Herbert Xu, Kim Phillips, Konrad Rzeszutek Wilk,
Stefano Stabellini, Claire Chang, linux-coco, iommu,
Alexey Kardashevskiy
In-Reply-To: <699e97d6e8be7_1cc51003c@dwillia2-mobl4.notmuch>
<dan.j.williams@intel.com> writes:
> 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 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.
>
Agreed. For CCA, we use rsi_vdev_info, but we need a generic mechanism
to associate this with the report that the guest has attested.
In CCA, we call rsi_vdev_get_info(vdev_id, dev_info) and later use that
information in rsi_vdev_enable_dma(vdev_id, dev_info).
Perhaps we could add a generation number (or meas_nonce) to the TSM
netlink response and use it when accepting the device, so we can
reliably bind the device measurement to the attested one?
-aneesh
^ 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