On Thursday, July 23, 2026 10:53 AM, Michael Kelley wrote: > From: Kameron Carr <[email protected]> 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. [...]
