From: Tianyu Lan <ltykernel@gmail.com>
To: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, longli@microsoft.com,
James.Bottomley@HansenPartnership.com,
martin.petersen@oracle.com
Cc: Tianyu Lan <tiala@microsoft.com>,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-scsi@vger.kernel.org, hch@infradead.org,
robin.murphy@arm.com, vdso@hexbites.dev, mhklinux@outlook.com
Subject: [PATCH V2 1/1] x86/VMBus: Confidential VMBus for dynamic DMA transfers
Date: Mon, 27 Jul 2026 11:27:11 -0400 [thread overview]
Message-ID: <20260727152711.2045-1-tiala@microsoft.com> (raw)
Hyper-V provides Confidential VMBus to communicate between
device model and device guest driver via encrypted/private
memory in Confidential VM. The device model is in OpenHCL
(https://openvmm.dev/guide/user_guide/openhcl.html) that
plays the paravisor role.
For a VMBus device, there are two communication methods to
talk with Host/Hypervisor. 1) VMBUS Ring buffer 2) Dynamic
DMA transfer.
The Confidential VMBus Ring buffer has been upstreamed by
Roman Kisel(commit 6802d8af47d1).
The dynamic DMA transition of VMBus device normally goes
through DMA core and it uses SWIOTLB as bounce buffer in
a CoCo VM.
The Confidential VMBus device can do DMA directly to
private/encrypted memory. Because the swiotlb is decrypted
memory, the DMA transfer must not be bounced through the
swiotlb, so as to preserve confidentiality. This is different
from the default for Linux CoCo VMs, so not use DMA(SWIOTLB)
API in VMBus driver when confidential dynamic DMA transfers
capability is present.
Signed-off-by: Tianyu Lan <tiala@microsoft.com>
---
Change since v1:
* Fix code style issue
* Use co_external_memory flag in struct vmbus_channel
directly instead of adding new flag in the struct
hv_device.
---
drivers/scsi/storvsc_drv.c | 32 ++++++++++++++++++++++----------
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 6977ca8a0658..a3b22cba3421 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1326,7 +1326,8 @@ static void storvsc_on_channel_callback(void *context)
continue;
}
request = (struct storvsc_cmd_request *)scsi_cmd_priv(scmnd);
- scsi_dma_unmap(scmnd);
+ if (!device->channel->co_external_memory)
+ scsi_dma_unmap(scmnd);
}
storvsc_on_receive(stor_device, packet, request);
@@ -1815,7 +1816,7 @@ static enum scsi_qc_status storvsc_queuecommand(struct Scsi_Host *host,
unsigned long offset_in_hvpg = offset_in_hvpage(sgl->offset);
unsigned int hvpg_count = HVPFN_UP(offset_in_hvpg + length);
struct scatterlist *sg;
- unsigned long hvpfn, hvpfns_to_add;
+ unsigned long hvpfn, hvpfns_to_add, hvpgoff;
int j, i = 0, sg_count;
payload_sz = (hvpg_count * sizeof(u64) +
@@ -1831,10 +1832,14 @@ static enum scsi_qc_status storvsc_queuecommand(struct Scsi_Host *host,
payload->range.len = length;
payload->range.offset = offset_in_hvpg;
- sg_count = scsi_dma_map(scmnd);
- if (sg_count < 0) {
- ret = SCSI_MLQUEUE_DEVICE_BUSY;
- goto err_free_payload;
+ if (dev->channel->co_external_memory) {
+ sg_count = scsi_sg_count(scmnd);
+ } else {
+ sg_count = scsi_dma_map(scmnd);
+ if (sg_count < 0) {
+ ret = SCSI_MLQUEUE_DEVICE_BUSY;
+ goto err_free_payload;
+ }
}
for_each_sg(sgl, sg, sg_count, j) {
@@ -1846,9 +1851,16 @@ static enum scsi_qc_status storvsc_queuecommand(struct Scsi_Host *host,
* Such offsets are handled even on other than the first
* sgl entry, provided they are a multiple of PAGE_SIZE.
*/
- hvpfn = HVPFN_DOWN(sg_dma_address(sg));
- hvpfns_to_add = HVPFN_UP(sg_dma_address(sg) +
- sg_dma_len(sg)) - hvpfn;
+ if (dev->channel->co_external_memory) {
+ hvpgoff = HVPFN_DOWN(sg->offset);
+ hvpfn = page_to_hvpfn(sg_page(sg)) + hvpgoff;
+ hvpfns_to_add = HVPFN_UP(sg->offset + sg->length) -
+ hvpgoff;
+ } else {
+ hvpfn = HVPFN_DOWN(sg_dma_address(sg));
+ hvpfns_to_add = HVPFN_UP(sg_dma_address(sg) +
+ sg_dma_len(sg)) - hvpfn;
+ }
/*
* Fill the next portion of the PFN array with
@@ -1870,7 +1882,7 @@ static enum scsi_qc_status storvsc_queuecommand(struct Scsi_Host *host,
ret = storvsc_do_io(dev, cmd_request, smp_processor_id());
migrate_enable();
- if (ret)
+ if (ret && (!dev->channel->co_external_memory))
scsi_dma_unmap(scmnd);
if (ret == -EAGAIN) {
--
2.50.1
next reply other threads:[~2026-07-27 15:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 15:27 Tianyu Lan [this message]
2026-07-27 15:39 ` [PATCH V2 1/1] x86/VMBus: Confidential VMBus for dynamic DMA transfers sashiko-bot
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=20260727152711.2045-1-tiala@microsoft.com \
--to=ltykernel@gmail.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hch@infradead.org \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=martin.petersen@oracle.com \
--cc=mhklinux@outlook.com \
--cc=robin.murphy@arm.com \
--cc=tiala@microsoft.com \
--cc=vdso@hexbites.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox