From: Roman Kisel <rom...@linux.microsoft.com> Sent: Sunday, May 11, 2025 4:08 PM > > Define what the confidential VMBus is and describe what advantages > it offers on the capable hardware. > > Signed-off-by: Roman Kisel <rom...@linux.microsoft.com> > --- > Documentation/virt/hyperv/vmbus.rst | 41 +++++++++++++++++++++++++++++ > 1 file changed, 41 insertions(+) > > diff --git a/Documentation/virt/hyperv/vmbus.rst > b/Documentation/virt/hyperv/vmbus.rst > index 1dcef6a7fda3..ca2b948e5070 100644 > --- a/Documentation/virt/hyperv/vmbus.rst > +++ b/Documentation/virt/hyperv/vmbus.rst > @@ -324,3 +324,44 @@ rescinded, neither Hyper-V nor Linux retains any state > about > its previous existence. Such a device might be re-added later, > in which case it is treated as an entirely new device. See > vmbus_onoffer_rescind(). > + > +Confidential VMBus > +------------------ > + > +The confidential VMBus provides the control and data planes where > +the guest doesn't talk to either the hypervisor or the host. Instead, > +it relies on the trusted paravisor. The hardware (SNP or TDX) encrypts > +the guest memory and the register state also measuring the paravisor > +image via using the platform security processor to ensure trusted and > +confidential computing. > + > +To support confidential communication with the paravisor, a VMBus client > +will first attempt to use regular, non-isolated mechanisms for communication. > +To do this, it must: > + > +* Configure the paravisor SIMP with an encrypted page. The paravisor SIMP is > + configured by setting the relevant MSR directly, without using GHCB or > tdcall. > + > +* Enable SINT 2 on both the paravisor and hypervisor, without setting the > proxy > + flag on the paravisor SINT. Enable interrupts on the paravisor SynIC. > + > +* Configure both the paravisor and hypervisor event flags page. > + Both pages will need to be scanned when VMBus receives a channel interrupt. > + > +* Send messages to the paravisor by calling HvPostMessage directly, without > using > + GHCB or tdcall. > + > +* Set the EOM MSR directly in the paravisor, without using GHCB or tdcall. > + > +If sending the InitiateContact message using non-isolated HvPostMessage > fails, > +the client must fall back to using the hypervisor synic, by using the > GHCB/tdcall > +as appropriate. > + > +To fall back, the client will have to reconfigure the following: > + > +* Configure the hypervisor SIMP with a host-visible page. > + Since the hypervisor SIMP is not used when in confidential mode, > + this can be done up front, or only when needed, whichever makes sense for > + the particular implementation. > + > +* Set the proxy flag on SINT 2 for the paravisor.
I'm assuming there's no public documentation available for how Confidential VMBus works. If so, then this documentation needs to take a higher-level approach and explain the basic concepts. You've provided some nitty-gritty details about how to detect and enable Confidential VMBus, but I think that level of detail would be better as comments in the code. Here's an example of what I envision, with several embedded questions that need further explanation. Confidential VMBus is completely new to me, so I don't know the answers to the questions. I also think this documentation would be better added to the CoCo VM topic instead of the VMBus topic, as Confidential VMBus is an extension/enhancement to CoCo VMs that doesn't apply to normal VMs. ------------------------------------------ Confidential VMBus is an extension of Confidential Computing (CoCo) VMs (a.k.a. "Isolated" VMs in Hyper-V terminology). Without Confidential VMBus, guest VMBus device drivers (the "VSC"s in VMBus terminology) communicate with VMBus servers (the VSPs) running on the Hyper-V host. The communication must be through memory that has been decrypted so the host can access it. With Confidential VMBus, one or more of the VSPs reside in the trusted paravisor layer in the guest VM. Since the paravisor layer also operates in encrypted memory, the memory used for communication with such VSPs does not need to be decrypted and thereby exposed to the Hyper-V host. The paravisor is responsible for communicating securely with the Hyper-V host as necessary. [Does the paravisor do this in a way that is better than what the guest can do? This question seems to be core to the value prop for Confidential VMBus. I'm not really clear on the value prop.] A guest that is running with a paravisor must determine at runtime if Confidential VMBus is supported by the current paravisor. It does so by first trying to establish a Confidential VMBus connection with the paravisor using standard mechanisms where the memory remains encrypted. If this succeeds, then the guest can proceed to use Confidential VMBus. If it fails, then the guest must fallback to establishing a non-Confidential VMBus connection with the Hyper-V host. Confidential VMBus is a characteristic of the VMBus connection as a whole, and of each VMBus channel that is created. When a Confidential VMBus connection is established, the paravisor provides the guest the message-passing path that is used for VMBus device creation and deletion, and it provides a per-CPU synthetic interrupt controller (SynIC) just like the SyncIC that is offered by the Hyper-V host. Each VMBus device that is offered to the guest indicates the degree to which it participates in Confidential VMBus. The offer indicates if the device uses encrypted ring buffers, and if the device uses encrypted memory for DMA that is done outside the ring buffer. [Are these two settings independent? Could there be a device that has one set, and the other cleared? I'm having trouble understanding what such a mixed state would mean.] These settings may be different for different devices using the same Confidential VMBus connection. Because some devices on a Confidential VMBus may require decrypted ring buffers and DMA transfers, the guest must interact with two SynICs -- the one provided by the paravisor and the one provided by the Hyper-V host when Confidential VMBus is not offered. Interrupts are always signaled by the paravisor SynIC, but the guest must check for messages and for channel interrupts on both SynICs. [This requires some further explanation that I don't understand. What governs when a message arrives via the paravisor SynIC vs. the hypervisor SynIC, and when a VMBus channel indicates an interrupt in the paravisor SynIC event page vs. the hypervisor SynIC event page? And from looking at the code, it appears that the RelIDs assigned to channels are guaranteed to be unique within the guest VM, and not per-SynIC, but it would be good to confirm that.] [There are probably a few other topics to add a well.]
