Skip to content

Conversation

mfrohlich-msft
Copy link
Contributor

@mfrohlich-msft mfrohlich-msft commented Oct 2, 2025

This PR begins part of the process of merging the TDISP (Confidential VM Device Attestation + Encryption) prototype code into main and is part of a larger patch set split between other PRs to follow.

This PR adds dependencies for TDISP implementation and traits used by both host code and OpenHCL.

  • openhcl/openhcl_tdisp: Adds openhcl_tdisp crate which contains the implementation and traits for communicating with virtual devices that are TDISP capable.
  • vm/devices/tdisp: Adds tdisp crate which implements shared types and traits used across the guest to host boundary. This includes the serialization code for the custom guest-to-host protocol used to interface with the host VMM stack from the guest.
  • Cargo.toml: Adds crates to root Cargo.toml
  • openhcl/underhill_core: Adds tdisp and openhcl_tdisp to be built into underhill_core, although none of these crates are used yet as of this PR.

@mfrohlich-msft mfrohlich-msft requested review from a team as code owners October 2, 2025 20:37
@Copilot Copilot AI review requested due to automatic review settings October 2, 2025 20:37
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR introduces the TDISP (Confidential VM Device Attestation + Encryption) framework by adding new crates that implement the host-guest communication protocol and device state management. This is part of a larger effort to merge TDISP prototype code into the main codebase.

  • Adds foundational TDISP types, serialization, and device state machine for secure device attestation
  • Introduces OpenHCL client interfaces for TDISP-capable devices in guest partitions
  • Establishes the shared communication protocol between host and guest for device assignment flows

Reviewed Changes

Copilot reviewed 9 out of 10 changed files in this pull request and generated 5 comments.

Show a summary per file
File Description
vm/devices/tdisp/src/lib.rs Core TDISP implementation with state machine, host device interfaces, and operation error handling
vm/devices/tdisp/src/serialize.rs Serialization/deserialization for guest-to-host command and response packets
vm/devices/tdisp/src/devicereport.rs Device report types and TDI interface report parsing for attestation
vm/devices/tdisp/src/command.rs Command and response structures for the guest-to-host TDISP protocol
vm/devices/tdisp/Cargo.toml Cargo configuration for the core TDISP device crate
openhcl/openhcl_tdisp/src/lib.rs OpenHCL client device traits for TDISP communication in guest partitions
openhcl/openhcl_tdisp/Cargo.toml Cargo configuration for the OpenHCL TDISP client crate
openhcl/underhill_core/Cargo.toml Adds TDISP dependencies to OpenHCL core
Cargo.toml Registers new TDISP crates in workspace


/// Represents a TDISP device assigned to a guest partition that can be used to
/// send TDISP commands to the host through a backing interface.
pub trait VpciTdispInterface: Send + Sync {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can all these functions just be async instead of doing manual impl Futures?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the quick jump on this PR :)

I was recommended to use impl Future for traits instead of async by rust_analyzer. I believe this has to do with the way that async needs to express itself in traits vs. its implementations. I do not really understand it further than that.

}
}

impl From<u32> for TdispDeviceReportType {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again this feels like it should just be an open enum

Copy link
Contributor Author

@mfrohlich-msft mfrohlich-msft Oct 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will go back through and fix these, this was written before I knew about open_enum :)

Copy link
Contributor Author

@mfrohlich-msft mfrohlich-msft Oct 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I converted each of the old enums into the open_enum style, seems to have cleaned up a lot of the serialization considerably. The only concern I have is that because open_enum is designed to allow any discriminate value in the u64 range, this now means that match{} statements which consume it do not error out when new enum types are added to the enum. For example, if I add a new command id type, I'd expect other code that handles that to now explicitly handle the new Id in their match branches, but this now doesn't happen with open_enum. Is there a solution to this problem or am I misunderstanding something?

Copy link

github-actions bot commented Oct 2, 2025


/// MSI-X capability message control register state. Must be Clear if
/// a) capability is not supported or b) MSI-X table is not locked
pub msi_x_message_control: u16,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity, why is this only MSI-X as opposed to also the pre-X MSI?

Copy link

github-actions bot commented Oct 3, 2025

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants