On Wed, Feb 04, 2026 at 09:57:11PM +0800, Linlin Zhang wrote:
> On 2/3/2026 10:43 PM, Stefan Hajnoczi wrote:
> > On Tue, Feb 03, 2026 at 06:06:33PM +0800, Linlin Zhang wrote:
> >> On 2/2/2026 11:56 PM, Stefan Hajnoczi wrote:
> >>> On Fri, Jan 30, 2026 at 06:23:55PM +0800, Linlin Zhang wrote:
> >>>> On 1/28/2026 5:09 AM, Stefan Hajnoczi wrote:
> >>>>> On Tue, Jan 27, 2026 at 10:20:32PM +0800, Linlin Zhang wrote:
> >>>>>> +  starting block of the request.
> >>>>>> +\end{itemize}
> >>>>>> +
> >>>>>>  VIRTIO_BLK_T_IN requests populate \field{data} with the contents of sectors
> >>>>>>  read from the block device (in multiples of 512 bytes).  VIRTIO_BLK_T_OUT
> >>>>>>  requests write the contents of \field{data} to the block device (in multiples
> >>>>>> @@ -912,6 +979,8 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
> >>>>>>  successfully, failed, or were processed by the device at all if the request
> >>>>>>  failed with VIRTIO_BLK_S_IOERR.
> >>>>>>  
> >>>>>> +A driver MUST set \field{activate} to 0 for a non VIRTIO_BLK_F_ICE request.
> >>>>>
> >>>>> Please explicitly list request types where the payload field is present
> >>>>> and where activate is optional.
> >>>>
> >>>> How about adding the following supplement?
> >>>>
> >>>>   \begin{itemize}
> >>>>   \item only when the block request contains crypto context and the request type
> >>>
> >>> I'm not sure what "when the block request contains crypto context"
> >>> means. Is that the same as "when VIRTIO_BLK_F_ICE has been negotiated"?
> >>
> >> No, crypto context means bio_crypt_ctx in BIO struct.
> >>   struct bio {
> >>   ...
> >>   #ifdef CONFIG_BLK_INLINE_ENCRYPTION
> >> 	  struct bio_crypt_ctx	*bi_crypt_context;
> >>   #endif
> >>   ...
> >>   }
> >>
> >> When VIRTIO_BLK_F_ICE has been negotiated, virtio block backend receives crypto
> >> payload from virtio block frontend, and the crypto payload, together with I/O
> >> transaction, is sent to block layer of the host finally. The crypto payload is
> >> used to construct the bio_crypt_ctx filed of BIO.
> > 
> > Is that equivalent to struct virtio_blk_crypto_payload in this patch? If
> > yes, then I suggest only talking about the payload or slots - concepts
> > that are part of the virtio-blk inline crypto interface - instead of
> > Linux's bio_crypt_ctx.
> > 
> > If that's not possible, then the crypto context needs to be defined in
> > the spec so that readers know what it means.
> 
> Crypto context - bio_crypt_ctx structure - is different with virtio_blk_crypto_payload.
> bio_crypt_ctx is the struct bound to BIO and request structs in Linux to imply this is
> a inline encryption bio/request. While virtio_blk_crypto_payload is a new struct in this
> patch, it is used to issue the inline encryption metadata (slot, activate, DUN) to the
> virtio backend, so that the backend virtio device can use such inline encryption metadata
> to initialized the crypto info of Storage protocol. For instance, the CCI in DW0 of UTP
> Transfer Request Descriptor.
> 
> Change it to the following.
>   \begin{itemize}
>   \item only when the block request contains a valid bio_crypt_ctx and the request type
>   is one of VIRTIO_BLK_T_IN, VIRTIO_BLK_T_OUT and VIRTIO_BLK_T_FLUSH,\field{activate} MUST
>   be set to 1. bio_crypt_ctx is defined in linux/blk-crypto.h.
>     \begin{lstlisting}
>     struct bio_crypt_ctx {
>         const struct blk_crypto_key     *bc_key;
>         u64                             bc_dun[BLK_CRYPTO_DUN_ARRAY_SIZE];
>     };
>     \end{lstlisting}

bio_crypt_ctx is Linux-specific. Can you phrase this in a way that does
not rely on Linux block layer concepts?

For example:

  The \field{activate} field is set to 1 on VIRTIO_BLK_T_IN,
  VIRTIO_BLK_T_OUT, and VIRTIO_BLK_T_FLUSH requests that require inline
  encryption. For other request types or when inline encryption is not
  required, it is set to 0.

Thanks,
Stefan