Message-ID: <f6c01c55-8930-459a-baa5-1465c5047b3e@linux.microsoft.com>
Date: Tue, 4 Nov 2025 17:10:40 -0800
From: Hardik Garg <hargar@...ux.microsoft.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: apais@...rosoft.com, cho@...rosoft.com, conor+dt@...nel.org,
 decui@...rosoft.com, devicetree@...r.kernel.org, haiyangz@...rosoft.com,
 hargar@...rosoft.com, krzk+dt@...nel.org, kys@...rosoft.com,
 linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org, robh@...nel.org,
 ssengar@...ux.microsoft.com, wei.liu@...nel.org
Subject: Re: [PATCH v4 1/2] dt-bindings: microsoft: Add vmbus
 message-connection-id property



On 7/25/2025 12:32 AM, Krzysztof Kozlowski wrote:
> On 25/07/2025 00:12, Hardik Garg wrote:
>>> Then all guests can use the same value, 0, making this property redundant.
>>
>> No, they cannot use the same value. The protocol requires different connection IDs for different communication paths.
>> For example, a guest communicating with a VTL0 control plane uses a different connection ID than one communicating with
>> a VTL2 control plane. The host specifies this value based on the guest's configuration, and there is no other discovery
>> method available to determine the correct connection ID.
> 
> You completely removed entire thread and discussion making it difficult
> to connect to one of 100 or more discussions I am doing.
> 

Apologies for the very late reply — I realize it’s been a few months
since your last feedback. I wanted to take time to revisit the design
and explore possible alternatives to avoid introducing the connection-id
property in the Device Tree. After evaluating the available mechanisms,
unfortunately there isn’t a viable alternative for passing this
information from the host to the guest in the current Hyper-V architecture.

To address your earlier comments in detail:

The connection-id is not an arbitrary or per-guest runtime configuration
parameter — it is a hardware-level identifier that specifies which
Hyper-V message port (or mailbox slot) the guest should use to
communicate with the VMBus control plane. Historically, VMBus always
used a single, fixed connection ID. However, with the introduction of
Virtual Trust Level 2 (VTL2) support, the control plane can now reside
in a different trust level, requiring the guest to communicate through a
different message port. This connection-id is determined by the
hypervisor based on the status of VMBus relay. From the guest’s
perspective, it is completely static for the lifetime of that VM
instance — it never changes at runtime. Once the kernel boots, it must
read this value to establish communication with the correct VMBus
control plane. There is currently no system API, or discoverable
interface that allows the guest to determine this value dynamically.

> 
> The guest should not care about the value. Otherwise what if guests
> decides to ignore your DT property and start using other value? Sniffing
> other guests traffic? Causing conflicts or denial of service?
> 

Regarding security and isolation:

Each guest has a private hypervisor mailbox and cannot access any other
guest’s communication path. Using an incorrect connection ID does not
allow eavesdropping or cause interference — it only results in failed
VMBus initialization because the host drops messages sent to an
unexpected port. Thus, exposing the correct connection ID to the guest
is safe and necessary for correct initialization.

> If different values are important for the host, then all guests should
> use whatever 0 which will map to different values on host by other means
> of your protocol.
> 

Using a fixed value such as 0 for all guests would not work, because the
Hyper-V host differentiates between multiple control-plane contexts (for
example, VTL0 vs VTL2) using distinct connection IDs. The guest must use
the value assigned by the host, as there is no implicit mapping or
negotiation protocol to determine it otherwise.

In summary:
The connection-id is a static hardware configuration detail provided by
the host before boot, not a runtime variable. It is required for correct
message routing between the guest’s VMBus driver and the appropriate
control plane. There is no existing API or firmware interface that can
expose this information. Each guest has a dedicated, isolated mailbox,
so security is preserved. If you still feel that Device Tree is not the
right mechanism, I’m open to discussing alternative approaches that
could convey this information from the host to the guest early during
boot — though based on the current architecture, I have not found a
suitable one yet.

Thank you again for your time, patience, and for your detailed feedback.
I’ll make sure my next submission keeps full context and follows proper
wrapping and quoting conventions.



Thanks,
Hardik

Powered by blists - more mailing lists