From: Hardik Garg <hargar@linux.microsoft.com>
To: krzk@kernel.org
Cc: apais@microsoft.com, conor+dt@kernel.org, decui@microsoft.com,
devicetree@vger.kernel.org, haiyangz@microsoft.com,
hargar@linux.microsoft.com, hargar@microsoft.com,
krzk+dt@kernel.org, kys@microsoft.com,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
robh@kernel.org, ssengar@linux.microsoft.com, wei.liu@kernel.org,
cho@microsoft.com
Subject: Re: [PATCH v4 1/2] dt-bindings: microsoft: Add vmbus message-connection-id property
Date: Tue, 22 Jul 2025 20:08:09 -0700 [thread overview]
Message-ID: <1753240089-29558-1-git-send-email-hargar@linux.microsoft.com> (raw)
In-Reply-To: <095a1455-c6ac-4a7d-a219-ddfd0a93d8d6@kernel.org>
> 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
4. Security and Isolation:
- Each guest has its private hypervisor mailbox
- Multiple guests using the same connection ID cannot interfere with each other
- 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)
- 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
Thanks,
Hardik
next prev parent reply other threads:[~2025-07-23 3:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-19 23:06 [PATCH v4 0/2] vmbus: Add DeviceTree support for message connection-id Hardik Garg
2025-06-19 23:06 ` [PATCH v4 1/2] dt-bindings: microsoft: Add vmbus message-connection-id property Hardik Garg
2025-06-20 7:21 ` Krzysztof Kozlowski
2025-07-14 7:48 ` Hardik Garg
2025-07-14 7:56 ` Krzysztof Kozlowski
2025-07-16 4:42 ` Hardik Garg
2025-07-16 14:35 ` Krzysztof Kozlowski
2025-07-23 3:08 ` Hardik Garg [this message]
2025-07-23 6:18 ` Krzysztof Kozlowski
2025-07-24 22:12 ` Hardik Garg
2025-07-25 7:32 ` Krzysztof Kozlowski
2025-11-05 1:10 ` Hardik Garg
2025-11-05 6:55 ` Krzysztof Kozlowski
2025-11-06 21:36 ` Hardik Garg
2025-06-19 23:06 ` [PATCH v4 2/2] vmbus: retrieve connection-id from DeviceTree Hardik Garg
2025-06-20 2:36 ` Michael Kelley
2025-06-20 7:22 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1753240089-29558-1-git-send-email-hargar@linux.microsoft.com \
--to=hargar@linux.microsoft.com \
--cc=apais@microsoft.com \
--cc=cho@microsoft.com \
--cc=conor+dt@kernel.org \
--cc=decui@microsoft.com \
--cc=devicetree@vger.kernel.org \
--cc=haiyangz@microsoft.com \
--cc=hargar@microsoft.com \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=ssengar@linux.microsoft.com \
--cc=wei.liu@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.