RE: [RFC PATCH 1/2] Drivers: hv: vmbus: add vmbus_establish_gpadl_caller_decrypted()

From: Kameron Carr

Date: Thu Jul 23 2026 - 17:26:11 EST


On Thursday, July 23, 2026 10:53 AM, Michael Kelley wrote:
> From: Kameron Carr <kameroncarr@xxxxxxxxxxxxxxxxxxx> Sent: Tuesday, July
21, 2026 12:57 PM
> >
> > Refactor vmbus_establish_gpadl() to separate the encryption lifecycle
> > from the rest of the GPADL establishment logic.
> >
> > Add a new vmbus_establish_gpadl_caller_decrypted() for callers that want
> > to decrypt their own buffers.
> >
> > No functional change for existing callers.
>
> I have a suggestion for a different way to accomplish this. I haven't
coded
> it, but I think it will result in less code churn and be simpler overall.
>
> 1) In enum hv_gpadl_type, add value HV_GPADL_BUFFER_DECRYPTED
>
> 2) Update hv_gpadl_size() and hv_gpadl_hvpfn() to treat the new enum
> value just like HV_GPADL_BUFFER
>
> 3) In __vmbus_establish_gpadl(), change this code
>
> gpadl->decrypted = !((channel->co_external_memory && type ==
HV_GPADL_BUFFER) ||
> (channel->co_ring_buffer && type == HV_GPADL_RING));
>
> to
>
> gpadl->decrypted = !((channel->co_external_memory && type ==
HV_GPADL_BUFFER) ||
> (channel->co_ring_buffer && type == HV_GPADL_RING) ||
> (type == HV_GPADL_BUFFER_DECRYPTED));
>
> 4) Add the function vmbus_establish_gpadl_caller_decrypted() like you
> have in this patch. It just calls __vmbus_establish_gpadl(), passing
> HV_GPADL_BUFFER_DECRYPTED.

Ack. Thank you for the feedback. I will use this approach in v2.

Regards,
Kameron

> I think that's all that is needed, though I haven't gone through
> everything rigorously and might be missing something.
>
> FWIW, the meaning of the "decrypted" field in struct vmbus_gpadl is
> a bit abused, but it was already that way. In current code, it initially
> means "decryption needed". Then after the gpadl is created, it
> means "was decrypted" so that gpadl teardown will re-encrypt.
> But my suggested approach doesn't really make the abuse any worse.
[...]