On Sun, Sep 13, 2026 at 09:16:13AM -0700, Linlin Zhang wrote:
> From: linlzhan <linlin.zhang@oss.qualcomm.com>
> 
> This series adds virtio-blk inline encryption support for devices backed
> by storage hardware with an inline crypto engine.
> 
> The protocol exposes device capabilities such as keyslot count, maximum
> DUN size, and supported key types. Encrypted requests identify a
> provisioned keyslot and carry a 256-bit DUN. Key management and crypto
> capability discovery use the block device control virtqueue.
> 
> The control virtqueue is defined as a generic framework so that its
> buffer layout and queue placement are independent of any particular
> control command. Inline encryption then builds on this framework with
> explicit crypto command formats, capability validation, and keyslot
> state semantics.
> 
> All key related operatios are handled in the control virtqueue, and
> the crypto I/O request is handled in the request queue.
> 
> For background on inline encryption in UFS and eMMC storage, see:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/block/inline-encryption.rst
> 
> changes in v3:
>  - Add a control virtqueue
>  - Move key program/evict/derive_sw_secret/generate/prepare/import to
>    the control virtqueue

Thank you. This was a big change, especially if you already have an
implementation. I appreciate it!

My main feedback is that the new control virtqueue commands are not yet
documented in enough detail so that implementors could implement them.
Once you've decided on the precise semantics, error codes, etc and added
them to the spec, then this will round off the inline encryption
feature. I look forward to reviewing that in the future.

Stefan