Re: [PATCH v1] virtio-blk: Add inline encryption support

[Linlin Zhang <linlin.zhang@oss.qualcomm.com>]

On 8/21/2026 12:18 AM, Linlin Zhang wrote:
> 
> 
> On 8/20/2026 5:18 AM, Stefan Hajnoczi wrote:
>> On Fri, Aug 14, 2026 at 07:23:01AM -0700, Linlin Zhang wrote:
> 
>>> +\field{enc_characteristics}, or that identifies a key slot into which no key
>>> +has been provisioned.
>>> +
>>> +A driver MUST set \field{data_unit_size_bits} of a VIRTIO_BLK_T_CRYPTO_IN or
>>> +VIRTIO_BLK_T_CRYPTO_OUT request's \field{crypto_msg} to $log_2$ of the data
>>> +unit size in bytes associated with the key provisioned in the virtual key
>>> +slot identified by \field{slot}. Since data unit sizes are reported by
>>> +VIRTIO_BLK_T_GET_CRYPTO_MODES as a bitmask of \field{le32} elements, a
>>> +driver MUST NOT set \field{data_unit_size_bits} to a value greater than 31.
>>> +
>>> +A driver MUST NOT submit a VIRTIO_BLK_T_CRYPTO_IN or VIRTIO_BLK_T_CRYPTO_OUT
>>> +request with a zero length \field{data}.
>>
>> Does VIRTIO_BLK_T_WRITE_ZEROES need an equivalent
>> VIRTIO_BLK_T_CRYPTO_WRITE_ZEROES request type? If the driver sends
>> VIRTIO_BLK_T_WRITE_ZEROES then the device might write zeroes in
>> plaintext, which isn't what we want.
>>
> 
> Yes, it's still cipher text that is flushed into disk even the driver sends
> VIRTIO_BLK_T_WRITE_ZEROES. Need add a VIRTIO_BLK_T_CRYPTO_WRITE_ZEROES request
> type.
> 

I double-checked VIRTIO_BLK_T_WRITE_ZEROES. Since a request may consist of
multiple non-contiguous segments, handling DUN calculation becomes difficult
if the backend needs to divide the request. Because both sector offset and
data length per segment need be aligned with Data Unit Size, and only the DUN
for the first segment can be appended to the crypto message in the virtio reqeust.

For this reason, I would prefer not to introduce VIRTIO_BLK_T_CRYPTO_WRITE_ZEROES,
consistent with the treatment of discard/erase requests.

I'm appreciated if you have any thoughts about it.