From: <dan.j.williams@intel.com>
To: Jon Lange <jlange@microsoft.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Dave Hansen <dave.hansen@intel.com>
Cc: "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" <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
Date: Tue, 6 Jan 2026 17:58:19 -0800 [thread overview]
Message-ID: <695dbdbb37d41_4b7a1003@dwillia2-mobl4.notmuch> (raw)
In-Reply-To: <CH8PR21MB5222D4771880715FC8104835CA87A@CH8PR21MB5222.namprd21.prod.outlook.com>
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.
next prev parent reply other threads:[~2026-01-07 1:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-05 21:42 "Paravisor" Feature Enumeration Dave Hansen
2026-01-06 0:01 ` dan.j.williams
2026-01-06 0:10 ` [EXTERNAL] " Jon Lange
2026-01-06 0:46 ` Dave Hansen
2026-01-06 0:36 ` Dave Hansen
2026-01-06 1:08 ` Sean Christopherson
2026-01-06 3:24 ` dan.j.williams
2026-01-06 1:44 ` Andrew Cooper
2026-01-06 2:12 ` [EXTERNAL] " Jon Lange
2026-01-06 22:39 ` Andrew Cooper
2026-01-06 23:01 ` Jon Lange
2026-01-07 1:58 ` dan.j.williams [this message]
2026-01-07 2:48 ` Jon Lange
2026-01-07 18:42 ` dan.j.williams
2026-01-08 6:53 ` Jon Lange
2026-01-07 12:06 ` Kiryl Shutsemau
2026-01-06 19:17 ` Edgecombe, Rick P
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=695dbdbb37d41_4b7a1003@dwillia2-mobl4.notmuch \
--to=dan.j.williams@intel.com \
--cc=John.Starks@microsoft.com \
--cc=andrew.cooper3@citrix.com \
--cc=dave.hansen@intel.com \
--cc=jlange@microsoft.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox