* SVSM Development Call March 18, 2026
From: Jörg Rödel @ 2026-03-17 17:06 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: Lukas Wunner @ 2026-03-17 18:14 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Dan Williams, linux-coco, linux-pci, gregkh, aik, aneesh.kumar,
yilun.xu, bhelgaas, alistair23, jgg, Donald Hunter
In-Reply-To: <20260314111245.76d18d73@kernel.org>
On Sat, Mar 14, 2026 at 11:12:45AM -0700, Jakub Kicinski wrote:
> On Mon, 2 Mar 2026 16:01:56 -0800 Dan Williams wrote:
> > 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.
>
> My understanding of F_MULTI is that deserializer is supposed to
> continue deserializing into current object.
So is the "should" above meant to be understood in the RFC 2119 way,
i.e. as a mere recommendation?
The problem we're facing is that nlattr::nla_len is u16, so the maximum
size is 65531 bytes (65535 minus header). That's insufficient for
transmitting blobs that are several megabytes in size.
The obvious solution is to split the blobs into smaller chunks and
transmit each chunk in an attribute of the same type. The application
then concatenates them together to reconstruct the blob. For particularly
large blobs, it may even be necessary to split across multiple messages
by way of NLM_F_MULTI.
Apart from the attribute size limitation, there's the problem that copying
large blobs in memory is inefficient. Ideally we'd want zero-copy.
The solution I came up with is to attach the blob's pages as fragments
to the skb. Conceptually the fragments succeed the linear buffer of the
skb, so by putting the nlattr header into the linear buffer and attaching
the blob as fragments, the receiver consumes the netlink message in a
natural way. This patch introduces an nla_put_blob() helper which was
pretty straightforward:
https://github.com/l1k/linux/commit/af9b939fc30b
This patch is taking advantage of the helper:
https://github.com/l1k/linux/commit/009663bd172e
The only change I had to make is amending nlmsg_end() to take the
fragments into account when calculating the nlmsg_len.
The patch does achieve zero-copy on the sender's end. It may also
achieve zero-copy on the receiver's end if the receiver is in the
kernel. However it does *not* achieve zero-copy if the receiver is
in user space. That's because:
simple_copy_to_iter()
copy_to_iter()
_copy_to_iter()
copy_to_user_iter()
raw_copy_to_user()
... will just stupidly copy the data into the user space buffer.
It might be possible to achieve zero-copy in user space via io_uring.
At this point perhaps your conclusion is that netlink isn't the right
protocol for this job. It's great for transmitting sets of small items,
some of which may be optional, but it's obviously not well-suited for
large items.
Jason Gunthorpe was quite insistent that we use netlink and you know
how consensus-oriented kernel development is. Indeed sysfs has turned
out not to be ideal because the protocol that we're dealing with
(SPDM - DMTF DSP0274) allows many degrees of freedom and making
them available through sysfs quickly becomes unwieldy.
E.g. when installing a certificate onto a device, the protocol allows
specifying additional parameters (a keypair ID and a certificate model)
together with the certificate chain that shall be installed. That doesn't
square well with the "one value per file" sysfs model. User space would
have to write the keypair ID and certificate model to separate attributes,
then write the certificate chain to a third attribute. So the kernel would
need some kind of state machine to keep track of which sysfs attributes
have been written. It gets quite ugly.
As another example, the SPDM protocol allows retrieving measurements
from the device. The measurements are indexed by an 8-bit number.
To expose them via sysfs, the kernel would have to retrieve all of them
on device enumeration so that it knows which indices are populated
and need to be exposed in sysfs. That would incur a delay on device
enumeration and thus lead to slower boot times.
If netlink is at all the right protocol for the job, I'm wondering if an
extension for larger attributes would be entertained. Basically a
variation of struct nlattr, but with a 24-bit or 32-bit size and
maybe a list of fragment numbers. The latter would be useful to have
*multiple* zero-copy attributes because the patches linked above only
allow for a single zero-copy attribute per nlmsg.
Thanks,
Lukas
^ permalink raw reply
* Re: [PATCH v2 08/19] PCI/TSM: Add "evidence" support
From: Lukas Wunner @ 2026-03-17 18:24 UTC (permalink / raw)
To: Dan Williams
Cc: linux-coco, linux-pci, gregkh, aik, aneesh.kumar, yilun.xu,
bhelgaas, alistair23, jgg, Donald Hunter, Jakub Kicinski
In-Reply-To: <20260303000207.1836586-9-dan.j.williams@intel.com>
On Mon, Mar 02, 2026 at 04:01:56PM -0800, Dan Williams wrote:
> + type: const
> + name: max-nonce-size
> + value: 256
[...]
> +#define PCI_TSM_MAX_OBJECT_SIZE 16777216
> +#define PCI_TSM_MAX_NONCE_SIZE 256
> +#define PCI_TSM_MAX_OBJ_TYPE 4
Where is the maximum nonce size of 256 bytes coming from?
Such definitions should always be accompanied by a spec reference,
not pulled out of thin air.
SPDM nonces are 32 bytes, I assume that's what we're dealing with here?
This patch:
https://github.com/l1k/linux/commit/bca645e08ee9
... contains the following definition:
#define SPDM_NONCE_SZ 32 /* SPDM 1.0.0 table 20 */
Though it's defined in a private header in lib/spdm/spdm.h. If there's
a need outside of the SPDM library, its visibility can be broadened
of course.
Thanks,
Lukas
^ permalink raw reply
* Re: [PATCH 3/4] x86/virt/tdx: Add SEAMCALL wrapper for TDH.SYS.DISABLE
From: Edgecombe, Rick P @ 2026-03-17 21:55 UTC (permalink / raw)
To: kas@kernel.org
Cc: pbonzini@redhat.com, Hansen, Dave, seanjc@google.com,
bp@alien8.de, ackerleytng@google.com, hpa@zytor.com,
linux-kernel@vger.kernel.org, mingo@redhat.com, x86@kernel.org,
tglx@kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev,
Huang, Kai, Verma, Vishal L, Gao, Chao
In-Reply-To: <abkdNQnvgJWmaKWk@thinkstation>
On Tue, 2026-03-17 at 09:47 +0000, Kiryl Shutsemau wrote:
> We debated checking the feature bit before allowing kexec, but decided it was
> > simpler to just blindly call and ignore the errors. The reasoning was that this
> > is already a somewhat exotic scenario being addressed, and future modules will
> > have the feature. So maintaining a check for the feature bit only helps a little
> > bit, for a short time. And then only if the user would rather have kexec blocked
> > than attempt it. Do you think it is worth it?
>
> No, I see very limited reason to support stale TDX modules. Users are
> expected to keep the module up-to-date, so skipping enumeration should
> be okay. But it deserves explanation in the commit message or a comment.
Ok.
>
> > >
> > > Silently ignore any other errors?
> >
> > Do you think it's worth a warn? There are a couple other considerations.
> > - Kai brought up offline that we should handle TDX_SYS_BUSY here too.
> > - Previous kexec patches had trouble solving races around tdx enabling. So we
> > have to handle the seamcall failures.
> >
> > So we have to exclude a few different errors in different ways. And then the
> > warn worthy error codes either don't impact anything, or the new kernel will
> > fail to initialize the TDX module and give notice there.
>
> The delayed error is harder to debug. It can be useful to leave a
> breadcrumbs.
Ok, we can parse the errors.
>
> Also, do we want to make try_init_module_global() return failure after
> tdx_sys_disable()? I guess, TDH_SYS_LP_INIT will fail anyway, so it
> shouldn't matter.
Yea, a side effect of TDH.SYS.DISABLE is that it blocks other seamcalls while it
is executing. I guess the scenario here is TDX init racing with kexec.
But in general if TDX is disabled while any TDX stuff is running, the seamcalls
will be surprised. This is not fully related to TDH.SYS.DISABLE, because VMXOFF
will also cause similar SEAMCALL failures. Each SEAMCALL path would need to
handle the rug pull. And probably we need to balance harmless noise against the
code it takes to be quieter.
try_init_module_global() is different in that it's kernel side code that gets
confused, but I'm not sure how it could be handled in a non-racy way either.
So... I'd think to leave it. Maybe what we really need is a big block comment
about TDX enable/disable lifecycle quirks.
^ permalink raw reply
* Re: [PATCH v5 06/22] coco/tdx-host: Expose P-SEAMLDR information via sysfs
From: Chao Gao @ 2026-03-18 6:54 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: x86, linux-coco, kvm, linux-kernel, binbin.wu, dan.j.williams,
dave.hansen, ira.weiny, kai.huang, nik.borisov, paulmck, pbonzini,
reinette.chatre, rick.p.edgecombe, sagis, seanjc, tony.lindgren,
vannapurve, vishal.l.verma, yilun.xu
In-Reply-To: <abkmceqUtMTnLI0V@thinkstation>
>> +
>> +What: /sys/devices/faux/tdx_host/seamldr/version
>> +Contact: linux-coco@lists.linux.dev
>> +Description: (RO) Report the version of the loaded SEAM loader. The SEAM
>> + loader version is formatted as x.y.z, where "x" is the major
>> + version, "y" is the minor version and "z" is the update version.
>> + Versions are used for bug reporting and compatibility checks.
>> +
>> +What: /sys/devices/faux/tdx_host/seamldr/num_remaining_updates
>> +Contact: linux-coco@lists.linux.dev
>> +Description: (RO) Report the number of remaining updates. TDX maintains a
>> + log about each TDX module that has been loaded. This log has
>> + a finite size, which limits the number of TDX module updates
>> + that can be performed.
>> +
>> + After each successful update, the number reduces by one. Once it
>> + reaches zero, further updates will fail until next reboot. The
>> + number is always zero if the P-SEAMLDR doesn't support updates.
>> +
>> + See Intel® Trust Domain Extensions - SEAM Loader (SEAMLDR)
>> + Interface Specification, Revision 343755-003, Chapter 3.3
>> + "SEAMLDR_INFO" and Chapter 4.2 "SEAMLDR.INSTALL" for more
>> + information.
>
>Do you think revision and chapter numbers useful here?
I think it's nice-to-have. Without specific references, people would need to
read the entire 26-page spec. But I can drop them if they make it too verbose.
^ permalink raw reply
* Re: [PATCH v5 04/22] x86/virt/seamldr: Introduce a wrapper for P-SEAMLDR SEAMCALLs
From: Xiaoyao Li @ 2026-03-18 7:13 UTC (permalink / raw)
To: Chao Gao, linux-kernel, linux-coco, kvm
Cc: binbin.wu, dan.j.williams, dave.hansen, ira.weiny, kai.huang, kas,
nik.borisov, paulmck, pbonzini, reinette.chatre, rick.p.edgecombe,
sagis, seanjc, tony.lindgren, vannapurve, vishal.l.verma,
yilun.xu, Farrah Chen, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, x86, H. Peter Anvin
In-Reply-To: <20260315135920.354657-5-chao.gao@intel.com>
On 3/15/2026 9:58 PM, Chao Gao wrote:
> The TDX architecture uses the "SEAMCALL" instruction to communicate with
> SEAM mode software. Right now, the only SEAM mode software that the kernel
> communicates with is the TDX module. But, there is actually another
> component that runs in SEAM mode but it is separate from the TDX module:
> the persistent SEAM loader or "P-SEAMLDR". Right now, the only component
> that communicates with it is the BIOS which loads the TDX module itself at
> boot. But, to support updating the TDX module, the kernel now needs to be
> able to talk to it.
>
> P-SEAMLDR SEAMCALLs differ from TDX module SEAMCALLs in areas such as
> concurrency requirements. Add a P-SEAMLDR wrapper to handle these
> differences and prepare for implementing concrete functions.
>
> Note that unlike P-SEAMLDR, there is also a non-persistent SEAM loader
> ("NP-SEAMLDR"). This is an authenticated code module (ACM) that is not
> callable at runtime. Only BIOS launches it to load P-SEAMLDR at boot;
> the kernel does not need to interact with it for runtime update.
>
> For details of P-SEAMLDR SEAMCALLs, see Intel® Trust Domain CPU
> Architectural Extensions, Revision 343754-002, Chapter 2.3 "INSTRUCTION
> SET REFERENCE".
SDM started to contain SEAMCALL definitions. How about just dropping
this paragraph to avoid people from reading the old doc?
...
> +static __maybe_unused int seamldr_call(u64 fn, struct tdx_module_args *args)
> +{
> + guard(raw_spinlock)(&seamldr_lock);
> + return seamcall_prerr(fn, args);
How about adding the reason of why choosing seamcall_prerr() instead of
seamcall_prerr_ret() in the changelog?
^ permalink raw reply
* Re: [PATCH v2 08/19] PCI/TSM: Add "evidence" support
From: Dan Williams @ 2026-03-18 7:22 UTC (permalink / raw)
To: Lukas Wunner, Dan Williams
Cc: linux-coco, linux-pci, gregkh, aik, aneesh.kumar, yilun.xu,
bhelgaas, alistair23, jgg, Donald Hunter, Jakub Kicinski
In-Reply-To: <ablhfHEIsz5IPW14@wunner.de>
Lukas Wunner wrote:
> On Mon, Mar 16, 2026 at 04:02:22PM -0700, Dan Williams wrote:
> > Dan Williams wrote:
> > > Lukas Wunner wrote:
> > > > This doesn't look like it's ever been tested, so at the very least
> > > > it should be marked RFC in the subject to convey that it's not yet
> > > > in a cut-and-dried state.
> > >
> > > The 16MB limit has indeed not been tested, the test script in this set
> > > was using smaller than 64K payloads to check out the interface.
> >
> > So 16MB works ok, slow, but works. A given attribute in this
> > implementation never exceeds the limit
>
> Famous last words.
I am not convinced you have found the "gotcha" you think you have...
> If you look at netlink_dump(), it sizes the skb based on
> nlk->max_recvmsg_len. If that's larger than 64k, you'll
> try to fill as much as possible of that space with a single
> netlink attribute. The computation of "available" in your
> patch doesn't take the 65531 bytes limit for a netlink attribute
> into account so it looks like you'll end up overflowing the length
> of the netlink attribute.
The @len to nla_put() should not overflow because it is based on the
available tailroom in the skb minus netlink overhead. The "inventive"
hack that Jakub is reacting to is that this scheme requires a receiver
that assumes repeating the attribute in the receive stream must be
handled as concatenation.
> Unfortunately nla_put() doesn't prevent such overflows, it does
> all the size calculations with an int, not a u16.
Are we looking at the same capacity calculation?
len = min(available - overhead, object_len - ctx->offset);
^ permalink raw reply
* Re: [PATCH v2 08/19] PCI/TSM: Add "evidence" support
From: Dan Williams @ 2026-03-18 7:41 UTC (permalink / raw)
To: Lukas Wunner, Dan Williams
Cc: linux-coco, linux-pci, gregkh, aik, aneesh.kumar, yilun.xu,
bhelgaas, alistair23, jgg, Donald Hunter, Jakub Kicinski
In-Reply-To: <abmcWIgaAyw66h5J@wunner.de>
Lukas Wunner wrote:
> On Mon, Mar 02, 2026 at 04:01:56PM -0800, Dan Williams wrote:
> > + type: const
> > + name: max-nonce-size
> > + value: 256
> [...]
> > +#define PCI_TSM_MAX_OBJECT_SIZE 16777216
> > +#define PCI_TSM_MAX_NONCE_SIZE 256
> > +#define PCI_TSM_MAX_OBJ_TYPE 4
>
> Where is the maximum nonce size of 256 bytes coming from?
I took it from Aneesh's off-list RFC, and meant to circle back with him.
Yes, it should come with a spec reference.
I am having trouble finding a clear reference for ARM CCA that clarifies
that measurement recollection takes the SPDM standard nonce as an input.
Perhaps the document I have "DEN0137 1.1-alp8" is out of date? TDX and
SEV-TIO do reference SPDM for the nonce size.
> Such definitions should always be accompanied by a spec reference,
> not pulled out of thin air.
Yes.
> SPDM nonces are 32 bytes, I assume that's what we're dealing with here?
>
> This patch:
> https://github.com/l1k/linux/commit/bca645e08ee9
>
> ... contains the following definition:
> #define SPDM_NONCE_SZ 32 /* SPDM 1.0.0 table 20 */
>
> Though it's defined in a private header in lib/spdm/spdm.h. If there's
> a need outside of the SPDM library, its visibility can be broadened
> of course.
Of course. Again this points to a need to pull this proposal out
separate from the rest.
The ARM CCA spec does reference the EAT nonce which is 64-bytes. So it
may be the case that PCI_TSM_MAX_NONCE_SIZE != SPDM_NONCE_SZ depending
on what evidence can be collected over this interface, but I am not
finding any spec references for 256, Aneesh?
^ permalink raw reply
* Re: [PATCH v5 05/22] x86/virt/seamldr: Retrieve P-SEAMLDR information
From: Xiaoyao Li @ 2026-03-18 7:53 UTC (permalink / raw)
To: Chao Gao, linux-kernel, linux-coco, kvm
Cc: binbin.wu, dan.j.williams, dave.hansen, ira.weiny, kai.huang, kas,
nik.borisov, paulmck, pbonzini, reinette.chatre, rick.p.edgecombe,
sagis, seanjc, tony.lindgren, vannapurve, vishal.l.verma,
yilun.xu, Farrah Chen, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, x86, H. Peter Anvin
In-Reply-To: <20260315135920.354657-6-chao.gao@intel.com>
On 3/15/2026 9:58 PM, Chao Gao wrote:
> P-SEAMLDR returns its information such as version number, in response to
> the SEAMLDR.INFO SEAMCALL.
>
> This information is useful for userspace. For example, the admin can decide
> which TDX module versions are compatible with the P-SEAMLDR according to
> the P-SEAMLDR version.
>
> Retrieve P-SEAMLDR information in preparation for exposing P-SEAMLDR
This patch only implements the function but nowhere calls it. Please
adjust the wording and the PATCH subject.
...
> +
> +/*
> + * This is called the "SEAMLDR_INFO" data structure and is defined
I'm curious why you changed "This called" to "This is called" in this
v5. In v4[1] you just used what Dave provided to v3[2]
[1] https://lore.kernel.org/kvm/20260212143606.534586-6-chao.gao@intel.com/
[2]
https://lore.kernel.org/all/b2e2fd5e-8aff-4eda-a648-9ae9f8234d25@intel.com/
^ permalink raw reply
* Re: [PATCH v2 08/19] PCI/TSM: Add "evidence" support
From: Dan Williams @ 2026-03-18 7:56 UTC (permalink / raw)
To: Lukas Wunner, Jakub Kicinski
Cc: Dan Williams, linux-coco, linux-pci, gregkh, aik, aneesh.kumar,
yilun.xu, bhelgaas, alistair23, jgg, Donald Hunter
In-Reply-To: <abmaG0jC7b05Lytz@wunner.de>
Lukas Wunner wrote:
[..]
> At this point perhaps your conclusion is that netlink isn't the right
> protocol for this job. It's great for transmitting sets of small items,
> some of which may be optional, but it's obviously not well-suited for
> large items.
Right, and sysfs is not well suited for transaction in/out semantics.
> Jason Gunthorpe was quite insistent that we use netlink and you know
Jason can of course correct me, but the insistence was less that netlink
was the right tool for the job, and more that sysfs was the wrong tool
for the job.
Netlink appears to be the least worst option.
> how consensus-oriented kernel development is. Indeed sysfs has turned
> out not to be ideal because the protocol that we're dealing with
> (SPDM - DMTF DSP0274) allows many degrees of freedom and making
> them available through sysfs quickly becomes unwieldy.
[..]
> If netlink is at all the right protocol for the job, I'm wondering if an
> extension for larger attributes would be entertained.
It is still not clear to me that allowing larger attributes are part of
the solution space. They seem to be a premature performance optimization
once userspace is prepared to reassemble a large blob over multiple
messages.
^ permalink raw reply
* Re: [PATCH v5 06/22] coco/tdx-host: Expose P-SEAMLDR information via sysfs
From: Xiaoyao Li @ 2026-03-18 8:20 UTC (permalink / raw)
To: Chao Gao, Kiryl Shutsemau
Cc: x86, linux-coco, kvm, linux-kernel, binbin.wu, dan.j.williams,
dave.hansen, ira.weiny, kai.huang, nik.borisov, paulmck, pbonzini,
reinette.chatre, rick.p.edgecombe, sagis, seanjc, tony.lindgren,
vannapurve, vishal.l.verma, yilun.xu
In-Reply-To: <abpMHxwhYqbmrX8s@intel.com>
On 3/18/2026 2:54 PM, Chao Gao wrote:
>>> +
>>> +What: /sys/devices/faux/tdx_host/seamldr/version
>>> +Contact: linux-coco@lists.linux.dev
>>> +Description: (RO) Report the version of the loaded SEAM loader. The SEAM
>>> + loader version is formatted as x.y.z, where "x" is the major
>>> + version, "y" is the minor version and "z" is the update version.
>>> + Versions are used for bug reporting and compatibility checks.
>>> +
>>> +What: /sys/devices/faux/tdx_host/seamldr/num_remaining_updates
>>> +Contact: linux-coco@lists.linux.dev
>>> +Description: (RO) Report the number of remaining updates. TDX maintains a
>>> + log about each TDX module that has been loaded. This log has
>>> + a finite size, which limits the number of TDX module updates
>>> + that can be performed.
>>> +
>>> + After each successful update, the number reduces by one. Once it
>>> + reaches zero, further updates will fail until next reboot. The
>>> + number is always zero if the P-SEAMLDR doesn't support updates.
>>> +
>>> + See Intel® Trust Domain Extensions - SEAM Loader (SEAMLDR)
>>> + Interface Specification, Revision 343755-003, Chapter 3.3
>>> + "SEAMLDR_INFO" and Chapter 4.2 "SEAMLDR.INSTALL" for more
>>> + information.
>>
>> Do you think revision and chapter numbers useful here?
>
> I think it's nice-to-have. Without specific references, people would need to
> read the entire 26-page spec. But I can drop them if they make it too verbose.
I have some concerns about the "revision". The good thing is that it can
tell what the attribute was built against while the bad thing is that it
might not be easy for people to find an old revision years later.
^ permalink raw reply
* Re: [PATCH v5 07/22] coco/tdx-host: Implement firmware upload sysfs ABI for TDX module updates
From: Chao Gao @ 2026-03-18 8:28 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-kernel, linux-coco, kvm, binbin.wu, dan.j.williams,
dave.hansen, ira.weiny, kai.huang, nik.borisov, paulmck, pbonzini,
reinette.chatre, rick.p.edgecombe, sagis, seanjc, tony.lindgren,
vannapurve, vishal.l.verma, yilun.xu, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, x86, H. Peter Anvin
In-Reply-To: <abko0v2bYxNJtegT@thinkstation>
>> Signed-off-by: Chao Gao <chao.gao@intel.com>
>> Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
>
>Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Thanks a lot for your reviews.
<snip>
>> static int seamldr_init(struct device *dev)
>> {
>> + const struct tdx_sys_info *tdx_sysinfo = tdx_get_sysinfo();
>> + struct fw_upload *tdx_fwl;
>> + int ret;
>> +
>> + if (WARN_ON_ONCE(!tdx_sysinfo))
>> + return -EIO;
>> +
>> + if (!tdx_supports_runtime_update(tdx_sysinfo))
>> + return 0;
>
>Hm. Do we still want to register seamldr_group for this case?
seamldr_group currently serves only module updates, so registering it when
updates aren't supported seems unnecessary.
>
>Maybe move it up before the check?
If new use cases emerge and need seamldr version etc, we can do the
changes.
FWIW, seamldr_group visibility does matter in one case: it must be
hidden on CPUs with an erratum (see
https://lore.kernel.org/kvm/20260315135920.354657-19-chao.gao@intel.com/)
^ permalink raw reply
* Re: [PATCH v5 08/22] x86/virt/seamldr: Allocate and populate a module update request
From: Chao Gao @ 2026-03-18 8:50 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-kernel, linux-coco, kvm, binbin.wu, dan.j.williams,
dave.hansen, ira.weiny, kai.huang, nik.borisov, paulmck, pbonzini,
reinette.chatre, rick.p.edgecombe, sagis, seanjc, tony.lindgren,
vannapurve, vishal.l.verma, yilun.xu, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, x86, H. Peter Anvin
In-Reply-To: <abkvOYQIi2RvEYh8@thinkstation>
>> + ptr = sig;
>> + for (i = 0; i < sig_size / SZ_4K; i++) {
>> + /*
>> + * Don't assume @sig is page-aligned although it is 4KB-aligned.
>> + * Always add the in-page offset to get the physical address.
>> + */
>
>I don't follow this. If @sig is 4k aligned in VA, it is page aligned.
Dan's concern was that PAGE_SIZE is not guaranteed to be 4096.
I agree that PAGE_SIZE is 4K on x86 today. But to address that concern, I saw
two options:
1. Add WARN_ON_ONCE(PAGE_SIZE != SZ_4K), or
2. Handle it as in the code above.
I didn't find existing code using option 1 in x86, so I chose option 2.
>
>If you want to handle case when @sig is not 4k aligned, than this is
>broken. You need to bump ptr to the next 4k boundary, not by 4k.
@sig is 4KB aligned.
<snip>
>> +static struct seamldr_params *init_seamldr_params(const u8 *data, u32 size)
>> +{
>> + const struct tdx_blob *blob = (const void *)data;
>> + int module_size, sig_size;
>> + const void *sig, *module;
>> +
>> + /* Ensure the size is valid otherwise reading any field from the blob may overflow. */
>> + if (size <= sizeof(struct tdx_blob) || size <= blob->offset_of_module)
>> + return ERR_PTR(-EINVAL);
>> +
>> + if (blob->version != TDX_BLOB_VERSION_1) {
>> + pr_err("unsupported blob version: %x\n", blob->version);
>> + return ERR_PTR(-EINVAL);
>> + }
>> +
>> + /* Split the blob into a sigstruct and a module. */
>> + sig = blob->data;
>> + sig_size = blob->offset_of_module - sizeof(struct tdx_blob);
>> + module = data + blob->offset_of_module;
>> + module_size = size - blob->offset_of_module;
>> +
>> + if (sig_size <= 0 || module_size <= 0 || blob->length != size)
>> + return ERR_PTR(-EINVAL);
>
>Maybe add a comment somewhere that block->offset_of_module is relative
>to start of struct tdx_blob, not blob->data and blob->length includes
>length of struct tdx_blob.
>
>It can be either way and it is better to give a reader a hint.
Sure. Will do.
^ permalink raw reply
* Re: [PATCH v5 05/22] x86/virt/seamldr: Retrieve P-SEAMLDR information
From: Chao Gao @ 2026-03-18 8:57 UTC (permalink / raw)
To: Xiaoyao Li
Cc: linux-kernel, linux-coco, kvm, binbin.wu, dan.j.williams,
dave.hansen, ira.weiny, kai.huang, kas, nik.borisov, paulmck,
pbonzini, reinette.chatre, rick.p.edgecombe, sagis, seanjc,
tony.lindgren, vannapurve, vishal.l.verma, yilun.xu, Farrah Chen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86,
H. Peter Anvin
In-Reply-To: <0f5fe0ba-1699-4762-90b0-60fd8bb9c869@intel.com>
On Wed, Mar 18, 2026 at 03:53:26PM +0800, Xiaoyao Li wrote:
>On 3/15/2026 9:58 PM, Chao Gao wrote:
>> P-SEAMLDR returns its information such as version number, in response to
>> the SEAMLDR.INFO SEAMCALL.
>>
>> This information is useful for userspace. For example, the admin can decide
>> which TDX module versions are compatible with the P-SEAMLDR according to
>> the P-SEAMLDR version.
>>
>> Retrieve P-SEAMLDR information in preparation for exposing P-SEAMLDR
>
>This patch only implements the function but nowhere calls it. Please adjust
>the wording and the PATCH subject.
How about:
Add a helper to retrieve ...?
>
>...
>
>> +
>> +/*
>> + * This is called the "SEAMLDR_INFO" data structure and is defined
>
>I'm curious why you changed "This called" to "This is called" in this v5. In
>v4[1] you just used what Dave provided to v3[2]
I ran the patches through Copilot before posting, and it flagged "This called"
as a typo, so I fixed it.
>
>[1] https://lore.kernel.org/kvm/20260212143606.534586-6-chao.gao@intel.com/
>[2]
>https://lore.kernel.org/all/b2e2fd5e-8aff-4eda-a648-9ae9f8234d25@intel.com/
^ permalink raw reply
* Re: [PATCH v5 06/22] coco/tdx-host: Expose P-SEAMLDR information via sysfs
From: Chao Gao @ 2026-03-18 9:10 UTC (permalink / raw)
To: Xiaoyao Li
Cc: Kiryl Shutsemau, x86, linux-coco, kvm, linux-kernel, binbin.wu,
dan.j.williams, dave.hansen, ira.weiny, kai.huang, nik.borisov,
paulmck, pbonzini, reinette.chatre, rick.p.edgecombe, sagis,
seanjc, tony.lindgren, vannapurve, vishal.l.verma, yilun.xu
In-Reply-To: <3614e6fb-bdad-4e59-9769-5dc9869e03bf@intel.com>
On Wed, Mar 18, 2026 at 04:20:54PM +0800, Xiaoyao Li wrote:
>On 3/18/2026 2:54 PM, Chao Gao wrote:
>> > > +
>> > > +What: /sys/devices/faux/tdx_host/seamldr/version
>> > > +Contact: linux-coco@lists.linux.dev
>> > > +Description: (RO) Report the version of the loaded SEAM loader. The SEAM
>> > > + loader version is formatted as x.y.z, where "x" is the major
>> > > + version, "y" is the minor version and "z" is the update version.
>> > > + Versions are used for bug reporting and compatibility checks.
>> > > +
>> > > +What: /sys/devices/faux/tdx_host/seamldr/num_remaining_updates
>> > > +Contact: linux-coco@lists.linux.dev
>> > > +Description: (RO) Report the number of remaining updates. TDX maintains a
>> > > + log about each TDX module that has been loaded. This log has
>> > > + a finite size, which limits the number of TDX module updates
>> > > + that can be performed.
>> > > +
>> > > + After each successful update, the number reduces by one. Once it
>> > > + reaches zero, further updates will fail until next reboot. The
>> > > + number is always zero if the P-SEAMLDR doesn't support updates.
>> > > +
>> > > + See Intel® Trust Domain Extensions - SEAM Loader (SEAMLDR)
>> > > + Interface Specification, Revision 343755-003, Chapter 3.3
>> > > + "SEAMLDR_INFO" and Chapter 4.2 "SEAMLDR.INSTALL" for more
>> > > + information.
>> >
>> > Do you think revision and chapter numbers useful here?
>>
>> I think it's nice-to-have. Without specific references, people would need to
>> read the entire 26-page spec. But I can drop them if they make it too verbose.
>
>I have some concerns about the "revision". The good thing is that it can tell
>what the attribute was built against while the bad thing is that it might not
>be easy for people to find an old revision years later.
I'm okay with dropping the revision number.
The intent is not to require readers to find the exact same revision. If they
can find that exact revision, great. If not, the chapter numbers may differ
in newer revisions.
Kirill, do you mean dropping the numbers but keeping the chapter titles:
See Intel® Trust Domain Extensions - SEAM Loader (SEAMLDR)
Interface Specification, Chapter "SEAMLDR_INFO" and Chapter
"SEAMLDR.INSTALL" for more information.
This keeps a targeted reference so readers do not need to scan the entire spec.
^ permalink raw reply
* Re: [PATCH v5 06/22] coco/tdx-host: Expose P-SEAMLDR information via sysfs
From: Kiryl Shutsemau @ 2026-03-18 9:28 UTC (permalink / raw)
To: Chao Gao
Cc: Xiaoyao Li, x86, linux-coco, kvm, linux-kernel, binbin.wu,
dan.j.williams, dave.hansen, ira.weiny, kai.huang, nik.borisov,
paulmck, pbonzini, reinette.chatre, rick.p.edgecombe, sagis,
seanjc, tony.lindgren, vannapurve, vishal.l.verma, yilun.xu
In-Reply-To: <abpr/Sg3QXfDd1Q+@intel.com>
On Wed, Mar 18, 2026 at 05:10:21PM +0800, Chao Gao wrote:
> On Wed, Mar 18, 2026 at 04:20:54PM +0800, Xiaoyao Li wrote:
> >On 3/18/2026 2:54 PM, Chao Gao wrote:
> >> > > +
> >> > > +What: /sys/devices/faux/tdx_host/seamldr/version
> >> > > +Contact: linux-coco@lists.linux.dev
> >> > > +Description: (RO) Report the version of the loaded SEAM loader. The SEAM
> >> > > + loader version is formatted as x.y.z, where "x" is the major
> >> > > + version, "y" is the minor version and "z" is the update version.
> >> > > + Versions are used for bug reporting and compatibility checks.
> >> > > +
> >> > > +What: /sys/devices/faux/tdx_host/seamldr/num_remaining_updates
> >> > > +Contact: linux-coco@lists.linux.dev
> >> > > +Description: (RO) Report the number of remaining updates. TDX maintains a
> >> > > + log about each TDX module that has been loaded. This log has
> >> > > + a finite size, which limits the number of TDX module updates
> >> > > + that can be performed.
> >> > > +
> >> > > + After each successful update, the number reduces by one. Once it
> >> > > + reaches zero, further updates will fail until next reboot. The
> >> > > + number is always zero if the P-SEAMLDR doesn't support updates.
> >> > > +
> >> > > + See Intel® Trust Domain Extensions - SEAM Loader (SEAMLDR)
> >> > > + Interface Specification, Revision 343755-003, Chapter 3.3
> >> > > + "SEAMLDR_INFO" and Chapter 4.2 "SEAMLDR.INSTALL" for more
> >> > > + information.
> >> >
> >> > Do you think revision and chapter numbers useful here?
> >>
> >> I think it's nice-to-have. Without specific references, people would need to
> >> read the entire 26-page spec. But I can drop them if they make it too verbose.
> >
> >I have some concerns about the "revision". The good thing is that it can tell
> >what the attribute was built against while the bad thing is that it might not
> >be easy for people to find an old revision years later.
>
> I'm okay with dropping the revision number.
>
> The intent is not to require readers to find the exact same revision. If they
> can find that exact revision, great. If not, the chapter numbers may differ
> in newer revisions.
>
> Kirill, do you mean dropping the numbers but keeping the chapter titles:
>
> See Intel® Trust Domain Extensions - SEAM Loader (SEAMLDR)
> Interface Specification, Chapter "SEAMLDR_INFO" and Chapter
> "SEAMLDR.INSTALL" for more information.
>
> This keeps a targeted reference so readers do not need to scan the entire spec.
Yeah, looks good to me.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v5 04/22] x86/virt/seamldr: Introduce a wrapper for P-SEAMLDR SEAMCALLs
From: Chao Gao @ 2026-03-18 9:34 UTC (permalink / raw)
To: Xiaoyao Li
Cc: linux-kernel, linux-coco, kvm, binbin.wu, dan.j.williams,
dave.hansen, ira.weiny, kai.huang, kas, nik.borisov, paulmck,
pbonzini, reinette.chatre, rick.p.edgecombe, sagis, seanjc,
tony.lindgren, vannapurve, vishal.l.verma, yilun.xu, Farrah Chen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86,
H. Peter Anvin
In-Reply-To: <935081ba-9f66-4bdf-a408-c19be32c6ad3@intel.com>
On Wed, Mar 18, 2026 at 03:13:06PM +0800, Xiaoyao Li wrote:
>On 3/15/2026 9:58 PM, Chao Gao wrote:
>> The TDX architecture uses the "SEAMCALL" instruction to communicate with
>> SEAM mode software. Right now, the only SEAM mode software that the kernel
>> communicates with is the TDX module. But, there is actually another
>> component that runs in SEAM mode but it is separate from the TDX module:
>> the persistent SEAM loader or "P-SEAMLDR". Right now, the only component
>> that communicates with it is the BIOS which loads the TDX module itself at
>> boot. But, to support updating the TDX module, the kernel now needs to be
>> able to talk to it.
>>
>> P-SEAMLDR SEAMCALLs differ from TDX module SEAMCALLs in areas such as
>> concurrency requirements. Add a P-SEAMLDR wrapper to handle these
>> differences and prepare for implementing concrete functions.
>>
>> Note that unlike P-SEAMLDR, there is also a non-persistent SEAM loader
>> ("NP-SEAMLDR"). This is an authenticated code module (ACM) that is not
>> callable at runtime. Only BIOS launches it to load P-SEAMLDR at boot;
>> the kernel does not need to interact with it for runtime update.
>>
>> For details of P-SEAMLDR SEAMCALLs, see Intel® Trust Domain CPU
>> Architectural Extensions, Revision 343754-002, Chapter 2.3 "INSTRUCTION
>> SET REFERENCE".
>
>SDM started to contain SEAMCALL definitions. How about just dropping this
>paragraph to avoid people from reading the old doc?
I didn't realize that. Thanks for the information.
But I don't think this is a stale reference. The SDM description is high-level
and points to the same spec for details:
The details of such transitions are specified in the Intel® Trust Domain CPU
Architectural Extensions.
>
>...
>
>> +static __maybe_unused int seamldr_call(u64 fn, struct tdx_module_args *args)
>> +{
>> + guard(raw_spinlock)(&seamldr_lock);
>> + return seamcall_prerr(fn, args);
>
>How about adding the reason of why choosing seamcall_prerr() instead of
>seamcall_prerr_ret() in the changelog?
Sure. Will add:
Use seamcall_prerr() (not '_ret') because current P-SEAMLDR calls do not use
any output registers other than RAX.
^ permalink raw reply
* [Invitation] bi-weekly guest_memfd upstream call on 2026-03-19
From: David Hildenbrand (Arm) @ 2026-03-18 10:50 UTC (permalink / raw)
To: linux-coco@lists.linux.dev, linux-mm@kvack.org, KVM
Hi,
Our next guest_memfd upstream call is scheduled for tomorrow, Thursday,
2026-03-19 at 8:00 - 9:00am (GMT-07:00) Pacific Time - Vancouver.
!!! Note the GMT-08:00 -> GMT-07:00 change due to DST in the US :) !!!
We'll be using the following Google meet:
http://meet.google.com/wxp-wtju-jzw
The meeting notes can be found at [1], where we also link recordings and
collect current guest_memfd upstream proposals. If you want an google
calendar invitation that also covers all future meetings, just write me
or Ackerley a mail.
In this meeting, we'll talk about the in-place conversion series and ABI
implications ... and I'm sure other things will come up (pKVM update? :) ).
To put something to discuss onto the agenda, reply to this mail or add
them to the "Topics/questions for next meeting(s)" section in the
meeting notes as a comment.
[1]
https://docs.google.com/document/d/1M6766BzdY1Lhk7LiR5IqVR8B8mG3cr-cxTxOrAosPOk/edit?usp=sharing
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v5 08/22] x86/virt/seamldr: Allocate and populate a module update request
From: Kiryl Shutsemau @ 2026-03-18 10:58 UTC (permalink / raw)
To: Chao Gao
Cc: linux-kernel, linux-coco, kvm, binbin.wu, dan.j.williams,
dave.hansen, ira.weiny, kai.huang, nik.borisov, paulmck, pbonzini,
reinette.chatre, rick.p.edgecombe, sagis, seanjc, tony.lindgren,
vannapurve, vishal.l.verma, yilun.xu, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, x86, H. Peter Anvin
In-Reply-To: <abpnWkENgaWoofZV@intel.com>
On Wed, Mar 18, 2026 at 04:50:34PM +0800, Chao Gao wrote:
> >> + ptr = sig;
> >> + for (i = 0; i < sig_size / SZ_4K; i++) {
> >> + /*
> >> + * Don't assume @sig is page-aligned although it is 4KB-aligned.
> >> + * Always add the in-page offset to get the physical address.
> >> + */
> >
> >I don't follow this. If @sig is 4k aligned in VA, it is page aligned.
>
> Dan's concern was that PAGE_SIZE is not guaranteed to be 4096.
>
> I agree that PAGE_SIZE is 4K on x86 today. But to address that concern, I saw
> two options:
>
> 1. Add WARN_ON_ONCE(PAGE_SIZE != SZ_4K), or
> 2. Handle it as in the code above.
>
> I didn't find existing code using option 1 in x86, so I chose option 2.
Please, make it clear in the comment that you are talking about PAGE_SIZE != SZ_4K.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v2 3/7] x86/sev: add support for RMPOPT instruction
From: Dave Hansen @ 2026-03-18 14:00 UTC (permalink / raw)
To: Kalra, Ashish, Sean Christopherson
Cc: tglx, mingo, bp, dave.hansen, x86, hpa, peterz, thomas.lendacky,
herbert, davem, ardb, pbonzini, aik, Michael.Roth, KPrateek.Nayak,
Tycho.Andersen, Nathan.Fontenot, jackyli, pgonda, rientjes,
jacobhxu, xin, pawan.kumar.gupta, babu.moger, dyoung, nikunj,
john.allen, darwi, linux-kernel, linux-crypto, kvm, linux-coco
In-Reply-To: <cdedb126-777a-4e40-a5a5-93aa5dbc38aa@amd.com>
Thanks for the additional performance numbers!
On 3/16/26 12:03, Kalra, Ashish wrote:
> Again, looking at the numbers above, what are your suggestions for
>
> 1). using the kthread approach OR
I don't like the kthread approach. The kernel has a billion features. If
each one gets a kthread or kthread-per-$SOMETHING, we'll spend all of
our RAM on kthread task_structs and stacks.
> 2). probably scheduling it for later execution after SNP guest termination via a workqueue OR
I think there are two different issues:
1. What asynchronous kernel mechanism is used to execute the RMPOPT?
2. How does that mechanism get triggered?
For #1, I think schedule_work() is the place to start. You need more
justification on why it needs a dedicated kthread.
For #2, I say just schedule some delayed work on every SEV-SNP
private=>shared conversion to do RMPOPT. Schedule it out 1 second or 10
seconds or _something_. If work is scheduled and you convert another
page, cancel it and push it out another 1 or 10 seconds.
> 3). use some additional data structure like a bitmap to track 1G pages in guest_memfd
> to do the RMP re-optimizations.
That's an optimization that can be added later.
Whatever you do, it's going to need trigger points and asynchronous
work. There will always be ways to get the work amount down, but the
worst case will always be there.
^ permalink raw reply
* [PATCH v13 00/48] arm64: Support for Arm CCA in KVM
From: Steven Price @ 2026-03-18 15:53 UTC (permalink / raw)
To: kvm, kvmarm
Cc: Steven Price, Catalin Marinas, Marc Zyngier, 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
This series adds support for running protected VMs using KVM under the
Arm Confidential Compute Architecture (CCA).
New major version number! This now targets RMM v2.0-bet0[1]. And unlike
for Linux this represents a significant change.
RMM v2.0 brings with it the ability to configure the RMM to have the
same page size as the host (so no more RMM_PAGE_SIZE and dealing with
granules being different from host pages). It also introduces range
based APIs for many operations which should be more efficient and
simplifies the code in places.
The handling of the GIC has changed, so the system registers are used to
pass the GIC state rather than memory. This means fewer changes to the
KVM code as it looks much like a normal VM in this respect.
And of course the new uAPI introduced in the previous v12 posting is
retained so that also remains simplified compared to earlier postings.
The RMM support for v2.0 is still early and so this series includes a
few hacks to ease the integration. Of note are that there are some RMM
v1.0 SMCs added to paper over areas where the RMM implementation isn't
quite ready for v2.0, and "SROs" (see below) are deferred to the final
patch in the series.
The PMU in RMM v2.0 requires more handling on the RMM-side (and
therefore simplifies the implementation on Linux), but this isn't quite
ready yet. The Linux side is implemented (but untested).
PSCI still requires the VMM to provide the "target" REC for operations
that affect another vCPU. This is likely to change in a future version
of the specification. There's also a desire to force PSCI to be handled
in the VMM for realm guests - this isn't implemented yet as I'm waiting
for the dust to settle on the RMM interface first.
Stateful RMI Operations
-----------------------
The RMM v2.0 spec brings a new concept of Stateful RMI Operations (SROs)
which allow the RMM to complete an operation over several SMC calls and
requesting/returning memory to the host. This has the benefit of
allowing interrupts to be handled in the middle of an operation (by
returning to the host to handle the interrupt without completing the
operation) and enables the RMM to dynamically allocate memory for
internal tracking purposes. One example of this is RMI_REC_CREATE no
longer needs "auxiliary granules" provided upfront but can request the
memory needed during the RMI_REC_CREATE operation.
There are a fairly large number of operations that are defined as SROs
in the specification, but current both Linux and RMM only have support
for RMI_REC_CREATE and RMI_REC_DESTROY. There a number of TODOs/FIXMEs
in the code where support is missing.
Given the early stage support for this, the SRO handling is all confined
to the final patch. This patch can be dropped to return to a pre-SRO
state (albeit a mixture of RMM v1.0 and v2.0 APIs) for testing purposes.
A future posting will reorder the series to move the generic SRO support
to an early patch and will implement the proper support for this in all
RMI SMCs.
One aspect of SROs which is not yet well captured is that in some
circumstances the Linux kernel will need to call an SRO call in a
context where memory allocation is restricted (e.g. because a spinlock
is held). In this case the intention is that the SRO will be cancelled,
the spinlock dropped so the memory allocation can be completed, and then
the SRO restarted (obviously after rechecking the state that the
spinlock was protecting). For this reason the code stores the memory
allocations within a struct rmi_sro_state object - see the final patch
for more details.
This series is based on v7.0-rc1. It is also available as a git
repository:
https://gitlab.arm.com/linux-arm/linux-cca cca-host/v13
Work in progress changes for kvmtool are available from the git
repository below:
https://gitlab.arm.com/linux-arm/kvmtool-cca cca/v11
Note that the kvmtool code has been tidied up (thanks to Suzuki) and
this involves a minor change in flags. The "--restricted_mem" flag is no
longer recognised (or necessary).
The TF-RMM has not yet merged the RMMv2.0 support, so you will need to
use the following branch:
https://git.trustedfirmware.org/TF-RMM/tf-rmm.git topics/rmm-v2.0-poc
[1] https://developer.arm.com/documentation/den0137/2-0bet0/
Jean-Philippe Brucker (7):
arm64: RMI: Propagate number of breakpoints and watchpoints to
userspace
arm64: RMI: Set breakpoint parameters through SET_ONE_REG
arm64: RMI: Initialize PMCR.N with number counter supported by RMM
arm64: RMI: Propagate max SVE vector length from RMM
arm64: RMI: Configure max SVE vector length for a Realm
arm64: RMI: Provide register list for unfinalized RMI RECs
arm64: RMI: Provide accurate register list
Joey Gouly (2):
arm64: RMI: allow userspace to inject aborts
arm64: RMI: support RSI_HOST_CALL
Steven Price (36):
kvm: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h
arm64: RME: Handle Granule Protection Faults (GPFs)
arm64: RMI: Add SMC definitions for calling the RMM
arm64: RMI: Temporarily add SMCs from RMM v1.0 spec
arm64: RMI: Add wrappers for RMI calls
arm64: RMI: Check for RMI support at KVM init
arm64: RMI: Configure the RMM with the host's page size
arm64: RMI: Check for LPA2 support
arm64: RMI: Ensure that the RMM has GPT entries for memory
arm64: RMI: Define the user ABI
arm64: RMI: Basic infrastructure for creating a realm.
KVM: arm64: Allow passing machine type in KVM creation
arm64: RMI: RTT tear down
arm64: RMI: Activate realm on first VCPU run
arm64: RMI: Allocate/free RECs to match vCPUs
arm64: RMI: Support for the VGIC in realms
KVM: arm64: Support timers in realm RECs
arm64: RMI: Handle realm enter/exit
arm64: RMI: Handle RMI_EXIT_RIPAS_CHANGE
KVM: arm64: Handle realm MMIO emulation
KVM: arm64: Expose support for private memory
arm64: RMI: Allow populating initial contents
arm64: RMI: Set RIPAS of initial memslots
arm64: RMI: Create the realm descriptor
arm64: RMI: Runtime faulting of memory
KVM: arm64: Handle realm VCPU load
KVM: arm64: Validate register access for a Realm VM
KVM: arm64: Handle Realm PSCI requests
KVM: arm64: WARN on injected undef exceptions
arm64: Don't expose stolen time for realm guests
arm64: RMI: Always use 4k pages for realms
arm64: RMI: Prevent Device mappings for Realms
arm64: RMI: Enable PMU support with a realm guest
KVM: arm64: Expose KVM_ARM_VCPU_REC to user space
arm64: RMI: Enable realms to be created
[WIP] arm64: RMI: Add support for SRO
Suzuki K Poulose (3):
kvm: arm64: Include kvm_emulate.h in kvm/arm_psci.h
kvm: arm64: Don't expose unsupported capabilities for realm guests
arm64: RMI: Allow checking SVE on VM instance
Documentation/virt/kvm/api.rst | 86 +-
arch/arm64/include/asm/kvm_emulate.h | 31 +
arch/arm64/include/asm/kvm_host.h | 15 +-
arch/arm64/include/asm/kvm_pgtable.h | 5 +-
arch/arm64/include/asm/kvm_pkvm.h | 2 +-
arch/arm64/include/asm/kvm_rmi.h | 129 ++
arch/arm64/include/asm/rmi_cmds.h | 692 +++++++++
arch/arm64/include/asm/rmi_smc.h | 430 ++++++
arch/arm64/include/asm/virt.h | 1 +
arch/arm64/kernel/cpufeature.c | 1 +
arch/arm64/kvm/Kconfig | 2 +
arch/arm64/kvm/Makefile | 2 +-
arch/arm64/kvm/arch_timer.c | 28 +-
arch/arm64/kvm/arm.c | 178 ++-
arch/arm64/kvm/guest.c | 95 +-
arch/arm64/kvm/hyp/pgtable.c | 1 +
arch/arm64/kvm/hypercalls.c | 4 +-
arch/arm64/kvm/inject_fault.c | 5 +-
arch/arm64/kvm/mmio.c | 16 +-
arch/arm64/kvm/mmu.c | 214 ++-
arch/arm64/kvm/pmu-emul.c | 6 +
arch/arm64/kvm/psci.c | 30 +
arch/arm64/kvm/reset.c | 13 +-
arch/arm64/kvm/rmi-exit.c | 207 +++
arch/arm64/kvm/rmi.c | 1948 ++++++++++++++++++++++++++
arch/arm64/kvm/sys_regs.c | 53 +-
arch/arm64/kvm/vgic/vgic-init.c | 2 +-
arch/arm64/mm/fault.c | 28 +-
include/kvm/arm_arch_timer.h | 2 +
include/kvm/arm_pmu.h | 4 +
include/kvm/arm_psci.h | 2 +
include/uapi/linux/kvm.h | 41 +-
32 files changed, 4176 insertions(+), 97 deletions(-)
create mode 100644 arch/arm64/include/asm/kvm_rmi.h
create mode 100644 arch/arm64/include/asm/rmi_cmds.h
create mode 100644 arch/arm64/include/asm/rmi_smc.h
create mode 100644 arch/arm64/kvm/rmi-exit.c
create mode 100644 arch/arm64/kvm/rmi.c
--
2.43.0
^ permalink raw reply
* [PATCH v13 01/48] kvm: arm64: Include kvm_emulate.h in kvm/arm_psci.h
From: Steven Price @ 2026-03-18 15:53 UTC (permalink / raw)
To: kvm, kvmarm
Cc: Suzuki K Poulose, Catalin Marinas, Marc Zyngier, 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, Steven Price
In-Reply-To: <20260318155413.793430-1-steven.price@arm.com>
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Fix a potential build error (like below, when asm/kvm_emulate.h gets
included after the kvm/arm_psci.h) by including the missing header file
in kvm/arm_psci.h:
./include/kvm/arm_psci.h: In function ‘kvm_psci_version’:
./include/kvm/arm_psci.h:29:13: error: implicit declaration of function
‘vcpu_has_feature’; did you mean ‘cpu_have_feature’? [-Werror=implicit-function-declaration]
29 | if (vcpu_has_feature(vcpu, KVM_ARM_VCPU_PSCI_0_2)) {
| ^~~~~~~~~~~~~~~~
| cpu_have_feature
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Steven Price <steven.price@arm.com>
---
include/kvm/arm_psci.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/kvm/arm_psci.h b/include/kvm/arm_psci.h
index cbaec804eb83..38dab7add79b 100644
--- a/include/kvm/arm_psci.h
+++ b/include/kvm/arm_psci.h
@@ -10,6 +10,8 @@
#include <linux/kvm_host.h>
#include <uapi/linux/psci.h>
+#include <asm/kvm_emulate.h>
+
#define KVM_ARM_PSCI_0_1 PSCI_VERSION(0, 1)
#define KVM_ARM_PSCI_0_2 PSCI_VERSION(0, 2)
#define KVM_ARM_PSCI_1_0 PSCI_VERSION(1, 0)
--
2.43.0
^ permalink raw reply related
* [PATCH v13 02/48] kvm: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h
From: Steven Price @ 2026-03-18 15:53 UTC (permalink / raw)
To: kvm, kvmarm
Cc: Steven Price, Catalin Marinas, Marc Zyngier, 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: <20260318155413.793430-1-steven.price@arm.com>
To avoid future include cycles, drop the linux/kvm_host.h include in
kvm_pgtable.h and include two _types.h headers for the types that are
actually used. Additionally provide a forward declaration for struct
kvm_s2_mmu as it's only used as a pointer in this file.
Both pgtable.c and kvm_pkvm.h relied on the indirect inclusion of
kvm_host.h, so make that explicit.
Signed-off-by: Steven Price <steven.price@arm.com>
---
New patch in v13
---
arch/arm64/include/asm/kvm_pgtable.h | 5 ++++-
arch/arm64/include/asm/kvm_pkvm.h | 2 +-
arch/arm64/kvm/hyp/pgtable.c | 1 +
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
index c201168f2857..f3fe85cebdf1 100644
--- a/arch/arm64/include/asm/kvm_pgtable.h
+++ b/arch/arm64/include/asm/kvm_pgtable.h
@@ -8,9 +8,12 @@
#define __ARM64_KVM_PGTABLE_H__
#include <linux/bits.h>
-#include <linux/kvm_host.h>
+#include <linux/kvm_types.h>
+#include <linux/rbtree_types.h>
#include <linux/types.h>
+struct kvm_s2_mmu;
+
#define KVM_PGTABLE_FIRST_LEVEL -1
#define KVM_PGTABLE_LAST_LEVEL 3
diff --git a/arch/arm64/include/asm/kvm_pkvm.h b/arch/arm64/include/asm/kvm_pkvm.h
index 757076ad4ec9..3a2480e269e6 100644
--- a/arch/arm64/include/asm/kvm_pkvm.h
+++ b/arch/arm64/include/asm/kvm_pkvm.h
@@ -9,7 +9,7 @@
#include <linux/arm_ffa.h>
#include <linux/memblock.h>
#include <linux/scatterlist.h>
-#include <asm/kvm_host.h>
+#include <linux/kvm_host.h>
#include <asm/kvm_pgtable.h>
/* Maximum number of VMs that can co-exist under pKVM. */
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 0e4ddd28ef5d..e2a3a52b163e 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -8,6 +8,7 @@
*/
#include <linux/bitfield.h>
+#include <linux/kvm_host.h>
#include <asm/kvm_pgtable.h>
#include <asm/stage2_pgtable.h>
--
2.43.0
^ permalink raw reply related
* [PATCH v13 03/48] arm64: RME: Handle Granule Protection Faults (GPFs)
From: Steven Price @ 2026-03-18 15:53 UTC (permalink / raw)
To: kvm, kvmarm
Cc: Steven Price, Catalin Marinas, Marc Zyngier, 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: <20260318155413.793430-1-steven.price@arm.com>
If the host attempts to access granules that have been delegated for use
in a realm these accesses will be caught and will trigger a Granule
Protection Fault (GPF).
A fault during a page walk signals a bug in the kernel and is handled by
oopsing the kernel. A non-page walk fault could be caused by user space
having access to a page which has been delegated to the kernel and will
trigger a SIGBUS to allow debugging why user space is trying to access a
delegated page.
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Steven Price <steven.price@arm.com>
---
Changes since v10:
* Don't call arm64_notify_die() in do_gpf() but simply return 1.
Changes since v2:
* Include missing "Granule Protection Fault at level -1"
---
arch/arm64/mm/fault.c | 28 ++++++++++++++++++++++------
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index be9dab2c7d6a..13b1d5de6d77 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -858,6 +858,22 @@ static int do_tag_check_fault(unsigned long far, unsigned long esr,
return 0;
}
+static int do_gpf_ptw(unsigned long far, unsigned long esr, struct pt_regs *regs)
+{
+ const struct fault_info *inf = esr_to_fault_info(esr);
+
+ die_kernel_fault(inf->name, far, esr, regs);
+ return 0;
+}
+
+static int do_gpf(unsigned long far, unsigned long esr, struct pt_regs *regs)
+{
+ if (!is_el1_instruction_abort(esr) && fixup_exception(regs, esr))
+ return 0;
+
+ return 1;
+}
+
static const struct fault_info fault_info[] = {
{ do_bad, SIGKILL, SI_KERNEL, "ttbr address size fault" },
{ do_bad, SIGKILL, SI_KERNEL, "level 1 address size fault" },
@@ -894,12 +910,12 @@ static const struct fault_info fault_info[] = {
{ do_bad, SIGKILL, SI_KERNEL, "unknown 32" },
{ do_alignment_fault, SIGBUS, BUS_ADRALN, "alignment fault" },
{ do_bad, SIGKILL, SI_KERNEL, "unknown 34" },
- { do_bad, SIGKILL, SI_KERNEL, "unknown 35" },
- { do_bad, SIGKILL, SI_KERNEL, "unknown 36" },
- { do_bad, SIGKILL, SI_KERNEL, "unknown 37" },
- { do_bad, SIGKILL, SI_KERNEL, "unknown 38" },
- { do_bad, SIGKILL, SI_KERNEL, "unknown 39" },
- { do_bad, SIGKILL, SI_KERNEL, "unknown 40" },
+ { do_gpf_ptw, SIGKILL, SI_KERNEL, "Granule Protection Fault at level -1" },
+ { do_gpf_ptw, SIGKILL, SI_KERNEL, "Granule Protection Fault at level 0" },
+ { do_gpf_ptw, SIGKILL, SI_KERNEL, "Granule Protection Fault at level 1" },
+ { do_gpf_ptw, SIGKILL, SI_KERNEL, "Granule Protection Fault at level 2" },
+ { do_gpf_ptw, SIGKILL, SI_KERNEL, "Granule Protection Fault at level 3" },
+ { do_gpf, SIGBUS, SI_KERNEL, "Granule Protection Fault not on table walk" },
{ do_bad, SIGKILL, SI_KERNEL, "level -1 address size fault" },
{ do_bad, SIGKILL, SI_KERNEL, "unknown 42" },
{ do_translation_fault, SIGSEGV, SEGV_MAPERR, "level -1 translation fault" },
--
2.43.0
^ permalink raw reply related
* [PATCH v13 04/48] arm64: RMI: Add SMC definitions for calling the RMM
From: Steven Price @ 2026-03-18 15:53 UTC (permalink / raw)
To: kvm, kvmarm
Cc: Steven Price, Catalin Marinas, Marc Zyngier, 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: <20260318155413.793430-1-steven.price@arm.com>
The RMM (Realm Management Monitor) provides functionality that can be
accessed by SMC calls from the host.
The SMC definitions are based on DEN0137[1] version 2.0-bet0
[1] https://developer.arm.com/documentation/den0137/2-0bet0/
Signed-off-by: Steven Price <steven.price@arm.com>
---
Changes since v12:
* Updated to RMM spec v2.0-bet0
Changes since v9:
* Corrected size of 'ripas_value' in struct rec_exit. The spec states
this is an 8-bit type with padding afterwards (rather than a u64).
Changes since v8:
* Added RMI_PERMITTED_GICV3_HCR_BITS to define which bits the RMM
permits to be modified.
Changes since v6:
* Renamed REC_ENTER_xxx defines to include 'FLAG' to make it obvious
these are flag values.
Changes since v5:
* Sorted the SMC #defines by value.
* Renamed SMI_RxI_CALL to SMI_RMI_CALL since the macro is only used for
RMI calls.
* Renamed REC_GIC_NUM_LRS to REC_MAX_GIC_NUM_LRS since the actual
number of available list registers could be lower.
* Provided a define for the reserved fields of FeatureRegister0.
* Fix inconsistent names for padding fields.
Changes since v4:
* Update to point to final released RMM spec.
* Minor rearrangements.
Changes since v3:
* Update to match RMM spec v1.0-rel0-rc1.
Changes since v2:
* Fix specification link.
* Rename rec_entry->rec_enter to match spec.
* Fix size of pmu_ovf_status to match spec.
---
arch/arm64/include/asm/rmi_smc.h | 432 +++++++++++++++++++++++++++++++
1 file changed, 432 insertions(+)
create mode 100644 arch/arm64/include/asm/rmi_smc.h
diff --git a/arch/arm64/include/asm/rmi_smc.h b/arch/arm64/include/asm/rmi_smc.h
new file mode 100644
index 000000000000..8a42b83218f8
--- /dev/null
+++ b/arch/arm64/include/asm/rmi_smc.h
@@ -0,0 +1,432 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2023-2024 ARM Ltd.
+ *
+ * The values and structures in this file are from the Realm Management Monitor
+ * specification (DEN0137) version 1.0-rel0:
+ * https://developer.arm.com/documentation/den0137/1-0rel0/
+ */
+
+#ifndef __ASM_RMI_SMC_H
+#define __ASM_RMI_SMC_H
+
+#include <linux/arm-smccc.h>
+
+#define SMC_RMI_CALL(func) \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_STANDARD, \
+ (func))
+
+#define SMC_RMI_VERSION SMC_RMI_CALL(0x0150)
+
+#define SMC_RMI_RTT_DATA_MAP_INIT SMC_RMI_CALL(0x0153)
+
+#define SMC_RMI_REALM_ACTIVATE SMC_RMI_CALL(0x0157)
+#define SMC_RMI_REALM_CREATE SMC_RMI_CALL(0x0158)
+#define SMC_RMI_REALM_DESTROY SMC_RMI_CALL(0x0159)
+#define SMC_RMI_REC_CREATE SMC_RMI_CALL(0x015a)
+#define SMC_RMI_REC_DESTROY SMC_RMI_CALL(0x015b)
+#define SMC_RMI_REC_ENTER SMC_RMI_CALL(0x015c)
+#define SMC_RMI_RTT_CREATE SMC_RMI_CALL(0x015d)
+#define SMC_RMI_RTT_DESTROY SMC_RMI_CALL(0x015e)
+
+#define SMC_RMI_RTT_READ_ENTRY SMC_RMI_CALL(0x0161)
+
+#define SMC_RMI_RTT_DEV_VALIDATE SMC_RMI_CALL(0x0163)
+#define SMC_RMI_PSCI_COMPLETE SMC_RMI_CALL(0x0164)
+#define SMC_RMI_FEATURES SMC_RMI_CALL(0x0165)
+#define SMC_RMI_RTT_FOLD SMC_RMI_CALL(0x0166)
+
+#define SMC_RMI_RTT_INIT_RIPAS SMC_RMI_CALL(0x0168)
+#define SMC_RMI_RTT_SET_RIPAS SMC_RMI_CALL(0x0169)
+#define SMC_RMI_VSMMU_CREATE SMC_RMI_CALL(0x016a)
+#define SMC_RMI_VSMMU_DESTROY SMC_RMI_CALL(0x016b)
+#define SMC_RMI_RMM_CONFIG_SET SMC_RMI_CALL(0x016e)
+#define SMC_RMI_PSMMU_IRQ_NOTIFY SMC_RMI_CALL(0x016f)
+#define SMC_RMI_ATTEST_PLAT_TOKEN_REFRESH SMC_RMI_CALL(0x0170)
+
+#define SMC_RMI_PDEV_ABORT SMC_RMI_CALL(0x0174)
+#define SMC_RMI_PDEV_COMMUNICATE SMC_RMI_CALL(0x0175)
+#define SMC_RMI_PDEV_CREATE SMC_RMI_CALL(0x0176)
+#define SMC_RMI_PDEV_DESTROY SMC_RMI_CALL(0x0177)
+#define SMC_RMI_PDEV_GET_STATE SMC_RMI_CALL(0x0178)
+
+#define SMC_RMI_PDEV_STREAM_KEY_REFRESH SMC_RMI_CALL(0x017a)
+#define SMC_RMI_PDEV_SET_PUBKEY SMC_RMI_CALL(0x017b)
+#define SMC_RMI_PDEV_STOP SMC_RMI_CALL(0x017c)
+#define SMC_RMI_RTT_AUX_CREATE SMC_RMI_CALL(0x017d)
+#define SMC_RMI_RTT_AUX_DESTROY SMC_RMI_CALL(0x017e)
+#define SMC_RMI_RTT_AUX_FOLD SMC_RMI_CALL(0x017f)
+
+#define SMC_RMI_VDEV_ABORT SMC_RMI_CALL(0x0185)
+#define SMC_RMI_VDEV_COMMUNICATE SMC_RMI_CALL(0x0186)
+#define SMC_RMI_VDEV_CREATE SMC_RMI_CALL(0x0187)
+#define SMC_RMI_VDEV_DESTROY SMC_RMI_CALL(0x0188)
+#define SMC_RMI_VDEV_GET_STATE SMC_RMI_CALL(0x0189)
+#define SMC_RMI_VDEV_UNLOCK SMC_RMI_CALL(0x018a)
+#define SMC_RMI_RTT_SET_S2AP SMC_RMI_CALL(0x018b)
+#define SMC_RMI_VDEV_COMPLETE SMC_RMI_CALL(0x018e)
+
+#define SMC_RMI_VDEV_GET_INTERFACE_REPORT SMC_RMI_CALL(0x01d0)
+#define SMC_RMI_VDEV_GET_MEASUREMENTS SMC_RMI_CALL(0x01d1)
+#define SMC_RMI_VDEV_LOCK SMC_RMI_CALL(0x01d2)
+#define SMC_RMI_VDEV_START SMC_RMI_CALL(0x01d3)
+#define SMC_RMI_VDEV_P2P_BIND SMC_RMI_CALL(0x01d4)
+#define SMC_RMI_VDEV_P2P_UNBIND SMC_RMI_CALL(0x01d5)
+#define SMC_RMI_VSMMU_EVENT_NOTIFY SMC_RMI_CALL(0x01d6)
+#define SMC_RMI_PSMMU_ACTIVATE SMC_RMI_CALL(0x01d7)
+#define SMC_RMI_PSMMU_DEACTIVATE SMC_RMI_CALL(0x01d8)
+
+#define SMC_RMI_PSMMU_ST_L2_CREATE SMC_RMI_CALL(0x01db)
+#define SMC_RMI_PSMMU_ST_L2_DESTROY SMC_RMI_CALL(0x01dc)
+#define SMC_RMI_DPT_L0_CREATE SMC_RMI_CALL(0x01dd)
+#define SMC_RMI_DPT_L0_DESTROY SMC_RMI_CALL(0x01de)
+#define SMC_RMI_DPT_L1_CREATE SMC_RMI_CALL(0x01df)
+#define SMC_RMI_DPT_L1_DESTROY SMC_RMI_CALL(0x01e0)
+#define SMC_RMI_GRANULE_TRACKING_GET SMC_RMI_CALL(0x01e1)
+
+#define SMC_RMI_GRANULE_TRACKING_SET SMC_RMI_CALL(0x01e3)
+#define SMC_RMI_CMEM_ADD_PDEV SMC_RMI_CALL(0x01e4)
+#define SMC_RMI_CMEM_CREATE SMC_RMI_CALL(0x01e5)
+#define SMC_RMI_CMEM_DESTROY SMC_RMI_CALL(0x01e6)
+#define SMC_RMI_CMEM_POPULATE SMC_RMI_CALL(0x01e7)
+#define SMC_RMI_CMEM_REMOTE_PDEV SMC_RMI_CALL(0x01e8)
+#define SMC_RMI_CMEM_START SMC_RMI_CALL(0x01e9)
+#define SMC_RMI_CMEM_STOP SMC_RMI_CALL(0x01ea)
+#define SMC_RMI_CMEM_UNPOPULATE SMC_RMI_CALL(0x01eb)
+#define SMC_RMI_RMM_CONFIG_GET SMC_RMI_CALL(0x01ec)
+#define SMC_RMI_PDEV_MEC_UPDATE SMC_RMI_CALL(0x01ed)
+#define SMC_RMI_VSMMU_EVENT_COMPLETE SMC_RMI_CALL(0x01ee)
+
+#define SMC_RMI_PSMMU_EVENT_DISCARD SMC_RMI_CALL(0x01f0)
+#define SMC_RMI_GRANULE_RANGE_DELEGATE SMC_RMI_CALL(0x01f1)
+#define SMC_RMI_GRANULE_RANGE_UNDELEGATE SMC_RMI_CALL(0x01f2)
+#define SMC_RMI_GPT_L1_CREATE SMC_RMI_CALL(0x01f3)
+#define SMC_RMI_GPT_L1_DESTROY SMC_RMI_CALL(0x01f4)
+#define SMC_RMI_RTT_DATA_MAP SMC_RMI_CALL(0x01f5)
+#define SMC_RMI_RTT_DATA_UNMAP SMC_RMI_CALL(0x01f6)
+#define SMC_RMI_RTT_DEV_MAP SMC_RMI_CALL(0x01f7)
+#define SMC_RMI_RTT_DEV_UNMAP SMC_RMI_CALL(0x01f8)
+#define SMC_RMI_RTT_ARCH_DEV_MAP SMC_RMI_CALL(0x01f9)
+#define SMC_RMI_RTT_ARCH_DEV_UNMAP SMC_RMI_CALL(0x01fa)
+#define SMC_RMI_RTT_UNPROT_MAP SMC_RMI_CALL(0x01fb)
+#define SMC_RMI_RTT_UNPROT_UNMAP SMC_RMI_CALL(0x01fc)
+#define SMC_RMI_RTT_AUX_PROT_MAP SMC_RMI_CALL(0x01fd)
+#define SMC_RMI_RTT_AUX_PROT_UNMAP SMC_RMI_CALL(0x01fe)
+#define SMC_RMI_RTT_AUX_UNPROT_MAP SMC_RMI_CALL(0x01ff)
+#define SMC_RMI_RTT_AUX_UNMAP_UNMAP SMC_RMI_CALL(0x0200)
+#define SMC_RMI_REALM_TERMINATE SMC_RMI_CALL(0x0201)
+#define SMC_RMI_RMM_ACTIVATE SMC_RMI_CALL(0x0202)
+#define SMC_RMI_OP_CONTINUE SMC_RMI_CALL(0x0203)
+#define SMC_RMI_PDEV_STREAM_CONNECT SMC_RMI_CALL(0x0204)
+#define SMC_RMI_PDEV_STREAM_DISCONNECT SMC_RMI_CALL(0x0205)
+#define SMC_RMI_PDEV_STREAM_COMPLETE SMC_RMI_CALL(0x0206)
+#define SMC_RMI_PDEV_STREAM_KEY_PURGE SMC_RMI_CALL(0x0207)
+#define SMC_RMI_OP_MEM_DONATE SMC_RMI_CALL(0x0208)
+#define SMC_RMI_OP_MEM_RECLAIM SMC_RMI_CALL(0x0209)
+#define SMC_RMI_OP_CANCEL SMC_RMI_CALL(0x020a)
+#define SMC_RMI_PDEV_SET_PROT SMC_RMI_CALL(0x020b)
+
+#define RMI_ABI_MAJOR_VERSION 2
+#define RMI_ABI_MINOR_VERSION 0
+
+#define RMI_ABI_VERSION_GET_MAJOR(version) ((version) >> 16)
+#define RMI_ABI_VERSION_GET_MINOR(version) ((version) & 0xFFFF)
+#define RMI_ABI_VERSION(major, minor) (((major) << 16) | (minor))
+
+#define RMI_UNASSIGNED 0
+#define RMI_ASSIGNED 1
+#define RMI_TABLE 2
+
+#define RMI_RETURN_STATUS(ret) ((ret) & 0xFF)
+#define RMI_RETURN_INDEX(ret) (((ret) >> 8) & 0xFF)
+#define RMI_RETURN_MEMREQ(ret) (((ret) >> 8) & 0x3)
+#define RMI_RETURN_CANCANCEL(ret) (((ret) >> 10) & 0x1)
+
+#define RMI_SUCCESS 0
+#define RMI_ERROR_INPUT 1
+#define RMI_ERROR_REALM 2
+#define RMI_ERROR_REC 3
+#define RMI_ERROR_RTT 4
+#define RMI_ERROR_NOT_SUPPORTED 5
+#define RMI_ERROR_DEVICE 6
+#define RMI_ERROR_RTT_AUX 7
+#define RMI_ERROR_PSMMU_ST 8
+#define RMI_ERROR_DPT 9
+#define RMI_BUSY 10
+#define RMI_ERROR_GLOBAL 11
+#define RMI_ERROR_TRACKING 12
+#define RMI_INCOMPLETE 13
+#define RMI_BLOCKED 14
+#define RMI_ERROR_GPT 15
+#define RMI_ERROR_GRANULE 16
+
+#define RMI_OP_MEM_REQ_NONE 0
+#define RMI_OP_MEM_REQ_DONATE 1
+#define RMI_OP_MEM_REQ_RECLAIM 2
+
+#define RMI_DONATE_SIZE(req) ((req) & 0x3)
+#define RMI_DONATE_COUNT_MASK GENMASK(15, 2)
+#define RMI_DONATE_COUNT(req) (((req) & RMI_DONATE_COUNT_MASK) >> 2)
+#define RMI_DONATE_CONTIG(req) (!!((req) & BIT(16)))
+#define RMI_DONATE_STATE(req) (!!((req) & BIT(17)))
+
+#define RMI_OP_MEM_DELEGATED 0
+#define RMI_OP_MEM_UNDELEGATED 1
+
+#define RMI_ADDR_TYPE_NONE 0
+#define RMI_ADDR_TYPE_SINGLE 1
+#define RMI_ADDR_TYPE_LIST 2
+
+#define RMI_ADDR_RANGE_SIZE(ar) (FIELD_GET(GENMASK(1, 0), (ar)))
+#define RMI_ADDR_RANGE_COUNT(ar) (FIELD_GET(GENMASK(PAGE_SHIFT - 1, 2), \
+ (ar)))
+#define RMI_ADDR_RANGE_ADDR(ar) ((ar) & PAGE_MASK & GENMASK(51, 0))
+#define RMI_ADDR_RANGE_STATE(ar) (FIELD_GET(BIT(63), (ar)))
+
+enum rmi_ripas {
+ RMI_EMPTY = 0,
+ RMI_RAM = 1,
+ RMI_DESTROYED = 2,
+};
+
+#define RMI_NO_MEASURE_CONTENT 0
+#define RMI_MEASURE_CONTENT 1
+
+#define RMI_FEATURE_REGISTER_0_S2SZ GENMASK(7, 0)
+#define RMI_FEATURE_REGISTER_0_LPA2 BIT(8)
+#define RMI_FEATURE_REGISTER_0_SVE BIT(9)
+#define RMI_FEATURE_REGISTER_0_SVE_VL GENMASK(13, 10)
+#define RMI_FEATURE_REGISTER_0_NUM_BPS GENMASK(19, 14)
+#define RMI_FEATURE_REGISTER_0_NUM_WPS GENMASK(25, 20)
+#define RMI_FEATURE_REGISTER_0_PMU BIT(26)
+#define RMI_FEATURE_REGISTER_0_PMU_NUM_CTRS GENMASK(31, 27)
+
+#define RMI_FEATURE_REGISTER_1_RMI_GRAN_SZ_4KB BIT(0)
+#define RMI_FEATURE_REGISTER_1_RMI_GRAN_SZ_16KB BIT(1)
+#define RMI_FEATURE_REGISTER_1_RMI_GRAN_SZ_64KB BIT(2)
+#define RMI_FEATURE_REGISTER_1_HASH_SHA_256 BIT(3)
+#define RMI_FEATURE_REGISTER_1_HASH_SHA_384 BIT(4)
+#define RMI_FEATURE_REGISTER_1_HASH_SHA_512 BIT(5)
+#define RMI_FEATURE_REGISTER_1_MAX_RECS_ORDER GENMASK(9, 6)
+#define RMI_FEATURE_REGISTER_1_L0GPTSZ GENMASK(13, 10)
+#define RMI_FEATURE_REGISTER_1_PPS GENMASK(16, 14)
+
+#define RMI_FEATURE_REGISTER_2_DA BIT(0)
+#define RMI_FEATURE_REGISTER_2_DA_COH BIT(1)
+#define RMI_FEATURE_REGISTER_2_VSMMU BIT(2)
+#define RMI_FEATURE_REGISTER_2_ATS BIT(3)
+#define RMI_FEATURE_REGISTER_2_MAX_VDEVS_ORDER GEN_MASK(7, 4)
+#define RMI_FEATURE_REGISTER_2_VDEV_KROU BIT(8)
+#define RMI_FEATURE_REGISTER_2_NON_TEE_STREAM BIT(9)
+
+#define RMI_FEATURE_REGISTER_3_MAX_NUM_AUX_PLANES GENMASK(3, 0)
+#define RMI_FEATURE_REGISTER_3_RTT_PLAN GENMASK(5, 4)
+#define RMI_FEATURE_REGISTER_3_RTT_S2AP_INDIRECT BIT(6)
+
+#define RMI_FEATURE_REGISTER_4_MEC_COUNT GENMASK(63, 0)
+
+#define RMI_MEM_CATEGORY_CONVENTIONAL 0
+#define RMI_MEM_CATEGORY_DEV_NCOH 1
+#define RMI_MEM_CATEGORY_DEV_COH 2
+
+#define RMI_TRACKING_RESERVED 0
+#define RMI_TRACKING_NONE 1
+#define RMI_TRACKING_FINE 2
+#define RMI_TRACKING_COARSE 3
+
+#define RMI_GRANULE_SIZE_4KB 0
+#define RMI_GRANULE_SIZE_16KB 1
+#define RMI_GRANULE_SIZE_64KB 2
+
+/*
+ * Note many of these fields are smaller than u64 but all fields have u64
+ * alignment, so use u64 to ensure correct alignment.
+ */
+struct rmm_config {
+ union { /* 0x0 */
+ struct {
+ u64 tracking_region_size;
+ u64 rmi_granule_size;
+ };
+ u8 sizer[0x1000];
+ };
+};
+
+#define RMI_REALM_PARAM_FLAG_LPA2 BIT(0)
+#define RMI_REALM_PARAM_FLAG_SVE BIT(1)
+#define RMI_REALM_PARAM_FLAG_PMU BIT(2)
+
+struct realm_params {
+ union { /* 0x0 */
+ struct {
+ u64 flags;
+ u64 s2sz;
+ u64 sve_vl;
+ u64 num_bps;
+ u64 num_wps;
+ u64 pmu_num_ctrs;
+ u64 hash_algo;
+ };
+ u8 padding0[0x400];
+ };
+ union { /* 0x400 */
+ u8 rpv[64];
+ u8 padding1[0x400];
+ };
+ union { /* 0x800 */
+ struct {
+ u64 padding;
+ u64 rtt_base;
+ s64 rtt_level_start;
+ u64 rtt_num_start;
+ };
+ u8 padding2[0x800];
+ };
+};
+
+/*
+ * The number of GPRs (starting from X0) that are
+ * configured by the host when a REC is created.
+ */
+#define REC_CREATE_NR_GPRS 8
+
+#define REC_PARAMS_FLAG_RUNNABLE BIT_ULL(0)
+
+#define REC_PARAMS_AUX_GRANULES 16
+
+struct rec_params {
+ union { /* 0x0 */
+ u64 flags;
+ u8 padding0[0x100];
+ };
+ union { /* 0x100 */
+ u64 mpidr;
+ u8 padding1[0x100];
+ };
+ union { /* 0x200 */
+ u64 pc;
+ u8 padding2[0x100];
+ };
+ union { /* 0x300 */
+ u64 gprs[REC_CREATE_NR_GPRS];
+ u8 padding3[0x500];
+ };
+ union { /* 0x800 */
+ struct {
+ u64 num_rec_aux;
+ u64 aux[REC_PARAMS_AUX_GRANULES];
+ };
+ u8 padding4[0x800];
+ };
+};
+
+#define REC_ENTER_FLAG_EMULATED_MMIO BIT(0)
+#define REC_ENTER_FLAG_INJECT_SEA BIT(1)
+#define REC_ENTER_FLAG_TRAP_WFI BIT(2)
+#define REC_ENTER_FLAG_TRAP_WFE BIT(3)
+#define REC_ENTER_FLAG_RIPAS_RESPONSE BIT(4)
+
+#define REC_RUN_GPRS 31
+#define REC_MAX_GIC_NUM_LRS 16
+
+#define RMI_PERMITTED_GICV3_HCR_BITS (ICH_HCR_EL2_UIE | \
+ ICH_HCR_EL2_LRENPIE | \
+ ICH_HCR_EL2_NPIE | \
+ ICH_HCR_EL2_VGrp0EIE | \
+ ICH_HCR_EL2_VGrp0DIE | \
+ ICH_HCR_EL2_VGrp1EIE | \
+ ICH_HCR_EL2_VGrp1DIE | \
+ ICH_HCR_EL2_TDIR)
+
+struct rec_enter {
+ union { /* 0x000 */
+ u64 flags;
+ u8 padding0[0x200];
+ };
+ union { /* 0x200 */
+ u64 gprs[REC_RUN_GPRS];
+ u8 padding1[0x100];
+ };
+ u8 padding3[0x500];
+};
+
+#define RMI_EXIT_SYNC 0x00
+#define RMI_EXIT_IRQ 0x01
+#define RMI_EXIT_FIQ 0x02
+#define RMI_EXIT_PSCI 0x03
+#define RMI_EXIT_RIPAS_CHANGE 0x04
+#define RMI_EXIT_HOST_CALL 0x05
+#define RMI_EXIT_SERROR 0x06
+
+struct rec_exit {
+ union { /* 0x000 */
+ u8 exit_reason;
+ u8 padding0[0x100];
+ };
+ union { /* 0x100 */
+ struct {
+ u64 esr;
+ u64 far;
+ u64 hpfar;
+ u64 rtt_tree;
+ };
+ u8 padding1[0x100];
+ };
+ union { /* 0x200 */
+ u64 gprs[REC_RUN_GPRS];
+ u8 padding2[0x100];
+ };
+ union { /* 0x300 */
+ u8 padding3[0x100];
+ };
+ union { /* 0x400 */
+ struct {
+ u64 cntp_ctl;
+ u64 cntp_cval;
+ u64 cntv_ctl;
+ u64 cntv_cval;
+ };
+ u8 padding4[0x100];
+ };
+ union { /* 0x500 */
+ struct {
+ u64 ripas_base;
+ u64 ripas_top;
+ u8 ripas_value;
+ u8 padding8[15];
+ u64 s2ap_base;
+ u64 s2ap_top;
+ u64 vdev_id_1;
+ u64 vdev_id_2;
+ u64 dev_mem_base;
+ u64 dev_mem_top;
+ u64 dev_mem_pa;
+ };
+ u8 padding5[0x100];
+ };
+ union { /* 0x600 */
+ struct {
+ u16 imm;
+ u16 padding9;
+ u64 plane;
+ };
+ u8 padding6[0x100];
+ };
+ union { /* 0x700 */
+ struct {
+ u8 pmu_ovf_status;
+ u8 padding10[15];
+ u64 vsmmu;
+ };
+ u8 padding7[0x100];
+ };
+};
+
+struct rec_run {
+ struct rec_enter enter;
+ struct rec_exit exit;
+};
+
+#endif /* __ASM_RMI_SMC_H */
--
2.43.0
^ permalink raw reply related
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