Message-ID:
 <CH8PR21MB5222DB4477497784FC170791CA84A@CH8PR21MB5222.namprd21.prod.outlook.com>
Date: Wed, 7 Jan 2026 02:48:40 +0000
From: Jon Lange <jlange@...rosoft.com>
To: "dan.j.williams@...el.com" <dan.j.williams@...el.com>, Andrew Cooper
	<andrew.cooper3@...rix.com>, Dave Hansen <dave.hansen@...el.com>
CC: Sean Christopherson <seanjc@...gle.com>, Paolo Bonzini
	<pbonzini@...hat.com>, John Starks <John.Starks@...rosoft.com>, Will Deacon
	<will@...nel.org>, Mark Rutland <mark.rutland@....com>,
	"linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>, LKML
	<linux-kernel@...r.kernel.org>, "Edgecombe, Rick P"
	<rick.p.edgecombe@...el.com>
Subject: RE: [EXTERNAL] Re: "Paravisor" Feature Enumeration

Dan W wrote:

> It sounds like the paravisor is going to hide confidential memory
> management details like page-acceptance, but it is going to advertise
> and intercept higher order operations like generate launch attestation
> report and TDISP paths like lock device, get device report, accept/run
> device.

I think that's roughly the right mental model.  The paravisor will additionally hide confidential details like MSR virtualization, I/O and MMIO handling, CPUID virtualization - all of the sorts of things that would generate #VE/#VC exceptions in a fully enlightened guest so that the guest doesn't have to worry about those, and the paravisor can provide useful functionality (like device emulation or hypervisor-type functionality) through those primitives.

> So does this paravisor need low level intercepts via pv_ops and a
> confidential memory-management model independent of TDX/SNP etc? Or,
> does it only need the higher order common "services" like attestation
> and TDISP.

I'm not following your question - I don't understand what you're envisioning when you describe confidential memory management independent of TDX/SNP.  It is the case that the paravisor is responsible for the confidentiality state of all memory, and therefore it will have some implementation to fulfill this responsibility.  It's natural for it to do so because its own operation has to integrate with the state of memory.  Following my earlier analogy that the paravisor acts like a nested hypervisor for a single (confidential) guest, the paravisor itself will have to implement all of the services necessary to satisfy the virtualization requirements of an unenlightened guest, which is far more than the "common services" that you mention.  Can you give some other examples of the sort of distinction you're trying to highlight?

-Jon

-----Original Message-----
From: dan.j.williams@...el.com <dan.j.williams@...el.com> 
Sent: Tuesday, January 6, 2026 5:58 PM
To: Jon Lange <jlange@...rosoft.com>; Andrew Cooper <andrew.cooper3@...rix.com>; Dave Hansen <dave.hansen@...el.com>
Cc: Williams, Dan J <dan.j.williams@...el.com>; Sean Christopherson <seanjc@...gle.com>; Paolo Bonzini <pbonzini@...hat.com>; John Starks <John.Starks@...rosoft.com>; Will Deacon <will@...nel.org>; Mark Rutland <mark.rutland@....com>; linux-coco@...ts.linux.dev; LKML <linux-kernel@...r.kernel.org>; Edgecombe, Rick P <rick.p.edgecombe@...el.com>
Subject: RE: [EXTERNAL] Re: "Paravisor" Feature Enumeration

Jon Lange wrote:
[..]
> > 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.

Where I get lost in this discussion is in the transition between wanting
to intercept operations like "private page acceptance" vs operations
like "guest OS is asking for an attestation report".

It sounds like the paravisor is going to hide confidential memory
management details like page-acceptance, but it is going to advertise
and intercept higher order operations like generate launch attestation
report and TDISP paths like lock device, get device report, accept/run
device.

So does this paravisor need low level intercepts via pv_ops and a
confidential memory-management model independent of TDX/SNP etc? Or,
does it only need the higher order common "services" like attestation
and TDISP.

Powered by blists - more mailing lists