[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