[RFC] virtio-gpu: guest request for host-managed HDCP

From: Huang, Lei <hidden>
Date: 2026-09-09 08:58:49
Also in: dri-devel

AMD General

  Hi,

  We would like to discuss adding an interface that allows a
  virtio-gpu guest to request HDCP on the host connector associated
  with a guest display output.

  Our use case has a trusted host and a fixed one-to-one mapping between
  a virtio-gpu output and a physical host connector dedicated to that
  guest display output. An Android guest uses the standard DRM Content
  Protection and HDCP Content Type properties, while the host owns the
  physical connector and performs HDCP authentication.

  The intended flow is:

  1. The feature is negotiated at the device level, and the host reports
     for each guest display output whether it can service HDCP requests
     and which request parameters, such as HDCP Content Type, it
     supports.

  2. The guest driver exposes the corresponding DRM content-protection
     properties only on outputs for which the host can service such
     requests. Whether the currently connected sink can establish the
     requested protection is reflected in the resulting state rather
     than by dynamically adding or removing the properties.

  3. Guest userspace sets the DRM Content Protection property to DESIRED
     or UNDESIRED. DESIRED requests protection, while UNDESIRED withdraws
     the guest's request. When applicable, the HDCP Content Type property
     is included in the request.

  4. The virtio-gpu guest driver sends the request to the host.

  5. The host validates the request against its policy and either applies
     it to the corresponding physical connector or rejects it. The host
     remains responsible for access control, HDCP key handling, and
     authentication.

  6. The host reports the effective HDCP state for that guest display
     output.

  7. The guest driver reports ENABLED only after the host confirms that
     HDCP authentication has completed successfully. If protection is
     subsequently lost while the requested state remains DESIRED, the
     guest property returns from ENABLED to DESIRED.

  After hotplug or a virtio device reset, the guest would stop reporting
  ENABLED until the host reports that protection is active again.

  A request response would indicate whether the host accepted or
  rejected the request. Acceptance would not mean that HDCP
  authentication had completed successfully. The guest would therefore
  also need a way to query the effective state and to be notified when
  that state changes.

  This interface assumes a trusted host. It does not protect guest
  framebuffers from the host and does not claim to provide a complete
  protected media path. Hosts without a fixed mapping to a dedicated,
  controllable physical connector, such as normal windowed, VNC, or
  SPICE display backends, would not offer this feature.

  Before preparing a virtio specification proposal, we would appreciate
  feedback on the following questions:

  1. Is a fixed guest-output-to-dedicated-host-connector mapping an
     acceptable model for an optional virtio-gpu HDCP feature?

  2. Should the host expose per-output request support and current HDCP
     state through control commands, or is another virtio-gpu mechanism
     preferred?

  3. What is the preferred way to notify the guest when authentication
     completes or when an enabled HDCP link subsequently loses
     protection?

  4. Should the protocol expose HDCP-specific values, or generic
     content-protection request and state values which the guest driver
     maps to DRM properties?

  If this model is acceptable, we can follow up with a virtio
  specification RFC, a host implementation, and Linux virtio-gpu driver
  patches.


BRs,
Lei




Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help