* Re: [PATCH kernel 4/9] dma/swiotlb: Stop forcing SWIOTLB for TDISP devices
From: Jason Gunthorpe @ 2026-03-04 12:43 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: dan.j.williams, 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, 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: <5d669086-a5c8-4e55-8108-a9fff41cf094@amd.com>
On Wed, Mar 04, 2026 at 05:45:31PM +1100, Alexey Kardashevskiy wrote:
> > I suspect AMD needs to use their vTOM feature to allow shared memory
> > to remain available to TDISP RUN with a high/low address split.
>
> I could probably do something about it bit I wonder what is the real
> live use case which requires leaking SME mask, have a live example
> which I could try recreating?
We need shared memory allocated through a DMABUF heap:
https://lore.kernel.org/all/20260223095136.225277-1-jiri@resnulli.us/
To work with all PCI devices in the system, TDISP or not.
Without this the ability for a TDISP device to ingest (encrypted) data
requires all kinds of memcpy..
So the DMA API should see the DMA_ATTR_CC_DECRYPTED and setup the
correct dma_dddr_t either by choosing the shared alias for the TDISP
device's vTOM, or setting the C bit in a vIOMMU S1.
Jason
^ permalink raw reply
* Re: [PATCH v12 06/46] arm64: RMI: Define the user ABI
From: Steven Price @ 2026-03-04 12:08 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve
In-Reply-To: <86h5qx83df.wl-maz@kernel.org>
On 03/03/2026 13:11, Marc Zyngier wrote:
> On Mon, 02 Mar 2026 15:23:44 +0000,
> Steven Price <steven.price@arm.com> wrote:
>>
>> Hi Marc,
>>
>> On 02/03/2026 14:25, Marc Zyngier wrote:
>>> On Wed, 17 Dec 2025 10:10:43 +0000,
>>> Steven Price <steven.price@arm.com> wrote:
>>>>
>>>> There is one CAP which identified the presence of CCA, and two ioctls.
>>>> One ioctl is used to populate memory and the other is used when user
>>>> space is providing the PSCI implementation to identify the target of the
>>>> operation.
>>>>
>>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>>> ---
>>>> Changes since v11:
>>>> * Completely reworked to be more implicit. Rather than having explicit
>>>> CAP operations to progress the realm construction these operations
>>>> are done when needed (on populating and on first vCPU run).
>>>> * Populate and PSCI complete are promoted to proper ioctls.
>>>> Changes since v10:
>>>> * Rename symbols from RME to RMI.
>>>> Changes since v9:
>>>> * Improvements to documentation.
>>>> * Bump the magic number for KVM_CAP_ARM_RME to avoid conflicts.
>>>> Changes since v8:
>>>> * Minor improvements to documentation following review.
>>>> * Bump the magic numbers to avoid conflicts.
>>>> Changes since v7:
>>>> * Add documentation of new ioctls
>>>> * Bump the magic numbers to avoid conflicts
>>>> Changes since v6:
>>>> * Rename some of the symbols to make their usage clearer and avoid
>>>> repetition.
>>>> Changes from v5:
>>>> * Actually expose the new VCPU capability (KVM_ARM_VCPU_REC) by bumping
>>>> KVM_VCPU_MAX_FEATURES - note this also exposes KVM_ARM_VCPU_HAS_EL2!
>>>> ---
>>>> Documentation/virt/kvm/api.rst | 57 ++++++++++++++++++++++++++++++++++
>>>> include/uapi/linux/kvm.h | 23 ++++++++++++++
>>>> 2 files changed, 80 insertions(+)
>>>>
>>>> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
>>>> index 01a3abef8abb..2d5dc7e48954 100644
>>>> --- a/Documentation/virt/kvm/api.rst
>>>> +++ b/Documentation/virt/kvm/api.rst
>>>> @@ -6517,6 +6517,54 @@ the capability to be present.
>>>>
>>>> `flags` must currently be zero.
>>>>
>>>> +4.144 KVM_ARM_VCPU_RMI_PSCI_COMPLETE
>>>> +------------------------------------
>>>> +
>>>> +:Capability: KVM_CAP_ARM_RMI
>>>> +:Architectures: arm64
>>>> +:Type: vcpu ioctl
>>>> +:Parameters: struct kvm_arm_rmi_psci_complete (in)
>>>> +:Returns: 0 if successful, < 0 on error
>>>> +
>>>> +::
>>>> +
>>>> + struct kvm_arm_rmi_psci_complete {
>>>> + __u64 target_mpidr;
>>>> + __u32 psci_status;
>>>> + __u32 padding[3];
>>>> + };
>>>> +
>>>> +Where PSCI functions are handled by user space, the RMM needs to be informed of
>>>> +the target of the operation using `target_mpidr`, along with the status
>>>> +(`psci_status`). The RMM v1.0 specification defines two functions that require
>>>> +this call: PSCI_CPU_ON and PSCI_AFFINITY_INFO.
>>>> +
>>>> +If the kernel is handling PSCI then this is done automatically and the VMM
>>>> +doesn't need to call this ioctl.
>>>
>>> Shouldn't we make handling of PSCI mandatory for VMMs that deal with
>>> CCA? I suspect it would simplify the implementation significantly.
>>
>> What do you mean by making it "mandatory for VMMs"? If you mean PSCI is
>> always forwarded to user space then I don't think it's going to make
>> much difference. Patch 27 handles the PSCI changes (72 lines added), and
>> some of that is adding this uAPI for the VMM to handle it.
>>
>> Removing the functionality to allow the VMM to handle it would obviously
>> simplify things a bit (we can drop this uAPI), but I think the desire is
>> to push this onto user space.
>
> And that's what I'm asking for. I do not want this to be optional. CCA
> should implies PSCI in userspace, and that's it.
>
>>
>>> What vcpu fd does this apply to? The vcpu calling the PSCI function?
>>> Or the target? This is pretty important for PSCI_ON. My guess is that
>>> this is setting the return value for the caller?
>>
>> Yes the fd is the vcpu calling PSCI. As you say, this is for the return
>> value to be set correctly.
>
> Another question is why do we need the ioctl at all? Why can't it be
> done on the first run of the target vcpu? If no PSCI call was issued
> to run it, then the run fails.
So my concern is the ordering of operations for PSCI_CPU_ON. As things
stand the RMM needs to know the MPIDR mapping to look up the REC object
before either VCPU runs again.
If we do this on the first run of the target VCPU, then how is the VMM
to tell that the target VCPU has executed "long enough" that it is safe
to do the return on the initial VCPU? Since the VCPUs are different
threads this becomes tricky. Options I can see are:
a) The VMM has to wait for the target VCPU to exit - we'd probably want
to trigger an artificial early exit in this case to unblock things.
b) The kernel blocks the initial VCPU from running until the target VCPU
has completed this "first run" logic. I think waiting in the kernel is
probably problematic, so this implies return some sort of "retry later"
response to the VMM.
c) The kernel handles the "PSCI_COMPLETE" dance on whichever VCPU runs
first, blocking the other until the dance is complete. A disadvantage
here is that behaviour can differ (in error conditions) depending on
which VCPU thread wins the race.
All these options also involve the kernel keeping track of the PSCI
sequence, in particular:
1. Tracking that the exit was due to a PSCI_CPU_ON.
2. Treating attempting to run the target VCPU as an implicit success
return from the PSCI call.
3. Recognising the next run on the initial VCPU as containing the PSCI
result - if 2, above, has happened then the kernel will need to handle
this (by killing the guest).
TLDR; Yes this is possible but I don't think it's pretty, and I'm not
convinced it's an improved uAPI.
Of course the above all assumes that the RMM can't just track things
internally. My preference is to kill RMI_PSCI_COMPLETE altogether, but
I'm not sure how possible that is within the context of the RMM.
>>
>>> Assuming this is indeed for the caller, why do we have a different
>>> flow from anything else that returns a result from a hypercall?
>>
>> I'm not entirely sure what you are suggesting. Do you mean why are we
>> not just writing to the GPRS that would contain the result? The issue
>> here is that the RMM needs to know the PA of the target REC structure -
>> this isn't a return to the guest, but information for the RMM itself to
>> complete the PSCI call.
>
> PSCI is a SMC call. SMC calls are routed to userspace as such. For odd
> reasons, the RMM treats PSCI differently from any other SMC call.
>
> That seems a very bizarre behaviour to me.
The RMM generally treats SMC specially. We have the RSI_HOST_CALL as a
proxy for "general SMC-like" behaviour which is forwarded to the VMM. I
believe the intention here is to ensure that SMCs (from the realm guest)
are handled by a trusted agent (i.e. the RMM). PSCI is a corner case
because it requires some coordination and buy-in from the VMM.
I'm not sure I fully understand the security pros and cons of the design
here and what impact it would have if PSCI was well trusted.
Thanks,
Steve
>>
>> Ultimately even in the case where the VMM is handling PSCI, it's
>> actually a combination of the VMM and the RMM - with the RMM validating
>> the responses.
>
> I don't see why PSCI is singled out here, irrespective of the tracking
> that the RMM wants to do.
>
> M.
>
^ permalink raw reply
* Re: [PATCH kernel 4/9] dma/swiotlb: Stop forcing SWIOTLB for TDISP devices
From: Alexey Kardashevskiy @ 2026-03-04 6:45 UTC (permalink / raw)
To: Jason Gunthorpe, dan.j.williams
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, 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: <20260303124306.GA1002356@nvidia.com>
On 3/3/26 23:43, Jason Gunthorpe wrote:
> On Mon, Mar 02, 2026 at 08:19:11PM -0400, Jason Gunthorpe wrote:
>>> Oh, I thought SEV-TIO had trouble with this, if this is indeed the case,
>>> great, ignore my first comment.
>>
>> Alexey?
>>
>> I think it is really important that shared mappings continue to be
>> reachable by TDISP device.
>
> I think Alexey has clarified this in the other thread, and probably
> AMD has some work to do here.
>
> The issue is AMD does not have seperate address spaces for
> shared/private like ARM does, instead it relies on a C bit in the *PTE*
> to determine shared/private.
>
> The S2 IOMMU page table *does* have the full mapping of all shared &
> private pages but the HW requires a matching C bit to permit access.
>
> If there is a S1 IOMMU then the IOPTEs of the VM can provide the C
> bit, so no problem.
>
> If there is no S1 then the sDTE of the hypervisor controls the C bit,
sDTE is controlled by the FW (not the HV) on the VM behalf - the VM chooses whether to enable sDTE and therefore vTOM.
> and it sounds like currently AMD sets this globally which effectively
> locks TDISP RUN devices to *only* access private memory.
Right. The assumption is that if the guest wants finer control - there is secure vIOMMU (in the works).
> I suspect AMD needs to use their vTOM feature to allow shared memory
> to remain available to TDISP RUN with a high/low address split.
I could probably do something about it bit I wonder what is the real live use case which requires leaking SME mask, have a live example which I could try recreating?
> Alexey, did I capture this properly?
Yes, with the correction about sDTE above. Thanks,
>
> Jason
--
Alexey
^ permalink raw reply
* Re: [PATCH v3 00/16] KVM: x86/tdx: Have TDX handle VMXON during bringup
From: Sagi Shahar @ 2026-03-04 0:06 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, Chao Gao, Xu Yilun, Dan Williams
In-Reply-To: <CAAhR5DF5BAcFO2tj0H63ZoRCcdpDS4Jw9XzqC=L2xWMW0M=0QQ@mail.gmail.com>
On Tue, Mar 3, 2026 at 3:39 PM Sagi Shahar <sagis@google.com> wrote:
>
> On Fri, Feb 13, 2026 at 7:27 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > Assuming I didn't break anything between v2 and v3, I think this is ready to
> > rip. Given the scope of the KVM changes, and that they extend outside of x86,
> > my preference is to take this through the KVM tree. But a stable topic branch
> > in tip would work too, though I think we'd want it sooner than later so that
> > it can be used as a base.
> >
> > Chao, I deliberately omitted your Tested-by, as I shuffled things around enough
> > while splitting up the main patch that I'm not 100% positive I didn't regress
> > anything relative to v2.
>
> Tested running TDs and TDX module update using "Runtime TDX Module
> update support" patches [1]
> Tested-by: Sagi Shahar <sagishah@gmail.com>
>
> [1] https://lore.kernel.org/lkml/20260123145645.90444-1-chao.gao@intel.com/
Actually, looking at the "Runtime TDX Module update support" patches I
don't think I ran those with this version of the patches since the
"tdx_module_status" changes are incompatible. So it was just the
patches in this patchset.
^ permalink raw reply
* Re: [PATCH v2 00/19] PCI/TSM: TEE I/O infrastructure
From: dan.j.williams @ 2026-03-03 22:01 UTC (permalink / raw)
To: Aneesh Kumar K.V, Dan Williams, linux-coco, linux-pci
Cc: gregkh, aik, yilun.xu, bhelgaas, alistair23, lukas, jgg,
Andy Lutomirski, Arnd Bergmann, Borislav Petkov,
Christoph Hellwig, Danilo Krummrich, Dave Hansen, Donald Hunter,
H. Peter Anvin, Ingo Molnar, Jakub Kicinski, Jason Gunthorpe,
Luis Chamberlain, Marek Szyprowski, Peter Zijlstra,
Rafael J. Wysocki, Robin Murphy, Roman Kisel, Samuel Ortiz,
Saravana Kannan, Suzuki K Poulose, Thomas Gleixner,
Thomas Gleixner
In-Reply-To: <yq5aecm19shr.fsf@kernel.org>
Aneesh Kumar K.V wrote:
> Dan Williams <dan.j.williams@intel.com> writes:
>
> ....
>
> To support devices without IDE/DOE support we need something similar.
>
> modified drivers/pci/tsm/core.c
> @@ -1236,12 +1236,14 @@ int pci_tsm_pf0_constructor(struct pci_dev *pdev, struct pci_tsm_pf0 *tsm,
> struct tsm_dev *tsm_dev)
> {
> mutex_init(&tsm->lock);
> - tsm->doe_mb = pci_find_doe_mailbox(pdev, PCI_VENDOR_ID_PCI_SIG,
> - PCI_DOE_FEATURE_CMA);
> - if (!tsm->doe_mb) {
> - pci_warn(pdev, "TSM init failure, no CMA mailbox\n");
> - return -ENODEV;
> - }
> +
> + /*
> + * Note, low-level TSM driver responsible for determining if it wants to
> + * proceed with a device that has no DOE mailbox. TSM may have an
> + * alternate method for coordinating TDISP.
> + */
> + if (!tsm->doe_mb)
> + pci_dbg(pdev, "no CMA mailbox\n");
A patch like patch can go upstream now. Care to send?
^ permalink raw reply
* Re: [PATCH v3 00/16] KVM: x86/tdx: Have TDX handle VMXON during bringup
From: Sagi Shahar @ 2026-03-03 21:39 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, Chao Gao, Xu Yilun, Dan Williams
In-Reply-To: <20260214012702.2368778-1-seanjc@google.com>
On Fri, Feb 13, 2026 at 7:27 PM Sean Christopherson <seanjc@google.com> wrote:
>
> Assuming I didn't break anything between v2 and v3, I think this is ready to
> rip. Given the scope of the KVM changes, and that they extend outside of x86,
> my preference is to take this through the KVM tree. But a stable topic branch
> in tip would work too, though I think we'd want it sooner than later so that
> it can be used as a base.
>
> Chao, I deliberately omitted your Tested-by, as I shuffled things around enough
> while splitting up the main patch that I'm not 100% positive I didn't regress
> anything relative to v2.
Tested running TDs and TDX module update using "Runtime TDX Module
update support" patches [1]
Tested-by: Sagi Shahar <sagishah@gmail.com>
[1] https://lore.kernel.org/lkml/20260123145645.90444-1-chao.gao@intel.com/
^ permalink raw reply
* Re: [PATCH 14/14] KVM: x86: Add helpers to prepare kvm_run for userspace MMIO exit
From: Edgecombe, Rick P @ 2026-03-03 19:51 UTC (permalink / raw)
To: seanjc@google.com
Cc: x86@kernel.org, zhangjiaji1@huawei.com, kas@kernel.org,
Li, Xiaoyao, linux-kernel@vger.kernel.org,
thomas.lendacky@amd.com, pbonzini@redhat.com,
linux-coco@lists.linux.dev, michael.roth@amd.com,
kvm@vger.kernel.org, binbin.wu@linux.intel.com
In-Reply-To: <aac6DGISvMX4krhb@google.com>
On Tue, 2026-03-03 at 11:44 -0800, Sean Christopherson wrote:
> >
> > Seems ok and an improvement over the patch. But looking at the other
> > callers, there is quite a bit of min(8u, len) logic spread around. Might be
> > worth a wider cleanup someday.
>
> LOL, "might". :-)
Trying to not set you off... :)
>
> Definitely a project for the future though, especially given how subtle and
> brittle this all is.
^ permalink raw reply
* Re: [PATCH 14/14] KVM: x86: Add helpers to prepare kvm_run for userspace MMIO exit
From: Sean Christopherson @ 2026-03-03 19:44 UTC (permalink / raw)
To: Rick P Edgecombe
Cc: x86@kernel.org, zhangjiaji1@huawei.com, kas@kernel.org,
Xiaoyao Li, linux-kernel@vger.kernel.org, thomas.lendacky@amd.com,
binbin.wu@linux.intel.com, pbonzini@redhat.com,
linux-coco@lists.linux.dev, kvm@vger.kernel.org,
michael.roth@amd.com
In-Reply-To: <4574be9a29d75d565e553579ef6ce915ef33b19b.camel@intel.com>
On Tue, Mar 03, 2026, Rick P Edgecombe wrote:
> On Mon, 2026-03-02 at 18:24 -0800, Sean Christopherson wrote:
> > Ooh, better idea. Since TDX is the only direct user of
> > __kvm_prepare_emulated_mmio_exit() and it only supports lenths of 1, 2, 4, and 8,
> > kvm_prepare_emulated_mmio_exit() is the only path that actually needs to cap the
> > length. Then the inner helper can assert a valid length. Doesn't change anything
> > in practice, but I like the idea of making the caller be aware of the limitation
> > (even if that caller is itself a helper).
>
> Seems ok and an improvement over the patch. But looking at the other callers,
> there is quite a bit of min(8u, len) logic spread around. Might be worth a wider
> cleanup someday.
LOL, "might". :-)
Definitely a project for the future though, especially given how subtle and brittle
this all is.
^ permalink raw reply
* Re: [PATCH 14/14] KVM: x86: Add helpers to prepare kvm_run for userspace MMIO exit
From: Edgecombe, Rick P @ 2026-03-03 19:21 UTC (permalink / raw)
To: seanjc@google.com
Cc: x86@kernel.org, zhangjiaji1@huawei.com, kas@kernel.org,
Li, Xiaoyao, linux-kernel@vger.kernel.org,
thomas.lendacky@amd.com, binbin.wu@linux.intel.com,
pbonzini@redhat.com, linux-coco@lists.linux.dev,
kvm@vger.kernel.org, michael.roth@amd.com
In-Reply-To: <aaZGTY3CzhaCb1lc@google.com>
On Mon, 2026-03-02 at 18:24 -0800, Sean Christopherson wrote:
> Ooh, better idea. Since TDX is the only direct user of
> __kvm_prepare_emulated_mmio_exit() and it only supports lenths of 1, 2, 4, and 8,
> kvm_prepare_emulated_mmio_exit() is the only path that actually needs to cap the
> length. Then the inner helper can assert a valid length. Doesn't change anything
> in practice, but I like the idea of making the caller be aware of the limitation
> (even if that caller is itself a helper).
Seems ok and an improvement over the patch. But looking at the other callers,
there is quite a bit of min(8u, len) logic spread around. Might be worth a wider
cleanup someday.
^ permalink raw reply
* SVSM Development Call March 4, 2026
From: Jörg Rödel @ 2026-03-03 17:07 UTC (permalink / raw)
To: coconut-svsm, linux-coco
Hi,
Here is the call for agenda items for this weeks SVSM development call. Please
send any agenda items you have in mind as a reply to this email or raise them
in the meeting.
We will use the LF Zoom instance. Details of the meeting can be found in our
governance repository at:
https://github.com/coconut-svsm/governance
The link to the COCONUT-SVSM calendar is:
https://zoom-lfx.platform.linuxfoundation.org/meetings/coconut-svsm?view=week
The meeting will be recorded and the recording eventually published.
Regards,
Jörg
^ permalink raw reply
* Re: [PATCH v2 08/19] PCI/TSM: Add "evidence" support
From: Aneesh Kumar K.V @ 2026-03-03 16:38 UTC (permalink / raw)
To: Dan Williams, linux-coco, linux-pci
Cc: gregkh, aik, yilun.xu, bhelgaas, alistair23, lukas, jgg,
Donald Hunter, Jakub Kicinski
In-Reply-To: <20260303000207.1836586-9-dan.j.williams@intel.com>
Dan Williams <dan.j.williams@intel.com> writes:
> Once one accepts the threat model that devices may be adversarial the
> process of establishing trust in the device identity, the integrity +
> confidentiality of its link, and the integrity + confidentiality of its
> MMIO interface requires multiple evidence objects from the device. The
> device's certificate chain, measurements and interface report need to be
> retrieved by the host, validated by the TSM and transmitted to the guest
> all while mitigating TOCTOU races.
>
> All TSM implementations share the same fundamental objects, but vary in how
> the TSM conveys its trust in the objects. Some TSM implementations expect
> the full documents to be conveyed over untrustworthy channels while the TSM
> securely conveys a digest. Others transmit full objects with signed SPDM
> transcripts of requester provided nonces. Some offer a single transcript
> to convey the version, capabilities, and algorithms (VCA) data and
> measurements in one blob while others split VCA as a separate signed blob.
>
> Introduce a netlink interface to dump all these objects in a common way
> across TSM implementations and across host and guest environments.
> Userspace is responsible for handling the variance of "TSM provides combo
> measurements + VCA + nonce + signature, vs TSM provides a digest over a
> secure channel of the same".
>
> The implementation adheres to the guideline from:
> Documentation/userspace-api/netlink/genetlink-legacy.rst
>
> New Netlink families should never respond to a DO operation with
> multiple replies, with ``NLM_F_MULTI`` set. Use a filtered dump
> instead.
>
> Per SPDM, transcripts may grow to be 16MB in size. Large PCI/TSM netlink
> blobs are handled via a sequence of dump messages that userspace must
> concatenate.
>
Should we also expose evidence->generation to userspace so it can be
used during accept()? This would allow us to ensure that the device is
accepted using the same evidence generation observed by userspace.
-aneesh
^ permalink raw reply
* Re: [PATCH v12 06/46] arm64: RMI: Define the user ABI
From: Suzuki K Poulose @ 2026-03-03 16:02 UTC (permalink / raw)
To: Marc Zyngier
Cc: Steven Price, kvm, kvmarm, Catalin Marinas, Will Deacon,
James Morse, Oliver Upton, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve
In-Reply-To: <86ecm17zeb.wl-maz@kernel.org>
On 03/03/2026 14:37, Marc Zyngier wrote:
> On Tue, 03 Mar 2026 14:23:08 +0000,
> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>
>> On 03/03/2026 13:13, Marc Zyngier wrote:
>>> On Mon, 02 Mar 2026 17:13:41 +0000,
>>> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>>>
>>>> More importantly, we have to make sure that the "RMI_PSCI_COMPLETE" is
>>>> invoked before both of the following:
>>>> 1. The "source" vCPU is run again
>>>> 2. More importantly the "target" vCPU is run.
>>>
>>> I don't understand why (1) is required. Once the VMM gets the request,
>>
>> The underlying issue is, the RMM doesn't have the VCPU object for the
>> "target" VCPU, to make the book keeping. Also, please note that for a
>> Realm, PSCI is emulated by the "RMM". Host is obviously notified of the
>> "PSCI" changes via EXIT_PSCI (note, it is not SMCCC exit)
>> so that it can be in sync with the real state. And does have a say in
>> CPU_ON. So, before we return to running the "source" CPU,
>> Host must provide the target VCPU object and its consent (via
>> psci_status) to the RMM. This allows the RMM to emulate the PSCI
>> request correctly and also at the same time keep its book keeping
>> in tact (i.e., marking the Target VCPU as runnable or not).
>>
>> When a "source" VCPU exits to the host with a PSCI_EXIT, the RMM
>> marks the source VCPU has a pending PSCI operation, and
>> RMI_PSCI_COMPLETE request ticks that off, making it runnable again.
>
> Sure. What I don't get is what this has to happen on the source vcpu
> thread. The RMM has absolutely no clue about that, and there should be
> no impediment to letting the target vcpu do it as it starts.
Because, the RMM wants to make that the state is consistent. i.e,
Host cannot lie to the "source" VCPU and RMM (e.g., CPU_ON denied) and
then run the "target" VCPU.
In other words, the response to the CPU_ON must be recorded by the RMM
in the target VCPU state, to make sure the target VCPU state is
consistent with the response.
The only way to fix this would be RMM keeping track of "mpidr" to REC
object mapping (VCPU object), which impacts the scalability. With that
in place, RMM can update the target VCPU state from the return of the
REC_ENTER after a PSCI_EXIT.
That said, will explore the options to address this
Thanks
Suzuki
>
> Even better, you should be able to do that on the first thread that
> reenters the guest, completely removing any RMM knowledge from the
> PSCI handling in userspace.
>
> If you can't do that, then please consider fixing the RMM to allow it.
>
> Thanks,
>
> M.
>
^ permalink raw reply
* Re: [PATCH v12 06/46] arm64: RMI: Define the user ABI
From: Marc Zyngier @ 2026-03-03 14:37 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Steven Price, kvm, kvmarm, Catalin Marinas, Will Deacon,
James Morse, Oliver Upton, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve
In-Reply-To: <d87ee902-3b5e-4cf9-8b97-d83f8da02a5a@arm.com>
On Tue, 03 Mar 2026 14:23:08 +0000,
Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>
> On 03/03/2026 13:13, Marc Zyngier wrote:
> > On Mon, 02 Mar 2026 17:13:41 +0000,
> > Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> >>
> >> More importantly, we have to make sure that the "RMI_PSCI_COMPLETE" is
> >> invoked before both of the following:
> >> 1. The "source" vCPU is run again
> >> 2. More importantly the "target" vCPU is run.
> >
> > I don't understand why (1) is required. Once the VMM gets the request,
>
> The underlying issue is, the RMM doesn't have the VCPU object for the
> "target" VCPU, to make the book keeping. Also, please note that for a
> Realm, PSCI is emulated by the "RMM". Host is obviously notified of the
> "PSCI" changes via EXIT_PSCI (note, it is not SMCCC exit)
> so that it can be in sync with the real state. And does have a say in
> CPU_ON. So, before we return to running the "source" CPU,
> Host must provide the target VCPU object and its consent (via
> psci_status) to the RMM. This allows the RMM to emulate the PSCI
> request correctly and also at the same time keep its book keeping
> in tact (i.e., marking the Target VCPU as runnable or not).
>
> When a "source" VCPU exits to the host with a PSCI_EXIT, the RMM
> marks the source VCPU has a pending PSCI operation, and
> RMI_PSCI_COMPLETE request ticks that off, making it runnable again.
Sure. What I don't get is what this has to happen on the source vcpu
thread. The RMM has absolutely no clue about that, and there should be
no impediment to letting the target vcpu do it as it starts.
Even better, you should be able to do that on the first thread that
reenters the guest, completely removing any RMM knowledge from the
PSCI handling in userspace.
If you can't do that, then please consider fixing the RMM to allow it.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v12 06/46] arm64: RMI: Define the user ABI
From: Suzuki K Poulose @ 2026-03-03 14:23 UTC (permalink / raw)
To: Marc Zyngier
Cc: Steven Price, kvm, kvmarm, Catalin Marinas, Will Deacon,
James Morse, Oliver Upton, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve
In-Reply-To: <86fr6h838s.wl-maz@kernel.org>
On 03/03/2026 13:13, Marc Zyngier wrote:
> On Mon, 02 Mar 2026 17:13:41 +0000,
> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>
>> On 02/03/2026 15:23, Steven Price wrote:
>>> Hi Marc,
>>>
>>> On 02/03/2026 14:25, Marc Zyngier wrote:
>>>> On Wed, 17 Dec 2025 10:10:43 +0000,
>>>> Steven Price <steven.price@arm.com> wrote:
>>>>>
>>>>> There is one CAP which identified the presence of CCA, and two ioctls.
>>>>> One ioctl is used to populate memory and the other is used when user
>>>>> space is providing the PSCI implementation to identify the target of the
>>>>> operation.
>>>>>
>>>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>>>> ---
>>>>> Changes since v11:
>>>>> * Completely reworked to be more implicit. Rather than having explicit
>>>>> CAP operations to progress the realm construction these operations
>>>>> are done when needed (on populating and on first vCPU run).
>>>>> * Populate and PSCI complete are promoted to proper ioctls.
>>>>> Changes since v10:
>>>>> * Rename symbols from RME to RMI.
>>>>> Changes since v9:
>>>>> * Improvements to documentation.
>>>>> * Bump the magic number for KVM_CAP_ARM_RME to avoid conflicts.
>>>>> Changes since v8:
>>>>> * Minor improvements to documentation following review.
>>>>> * Bump the magic numbers to avoid conflicts.
>>>>> Changes since v7:
>>>>> * Add documentation of new ioctls
>>>>> * Bump the magic numbers to avoid conflicts
>>>>> Changes since v6:
>>>>> * Rename some of the symbols to make their usage clearer and avoid
>>>>> repetition.
>>>>> Changes from v5:
>>>>> * Actually expose the new VCPU capability (KVM_ARM_VCPU_REC) by bumping
>>>>> KVM_VCPU_MAX_FEATURES - note this also exposes KVM_ARM_VCPU_HAS_EL2!
>>>>> ---
>>>>> Documentation/virt/kvm/api.rst | 57 ++++++++++++++++++++++++++++++++++
>>>>> include/uapi/linux/kvm.h | 23 ++++++++++++++
>>>>> 2 files changed, 80 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
>>>>> index 01a3abef8abb..2d5dc7e48954 100644
>>>>> --- a/Documentation/virt/kvm/api.rst
>>>>> +++ b/Documentation/virt/kvm/api.rst
>>>>> @@ -6517,6 +6517,54 @@ the capability to be present.
>>>>> `flags` must currently be zero.
>>>>> +4.144 KVM_ARM_VCPU_RMI_PSCI_COMPLETE
>>>>> +------------------------------------
>>>>> +
>>>>> +:Capability: KVM_CAP_ARM_RMI
>>>>> +:Architectures: arm64
>>>>> +:Type: vcpu ioctl
>>>>> +:Parameters: struct kvm_arm_rmi_psci_complete (in)
>>>>> +:Returns: 0 if successful, < 0 on error
>>>>> +
>>>>> +::
>>>>> +
>>>>> + struct kvm_arm_rmi_psci_complete {
>>>>> + __u64 target_mpidr;
>>>>> + __u32 psci_status;
>>>>> + __u32 padding[3];
>>>>> + };
>>>>> +
>>>>> +Where PSCI functions are handled by user space, the RMM needs to be informed of
>>>>> +the target of the operation using `target_mpidr`, along with the status
>>>>> +(`psci_status`). The RMM v1.0 specification defines two functions that require
>>>>> +this call: PSCI_CPU_ON and PSCI_AFFINITY_INFO.
>>>>> +
>>>>> +If the kernel is handling PSCI then this is done automatically and the VMM
>>>>> +doesn't need to call this ioctl.
>>>>
>>>> Shouldn't we make handling of PSCI mandatory for VMMs that deal with
>>>> CCA? I suspect it would simplify the implementation significantly.
>>>
>>> What do you mean by making it "mandatory for VMMs"? If you mean PSCI is
>>> always forwarded to user space then I don't think it's going to make
>>> much difference. Patch 27 handles the PSCI changes (72 lines added), and
>>> some of that is adding this uAPI for the VMM to handle it.
>>>
>>> Removing the functionality to allow the VMM to handle it would obviously
>>> simplify things a bit (we can drop this uAPI), but I think the desire is
>>> to push this onto user space.
>>>
>>>> What vcpu fd does this apply to? The vcpu calling the PSCI function?
>>>> Or the target? This is pretty important for PSCI_ON. My guess is that
>>>> this is setting the return value for the caller?
>>>
>>> Yes the fd is the vcpu calling PSCI. As you say, this is for the return
>>> value to be set correctly.
>>>
>>>> Assuming this is indeed for the caller, why do we have a different
>>>> flow from anything else that returns a result from a hypercall?
>>>
>>> I'm not entirely sure what you are suggesting. Do you mean why are we
>>> not just writing to the GPRS that would contain the result? The issue
>>> here is that the RMM needs to know the PA of the target REC structure -
>>> this isn't a return to the guest, but information for the RMM itself to
>>> complete the PSCI call.
>>>
>>> Ultimately even in the case where the VMM is handling PSCI, it's
>>> actually a combination of the VMM and the RMM - with the RMM validating
>>> the responses.
>>>
>>
>> More importantly, we have to make sure that the "RMI_PSCI_COMPLETE" is
>> invoked before both of the following:
>> 1. The "source" vCPU is run again
>> 2. More importantly the "target" vCPU is run.
>
> I don't understand why (1) is required. Once the VMM gets the request,
The underlying issue is, the RMM doesn't have the VCPU object for the
"target" VCPU, to make the book keeping. Also, please note that for a
Realm, PSCI is emulated by the "RMM". Host is obviously notified of the
"PSCI" changes via EXIT_PSCI (note, it is not SMCCC exit)
so that it can be in sync with the real state. And does have a say in
CPU_ON. So, before we return to running the "source" CPU,
Host must provide the target VCPU object and its consent (via
psci_status) to the RMM. This allows the RMM to emulate the PSCI
request correctly and also at the same time keep its book keeping
in tact (i.e., marking the Target VCPU as runnable or not).
When a "source" VCPU exits to the host with a PSCI_EXIT, the RMM
marks the source VCPU has a pending PSCI operation, and
RMI_PSCI_COMPLETE request ticks that off, making it runnable again.
Suzuki
> the target vcpu can run, and can itself do the completion, without any
> additional userspace involvement.
>
> M.
>
^ permalink raw reply
* Re: [PATCH v12 06/46] arm64: RMI: Define the user ABI
From: Marc Zyngier @ 2026-03-03 13:13 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Steven Price, kvm, kvmarm, Catalin Marinas, Will Deacon,
James Morse, Oliver Upton, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve
In-Reply-To: <9d702666-72a8-43e4-8ab3-548d8154a529@arm.com>
On Mon, 02 Mar 2026 17:13:41 +0000,
Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>
> On 02/03/2026 15:23, Steven Price wrote:
> > Hi Marc,
> >
> > On 02/03/2026 14:25, Marc Zyngier wrote:
> >> On Wed, 17 Dec 2025 10:10:43 +0000,
> >> Steven Price <steven.price@arm.com> wrote:
> >>>
> >>> There is one CAP which identified the presence of CCA, and two ioctls.
> >>> One ioctl is used to populate memory and the other is used when user
> >>> space is providing the PSCI implementation to identify the target of the
> >>> operation.
> >>>
> >>> Signed-off-by: Steven Price <steven.price@arm.com>
> >>> ---
> >>> Changes since v11:
> >>> * Completely reworked to be more implicit. Rather than having explicit
> >>> CAP operations to progress the realm construction these operations
> >>> are done when needed (on populating and on first vCPU run).
> >>> * Populate and PSCI complete are promoted to proper ioctls.
> >>> Changes since v10:
> >>> * Rename symbols from RME to RMI.
> >>> Changes since v9:
> >>> * Improvements to documentation.
> >>> * Bump the magic number for KVM_CAP_ARM_RME to avoid conflicts.
> >>> Changes since v8:
> >>> * Minor improvements to documentation following review.
> >>> * Bump the magic numbers to avoid conflicts.
> >>> Changes since v7:
> >>> * Add documentation of new ioctls
> >>> * Bump the magic numbers to avoid conflicts
> >>> Changes since v6:
> >>> * Rename some of the symbols to make their usage clearer and avoid
> >>> repetition.
> >>> Changes from v5:
> >>> * Actually expose the new VCPU capability (KVM_ARM_VCPU_REC) by bumping
> >>> KVM_VCPU_MAX_FEATURES - note this also exposes KVM_ARM_VCPU_HAS_EL2!
> >>> ---
> >>> Documentation/virt/kvm/api.rst | 57 ++++++++++++++++++++++++++++++++++
> >>> include/uapi/linux/kvm.h | 23 ++++++++++++++
> >>> 2 files changed, 80 insertions(+)
> >>>
> >>> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> >>> index 01a3abef8abb..2d5dc7e48954 100644
> >>> --- a/Documentation/virt/kvm/api.rst
> >>> +++ b/Documentation/virt/kvm/api.rst
> >>> @@ -6517,6 +6517,54 @@ the capability to be present.
> >>> `flags` must currently be zero.
> >>> +4.144 KVM_ARM_VCPU_RMI_PSCI_COMPLETE
> >>> +------------------------------------
> >>> +
> >>> +:Capability: KVM_CAP_ARM_RMI
> >>> +:Architectures: arm64
> >>> +:Type: vcpu ioctl
> >>> +:Parameters: struct kvm_arm_rmi_psci_complete (in)
> >>> +:Returns: 0 if successful, < 0 on error
> >>> +
> >>> +::
> >>> +
> >>> + struct kvm_arm_rmi_psci_complete {
> >>> + __u64 target_mpidr;
> >>> + __u32 psci_status;
> >>> + __u32 padding[3];
> >>> + };
> >>> +
> >>> +Where PSCI functions are handled by user space, the RMM needs to be informed of
> >>> +the target of the operation using `target_mpidr`, along with the status
> >>> +(`psci_status`). The RMM v1.0 specification defines two functions that require
> >>> +this call: PSCI_CPU_ON and PSCI_AFFINITY_INFO.
> >>> +
> >>> +If the kernel is handling PSCI then this is done automatically and the VMM
> >>> +doesn't need to call this ioctl.
> >>
> >> Shouldn't we make handling of PSCI mandatory for VMMs that deal with
> >> CCA? I suspect it would simplify the implementation significantly.
> >
> > What do you mean by making it "mandatory for VMMs"? If you mean PSCI is
> > always forwarded to user space then I don't think it's going to make
> > much difference. Patch 27 handles the PSCI changes (72 lines added), and
> > some of that is adding this uAPI for the VMM to handle it.
> >
> > Removing the functionality to allow the VMM to handle it would obviously
> > simplify things a bit (we can drop this uAPI), but I think the desire is
> > to push this onto user space.
> >
> >> What vcpu fd does this apply to? The vcpu calling the PSCI function?
> >> Or the target? This is pretty important for PSCI_ON. My guess is that
> >> this is setting the return value for the caller?
> >
> > Yes the fd is the vcpu calling PSCI. As you say, this is for the return
> > value to be set correctly.
> >
> >> Assuming this is indeed for the caller, why do we have a different
> >> flow from anything else that returns a result from a hypercall?
> >
> > I'm not entirely sure what you are suggesting. Do you mean why are we
> > not just writing to the GPRS that would contain the result? The issue
> > here is that the RMM needs to know the PA of the target REC structure -
> > this isn't a return to the guest, but information for the RMM itself to
> > complete the PSCI call.
> >
> > Ultimately even in the case where the VMM is handling PSCI, it's
> > actually a combination of the VMM and the RMM - with the RMM validating
> > the responses.
> >
>
> More importantly, we have to make sure that the "RMI_PSCI_COMPLETE" is
> invoked before both of the following:
> 1. The "source" vCPU is run again
> 2. More importantly the "target" vCPU is run.
I don't understand why (1) is required. Once the VMM gets the request,
the target vcpu can run, and can itself do the completion, without any
additional userspace involvement.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v12 06/46] arm64: RMI: Define the user ABI
From: Marc Zyngier @ 2026-03-03 13:11 UTC (permalink / raw)
To: Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve
In-Reply-To: <33053e22-6cc6-4d55-bc7f-01f873a15d28@arm.com>
On Mon, 02 Mar 2026 15:23:44 +0000,
Steven Price <steven.price@arm.com> wrote:
>
> Hi Marc,
>
> On 02/03/2026 14:25, Marc Zyngier wrote:
> > On Wed, 17 Dec 2025 10:10:43 +0000,
> > Steven Price <steven.price@arm.com> wrote:
> >>
> >> There is one CAP which identified the presence of CCA, and two ioctls.
> >> One ioctl is used to populate memory and the other is used when user
> >> space is providing the PSCI implementation to identify the target of the
> >> operation.
> >>
> >> Signed-off-by: Steven Price <steven.price@arm.com>
> >> ---
> >> Changes since v11:
> >> * Completely reworked to be more implicit. Rather than having explicit
> >> CAP operations to progress the realm construction these operations
> >> are done when needed (on populating and on first vCPU run).
> >> * Populate and PSCI complete are promoted to proper ioctls.
> >> Changes since v10:
> >> * Rename symbols from RME to RMI.
> >> Changes since v9:
> >> * Improvements to documentation.
> >> * Bump the magic number for KVM_CAP_ARM_RME to avoid conflicts.
> >> Changes since v8:
> >> * Minor improvements to documentation following review.
> >> * Bump the magic numbers to avoid conflicts.
> >> Changes since v7:
> >> * Add documentation of new ioctls
> >> * Bump the magic numbers to avoid conflicts
> >> Changes since v6:
> >> * Rename some of the symbols to make their usage clearer and avoid
> >> repetition.
> >> Changes from v5:
> >> * Actually expose the new VCPU capability (KVM_ARM_VCPU_REC) by bumping
> >> KVM_VCPU_MAX_FEATURES - note this also exposes KVM_ARM_VCPU_HAS_EL2!
> >> ---
> >> Documentation/virt/kvm/api.rst | 57 ++++++++++++++++++++++++++++++++++
> >> include/uapi/linux/kvm.h | 23 ++++++++++++++
> >> 2 files changed, 80 insertions(+)
> >>
> >> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> >> index 01a3abef8abb..2d5dc7e48954 100644
> >> --- a/Documentation/virt/kvm/api.rst
> >> +++ b/Documentation/virt/kvm/api.rst
> >> @@ -6517,6 +6517,54 @@ the capability to be present.
> >>
> >> `flags` must currently be zero.
> >>
> >> +4.144 KVM_ARM_VCPU_RMI_PSCI_COMPLETE
> >> +------------------------------------
> >> +
> >> +:Capability: KVM_CAP_ARM_RMI
> >> +:Architectures: arm64
> >> +:Type: vcpu ioctl
> >> +:Parameters: struct kvm_arm_rmi_psci_complete (in)
> >> +:Returns: 0 if successful, < 0 on error
> >> +
> >> +::
> >> +
> >> + struct kvm_arm_rmi_psci_complete {
> >> + __u64 target_mpidr;
> >> + __u32 psci_status;
> >> + __u32 padding[3];
> >> + };
> >> +
> >> +Where PSCI functions are handled by user space, the RMM needs to be informed of
> >> +the target of the operation using `target_mpidr`, along with the status
> >> +(`psci_status`). The RMM v1.0 specification defines two functions that require
> >> +this call: PSCI_CPU_ON and PSCI_AFFINITY_INFO.
> >> +
> >> +If the kernel is handling PSCI then this is done automatically and the VMM
> >> +doesn't need to call this ioctl.
> >
> > Shouldn't we make handling of PSCI mandatory for VMMs that deal with
> > CCA? I suspect it would simplify the implementation significantly.
>
> What do you mean by making it "mandatory for VMMs"? If you mean PSCI is
> always forwarded to user space then I don't think it's going to make
> much difference. Patch 27 handles the PSCI changes (72 lines added), and
> some of that is adding this uAPI for the VMM to handle it.
>
> Removing the functionality to allow the VMM to handle it would obviously
> simplify things a bit (we can drop this uAPI), but I think the desire is
> to push this onto user space.
And that's what I'm asking for. I do not want this to be optional. CCA
should implies PSCI in userspace, and that's it.
>
> > What vcpu fd does this apply to? The vcpu calling the PSCI function?
> > Or the target? This is pretty important for PSCI_ON. My guess is that
> > this is setting the return value for the caller?
>
> Yes the fd is the vcpu calling PSCI. As you say, this is for the return
> value to be set correctly.
Another question is why do we need the ioctl at all? Why can't it be
done on the first run of the target vcpu? If no PSCI call was issued
to run it, then the run fails.
>
> > Assuming this is indeed for the caller, why do we have a different
> > flow from anything else that returns a result from a hypercall?
>
> I'm not entirely sure what you are suggesting. Do you mean why are we
> not just writing to the GPRS that would contain the result? The issue
> here is that the RMM needs to know the PA of the target REC structure -
> this isn't a return to the guest, but information for the RMM itself to
> complete the PSCI call.
PSCI is a SMC call. SMC calls are routed to userspace as such. For odd
reasons, the RMM treats PSCI differently from any other SMC call.
That seems a very bizarre behaviour to me.
>
> Ultimately even in the case where the VMM is handling PSCI, it's
> actually a combination of the VMM and the RMM - with the RMM validating
> the responses.
I don't see why PSCI is singled out here, irrespective of the tracking
that the RMM wants to do.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v12 27/46] KVM: arm64: Handle Realm PSCI requests
From: Marc Zyngier @ 2026-03-03 13:04 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Steven Price, kvm, kvmarm, Catalin Marinas, Will Deacon,
James Morse, Oliver Upton, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve
In-Reply-To: <ec27e294-0bee-474a-a15b-6be20ee10cd4@arm.com>
On Tue, 03 Mar 2026 09:26:31 +0000,
Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>
> On 02/03/2026 16:39, Marc Zyngier wrote:
> > On Wed, 17 Dec 2025 10:11:04 +0000,
> > Steven Price <steven.price@arm.com> wrote:
> >>
> >> The RMM needs to be informed of the target REC when a PSCI call is made
> >> with an MPIDR argument. Expose an ioctl to the userspace in case the PSCI
> >> is handled by it.
> >>
> >> Co-developed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> >> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> >> Signed-off-by: Steven Price <steven.price@arm.com>
> >> Reviewed-by: Gavin Shan <gshan@redhat.com>
> >> ---
> >> Changes since v11:
> >> * RMM->RMI renaming.
> >> Changes since v6:
> >> * Use vcpu_is_rec() rather than kvm_is_realm(vcpu->kvm).
> >> * Minor renaming/formatting fixes.
> >> ---
> >> arch/arm64/include/asm/kvm_rmi.h | 3 +++
> >> arch/arm64/kvm/arm.c | 25 +++++++++++++++++++++++++
> >> arch/arm64/kvm/psci.c | 30 ++++++++++++++++++++++++++++++
> >> arch/arm64/kvm/rmi.c | 14 ++++++++++++++
> >> 4 files changed, 72 insertions(+)
> >>
> >> diff --git a/arch/arm64/include/asm/kvm_rmi.h b/arch/arm64/include/asm/kvm_rmi.h
> >> index bfe6428eaf16..77da297ca09d 100644
> >> --- a/arch/arm64/include/asm/kvm_rmi.h
> >> +++ b/arch/arm64/include/asm/kvm_rmi.h
> >> @@ -118,6 +118,9 @@ int realm_map_non_secure(struct realm *realm,
> >> kvm_pfn_t pfn,
> >> unsigned long size,
> >> struct kvm_mmu_memory_cache *memcache);
> >> +int realm_psci_complete(struct kvm_vcpu *source,
> >> + struct kvm_vcpu *target,
> >> + unsigned long status);
> >> static inline bool kvm_realm_is_private_address(struct realm
> >> *realm,
> >> unsigned long addr)
> >> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> >> index 06070bc47ee3..fb04d032504e 100644
> >> --- a/arch/arm64/kvm/arm.c
> >> +++ b/arch/arm64/kvm/arm.c
> >> @@ -1797,6 +1797,22 @@ static int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
> >> return __kvm_arm_vcpu_set_events(vcpu, events);
> >> }
> >> +static int kvm_arm_vcpu_rmi_psci_complete(struct kvm_vcpu *vcpu,
> >> + struct kvm_arm_rmi_psci_complete *arg)
> >> +{
> >> + struct kvm_vcpu *target = kvm_mpidr_to_vcpu(vcpu->kvm, arg->target_mpidr);
> >> +
> >> + if (!target)
> >> + return -EINVAL;
> >> +
> >> + /*
> >> + * RMM v1.0 only supports PSCI_RET_SUCCESS or PSCI_RET_DENIED
> >> + * for the status. But, let us leave it to the RMM to filter
> >> + * for making this future proof.
> >> + */
> >> + return realm_psci_complete(vcpu, target, arg->psci_status);
> >> +}
> >> +
> >> long kvm_arch_vcpu_ioctl(struct file *filp,
> >> unsigned int ioctl, unsigned long arg)
> >> {
> >> @@ -1925,6 +1941,15 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
> >> return kvm_arm_vcpu_finalize(vcpu, what);
> >> }
> >> + case KVM_ARM_VCPU_RMI_PSCI_COMPLETE: {
> >> + struct kvm_arm_rmi_psci_complete req;
> >> +
> >> + if (!vcpu_is_rec(vcpu))
> >> + return -EPERM;
> >
> > Same remark as for the other ioctl: EPERM is not quite describing the
> > problem.
> >
> >> + if (copy_from_user(&req, argp, sizeof(req)))
> >> + return -EFAULT;
> >> + return kvm_arm_vcpu_rmi_psci_complete(vcpu, &req);
> >> + }
> >> default:
> >> r = -EINVAL;
> >> }
> >> diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
> >> index 3b5dbe9a0a0e..a68f3c1878a5 100644
> >> --- a/arch/arm64/kvm/psci.c
> >> +++ b/arch/arm64/kvm/psci.c
> >> @@ -103,6 +103,12 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
> >> reset_state->reset = true;
> >> kvm_make_request(KVM_REQ_VCPU_RESET, vcpu);
> >> + /*
> >> + * Make sure we issue PSCI_COMPLETE before the VCPU can be
> >> + * scheduled.
> >> + */
> >> + if (vcpu_is_rec(vcpu))
> >> + realm_psci_complete(source_vcpu, vcpu, PSCI_RET_SUCCESS);
> >>
> >
> > I really think in-kernel PSCI should be for NS VMs only. The whole
> > reason for moving to userspace support was to stop adding features to
> > an already complex infrastructure, and CCA is exactly the sort of
> > things we want userspace to deal with.
>
> Agreed. How would you like us to enforce this ? Should we always exit
> to the VMM, even if it hasn't requested the handling ? (I guess it is
> fine and in the worst case VMM could exit, it being buggy)
My current train of though is that a CCA VM always routes PSCI to
userspace, no configuration needed. That's part of the contract.
Now, I'm pretty sure we should *also* get rid of the ioctl that
establishes the relationship between MPIDR and REC. I can't see why
this can't be done at the point where the vcpu runs for the first
time, just like this is done for the first CPU.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH kernel 4/9] dma/swiotlb: Stop forcing SWIOTLB for TDISP devices
From: Jason Gunthorpe @ 2026-03-03 12:43 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: <20260303001911.GA964116@ziepe.ca>
On Mon, Mar 02, 2026 at 08:19:11PM -0400, Jason Gunthorpe wrote:
> > Oh, I thought SEV-TIO had trouble with this, if this is indeed the case,
> > great, ignore my first comment.
>
> Alexey?
>
> I think it is really important that shared mappings continue to be
> reachable by TDISP device.
I think Alexey has clarified this in the other thread, and probably
AMD has some work to do here.
The issue is AMD does not have seperate address spaces for
shared/private like ARM does, instead it relies on a C bit in the *PTE*
to determine shared/private.
The S2 IOMMU page table *does* have the full mapping of all shared &
private pages but the HW requires a matching C bit to permit access.
If there is a S1 IOMMU then the IOPTEs of the VM can provide the C
bit, so no problem.
If there is no S1 then the sDTE of the hypervisor controls the C bit,
and it sounds like currently AMD sets this globally which effectively
locks TDISP RUN devices to *only* access private memory.
I suspect AMD needs to use their vTOM feature to allow shared memory
to remain available to TDISP RUN with a high/low address split.
Alexey, did I capture this properly?
Jason
^ permalink raw reply
* Re: [PATCH kernel 6/9] x86/dma-direct: Stop changing encrypted page state for TDISP devices
From: Jason Gunthorpe @ 2026-03-03 12:15 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, 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: <9cf2e2e6-0fe2-4804-9c62-bc60c89d57c1@amd.com>
On Tue, Mar 03, 2026 at 07:19:36PM +1100, Alexey Kardashevskiy wrote:
> > It seems from your email that the CPU S2 has the Cbit as part of the
> > address and the S1 feeds it through to the S2, so it is genuinely has
> > two addres spaces?
>
> S1/S2 PTEs have Cbit. Addresses to look up those PTEs - do not.
So we are back to what I was saying before: using phys_addr_t to
encode a PTE bit is probably a very confusing idea - especially when
contrasted with the other arches that have a legitimate address bit.
> > Same way it knows if there is no S1?
>
> If no S1 - then sDTE decides on Cbit for the entire ASID (with the help of vTOM).
Sounds like the intention was the IOMMU shared/private space would be
controlled with vTOM which actually does a create a legitimate address
bit in the phys_addr_t.
A sDTE global control is OK for non-TDISP devices, or even devices
that haven't entered RUN yet, but it is not OK for a TDISP device that
must still be able to access shared memory.
> I understand I am often confusing, trying to unconfuse (including myself)... Thanks,
It seems to me the AMD architecture itself is pretty confusing. :\
Jason
^ permalink raw reply
* Re: [PATCH v2 08/19] PCI/TSM: Add "evidence" support
From: Aneesh Kumar K.V @ 2026-03-03 10:16 UTC (permalink / raw)
To: Dan Williams, linux-coco, linux-pci
Cc: gregkh, aik, yilun.xu, bhelgaas, alistair23, lukas, jgg,
Donald Hunter, Jakub Kicinski
In-Reply-To: <20260303000207.1836586-9-dan.j.williams@intel.com>
Dan Williams <dan.j.williams@intel.com> writes:
> Once one accepts the threat model that devices may be adversarial the
> process of establishing trust in the device identity, the integrity +
> confidentiality of its link, and the integrity + confidentiality of its
> MMIO interface requires multiple evidence objects from the device. The
> device's certificate chain, measurements and interface report need to be
> retrieved by the host, validated by the TSM and transmitted to the guest
> all while mitigating TOCTOU races.
>
> All TSM implementations share the same fundamental objects, but vary in how
> the TSM conveys its trust in the objects. Some TSM implementations expect
> the full documents to be conveyed over untrustworthy channels while the TSM
> securely conveys a digest. Others transmit full objects with signed SPDM
> transcripts of requester provided nonces. Some offer a single transcript
> to convey the version, capabilities, and algorithms (VCA) data and
> measurements in one blob while others split VCA as a separate signed blob.
>
> Introduce a netlink interface to dump all these objects in a common way
> across TSM implementations and across host and guest environments.
> Userspace is responsible for handling the variance of "TSM provides combo
> measurements + VCA + nonce + signature, vs TSM provides a digest over a
> secure channel of the same".
>
> The implementation adheres to the guideline from:
> Documentation/userspace-api/netlink/genetlink-legacy.rst
>
> New Netlink families should never respond to a DO operation with
> multiple replies, with ``NLM_F_MULTI`` set. Use a filtered dump
> instead.
>
> Per SPDM, transcripts may grow to be 16MB in size. Large PCI/TSM netlink
> blobs are handled via a sequence of dump messages that userspace must
> concatenate.
>
> Cc: Donald Hunter <donald.hunter@gmail.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Xu Yilun <yilun.xu@linux.intel.com>
> Cc: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>
> Cc: Alexey Kardashevskiy <aik@amd.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> drivers/pci/Makefile | 2 +-
> drivers/pci/tsm/Makefile | 9 +
> Documentation/netlink/specs/pci-tsm.yaml | 151 +++++++++++++
> drivers/pci/tsm/netlink.h | 23 ++
> include/linux/pci-tsm.h | 63 ++++++
> include/uapi/linux/pci-tsm-netlink.h | 101 +++++++++
> drivers/pci/{tsm.c => tsm/core.c} | 17 +-
> drivers/pci/tsm/evidence.c | 274 +++++++++++++++++++++++
> drivers/pci/tsm/netlink.c | 43 ++++
> MAINTAINERS | 4 +-
> 10 files changed, 682 insertions(+), 5 deletions(-)
> create mode 100644 drivers/pci/tsm/Makefile
> create mode 100644 Documentation/netlink/specs/pci-tsm.yaml
> create mode 100644 drivers/pci/tsm/netlink.h
> create mode 100644 include/uapi/linux/pci-tsm-netlink.h
> rename drivers/pci/{tsm.c => tsm/core.c} (98%)
> create mode 100644 drivers/pci/tsm/evidence.c
> create mode 100644 drivers/pci/tsm/netlink.c
>
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index e10cfe5a280b..31f5095360af 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -35,7 +35,7 @@ obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o
> obj-$(CONFIG_VGA_ARB) += vgaarb.o
> obj-$(CONFIG_PCI_DOE) += doe.o
> obj-$(CONFIG_PCI_IDE) += ide.o
> -obj-$(CONFIG_PCI_TSM) += tsm.o
> +obj-$(CONFIG_PCI_TSM) += tsm/
> obj-$(CONFIG_PCI_DYNAMIC_OF_NODES) += of_property.o
> obj-$(CONFIG_PCI_NPEM) += npem.o
> obj-$(CONFIG_PCIE_TPH) += tph.o
> diff --git a/drivers/pci/tsm/Makefile b/drivers/pci/tsm/Makefile
> new file mode 100644
> index 000000000000..afa775224b8d
> --- /dev/null
> +++ b/drivers/pci/tsm/Makefile
> @@ -0,0 +1,9 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Makefile for the PCI/TSM infrastructure
> +
> +obj-$(CONFIG_PCI_TSM) += tsm.o
> +
> +tsm-y := core.o
> +tsm-$(CONFIG_NET) += netlink.o
> +tsm-$(CONFIG_NET) += evidence.o
> diff --git a/Documentation/netlink/specs/pci-tsm.yaml b/Documentation/netlink/specs/pci-tsm.yaml
> new file mode 100644
> index 000000000000..eb7fc03bd705
> --- /dev/null
> +++ b/Documentation/netlink/specs/pci-tsm.yaml
> @@ -0,0 +1,151 @@
> +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
> +#
> +---
> +name: pci-tsm
> +protocol: genetlink
> +uapi-header: linux/pci-tsm-netlink.h
> +doc: PCI TSM Evidence retrieval over generic netlink
> +
> +definitions:
> + -
> + type: const
> + name: max-object-size
> + value: 0x01000000
> + -
> + type: const
> + name: max-nonce-size
> + value: 256
> + -
> + type: const
> + name: max-obj-type
> + value: 4
> + -
> + name: evidence-type
> + type: enum
> + doc: PCI device security evidence objects
> + entries:
> + -
> + name: cert0
> + doc: SPDM certificate chain from device slot0
> + -
> + name: cert1
> + doc: SPDM certificate chain from device slot1
> + -
> + name: cert2
> + doc: SPDM certificate chain from device slot2
> + -
> + name: cert3
> + doc: SPDM certificate chain from device slot3
> + -
> + name: cert4
> + doc: SPDM certificate chain from device slot4
> + -
> + name: cert5
> + doc: SPDM certificate chain from device slot5
> + -
> + name: cert6
> + doc: SPDM certificate chain from device slot6
> + -
> + name: cert7
> + doc: SPDM certificate chain from device slot7
> + -
> + name: vca
> + doc: SPDM transcript of version, capabilities, and algorithms negotiation
> + -
> + name: measurements
> + doc: SPDM GET_MEASUREMENTS response
> + -
> + name: report
> + doc: TDISP GET_DEVICE_INTERFACE_REPORT response
> +
>
In the case of CCA, the slot number is determined early, when we create
the pdev object that maps to PF0. This is done as part of the connect
callback. Currently, the slot number is hardcoded to 0. I believe we
need to extend connect to include slot information.
Even with that change, we would only have one certificate type.
These would correspond to whichever slot number was selected during
connect.
-aneesh
^ permalink raw reply
* Re: [PATCH v12 27/46] KVM: arm64: Handle Realm PSCI requests
From: Suzuki K Poulose @ 2026-03-03 9:26 UTC (permalink / raw)
To: Marc Zyngier, Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve
In-Reply-To: <86pl5m89ub.wl-maz@kernel.org>
On 02/03/2026 16:39, Marc Zyngier wrote:
> On Wed, 17 Dec 2025 10:11:04 +0000,
> Steven Price <steven.price@arm.com> wrote:
>>
>> The RMM needs to be informed of the target REC when a PSCI call is made
>> with an MPIDR argument. Expose an ioctl to the userspace in case the PSCI
>> is handled by it.
>>
>> Co-developed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> Reviewed-by: Gavin Shan <gshan@redhat.com>
>> ---
>> Changes since v11:
>> * RMM->RMI renaming.
>> Changes since v6:
>> * Use vcpu_is_rec() rather than kvm_is_realm(vcpu->kvm).
>> * Minor renaming/formatting fixes.
>> ---
>> arch/arm64/include/asm/kvm_rmi.h | 3 +++
>> arch/arm64/kvm/arm.c | 25 +++++++++++++++++++++++++
>> arch/arm64/kvm/psci.c | 30 ++++++++++++++++++++++++++++++
>> arch/arm64/kvm/rmi.c | 14 ++++++++++++++
>> 4 files changed, 72 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/kvm_rmi.h b/arch/arm64/include/asm/kvm_rmi.h
>> index bfe6428eaf16..77da297ca09d 100644
>> --- a/arch/arm64/include/asm/kvm_rmi.h
>> +++ b/arch/arm64/include/asm/kvm_rmi.h
>> @@ -118,6 +118,9 @@ int realm_map_non_secure(struct realm *realm,
>> kvm_pfn_t pfn,
>> unsigned long size,
>> struct kvm_mmu_memory_cache *memcache);
>> +int realm_psci_complete(struct kvm_vcpu *source,
>> + struct kvm_vcpu *target,
>> + unsigned long status);
>>
>> static inline bool kvm_realm_is_private_address(struct realm *realm,
>> unsigned long addr)
>> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
>> index 06070bc47ee3..fb04d032504e 100644
>> --- a/arch/arm64/kvm/arm.c
>> +++ b/arch/arm64/kvm/arm.c
>> @@ -1797,6 +1797,22 @@ static int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
>> return __kvm_arm_vcpu_set_events(vcpu, events);
>> }
>>
>> +static int kvm_arm_vcpu_rmi_psci_complete(struct kvm_vcpu *vcpu,
>> + struct kvm_arm_rmi_psci_complete *arg)
>> +{
>> + struct kvm_vcpu *target = kvm_mpidr_to_vcpu(vcpu->kvm, arg->target_mpidr);
>> +
>> + if (!target)
>> + return -EINVAL;
>> +
>> + /*
>> + * RMM v1.0 only supports PSCI_RET_SUCCESS or PSCI_RET_DENIED
>> + * for the status. But, let us leave it to the RMM to filter
>> + * for making this future proof.
>> + */
>> + return realm_psci_complete(vcpu, target, arg->psci_status);
>> +}
>> +
>> long kvm_arch_vcpu_ioctl(struct file *filp,
>> unsigned int ioctl, unsigned long arg)
>> {
>> @@ -1925,6 +1941,15 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
>>
>> return kvm_arm_vcpu_finalize(vcpu, what);
>> }
>> + case KVM_ARM_VCPU_RMI_PSCI_COMPLETE: {
>> + struct kvm_arm_rmi_psci_complete req;
>> +
>> + if (!vcpu_is_rec(vcpu))
>> + return -EPERM;
>
> Same remark as for the other ioctl: EPERM is not quite describing the
> problem.
>
>> + if (copy_from_user(&req, argp, sizeof(req)))
>> + return -EFAULT;
>> + return kvm_arm_vcpu_rmi_psci_complete(vcpu, &req);
>> + }
>> default:
>> r = -EINVAL;
>> }
>> diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
>> index 3b5dbe9a0a0e..a68f3c1878a5 100644
>> --- a/arch/arm64/kvm/psci.c
>> +++ b/arch/arm64/kvm/psci.c
>> @@ -103,6 +103,12 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
>>
>> reset_state->reset = true;
>> kvm_make_request(KVM_REQ_VCPU_RESET, vcpu);
>> + /*
>> + * Make sure we issue PSCI_COMPLETE before the VCPU can be
>> + * scheduled.
>> + */
>> + if (vcpu_is_rec(vcpu))
>> + realm_psci_complete(source_vcpu, vcpu, PSCI_RET_SUCCESS);
>>
>
> I really think in-kernel PSCI should be for NS VMs only. The whole
> reason for moving to userspace support was to stop adding features to
> an already complex infrastructure, and CCA is exactly the sort of
> things we want userspace to deal with.
Agreed. How would you like us to enforce this ? Should we always exit
to the VMM, even if it hasn't requested the handling ? (I guess it is
fine and in the worst case VMM could exit, it being buggy)
Cheers
Suzuki
>
> Thanks,
>
> M.
>
^ permalink raw reply
* Re: [PATCH v2 00/19] PCI/TSM: TEE I/O infrastructure
From: Aneesh Kumar K.V @ 2026-03-03 9:23 UTC (permalink / raw)
To: Dan Williams, linux-coco, linux-pci
Cc: gregkh, aik, yilun.xu, bhelgaas, alistair23, lukas, jgg,
Andy Lutomirski, Arnd Bergmann, Borislav Petkov,
Christoph Hellwig, Danilo Krummrich, Dave Hansen, Donald Hunter,
H. Peter Anvin, Ingo Molnar, Jakub Kicinski, Jason Gunthorpe,
Luis Chamberlain, Marek Szyprowski, Peter Zijlstra,
Rafael J. Wysocki, Robin Murphy, Roman Kisel, Samuel Ortiz,
Saravana Kannan, Suzuki K Poulose, Thomas Gleixner,
Thomas Gleixner
In-Reply-To: <20260303000207.1836586-1-dan.j.williams@intel.com>
Dan Williams <dan.j.williams@intel.com> writes:
....
To support devices without IDE/DOE support we need something similar.
modified drivers/pci/tsm/core.c
@@ -1236,12 +1236,14 @@ int pci_tsm_pf0_constructor(struct pci_dev *pdev, struct pci_tsm_pf0 *tsm,
struct tsm_dev *tsm_dev)
{
mutex_init(&tsm->lock);
- tsm->doe_mb = pci_find_doe_mailbox(pdev, PCI_VENDOR_ID_PCI_SIG,
- PCI_DOE_FEATURE_CMA);
- if (!tsm->doe_mb) {
- pci_warn(pdev, "TSM init failure, no CMA mailbox\n");
- return -ENODEV;
- }
+
+ /*
+ * Note, low-level TSM driver responsible for determining if it wants to
+ * proceed with a device that has no DOE mailbox. TSM may have an
+ * alternate method for coordinating TDISP.
+ */
+ if (!tsm->doe_mb)
+ pci_dbg(pdev, "no CMA mailbox\n");
return pci_tsm_link_constructor(pdev, &tsm->base_tsm, tsm_dev);
}
^ permalink raw reply
* Re: [PATCH v2 10/19] x86, swiotlb: Teach swiotlb to skip "accepted" devices
From: Aneesh Kumar K.V @ 2026-03-03 9:07 UTC (permalink / raw)
To: Dan Williams, linux-coco, linux-pci
Cc: gregkh, aik, yilun.xu, bhelgaas, alistair23, lukas, jgg,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Marek Szyprowski, Robin Murphy
In-Reply-To: <20260303000207.1836586-11-dan.j.williams@intel.com>
Dan Williams <dan.j.williams@intel.com> writes:
> There are two mechanisms to force SWIOTLB operation, the kernel command
> line option and the internal SWIOTLB_FORCE flag. With the arrival of
> "accepted" devices, devices that have been enabled to DMA to private
> encrypted memory, the SWIOTLB_FORCE flag is an awkward fit. It may be the
> case that SWIOTLB operation wants to be forced regardless of the device
> acceptance state.
>
> Introduce a new SWIOTLB_UNACCPTED flag that allows for both augmenting the
> result of is_swiotlb_force_bounce() dynamically and allowing for an "always
> SWIOTLB" override.
>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: x86@kernel.org
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> include/linux/swiotlb.h | 15 ++++++++++++---
> arch/x86/kernel/pci-dma.c | 2 +-
> kernel/dma/swiotlb.c | 1 +
> 3 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> index 3dae0f592063..0efb9b8e5dd0 100644
> --- a/include/linux/swiotlb.h
> +++ b/include/linux/swiotlb.h
> @@ -17,6 +17,7 @@ struct scatterlist;
> #define SWIOTLB_VERBOSE (1 << 0) /* verbose initialization */
> #define SWIOTLB_FORCE (1 << 1) /* force bounce buffering */
> #define SWIOTLB_ANY (1 << 2) /* allow any memory for the buffer */
> +#define SWIOTLB_UNACCEPTED (1 << 3) /* swiotlb for unaccepted devices */
>
> /*
> * Maximum allowable number of contiguous slabs to map,
> @@ -91,6 +92,7 @@ struct io_tlb_pool {
> * @nslabs: Total number of IO TLB slabs in all pools.
> * @debugfs: The dentry to debugfs.
> * @force_bounce: %true if swiotlb bouncing is forced
> + * @bounce_unaccepted: %true if unaccepted devices must bounce
> * @for_alloc: %true if the pool is used for memory allocation
> * @can_grow: %true if more pools can be allocated dynamically.
> * @phys_limit: Maximum allowed physical address.
> @@ -109,8 +111,9 @@ struct io_tlb_mem {
> struct io_tlb_pool defpool;
> unsigned long nslabs;
> struct dentry *debugfs;
> - bool force_bounce;
> - bool for_alloc;
> + u8 force_bounce:1;
> + u8 bounce_unaccepted:1;
> + u8 for_alloc:1;
> #ifdef CONFIG_SWIOTLB_DYNAMIC
> bool can_grow;
> u64 phys_limit;
> @@ -173,7 +176,13 @@ static inline bool is_swiotlb_force_bounce(struct device *dev)
> {
> struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
>
> - return mem && mem->force_bounce;
> + if (!mem)
> + return false;
> + if (mem->force_bounce)
> + return true;
> + if (mem->bounce_unaccepted && !device_cc_accepted(dev))
> + return true;
> + return false;
> }
>
> void swiotlb_init(bool addressing_limited, unsigned int flags);
> diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> index 6267363e0189..8a737f501ae5 100644
> --- a/arch/x86/kernel/pci-dma.c
> +++ b/arch/x86/kernel/pci-dma.c
> @@ -61,7 +61,7 @@ static void __init pci_swiotlb_detect(void)
> */
> if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
> x86_swiotlb_enable = true;
> - x86_swiotlb_flags |= SWIOTLB_FORCE;
> + x86_swiotlb_flags |= SWIOTLB_UNACCEPTED;
> }
> }
> #else
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index a547c7693135..57e9647939fe 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -365,6 +365,7 @@ void __init swiotlb_init_remap(bool addressing_limit, unsigned int flags,
>
> io_tlb_default_mem.force_bounce =
> swiotlb_force_bounce || (flags & SWIOTLB_FORCE);
> + io_tlb_default_mem.bounce_unaccepted = flags & SWIOTLB_UNACCEPTED;
>
This should be.
@@ -373,7 +373,7 @@ void __init swiotlb_init_remap(bool addressing_limit, unsigned int flags,
io_tlb_default_mem.force_bounce =
swiotlb_force_bounce || (flags & SWIOTLB_FORCE);
- io_tlb_default_mem.bounce_unaccepted = flags & SWIOTLB_UNACCEPTED;
+ io_tlb_default_mem.bounce_unaccepted = !!(flags & SWIOTLB_UNACCEPTED);
>
> #ifdef CONFIG_SWIOTLB_DYNAMIC
> if (!remap)
> --
> 2.52.0
^ permalink raw reply
* Re: [PATCH kernel 6/9] x86/dma-direct: Stop changing encrypted page state for TDISP devices
From: Alexey Kardashevskiy @ 2026-03-03 8:19 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, 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: <20260302133527.GV44359@ziepe.ca>
On 3/3/26 00:35, Jason Gunthorpe wrote:
> On Mon, Mar 02, 2026 at 04:26:58PM +1100, Alexey Kardashevskiy wrote:
>
>>>> 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).
"no Cbit" here was "there is Cbit in PTe and it is 0", rather than "Cbit is an address bit".
>>> Is this "Cbit" part of the CPU S2 page table address space or is it
>>> actually some PTE bit that says it is "encrypted" ?
afaik it is always (while SNP is enabled) a PTE bit that says "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.
>
> Yes, I understand this.
>
> It seems from your email that the CPU S2 has the Cbit as part of the
> address and the S1 feeds it through to the S2, so it is genuinely has
> two addres spaces?
S1/S2 PTEs have Cbit. Addresses to look up those PTEs - do not.
(both are "addresses" - one in the PTE and another one - to look up the PTE)
> While the IOMMU S1 does not and instead needs a PTE bit which is
> emphatically not an address bit because it does not feed through the
> S2?
afaik IOMMU works the same.
>>> 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.
>
> Well, I think things work more sensibly if you don't have to mangle
> the address..
>
>>> 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.
>
> Same way it knows if there is no S1?
If no S1 - then sDTE decides on Cbit for the entire ASID (with the help of vTOM).
> Why does the S1 change anything?
S1 will have Cbit in individual PTEs, allowing per page control.
>>>> 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,
>
> Weird!!
:)
I understand I am often confusing, trying to unconfuse (including myself)... Thanks,
--
Alexey
^ permalink raw reply
* Re: [PATCH v2 11/19] x86, dma: Allow accepted devices to map private memory
From: Alexey Kardashevskiy @ 2026-03-03 7:36 UTC (permalink / raw)
To: Dan Williams, linux-coco, linux-pci
Cc: gregkh, aneesh.kumar, yilun.xu, bhelgaas, alistair23, lukas, jgg,
Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, x86, H. Peter Anvin
In-Reply-To: <20260303000207.1836586-12-dan.j.williams@intel.com>
On 3/3/26 11:01, Dan Williams wrote:
> With the arrival of "accepted" devices, devices that have been enabled to
> DMA to private encrypted memory, coherent DMA allocation no longer requires
> page conversion. Update force_dma_unencrypted() to skip accepted devices.
>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: x86@kernel.org
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Alexey Kardashevskiy <aik@amd.com>
> ---
> arch/x86/mm/mem_encrypt.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 95bae74fdab2..6d2972ff6ed8 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -20,10 +20,11 @@
> bool force_dma_unencrypted(struct device *dev)
> {
> /*
> - * For SEV, all DMA must be to unencrypted addresses.
> + * Require unencrypted DMA unless the device has been "accepted",
> + * enabled by a TSM driver to DMA to private encrypted memory.
> */
> if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
> - return true;
> + return !device_cc_accepted(dev);
>
> /*
> * For SME, all DMA must be to unencrypted addresses if the
--
Alexey
^ 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