On Tue, Sep 22, 2026 at 12:29:37PM +0800, Linlin Zhang wrote:
> 
> 
> On 9/18/2026 5:08 AM, Stefan Hajnoczi wrote:
> > 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.
> > 
> Thanks a lot for your comment!
> 
> Would you please help clarify what the precise semantics are about? detail
> introduction of the filed in the inline encryption control command struct?
> like struct virtio_blk_crypto_key_desc?

By precise semantics, I mean specifying not just the constants and
structs, but documenting what each command does and how it can fail.
Each of the key slot programming commands needs this. There should be at
least one paragraph for each of VIRTIO_BLK_T_CRYPTO_KEYSLOT_PROGRAM,
VIRTIO_BLK_T_CRYPTO_KEYSLOT_EVICT, VIRTIO_BLK_T_CRYPTO_DERIVE_SW_SECRET,
VIRTIO_BLK_T_CRYPTO_GENERATE_KEY, VIRTIO_BLK_T_CRYPTO_IMPORT_KEY, or
VIRTIO_BLK_T_CRYPTO_PREPARE_KEY.

For example:

The VIRTIO_BLK_T_CRYPTO_KEYSLOT_EVICT command empties a key slot so that
key information is removed and the key slot cannot be used until it is
programmed again. The key slot index is specified by struct
virtio_blk_crypto_key_desc \field{slot} and all other fields in the
struct are ignored. The command succeeds with VIRTIO_BLK_S_OK if the key
slot index is valid, including if the slot is already empty. If the key
slot index is invalid, the command fails with VIRTIO_BLK_S_IOERR.

Stefan