* Re: [PATCH v2 0/3] Expose TDX Module version
From: dan.j.williams @ 2026-01-07 0:36 UTC (permalink / raw)
To: Chao Gao, Kiryl Shutsemau
Cc: kvm, linux-coco, linux-kernel, x86, vishal.l.verma, kai.huang,
dan.j.williams, yilun.xu, vannapurve, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Ingo Molnar, Rick Edgecombe,
Thomas Gleixner
In-Reply-To: <aVywHbHlcRw2tM/X@intel.com>
Chao Gao wrote:
[..]
> And in my opinion, exposing version information to guests is also unnecessary
> since the module version can already be read from the host with this series.
> In debugging scenarios, I'm not sure why the TDX module would be so special
> that guests should know its version but not other host information, such as
> host kernel version, microcode version, etc. None of these are exposed to guest
> kernel (not to mention guest userspace).
Agree, and note that the guest already has full launch attestation
details available via the common
Documentation/ABI/testing/configfs-tsm-report transport.
I assume the primary need for version information is debug, but if you
are debugging a guest problem might as well get the entire launch
attestation with the version of "all the things" included.
^ permalink raw reply
* RE: [EXTERNAL] Re: "Paravisor" Feature Enumeration
From: Jon Lange @ 2026-01-06 23:01 UTC (permalink / raw)
To: Andrew Cooper, Dave Hansen
Cc: Williams, Dan J, Sean Christopherson, Paolo Bonzini, John Starks,
Will Deacon, Mark Rutland, linux-coco@lists.linux.dev, LKML,
Edgecombe, Rick P
In-Reply-To: <43ae1b15-c911-4ecd-aaaa-15bc23ec6192@citrix.com>
Andrew wrote:
> So overall, we're wanting the paravisor to be able to express "You're in
> a confidential VM, but you're not in charge" to the OS.
That is a great way to summarize the goal here.
> In your first example, when you say "attestation report", do you mean of
> the whole encrypted VM, or only the "OS" part of it? After all, a
> paravisor could be running multiple OSes.
No, a paravisor can only run a single OS. This is the key defining difference between a paravisor and a nested hypervisor. This arises out of necessity from the confidential multi-privilege architectures that exist today; there is no architectural support for managing multiple guests. So you can think of the paravisor as the entity that provides virtualization services to the single OS.
> What you're really describing is "just another hypervisor". So really,
> on x86, the paravisor (which does control CPUID in this scenario) ought
> to hide the outer data, advertise itself at 0x4000_0000, and Linux wants
> a new paravirt mode for this new kind of virtual platform, which is
> probably not going to be very different from a typical KVM/XenHVM/HyperV
> guest today.
This is the reason that I find it so attractive to embed this in the virtualization driver. In the case of the Hyper-V paravisor, the paravisor exposes the same Hyper-V interface as the Hyper-V hypervisor does, including all of its synthetic CPUID leaves, synthetic MSRs, and hypercalls. As you suggest, the OS will boot up, completely unaware that it is running in a confidential VM (because the paravisor hides SNP/TDX/RME) and at some point, when it is discovering the presence of what it thinks of as the "hypervisor", the "hypervisor" (which is the paravisor in this context) can just advertise its unique presence in its own dialect. Hyper-V is already capable of doing this through a hypervisor feature enumeration called the "isolation configuration". I think you are arguing the same point that I am increasingly coming to believe: the existing hypervisor interfaces are adequate to express this configuration. In that case, the challenge before us now is how to teach the kernel that "paravisor mode" is meaningful so that state can be advertised across the system for use by those components that need to know (attestation and TDISP, in my examples). But if this is a configuration that is enumerated by the virtualization driver, then it can't live in device tree nor in ACPI, because those are passed into the kernel and not generated by it.
> Do you foresee a need to pass anything other than "here's a handful of
> services that are available to you"?
Assuming we move past the question of "are we in paravisor mode", something that is less clear to me is how components like the attestation driver know how to consume the confidential services that exist. A fully enlightened OS that knows that it is in charge also knows that it has direct access to all of the platform services that support confidentiality (whether it's specific SNP ABI calls, or TDG.* TDCALL leaves, or GHCB/GHCI interaction, or whatever). But when running behind a paravisor, some of that access might be restricted, and it might not be possible for the existing drivers to work without modification. Since none of these paravisor support services have been built yet, it's hard for me to predict what kinds of differences need to exist in these drivers between paravisor mode and fully enlightened mode - it might turn out to be none at all. I suspect that we're going to have to just try to build something and see where the problems lie in practice, and that will information how much additional information might need to flow (which might go beyond "these services are available" to "here's how you access them"). I don't think it's too productive to conjecture any specifics now until we have code to point to, but this is a potential problem worth acknowledging.
My hope is to try to spend some time on supporting attestation with a paravisor in the next several months, but I don't know when I'll be able to set aside the time. So somebody other than me might end up blazing the trail.
-Jon
-----Original Message-----
From: Andrew Cooper <andrew.cooper3@citrix.com>
Sent: Tuesday, January 6, 2026 2:39 PM
To: Jon Lange <jlange@microsoft.com>; Dave Hansen <dave.hansen@intel.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>; Williams, Dan J <dan.j.williams@intel.com>; Sean Christopherson <seanjc@google.com>; Paolo Bonzini <pbonzini@redhat.com>; John Starks <John.Starks@microsoft.com>; Will Deacon <will@kernel.org>; Mark Rutland <mark.rutland@arm.com>; linux-coco@lists.linux.dev; LKML <linux-kernel@vger.kernel.org>; Edgecombe, Rick P <rick.p.edgecombe@intel.com>
Subject: Re: [EXTERNAL] Re: "Paravisor" Feature Enumeration
On 06/01/2026 2:12 am, Jon Lange wrote:
> Andrew wrote:
>
>> Are we saying that, inside an opaque blob that a customer provides to a CSP to run we might have:
>> * a paravisor and an unaware OS, or
>> * svsm and a fully-aware OS, or
>> * something in-between these two.
>> and we're looking a way to describe which piece of the interior stack owns which capability/service?
>> I think the discussion would benefit greatly from having a couple of concrete examples of data this wants to hold,
>> and how it is to be used at different levels of the interior software stack.
> Here are two examples. In both examples, the OS is running behind a paravisor but I wouldn't term it an "unaware OS". Rather, the paravisor is present because of the set of services it provides, and it is running in paravisor mode (not SVSM mode) because the implementation benefits from taking full management responsibility for the confidential trust boundary (e.g. determination of when/how to validate/accept pages). In such a configuration, where the paravisor has management responsibility for the confidential trust boundary, all of the enlightenments in the guest OS for managing confidentiality state must be suppressed. The straightforward way to do this is for the paravisor to suppress the confidential VM enumeration information visible to the guest OS (the "SNP available" CPUID bit, or the "TDX active" bit, for example).
>
> Note that this occurs out of necessity because we can't have the paravisor and the guest OS fighting over who has the right/responsibility to execute PVALIDATE, or TDG.MEM.PAGE.ACCEPT, or whatever. The kernel today only has two concepts of its execution mode: either it is a confidential VM, in which case it takes full responsibility, or it is not a confidential VM, in which case it ignores the responsibility. When a paravisor (not SVSM) is active, we have to operate in the second mode because the first mode would provoke precisely the conflict we're trying to avoid.
>
> First example: a confidential VM running under a paravisor wants to obtain an attestation report for itself to pass to a third party to vouch for the fact that it is a confidential VM. Assume in this example that the relying party is aware of the paravisor and the paravisor's measurements, so the evidence provided in such an attestation report can successfully be verified as authentic. In order for this to be possible, the kernel has to know that it's running in a confidential VM in a mode where attestation reports are available but where the responsibility for confidential memory state management is suppressed. This is a third state beyond the two states described above. This isn't just a userspace problem because access to the attestation service is mediated by a kernel-mode driver that needs to know how to configure itself (such configuration today is based on CPUID and not on ACPI).
>
> Second example: a confidential VM running under a paravisor determines that one of the devices available to it is a TDISP device that requires the OS - not the paravisor - to perform the operations required to configure the device, to obtain and verify its attestation information, and to consent to activating the device in the TDISP RUN state. In order for the OS to be able to execute that sequence, the device has to know that it is running as a confidential VM so it knows that TDISP configuration may be necessary.
Thankyou - that is helpful.
So overall, we're wanting the paravisor to be able to express "You're in
a confidential VM, but you're not in charge" to the OS.
Hiding the SNP / TDX bit is of course necessary. They have well defined
meanings which the OS cannot use when it's not in charge.
In your first example, when you say "attestation report", do you mean of
the whole encrypted VM, or only the "OS" part of it? After all, a
paravisor could be running multiple OSes.
Whichever it is, this is clearly a service provided by the paravisor,
with some kind of API that's going to be of the from "execute
VM(M)CALL/etc with these regs". TDISP is also CPU-initiated actions,
some of which may need a paravisor API.
What you're really describing is "just another hypervisor". So really,
on x86, the paravisor (which does control CPUID in this scenario) ought
to hide the outer data, advertise itself at 0x4000_0000, and Linux wants
a new paravirt mode for this new kind of virtual platform, which is
probably not going to be very different from a typical KVM/XenHVM/HyperV
guest today.
Anything else, and it seems like you're just re-inventing the wheel but
a little more square.
Do you foresee a need to pass anything other than "here's a handful of
services that are available to you"? An ACPI table might be an
approach, but this seems like it could be a leaf or two and nothing more.
There's no common enumeration scheme between different architectures,
but I'm a firm believer that things ought to be enumerated in the
typical way for the architecture/platform. This means CPUID on x86, and
things like devicetree on ARM. It's slightly ugly duplicating
information, but it's less ugly than shoehorning a non-typical
enumeration scheme in to an existing infrastructure.
~Andrew
^ permalink raw reply
* Re: [EXTERNAL] Re: "Paravisor" Feature Enumeration
From: Andrew Cooper @ 2026-01-06 22:39 UTC (permalink / raw)
To: Jon Lange, Dave Hansen
Cc: Andrew Cooper, Williams, Dan J, Sean Christopherson,
Paolo Bonzini, John Starks, Will Deacon, Mark Rutland,
linux-coco@lists.linux.dev, LKML, Edgecombe, Rick P
In-Reply-To: <CH8PR21MB522275E86FF5D33B04CE7A75CA87A@CH8PR21MB5222.namprd21.prod.outlook.com>
On 06/01/2026 2:12 am, Jon Lange wrote:
> Andrew wrote:
>
>> Are we saying that, inside an opaque blob that a customer provides to a CSP to run we might have:
>> * a paravisor and an unaware OS, or
>> * svsm and a fully-aware OS, or
>> * something in-between these two.
>> and we're looking a way to describe which piece of the interior stack owns which capability/service?
>> I think the discussion would benefit greatly from having a couple of concrete examples of data this wants to hold,
>> and how it is to be used at different levels of the interior software stack.
> Here are two examples. In both examples, the OS is running behind a paravisor but I wouldn't term it an "unaware OS". Rather, the paravisor is present because of the set of services it provides, and it is running in paravisor mode (not SVSM mode) because the implementation benefits from taking full management responsibility for the confidential trust boundary (e.g. determination of when/how to validate/accept pages). In such a configuration, where the paravisor has management responsibility for the confidential trust boundary, all of the enlightenments in the guest OS for managing confidentiality state must be suppressed. The straightforward way to do this is for the paravisor to suppress the confidential VM enumeration information visible to the guest OS (the "SNP available" CPUID bit, or the "TDX active" bit, for example).
>
> Note that this occurs out of necessity because we can't have the paravisor and the guest OS fighting over who has the right/responsibility to execute PVALIDATE, or TDG.MEM.PAGE.ACCEPT, or whatever. The kernel today only has two concepts of its execution mode: either it is a confidential VM, in which case it takes full responsibility, or it is not a confidential VM, in which case it ignores the responsibility. When a paravisor (not SVSM) is active, we have to operate in the second mode because the first mode would provoke precisely the conflict we're trying to avoid.
>
> First example: a confidential VM running under a paravisor wants to obtain an attestation report for itself to pass to a third party to vouch for the fact that it is a confidential VM. Assume in this example that the relying party is aware of the paravisor and the paravisor's measurements, so the evidence provided in such an attestation report can successfully be verified as authentic. In order for this to be possible, the kernel has to know that it's running in a confidential VM in a mode where attestation reports are available but where the responsibility for confidential memory state management is suppressed. This is a third state beyond the two states described above. This isn't just a userspace problem because access to the attestation service is mediated by a kernel-mode driver that needs to know how to configure itself (such configuration today is based on CPUID and not on ACPI).
>
> Second example: a confidential VM running under a paravisor determines that one of the devices available to it is a TDISP device that requires the OS - not the paravisor - to perform the operations required to configure the device, to obtain and verify its attestation information, and to consent to activating the device in the TDISP RUN state. In order for the OS to be able to execute that sequence, the device has to know that it is running as a confidential VM so it knows that TDISP configuration may be necessary.
Thankyou - that is helpful.
So overall, we're wanting the paravisor to be able to express "You're in
a confidential VM, but you're not in charge" to the OS.
Hiding the SNP / TDX bit is of course necessary. They have well defined
meanings which the OS cannot use when it's not in charge.
In your first example, when you say "attestation report", do you mean of
the whole encrypted VM, or only the "OS" part of it? After all, a
paravisor could be running multiple OSes.
Whichever it is, this is clearly a service provided by the paravisor,
with some kind of API that's going to be of the from "execute
VM(M)CALL/etc with these regs". TDISP is also CPU-initiated actions,
some of which may need a paravisor API.
What you're really describing is "just another hypervisor". So really,
on x86, the paravisor (which does control CPUID in this scenario) ought
to hide the outer data, advertise itself at 0x4000_0000, and Linux wants
a new paravirt mode for this new kind of virtual platform, which is
probably not going to be very different from a typical KVM/XenHVM/HyperV
guest today.
Anything else, and it seems like you're just re-inventing the wheel but
a little more square.
Do you foresee a need to pass anything other than "here's a handful of
services that are available to you"? An ACPI table might be an
approach, but this seems like it could be a leaf or two and nothing more.
There's no common enumeration scheme between different architectures,
but I'm a firm believer that things ought to be enumerated in the
typical way for the architecture/platform. This means CPUID on x86, and
things like devicetree on ARM. It's slightly ugly duplicating
information, but it's less ugly than shoehorning a non-typical
enumeration scheme in to an existing infrastructure.
~Andrew
^ permalink raw reply
* Re: "Paravisor" Feature Enumeration
From: Edgecombe, Rick P @ 2026-01-06 19:17 UTC (permalink / raw)
To: Hansen, Dave, Lange, Jon, andrew.cooper3@citrix.com
Cc: seanjc@google.com, mark.rutland@arm.com,
john.starks@microsoft.com, Williams, Dan J, will@kernel.org,
pbonzini@redhat.com, linux-coco@lists.linux.dev,
linux-kernel@vger.kernel.org, kirill.shutemov@linux.intel.com
In-Reply-To: <4f3e1701-3ccd-4ee8-a45e-3872d71ef548@citrix.com>
On Tue, 2026-01-06 at 01:44 +0000, Andrew Cooper wrote:
> I agree that it seems like "just" an enumeration problem, but despite
> attending the presentation and rereading the slides, I'm still not clear
> on the precise scope.
>
> Are we saying that, inside an opaque blob that a customer provides to a
> CSP to run we might have:
>
> * a paravisor and an unaware OS, or
> * svsm and a fully-aware OS, or
> * something in-between these two.
>
> and we're looking a way to describe which piece of the interior stack
> owns which capability/service?
>
> If so, it can't come in from the outside; given that it's the capability
> enumeration, there's a chicken/egg problem with verifying the integrity.
>
> It seems like it needs to be produced by whatever the first code to run
> is, after gathering capabilities in a vendor-specific way, and deciding
> which services it wants to provide, and which to delegate.
>
> And if so, then it definitely cannot be in CPUID because that needs to
> be fixed from prior to the guest starting to run, and doesn't express
> dynamic properties of the system[*]
For TDX, the guest has some control of the CPUID bits. Both via #VE
interception, and poking at the TDX module guest side interfaces to change which
CPUID leafs generate a #VE.
This is indeed a complication for "the outside". It handles some MSRs accesses
that depend on the CPUID config which it doesn't have final visibility into.
I would like to see less of that in the future. But marking off a certain range
of leafs to be handled by the paravisor/SVSM and that KVM/outside just ignores
seems better than current situation we already have at least. Not to dismiss the
other points.
^ permalink raw reply
* SVSM Development Call January 7th, 2026
From: Jörg Rödel @ 2026-01-06 17:12 UTC (permalink / raw)
To: coconut-svsm, linux-coco
Hi,
Happy new year everyone!
Here is the call for agenda items for the the first SVSM development call of
the year. Please send me any agenda items you have in mind 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 v4 04/16] x86/virt/tdx: Allocate page bitmap for Dynamic PAMT
From: Edgecombe, Rick P @ 2026-01-06 17:00 UTC (permalink / raw)
To: yilun.xu@linux.intel.com
Cc: kvm@vger.kernel.org, linux-coco@lists.linux.dev, Huang, Kai,
Li, Xiaoyao, Hansen, Dave, Zhao, Yan Y, Wu, Binbin,
kas@kernel.org, seanjc@google.com, mingo@redhat.com,
pbonzini@redhat.com, tglx@linutronix.de, Yamahata, Isaku,
linux-kernel@vger.kernel.org, kirill.shutemov@linux.intel.com,
Annapurve, Vishal, Gao, Chao, bp@alien8.de, x86@kernel.org
In-Reply-To: <aVyJG+vh9r/ZMmOG@yilunxu-OptiPlex-7050>
On Tue, 2026-01-06 at 12:01 +0800, Xu Yilun wrote:
> Yes the extra indentation is unconventional, but everything here is,
> and we know we will eventually change them all. So I more prefer
> simple changes based on:
>
> if (!ret && !(ret = read_sys_metadata_field(0xABCDEF, &val)))
>
> rather than neat but more LOC (when both are easy to read).
This whole code style was optimized to be verifiable, not for LOC. Kai
originally had several macro based solution that had a bunch of code
reuse before this style got settled on as part of the code gen. It
would definitely be a good thing to review the previous versions before
working on yet another solution to metadata reading.
>
> Anyway, this is trivial concern. I have more optional fields to add
> and will follow the final decision.
This is the kind of thing that shouldn't need a clever solution. There
*should* be a way to more simply copy structured data from the TDX
module.
I do think this is a good area for cleanup, but let's not overhaul it
just to get a small incremental benefit. If we need a new interface in
the TDX module, let's explore it and actually get to something simple.
^ permalink raw reply
* Re: [PATCH v2 0/3] Expose TDX Module version
From: Dave Hansen @ 2026-01-06 16:37 UTC (permalink / raw)
To: Chao Gao
Cc: Kiryl Shutsemau, kvm, linux-coco, linux-kernel, x86,
vishal.l.verma, kai.huang, dan.j.williams, yilun.xu, vannapurve,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Ingo Molnar,
Rick Edgecombe, Thomas Gleixner
In-Reply-To: <aVzinyLe5rxkJXUu@intel.com>
On 1/6/26 02:23, Chao Gao wrote:
> First I don't think we should expose TDX module version or hypervisor
> version to guests. See my reply to Kirill.
I just read it. It didn't provide any insight. For now, it's a plain old
NAK on the new ABI. The water is too muddied.
I'm still open to dumping something to dmesg though.
^ permalink raw reply
* Re: [PATCH v2 0/3] Expose TDX Module version
From: Chao Gao @ 2026-01-06 13:31 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: kvm, linux-coco, linux-kernel, x86, vishal.l.verma, kai.huang,
dan.j.williams, yilun.xu, vannapurve, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Ingo Molnar, Rick Edgecombe,
Thomas Gleixner
In-Reply-To: <idebornlxlwj4zuk4h3upaibez7vcqiynzuqj65q6sycidax65@uqsqfqqosekx>
On Tue, Jan 06, 2026 at 11:19:46AM +0000, Kiryl Shutsemau wrote:
>On Tue, Jan 06, 2026 at 02:47:57PM +0800, Chao Gao wrote:
>> On Mon, Jan 05, 2026 at 10:38:19AM +0000, Kiryl Shutsemau wrote:
>> >On Sun, Jan 04, 2026 at 11:43:43PM -0800, Chao Gao wrote:
>> >> Hi reviewers,
>> >>
>> >> This series is quite straightforward and I believe it's well-polished.
>> >> Please consider providing your ack tags. However, since it depends on
>> >> two other series (listed below), please review those dependencies first if
>> >> you haven't already.
>> >>
>> >> Changes in v2:
>> >> - Print TDX Module version in demsg (Vishal)
>> >> - Remove all descriptions about autogeneration (Rick)
>> >> - Fix typos (Kai)
>> >> - Stick with TDH.SYS.RD (Dave/Yilun)
>> >> - Rebase onto Sean's VMXON v2 series
>> >>
>> >> === Problem & Solution ===
>> >>
>> >> Currently, there is no user interface to get the TDX Module version.
>> >> However, in bug reporting or analysis scenarios, the first question
>> >> normally asked is which TDX Module version is on your system, to determine
>> >> if this is a known issue or a new regression.
>> >>
>> >> To address this issue, this series exposes the TDX Module version as
>> >> sysfs attributes of the tdx_host device [*] and also prints it in dmesg
>> >> to keep a record.
>> >
>> >The version information is also useful for the guest. Maybe we should
>> >provide consistent interface for both sides?
>>
>> Note that only the Major and Minor versions (like 1.5 or 2.0) are available to
>> the guest; the TDX Module doesn't allow guests to read the update version.
>> Given this limitation, exposing version information to guests isn't
>> particularly useful.
>
>Ughh. I didn't realize this info is not available to the guest. This is
>unnecessary strict. Isn't it derivable from measurement report anyway?
Measurement report only has SVNs. it doesn't contain the TDX module version
directly AFAIK. But yes, I think the module version could be derived from the
TDX MODULE measurement (MRSEAM) of the TEE_TCB_INFO struct.
>
>> And in my opinion, exposing version information to guests is also unnecessary
>> since the module version can already be read from the host with this series.
>> In debugging scenarios, I'm not sure why the TDX module would be so special
>> that guests should know its version but not other host information, such as
>> host kernel version, microcode version, etc. None of these are exposed to guest
>> kernel (not to mention guest userspace).
>
>I already dump attributes and TD CTLS on guest boot, because it is
>useful for debug. Version and features can also be useful for reports
>from the field. Reported may not have access to hypervisor. Or it would
>require additional round trip to get this info from reported.
I would say a bug report likely requires other host information - CPU model,
microcode version, and kernel version if the TDX module version is needed.
This means we'd need that "round trip" regardless, unless we provide all this
data directly to the guest.
I do think exposing features within the guest would help with debugging. But,
this raises implementation questions that need careful consideration - do we
just expose the raw feature bitmasks or create human-readable names for each
feature? And it looks like an ongoing discussion [*] may intersect with this
topic. So, I prefer to handle it in a separate series.
*: https://lore.kernel.org/all/4c8524e5-b3e1-4113-a4e3-d3615465d9a8@intel.com/
^ permalink raw reply
* Re: [PATCH RESEND v2 02/12] firmware: smccc: coco: Manage arm-smccc platform device and CCA auxiliary drivers
From: Aneesh Kumar K.V @ 2026-01-06 12:33 UTC (permalink / raw)
To: linux-coco, kvmarm, Mark Rutland
Cc: linux-pci, linux-kernel, dan.j.williams, aik, lukas, Samuel Ortiz,
Xu Yilun, Jason Gunthorpe, Suzuki K Poulose, Steven Price,
Bjorn Helgaas, Jonathan Cameron, Catalin Marinas, Marc Zyngier,
Will Deacon, Oliver Upton, Jeremy Linton, Greg KH, Mark Rutland,
Lorenzo Pieralisi, Sudeep Holla
In-Reply-To: <20251027095602.1154418-3-aneesh.kumar@kernel.org>
Hi Mark,
"Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org> writes:
> Make the SMCCC driver responsible for registering the arm-smccc platform
> device and after confirming the relevant SMCCC function IDs, create
> the arm_cca_guest auxiliary device.
>
> Also update the arm-cca-guest driver to use the auxiliary device
> interface instead of the platform device (arm-cca-dev). The removal of
> the platform device registration will follow in a subsequent patch,
> allowing this change to be applied without immediately breaking existing
> userspace dependencies [1].
>
> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
> Cc: Jeremy Linton <jeremy.linton@arm.com>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>
Just a gentle ping on this patch — any feedback would be much appreciated.
-aneesh
^ permalink raw reply
* Re: [PATCH v2 0/3] Expose TDX Module version
From: Kiryl Shutsemau @ 2026-01-06 11:19 UTC (permalink / raw)
To: Chao Gao
Cc: kvm, linux-coco, linux-kernel, x86, vishal.l.verma, kai.huang,
dan.j.williams, yilun.xu, vannapurve, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Ingo Molnar, Rick Edgecombe,
Thomas Gleixner
In-Reply-To: <aVywHbHlcRw2tM/X@intel.com>
On Tue, Jan 06, 2026 at 02:47:57PM +0800, Chao Gao wrote:
> On Mon, Jan 05, 2026 at 10:38:19AM +0000, Kiryl Shutsemau wrote:
> >On Sun, Jan 04, 2026 at 11:43:43PM -0800, Chao Gao wrote:
> >> Hi reviewers,
> >>
> >> This series is quite straightforward and I believe it's well-polished.
> >> Please consider providing your ack tags. However, since it depends on
> >> two other series (listed below), please review those dependencies first if
> >> you haven't already.
> >>
> >> Changes in v2:
> >> - Print TDX Module version in demsg (Vishal)
> >> - Remove all descriptions about autogeneration (Rick)
> >> - Fix typos (Kai)
> >> - Stick with TDH.SYS.RD (Dave/Yilun)
> >> - Rebase onto Sean's VMXON v2 series
> >>
> >> === Problem & Solution ===
> >>
> >> Currently, there is no user interface to get the TDX Module version.
> >> However, in bug reporting or analysis scenarios, the first question
> >> normally asked is which TDX Module version is on your system, to determine
> >> if this is a known issue or a new regression.
> >>
> >> To address this issue, this series exposes the TDX Module version as
> >> sysfs attributes of the tdx_host device [*] and also prints it in dmesg
> >> to keep a record.
> >
> >The version information is also useful for the guest. Maybe we should
> >provide consistent interface for both sides?
>
> Note that only the Major and Minor versions (like 1.5 or 2.0) are available to
> the guest; the TDX Module doesn't allow guests to read the update version.
> Given this limitation, exposing version information to guests isn't
> particularly useful.
Ughh. I didn't realize this info is not available to the guest. This is
unnecessary strict. Isn't it derivable from measurement report anyway?
> And in my opinion, exposing version information to guests is also unnecessary
> since the module version can already be read from the host with this series.
> In debugging scenarios, I'm not sure why the TDX module would be so special
> that guests should know its version but not other host information, such as
> host kernel version, microcode version, etc. None of these are exposed to guest
> kernel (not to mention guest userspace).
I already dump attributes and TD CTLS on guest boot, because it is
useful for debug. Version and features can also be useful for reports
from the field. Reported may not have access to hypervisor. Or it would
require additional round trip to get this info from reported.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v2 0/3] Expose TDX Module version
From: Chao Gao @ 2026-01-06 10:23 UTC (permalink / raw)
To: Dave Hansen
Cc: Kiryl Shutsemau, kvm, linux-coco, linux-kernel, x86,
vishal.l.verma, kai.huang, dan.j.williams, yilun.xu, vannapurve,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Ingo Molnar,
Rick Edgecombe, Thomas Gleixner
In-Reply-To: <d45cc504-509c-48a7-88e2-374e00068e79@intel.com>
>Generally, I find myself really wanting to know how this fits into the
>larger picture. Using this "faux" device really seems novel and
>TDX-specific. Should it be?
>
>What are other CPU vendors doing for this? SEV? CCA? S390? How are their
>firmware versions exposed? What about other things in the Intel world
>like CPU microcode or the billion other chunks of firmware? How about
>hypervisors? Do they expose their versions to guests with an explicit
>ABI? Are those exposed to userspace?
First I don't think we should expose TDX module version or hypervisor
version to guests. See my reply to Kirill.
Let me connect all the dots to explain why we use a "faux" device and expose
version information as device attributes.
Why add a device
================
SEV [1] employs a PCI device while CCA [2] adds a platform device. So, we add a
"virtual" device to represent TDX firmware. As illustrated in [3], the device
actually serves multiple purposes:
"""
Create a virtual device not only to align with other implementations but
also to make it easier to
- expose metadata (e.g., TDX module version, seamldr version etc) to
the userspace as device attributes
- implement firmware uploader APIs which are tied to a device. This is
needed to support TDX module runtime updates
- enable TDX Connect which will share a common infrastructure with other
platform implementations. In the TDX Connect context, every
architecture has a TSM, represented by a PCIe or virtual device. The
new "tdx_host" device will serve the TSM role.
"""
[1]: drivers/crypto/ccp/sev-dev.c
[2]: https://lore.kernel.org/all/20251208221319.1524888-5-vvidwans@nvidia.com/
[3]: https://lore.kernel.org/all/20251117022311.2443900-2-yilun.xu@linux.intel.com/
faux vs "virtual" device
========================
We previously implemented a virtual TDX device under /sys/devices/virtual/ but
it required creating a stub bus. As suggested by Dan, we switched to a faux
device to avoid this requirement.
The previous virtual device implementation was at:
https://lore.kernel.org/kvm/20250523095322.88774-5-chao.gao@intel.com/
As you can see from #LoC, the current tdx-host faux implementation is much
simpler:
before:
arch/x86/virt/vmx/tdx/tdx.c | 75 +++++++++++++++++++++++++++++++++++++
1 file changed, 75 insertions(+)
vs.
now:
drivers/virt/coco/Kconfig | 2 ++
drivers/virt/coco/tdx-host/Kconfig | 10 +++++++
drivers/virt/coco/Makefile | 1 +
drivers/virt/coco/tdx-host/Makefile | 1 +
drivers/virt/coco/tdx-host/tdx-host.c | 41 +++++++++++++++++++++++++++
5 files changed, 55 insertions(+)
Why expose version to userspace
===============================
SEV doesn't expose its API version (which I assume is the counterpart of TDX
module version, since it doesn't have a firmware version concept) to userspace
but only prints it in dmesg.
TDX Module version is exposed to userspace because:
1. For debugging purposes, the version will be available to userspace even if
dmesg logs are cleared. Like microcode version, it's printed in dmesg and
also readable from CPU virtual device attributes.
2. A userspace tool needs to read the current module version to select
compatible module versions for updates. This is a unique requirement of TDX.
Why expose version as device attribute
======================================
Once we have a virtual device to represent TDX firmware, using device
attributes is the natural choice. microcode version is exposed in a similar
way.
>
>For instance, I hear a lot of talk about updating the TDX module. But is
>this interface consistent with doing updates? Long term, I was hoping
>that TDX firmware could get treated like any other blob of modern
>firmware and have fwupd manage it, so I asked:
TDX module updates implement the firmware_upload API [*], just like NVMe firmware
updates and FPGA firmware updates. This results in them exposing similar uABIs
to userspace. If NVMe firmware or FPGA firmware can be supported by fwupd, it
shouldn't be difficult to have fwupd manage TDX modules as well.
[*]: https://docs.kernel.org/driver-api/firmware/fw_upload.html
>
> https://chatgpt.com/share/695be06c-3d40-8012-97c9-2089fc33cbb3
>
>My read on your approach here is that our new LLM overlords might
>consider it the "last resort".
The "last resort" in the above link refers to ACPI tables or WMI methods. But
IIUC, my approach here is the most common approach for non-UEFI firmware -
"sysfs devices", i.e.,
: Kernel dev takeaway
: - Make it a proper kernel device
: - Expose a stable firmware version attribute
: - Expose a way to trigger update (even if it’s just “write blob, reboot”)
Is there anything I misunderstood?
^ permalink raw reply
* Re: [PATCH v2 0/3] Expose TDX Module version
From: Nikolay Borisov @ 2026-01-06 9:17 UTC (permalink / raw)
To: Chao Gao, Kiryl Shutsemau
Cc: kvm, linux-coco, linux-kernel, x86, vishal.l.verma, kai.huang,
dan.j.williams, yilun.xu, vannapurve, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Ingo Molnar, Rick Edgecombe,
Thomas Gleixner
In-Reply-To: <aVywHbHlcRw2tM/X@intel.com>
On 6.01.26 г. 8:47 ч., Chao Gao wrote:
> On Mon, Jan 05, 2026 at 10:38:19AM +0000, Kiryl Shutsemau wrote:
>> On Sun, Jan 04, 2026 at 11:43:43PM -0800, Chao Gao wrote:
>>> Hi reviewers,
>>>
>>> This series is quite straightforward and I believe it's well-polished.
>>> Please consider providing your ack tags. However, since it depends on
>>> two other series (listed below), please review those dependencies first if
>>> you haven't already.
>>>
>>> Changes in v2:
>>> - Print TDX Module version in demsg (Vishal)
>>> - Remove all descriptions about autogeneration (Rick)
>>> - Fix typos (Kai)
>>> - Stick with TDH.SYS.RD (Dave/Yilun)
>>> - Rebase onto Sean's VMXON v2 series
>>>
>>> === Problem & Solution ===
>>>
>>> Currently, there is no user interface to get the TDX Module version.
>>> However, in bug reporting or analysis scenarios, the first question
>>> normally asked is which TDX Module version is on your system, to determine
>>> if this is a known issue or a new regression.
>>>
>>> To address this issue, this series exposes the TDX Module version as
>>> sysfs attributes of the tdx_host device [*] and also prints it in dmesg
>>> to keep a record.
>>
>> The version information is also useful for the guest. Maybe we should
>> provide consistent interface for both sides?
>
> Note that only the Major and Minor versions (like 1.5 or 2.0) are available to
> the guest; the TDX Module doesn't allow guests to read the update version.
> Given this limitation, exposing version information to guests isn't
> particularly useful.
>
> And in my opinion, exposing version information to guests is also unnecessary
> since the module version can already be read from the host with this series.
> In debugging scenarios, I'm not sure why the TDX module would be so special
> that guests should know its version but not other host information, such as
> host kernel version, microcode version, etc. None of these are exposed to guest
> kernel (not to mention guest userspace).
>
Just my 2 cents on the topic:
One thing which comes to mind is that the information to be provided to
the guest should ideally come from the hypervisor, for debugging
purposes at least, i.e via some sort of hypercall. The security model of
TDX is to ascertain information about the host via the attestation
mechanism, no? So I'd argue that the version information provided to the
guest is of no importance
^ permalink raw reply
* Re: [PATCH v2 0/3] Expose TDX Module version
From: Chao Gao @ 2026-01-06 6:47 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: kvm, linux-coco, linux-kernel, x86, vishal.l.verma, kai.huang,
dan.j.williams, yilun.xu, vannapurve, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Ingo Molnar, Rick Edgecombe,
Thomas Gleixner
In-Reply-To: <dfb66mcbxqw2a6qjyg74jqp7aucmnkztl224rj3u6znrcr7ukw@yy65kqagdsoh>
On Mon, Jan 05, 2026 at 10:38:19AM +0000, Kiryl Shutsemau wrote:
>On Sun, Jan 04, 2026 at 11:43:43PM -0800, Chao Gao wrote:
>> Hi reviewers,
>>
>> This series is quite straightforward and I believe it's well-polished.
>> Please consider providing your ack tags. However, since it depends on
>> two other series (listed below), please review those dependencies first if
>> you haven't already.
>>
>> Changes in v2:
>> - Print TDX Module version in demsg (Vishal)
>> - Remove all descriptions about autogeneration (Rick)
>> - Fix typos (Kai)
>> - Stick with TDH.SYS.RD (Dave/Yilun)
>> - Rebase onto Sean's VMXON v2 series
>>
>> === Problem & Solution ===
>>
>> Currently, there is no user interface to get the TDX Module version.
>> However, in bug reporting or analysis scenarios, the first question
>> normally asked is which TDX Module version is on your system, to determine
>> if this is a known issue or a new regression.
>>
>> To address this issue, this series exposes the TDX Module version as
>> sysfs attributes of the tdx_host device [*] and also prints it in dmesg
>> to keep a record.
>
>The version information is also useful for the guest. Maybe we should
>provide consistent interface for both sides?
Note that only the Major and Minor versions (like 1.5 or 2.0) are available to
the guest; the TDX Module doesn't allow guests to read the update version.
Given this limitation, exposing version information to guests isn't
particularly useful.
And in my opinion, exposing version information to guests is also unnecessary
since the module version can already be read from the host with this series.
In debugging scenarios, I'm not sure why the TDX module would be so special
that guests should know its version but not other host information, such as
host kernel version, microcode version, etc. None of these are exposed to guest
kernel (not to mention guest userspace).
^ permalink raw reply
* Re: [PATCH v2 0/4] Enforce host page-size alignment for shared buffers
From: Aneesh Kumar K.V @ 2026-01-06 6:39 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: linux-kernel, iommu, linux-coco, Catalin Marinas, will, maz, tglx,
robin.murphy, suzuki.poulose, akpm, steven.price
In-Reply-To: <20260106011143.GP125261@ziepe.ca>
Jason Gunthorpe <jgg@ziepe.ca> writes:
> On Sun, Dec 21, 2025 at 09:39:16PM +0530, Aneesh Kumar K.V (Arm) wrote:
>> Hi all,
>>
>> This patch series addresses alignment requirements for buffers shared between
>> private-memory guests and the host.
>>
>> When running private-memory guests, the guest kernel must apply additional
>> constraints when allocating buffers that are shared with the hypervisor. These
>> shared buffers are also accessed by the host kernel and therefore must be
>> aligned to the host’s page size.
>>
>> Architectures such as Arm can tolerate realm physical address space PFNs being
>> mapped as shared memory, as incorrect accesses are detected and reported as GPC
>> faults. However, relying on this mechanism alone is unsafe and can still lead to
>> kernel crashes.
>>
>> This is particularly likely when guest_memfd allocations are mmapped and
>> accessed from userspace. Once exposed to userspace, it is not possible to
>> guarantee that applications will only access the intended 4K shared region
>> rather than the full 64K page mapped into their address space. Such userspace
>> addresses may also be passed back into the kernel and accessed via the linear
>> map, potentially resulting in a GPC fault and a kernel crash.
>>
>> To address this, the series introduces a new helper, `mem_encrypt_align()`,
>> which allows callers to enforce the required alignment for shared buffers.
>
> This explanation makes sense, but to maybe bottom line the requirement
> to something very simple..
>
> In ARM64 the guest shared/private granule size must be >= the
> hypervisor PAGE_SIZE, which may be larger than the VM's natural
> PAGE_SIZE.
>
> Meaning we have to go through an change all the places doing
> shared/private stuff to work on a shared/private granual size. I think
> this is not just alignment, but allocation size as well?
>
That is correct. I updated the commit message to
These shared buffers are also accessed by the host kernel and therefore
must be aligned to the host’s page size, and have a size that is a
multiple of the host page size.
-aneesh
^ permalink raw reply
* Re: [PATCH v2 1/4] swiotlb: dma: its: Enforce host page-size alignment for shared buffers
From: Aneesh Kumar K.V @ 2026-01-06 6:37 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: linux-kernel, iommu, linux-coco, Catalin Marinas, will, maz, tglx,
robin.murphy, suzuki.poulose, akpm, steven.price
In-Reply-To: <20260106011636.GQ125261@ziepe.ca>
Jason Gunthorpe <jgg@ziepe.ca> writes:
> On Sun, Dec 21, 2025 at 09:39:17PM +0530, Aneesh Kumar K.V (Arm) wrote:
>> +#define mem_encrypt_align mem_encrypt_align
>> +static inline size_t mem_encrypt_align(size_t size)
>> +{
>> + return size;
>> +}
>> +
>
> IMHO this is the wrong API.
>
> The issue here is not about alignment, it is about the permitted
> granule size for shared/private.
>
> On X86 this will be PAGE_SIZE on ARM64 it is
> max(hypervisor_page_size, PAGE_SIZE)
>
> So think the arch helper should simply be
>
> __pure size_T mem_encrypt_granule_size(void);
>
>> + if (WARN_ON(!IS_ALIGNED(addr, mem_encrypt_align(PAGE_SIZE))))
>> + return 0;
>> +
>> + if (WARN_ON(!IS_ALIGNED(numpages << PAGE_SHIFT, mem_encrypt_align(PAGE_SIZE))))
>> + return 0;
>
> And then we don't end up with weiro reading stuff like this..
>
> if (WARN_ON(!IS_ALIGNED(addr, mem_encrypt_granule_size())) ||
> WARN_ON(!IS_ALIGNED(numpages, mem_encrypt_granule_size() / PAGE_SIZE)))
>
> Is much more readable..
>
I added this helper
>> @@ -319,8 +319,8 @@ static void __init *swiotlb_memblock_alloc(unsigned long nslabs,
>> unsigned int flags,
>> int (*remap)(void *tlb, unsigned long nslabs))
>> {
>> - size_t bytes = PAGE_ALIGN(nslabs << IO_TLB_SHIFT);
>> void *tlb;
>> + size_t bytes = mem_encrypt_align(nslabs << IO_TLB_SHIFT);
>
> The stuff like this is just ALING(nslabs << IO_TLB_SHIFT, mem_encrypt_granule_size())
>
I guess we can still keep mem_encrypt_align so that changes like below
becomes simpler.
- int page_order = get_order(min_size);
+ int page_order = get_order(mem_encrypt_align(min_size));
-aneesh
^ permalink raw reply
* Re: [PATCH v4 04/16] x86/virt/tdx: Allocate page bitmap for Dynamic PAMT
From: Xu Yilun @ 2026-01-06 4:01 UTC (permalink / raw)
To: Edgecombe, Rick P
Cc: kvm@vger.kernel.org, linux-coco@lists.linux.dev, Huang, Kai,
Li, Xiaoyao, Hansen, Dave, Zhao, Yan Y, Wu, Binbin,
kas@kernel.org, seanjc@google.com, mingo@redhat.com,
linux-kernel@vger.kernel.org, pbonzini@redhat.com,
Yamahata, Isaku, kirill.shutemov@linux.intel.com,
tglx@linutronix.de, Annapurve, Vishal, Gao, Chao, bp@alien8.de,
x86@kernel.org
In-Reply-To: <0734a6cc7da3d210f403fdf3e0461ffba6b0aea0.camel@intel.com>
On Mon, Jan 05, 2026 at 10:06:31PM +0000, Edgecombe, Rick P wrote:
> On Wed, 2025-12-24 at 17:10 +0800, Xu Yilun wrote:
> > Is it better we seal the awkward pattern inside the if (dpamt supported) block:
> >
> > if (tdx_support_dynamic_pamt(&tdx_sysinfo))
> > if (!ret && !(ret = read_sys_metadata_field(0x9100000100000013, &val)))
> > sysinfo_tdmr->pamt_page_bitmap_entry_bits = val;
>
> The extra indentation might be objectionable.
Yes the extra indentation is unconventional, but everything here is, and
we know we will eventually change them all. So I more prefer simple
changes based on:
if (!ret && !(ret = read_sys_metadata_field(0xABCDEF, &val)))
rather than neat but more LOC (when both are easy to read).
Anyway, this is trivial concern. I have more optional fields to add and
will follow the final decision.
^ permalink raw reply
* Re: "Paravisor" Feature Enumeration
From: dan.j.williams @ 2026-01-06 3:24 UTC (permalink / raw)
To: Dave Hansen, dan.j.williams, Lange, Jon
Cc: Sean Christopherson, Paolo Bonzini, john.starks, Will Deacon,
Mark Rutland, linux-coco@lists.linux.dev, LKML,
Kirill A. Shutemov, Edgecombe, Rick P, Andrew Cooper
In-Reply-To: <71f42b9e-793b-4f8d-8159-a6ca7800f292@intel.com>
Dave Hansen wrote:
> On 1/5/26 16:01, dan.j.williams@intel.com wrote:
> > Dave Hansen wrote:
> ...
> >> X86_FEATURE_KVM_CLOCKSOURCE in arm,pvclock
> >> or
> >> X86_FEATURE_KVM_STEAL_TIME in arm,kvm-steal-time
> >>
> >> As far as I can tell, these aliases are all done ad-hoc. This approach
> >> could obviously be extended to paravisor features, but it would probably
> >> be on the slow side to do it for each new feature.
> >
> > "Slow" as in standardization time?
>
> Yes.
That speed problem is mitigated by the EFI/ACPI Code First process.
Linux and any other impacted implementation that want to be party to a
new mechanism just come to a public agreement on the mailing lists per
usual and ACPI Working Group acks/naks that public proposal. That
effectively gets you in the same ballpark of time as landing a new
invented Linux enumeration upstream.
There is a lag between the ack and the spec release, but the intention
is the ack means it is safe to assume a future version of the
specification will adopt the change.
^ permalink raw reply
* Re: [PATCH v2] PCI/IDE: Fix duplicate stream symlink names for TSM class devices
From: Xu Yilun @ 2026-01-06 1:59 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-coco, linux-pci, dan.j.williams, yilun.xu, baolu.lu,
zhenzhong.duan, linux-kernel, yi1.lai, helgaas
In-Reply-To: <20260105101317.00003ade@huawei.com>
On Mon, Jan 05, 2026 at 10:13:17AM +0000, Jonathan Cameron wrote:
> On Mon, 5 Jan 2026 17:35:16 +0800
> Xu Yilun <yilun.xu@linux.intel.com> wrote:
>
> > The name streamH.R.E is used for 2 symlinks:
> >
> > 1. TSM class devices: /sys/class/tsm/tsmN/streamH.R.E
> > 2. host bridge devices: /sys/devices/pciDDDD:BB/streamH.R.E
>
> For those who have managed to completely forget, it would be useful
> to just mention what H R and E are. Given the docs
> say H is the host bridge number I'm a little confused why it
> isn't unique. At least at first glance I'd expect to see
No, the Documentation/ABI/testing/sysfs-devices-pci-host-bridge says
H represents a Stream ID slot (or a Stream index) within the host
bridge's context, not the host bridge index itself. So do R/E.
> stream0.0.0 and stream 1.0.0 your example.
> Maybe H isn't unique across segments / PCI Domains? (DDDD in the above)
> Maybe it should be?
No. The counter of H along with the pciDDDD:BB/available_secure_streams,
indicate the platform hardware limitation on the maximum number of
Streams a host bridge can support. It should not be a global counter
across System.
Thanks,
Yilun
^ permalink raw reply
* RE: [EXTERNAL] Re: "Paravisor" Feature Enumeration
From: Jon Lange @ 2026-01-06 2:12 UTC (permalink / raw)
To: Andrew Cooper, Dave Hansen
Cc: Williams, Dan J, Sean Christopherson, Paolo Bonzini, John Starks,
Will Deacon, Mark Rutland, linux-coco@lists.linux.dev, LKML,
Kirill A. Shutemov, Edgecombe, Rick P
In-Reply-To: <4f3e1701-3ccd-4ee8-a45e-3872d71ef548@citrix.com>
Andrew wrote:
> Are we saying that, inside an opaque blob that a customer provides to a CSP to run we might have:
> * a paravisor and an unaware OS, or
> * svsm and a fully-aware OS, or
> * something in-between these two.
> and we're looking a way to describe which piece of the interior stack owns which capability/service?
> I think the discussion would benefit greatly from having a couple of concrete examples of data this wants to hold,
> and how it is to be used at different levels of the interior software stack.
Here are two examples. In both examples, the OS is running behind a paravisor but I wouldn't term it an "unaware OS". Rather, the paravisor is present because of the set of services it provides, and it is running in paravisor mode (not SVSM mode) because the implementation benefits from taking full management responsibility for the confidential trust boundary (e.g. determination of when/how to validate/accept pages). In such a configuration, where the paravisor has management responsibility for the confidential trust boundary, all of the enlightenments in the guest OS for managing confidentiality state must be suppressed. The straightforward way to do this is for the paravisor to suppress the confidential VM enumeration information visible to the guest OS (the "SNP available" CPUID bit, or the "TDX active" bit, for example).
Note that this occurs out of necessity because we can't have the paravisor and the guest OS fighting over who has the right/responsibility to execute PVALIDATE, or TDG.MEM.PAGE.ACCEPT, or whatever. The kernel today only has two concepts of its execution mode: either it is a confidential VM, in which case it takes full responsibility, or it is not a confidential VM, in which case it ignores the responsibility. When a paravisor (not SVSM) is active, we have to operate in the second mode because the first mode would provoke precisely the conflict we're trying to avoid.
First example: a confidential VM running under a paravisor wants to obtain an attestation report for itself to pass to a third party to vouch for the fact that it is a confidential VM. Assume in this example that the relying party is aware of the paravisor and the paravisor's measurements, so the evidence provided in such an attestation report can successfully be verified as authentic. In order for this to be possible, the kernel has to know that it's running in a confidential VM in a mode where attestation reports are available but where the responsibility for confidential memory state management is suppressed. This is a third state beyond the two states described above. This isn't just a userspace problem because access to the attestation service is mediated by a kernel-mode driver that needs to know how to configure itself (such configuration today is based on CPUID and not on ACPI).
Second example: a confidential VM running under a paravisor determines that one of the devices available to it is a TDISP device that requires the OS - not the paravisor - to perform the operations required to configure the device, to obtain and verify its attestation information, and to consent to activating the device in the TDISP RUN state. In order for the OS to be able to execute that sequence, the device has to know that it is running as a confidential VM so it knows that TDISP configuration may be necessary.
We can quibble about whether there are better ways to accomplish these specific scenarios - for example, you could say that the availability of the attestation device should be handled by ACPI instead of CPUID and thus the firmware should take responsibility for figuring out whether it's present, and you could say that the PCI subsystem uses some additional information (possibly more ACPI information) to indicate that TDISP devices may be present. However, these two examples are far from an exhaustive list and it's hard to imagine that we won't discover a third or fourth scenario that doesn't lend itself to bootstrapping in the firmware (and I'm even convinced that these two scenarios can neatly be handled by firmware conventions). Defining "paravisor mode" gives us one more tool to figure out how to enable confidential services without requiring confidential management.
-Jon
-----Original Message-----
From: Andrew Cooper <andrew.cooper3@citrix.com>
Sent: Monday, January 5, 2026 5:45 PM
To: Dave Hansen <dave.hansen@intel.com>; Jon Lange <jlange@microsoft.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>; Williams, Dan J <dan.j.williams@intel.com>; Sean Christopherson <seanjc@google.com>; Paolo Bonzini <pbonzini@redhat.com>; John Starks <John.Starks@microsoft.com>; Will Deacon <will@kernel.org>; Mark Rutland <mark.rutland@arm.com>; linux-coco@lists.linux.dev; LKML <linux-kernel@vger.kernel.org>; Kirill A. Shutemov <kirill.shutemov@linux.intel.com>; Edgecombe, Rick P <rick.p.edgecombe@intel.com>
Subject: [EXTERNAL] Re: "Paravisor" Feature Enumeration
On 05/01/2026 9:42 pm, Dave Hansen wrote:
> First,
>
> Jon and John gave a talk in Tokyo about feature enumeration under
> paravisors:
>
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flpc
>> .events%2Fevent%2F19%2Fcontributions%2F2188%2Fattachments%2F1896%2F40
>> 57%2F05-Paravisor-Integration-with-Confidential-Services.pdf&data=05%
>> 7C02%7Cjlange%40microsoft.com%7C27436f719e4c465067c008de4cc53851%7C72
>> f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639032607107200108%7CUnknown
>> %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW
>> 4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Yr7zgaybC%2
>> FVrIWbX3%2BVkUVDxJz8OUVsSu7EzG2hUn%2BI%3D&reserved=0
> The tl;dr for me at least was that they'd like a common and consistent
> means of enumerating these features in OSes, regardless of the
> environment: TDX, SEV-SNP or even ARM CCA.
I agree that it seems like "just" an enumeration problem, but despite attending the presentation and rereading the slides, I'm still not clear on the precise scope.
Are we saying that, inside an opaque blob that a customer provides to a CSP to run we might have:
* a paravisor and an unaware OS, or
* svsm and a fully-aware OS, or
* something in-between these two.
and we're looking a way to describe which piece of the interior stack owns which capability/service?
If so, it can't come in from the outside; given that it's the capability enumeration, there's a chicken/egg problem with verifying the integrity.
It seems like it needs to be produced by whatever the first code to run is, after gathering capabilities in a vendor-specific way, and deciding which services it wants to provide, and which to delegate.
And if so, then it definitely cannot be in CPUID because that needs to be fixed from prior to the guest starting to run, and doesn't express dynamic properties of the system[*]
I think the discussion would benefit greatly from having a couple of concrete examples of data this wants to hold, and how it is to be used at different levels of the interior software stack.
Thanks,
~Andrew
[*] Yes, I know CPUID does have some dynamic properties. I think most people would agree that life would be better without them.
^ permalink raw reply
* Re: "Paravisor" Feature Enumeration
From: Andrew Cooper @ 2026-01-06 1:44 UTC (permalink / raw)
To: Dave Hansen, Lange, Jon
Cc: Andrew Cooper, Williams, Dan J, Sean Christopherson,
Paolo Bonzini, john.starks, Will Deacon, Mark Rutland,
linux-coco@lists.linux.dev, LKML, Kirill A. Shutemov,
Edgecombe, Rick P
In-Reply-To: <c4ef08a6-5600-4604-9e40-bd3263a0dcd3@intel.com>
On 05/01/2026 9:42 pm, Dave Hansen wrote:
> First,
>
> Jon and John gave a talk in Tokyo about feature enumeration under
> paravisors:
>
>> https://lpc.events/event/19/contributions/2188/attachments/1896/4057/05-Paravisor-Integration-with-Confidential-Services.pdf
> The tl;dr for me at least was that they'd like a common and consistent
> means of enumerating these features in OSes, regardless of the
> environment: TDX, SEV-SNP or even ARM CCA.
I agree that it seems like "just" an enumeration problem, but despite
attending the presentation and rereading the slides, I'm still not clear
on the precise scope.
Are we saying that, inside an opaque blob that a customer provides to a
CSP to run we might have:
* a paravisor and an unaware OS, or
* svsm and a fully-aware OS, or
* something in-between these two.
and we're looking a way to describe which piece of the interior stack
owns which capability/service?
If so, it can't come in from the outside; given that it's the capability
enumeration, there's a chicken/egg problem with verifying the integrity.
It seems like it needs to be produced by whatever the first code to run
is, after gathering capabilities in a vendor-specific way, and deciding
which services it wants to provide, and which to delegate.
And if so, then it definitely cannot be in CPUID because that needs to
be fixed from prior to the guest starting to run, and doesn't express
dynamic properties of the system[*]
I think the discussion would benefit greatly from having a couple of
concrete examples of data this wants to hold, and how it is to be used
at different levels of the interior software stack.
Thanks,
~Andrew
[*] Yes, I know CPUID does have some dynamic properties. I think most
people would agree that life would be better without them.
^ permalink raw reply
* Re: [PATCH v2 1/4] swiotlb: dma: its: Enforce host page-size alignment for shared buffers
From: Jason Gunthorpe @ 2026-01-06 1:16 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm)
Cc: linux-kernel, iommu, linux-coco, Catalin Marinas, will, maz, tglx,
robin.murphy, suzuki.poulose, akpm, steven.price
In-Reply-To: <20251221160920.297689-2-aneesh.kumar@kernel.org>
On Sun, Dec 21, 2025 at 09:39:17PM +0530, Aneesh Kumar K.V (Arm) wrote:
> +#define mem_encrypt_align mem_encrypt_align
> +static inline size_t mem_encrypt_align(size_t size)
> +{
> + return size;
> +}
> +
IMHO this is the wrong API.
The issue here is not about alignment, it is about the permitted
granule size for shared/private.
On X86 this will be PAGE_SIZE on ARM64 it is
max(hypervisor_page_size, PAGE_SIZE)
So think the arch helper should simply be
__pure size_T mem_encrypt_granule_size(void);
> + if (WARN_ON(!IS_ALIGNED(addr, mem_encrypt_align(PAGE_SIZE))))
> + return 0;
> +
> + if (WARN_ON(!IS_ALIGNED(numpages << PAGE_SHIFT, mem_encrypt_align(PAGE_SIZE))))
> + return 0;
And then we don't end up with weiro reading stuff like this..
if (WARN_ON(!IS_ALIGNED(addr, mem_encrypt_granule_size())) ||
WARN_ON(!IS_ALIGNED(numpages, mem_encrypt_granule_size() / PAGE_SIZE)))
Is much more readable..
> @@ -319,8 +319,8 @@ static void __init *swiotlb_memblock_alloc(unsigned long nslabs,
> unsigned int flags,
> int (*remap)(void *tlb, unsigned long nslabs))
> {
> - size_t bytes = PAGE_ALIGN(nslabs << IO_TLB_SHIFT);
> void *tlb;
> + size_t bytes = mem_encrypt_align(nslabs << IO_TLB_SHIFT);
The stuff like this is just ALING(nslabs << IO_TLB_SHIFT, mem_encrypt_granule_size())
etc
Jason
^ permalink raw reply
* Re: [PATCH v2 0/4] Enforce host page-size alignment for shared buffers
From: Jason Gunthorpe @ 2026-01-06 1:11 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm)
Cc: linux-kernel, iommu, linux-coco, Catalin Marinas, will, maz, tglx,
robin.murphy, suzuki.poulose, akpm, steven.price
In-Reply-To: <20251221160920.297689-1-aneesh.kumar@kernel.org>
On Sun, Dec 21, 2025 at 09:39:16PM +0530, Aneesh Kumar K.V (Arm) wrote:
> Hi all,
>
> This patch series addresses alignment requirements for buffers shared between
> private-memory guests and the host.
>
> When running private-memory guests, the guest kernel must apply additional
> constraints when allocating buffers that are shared with the hypervisor. These
> shared buffers are also accessed by the host kernel and therefore must be
> aligned to the host’s page size.
>
> Architectures such as Arm can tolerate realm physical address space PFNs being
> mapped as shared memory, as incorrect accesses are detected and reported as GPC
> faults. However, relying on this mechanism alone is unsafe and can still lead to
> kernel crashes.
>
> This is particularly likely when guest_memfd allocations are mmapped and
> accessed from userspace. Once exposed to userspace, it is not possible to
> guarantee that applications will only access the intended 4K shared region
> rather than the full 64K page mapped into their address space. Such userspace
> addresses may also be passed back into the kernel and accessed via the linear
> map, potentially resulting in a GPC fault and a kernel crash.
>
> To address this, the series introduces a new helper, `mem_encrypt_align()`,
> which allows callers to enforce the required alignment for shared buffers.
This explanation makes sense, but to maybe bottom line the requirement
to something very simple..
In ARM64 the guest shared/private granule size must be >= the
hypervisor PAGE_SIZE, which may be larger than the VM's natural
PAGE_SIZE.
Meaning we have to go through an change all the places doing
shared/private stuff to work on a shared/private granual size. I think
this is not just alignment, but allocation size as well?
Jason
^ permalink raw reply
* Re: "Paravisor" Feature Enumeration
From: Sean Christopherson @ 2026-01-06 1:08 UTC (permalink / raw)
To: Dave Hansen
Cc: dan.j.williams, Jon Lange, Paolo Bonzini, john.starks,
Will Deacon, Mark Rutland, linux-coco@lists.linux.dev, LKML,
Kirill A. Shutemov, Rick P Edgecombe, Andrew Cooper
In-Reply-To: <71f42b9e-793b-4f8d-8159-a6ca7800f292@intel.com>
On Mon, Jan 05, 2026, Dave Hansen wrote:
> On 1/5/26 16:01, dan.j.williams@intel.com wrote:
> > Dave Hansen wrote:
> ...
> >> X86_FEATURE_KVM_CLOCKSOURCE in arm,pvclock
> >> or
> >> X86_FEATURE_KVM_STEAL_TIME in arm,kvm-steal-time
> >>
> >> As far as I can tell, these aliases are all done ad-hoc. This approach
> >> could obviously be extended to paravisor features, but it would probably
> >> be on the slow side to do it for each new feature.
> >
> > "Slow" as in standardization time?
>
> Yes.
>
> ...
> >> Is there anything stopping us from carving out a chunk of CPUID for
> >> this purpose?
> >
> > At what point does an ACPI property become a CPUID? In other words if
> > there is an ACPI / DeviceTree enumeration of CPU/platform capabilities
> > in firmware that can supsersede / extend native enumeration, does it
> > matter if x86 maps that to extended CPUID space and ARM maps it however
> > is convenient?
> >
> > I have no problem with an extended CPUID concept, just trying to
> > understand more about the assumptions.
>
> The way it _seems_ to have worked until now is that KVM/x86 has led the
> way by defining a CPUID bit for things like KVM_CLOCK of KVM_STEAL_TIME.
> Then, the ARM folks came along and DeviceTree enumerations. Last, ACPI
> came along with a way to package up all the DeviceTree enumerations into
> a single table.
>
> So, maybe that's a hack on a hack on a hack and we should just start
> with ACPI this time. That would certainly make this pretty straightforward.
>
> I'd love to hear a take from the x86/KVM folks, though.
KVM x86 is blissfully unaware of ACPI. I believe the same goes for DeviceTree on
ARM64, but don't quote me on that. I can't envision a world where KVM would ever
enumerate or parse ACPI, let alone make ACPI a hard requirement, so any features
that need KVM support need KVM specific uAPI and/or arch-specific enumeration.
KVM uses CPUID for *KVM-defined* PV features on x86 because KVM already advertises
support for CPUID-based features via KVM_GET_SUPPORTED_CPUID. And KVM is handed a
userspace-defined virtual CPU module that includes virtual CPUID information
(KVM_SET_CPUID{,2}), which KVM can then use to know whether or not a feature is
enabled for a given guest. I.e. using CPUID gets KVM all the uAPI and guest ABI
it needs for super cheap.
PV features/devices that are provided solely by the VMM are a completely different
matter. E.g. KVM similiar has no direct knowledge of VirtIO. There are plenty of
optimizations in KVM that exist to make VirtIO go faster, but like ACPI, KVM is
blissfully unaware of what VirtIO devices are exposed to a guest, where they reside
in the platform topology, how they are enumerated to the guest, etc.
Concretely, exactly what type of PV features are we talking about? To me,
"Confidential Services" sounds like things that should be implemented as virtual
devices in userspace, attached via whatever bus the VMM is using (e.g. vmbus vs.
PCIe), and enumerated to the guest via whatever mechanism the VMM chooses (which
on x86 is pretty much guaranteed to be ACPI).
Trying to use CPUID for any such virtual devices will never fly in a KVM-based
setup (outside of completely private/proprietary environments). KVM shouldn't
ever accept a patch to define a CPUID feature for something that is conceptually
a device, and Linux-as-a-guest shouldn't ever accept a patch to consume CPUID
entries defined by a VMM (even if that VMM is QEMU).
So unless we're talking about services that require specific, dedicated KVM
support, i.e. where the KVM involvement can't be abstracted in some generic way,
I don't think there's a whole lot to discuss (in a good way).
^ permalink raw reply
* Re: "Paravisor" Feature Enumeration
From: Dave Hansen @ 2026-01-06 0:46 UTC (permalink / raw)
To: Jon Lange, dan.j.williams@intel.com
Cc: Sean Christopherson, Paolo Bonzini, John Starks, Will Deacon,
Mark Rutland, linux-coco@lists.linux.dev, LKML,
Kirill A. Shutemov, Edgecombe, Rick P, Andrew Cooper
In-Reply-To: <CH8PR21MB52221DBBF4D87FC24013FACFCA87A@CH8PR21MB5222.namprd21.prod.outlook.com>
On 1/5/26 16:10, Jon Lange wrote:
> It's not clear to me what advantages are gained by reflecting ACPI
> information into CPUID. ACPI is already available and is usable
> across architectures, unlike CPUID. What advantage is gained by
> replicating the information into CPUID?
If there is an ACPI approach that is expressive and agile enough to
convey the necessary information, then there's zero reason to replicate
it anywhere, CPUID included.
Like I said in the mail to Dan, I _think_ the current state of the art
for host=>guest enumeration involves ACPI wrapping DeviceTree properties
on ARM which mirror x86 CPUID bits.
> In the LPC session that Dave cites, Dan (I think it was Dan) threw
> out another suggestion: have the hypervisor driver detect the
> paravisor configuration using whatever is appropriate for that
> hypervisor architecture. I find this to be a very attractive
> direction because it eliminates the need to define standards that
> can be supported across hypervisors (and across virtual firmware
> implementations), and reduces it just to a small set of concepts
> that can be fed into the kernel. This could keep the enumeration
> out of the hands of ACPI altogether - thus no slow standards
> development. Are there downsides to this approach that make it
> unattractive?
I think you're saying that we'd have a fixed set of Linux-defined
features. Hypervisor drivers would set the features up. Generic,
architecture and vendor-neutral code would consume the feature enumeration.
That sounds familiar and sane to me. It's generally what we have with
the Linux-defined X86_FEATURE_* bits. Linux defines their behavior and
consumes them in generic code. x86 vendor-specific code sets them.
^ permalink raw reply
* Re: "Paravisor" Feature Enumeration
From: Dave Hansen @ 2026-01-06 0:36 UTC (permalink / raw)
To: dan.j.williams, Lange, Jon
Cc: Sean Christopherson, Paolo Bonzini, john.starks, Will Deacon,
Mark Rutland, linux-coco@lists.linux.dev, LKML,
Kirill A. Shutemov, Edgecombe, Rick P, Andrew Cooper
In-Reply-To: <695c50eee68e3_4b7a100e8@dwillia2-mobl4.notmuch>
On 1/5/26 16:01, dan.j.williams@intel.com wrote:
> Dave Hansen wrote:
...
>> X86_FEATURE_KVM_CLOCKSOURCE in arm,pvclock
>> or
>> X86_FEATURE_KVM_STEAL_TIME in arm,kvm-steal-time
>>
>> As far as I can tell, these aliases are all done ad-hoc. This approach
>> could obviously be extended to paravisor features, but it would probably
>> be on the slow side to do it for each new feature.
>
> "Slow" as in standardization time?
Yes.
...
>> Is there anything stopping us from carving out a chunk of CPUID for
>> this purpose?
>
> At what point does an ACPI property become a CPUID? In other words if
> there is an ACPI / DeviceTree enumeration of CPU/platform capabilities
> in firmware that can supsersede / extend native enumeration, does it
> matter if x86 maps that to extended CPUID space and ARM maps it however
> is convenient?
>
> I have no problem with an extended CPUID concept, just trying to
> understand more about the assumptions.
The way it _seems_ to have worked until now is that KVM/x86 has led the
way by defining a CPUID bit for things like KVM_CLOCK of KVM_STEAL_TIME.
Then, the ARM folks came along and DeviceTree enumerations. Last, ACPI
came along with a way to package up all the DeviceTree enumerations into
a single table.
So, maybe that's a hack on a hack on a hack and we should just start
with ACPI this time. That would certainly make this pretty straightforward.
I'd love to hear a take from the x86/KVM folks, though.
^ 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