On 23/07/2025 05:08, Hardik Garg wrote: >> Host is supposed to have multiple guests, so this feels like you are >> going to prepare for each guest different DTS with different connection >> ID. This feels like poor design. DTS is supposed to be relatively static >> configuration, not runtime choice vmguestid+1. > >> The guest cannot access other configuration channels, can it? If it can, >> it would mean it can eavesdrop on other guests? So obviously it cannot. >> Therefore from guest point of view this is completely redundant. Guest >> cannot use any other value, thus guest should not configure it. The >> guest has only one channel and uses only this one which gets to right >> place to the host. > > Thank you for your feedback. Let me explain the connection ID in more detail: > > 1. Message Port Architecture: > - The connection ID specifies which Hyper-V hypervisor message port > (mailbox slot) to use for communication between the host and guest > - The hypervisor has multiple message ports, but historically VMBus only > used one > - With the introduction of VTL2 (Virtual Trust Level 2), the control plane > can now be hosted in VTL2, requiring different message ports for communication > > 2. Control Plane Communication: > - The VMBus control plane on the host needs to communicate with the VMBus > driver in the guest > - When the control plane is hosted in VTL2, it requires a different > message port than the standard communication path > - The connection ID tells the guest whether to use the standard or > alternate message port for this control plane communication > > 3. Message Processing: > - Each message is tagged with an ID > - If the guest uses an incorrect ID, the host won't recognize the message > and will drop it > - This is not about choosing between multiple available channels - it's > about using the correct mailbox slot for communication >
Don't paste me specs in response to questions, but answer specific questions. > 4. Security and Isolation: > - Each guest has its private hypervisor mailbox > - Multiple guests using the same connection ID cannot interfere with each > other Then all guests can use the same value, 0, making this property redundant. > - The connection ID is more like a "root ID" that helps enumerate devices > on the bus, not a channel selector between guests > > 5. Dynamic Nature: > - The connection ID is specified when the guest starts running > - The host can change it during VM lifecycle events (reset/reboot) So not suitable for DT. DT is a static data. You cannot just keep changing existing DT to match whatever you want runtime. > - This is why the VMBus driver needs to know the connection ID every time > the kernel starts > - The ID might be different from what it was during the last guest run Best regards, Krzysztof
