RE: [Qemu-devel] [PATCH v18 1/2] virtio-crypto: Add virtio crypto device specification

["Gonglei (Arei)" <arei.gonglei@huawei.com>]

> 
> 
> On 05/04/2017 03:33 PM, Gonglei (Arei) wrote:
> >>> +\begin{description}
> >>> +\item[VIRTIO_CRYPTO_F_CIPHER_STATELESS_MODE] Requires
> >> VIRTIO_CRYPTO_F_STATELESS_MODE.
> >>> +\item[VIRTIO_CRYPTO_F_HASH_STATELESS_MODE] Requires
> >> VIRTIO_CRYPTO_F_STATELESS_MODE.
> >>> +\item[VIRTIO_CRYPTO_F_MAC_STATELESS_MODE] Requires
> >> VIRTIO_CRYPTO_F_STATELESS_MODE.
> >>> +\item[VIRTIO_CRYPTO_F_AEAD_STATELESS_MODE] Requires
> >> VIRTIO_CRYPTO_F_STATELESS_MODE.
> >>> +\end{description}
> >>
> >> I find feature bit 0 redundant and bit confusing. We had a discussion
> >> in v15 and v16.
> >>
> >> Could you answer:
> >> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg03214.html
> >> (Message-ID:
> <1fbe30cc-87ec-32bc-4c57-85f9b03b3034@linux.vnet.ibm.com>)
> >>
> >>
> > Please see my reply:
> > https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg03186.html
> >
> > The main reason is we should keep compatibility to pre-existing driver and
> > support some function that different services have different modes.
> > We have only one unique crypto request named structure
> virtio_crypto_op_data_req_mux.
> > Please continue to see the sepc, you'll find the truth.
> >
> 
> Sorry, I still do not understand why can't we drop
> VIRTIO_CRYPTO_F_STATELESS_MODE
> and just keep the four service specific modes.
> 
> Can you point me to the (published) code where
> VIRTIO_CRYPTO_F_STATELESS_MODE is
> used (that's what I'm missing -- preferably state the repository, the commit
> a file and a line using VIRTIO_CRYPTO_F_STATELESS_MODE)?
> 
No no no, there isn't existing code use VIRTIO_CRYPTO_F_STATELESS_MODE yet,
It's just for future use.

Please the blow description:
"""
\drivernormative{\paragraph}{HASH Service Operation}{Device Types / Crypto Device / Device Operation / HASH Service Operation}

\begin{itemize*}
\item If the driver uses the session mode, then the driver MUST set \field{session_id} in struct virtio_crypto_op_header
      to a valid value assigned by the device when the session was created.
\item If the VIRTIO_CRYPTO_F_STATELESS_MODE feature bit is negotiated, the driver MUST use struct virtio_crypto_op_data_req_mux to wrap crypto requests. Otherwise, the driver MUST use struct virtio_crypto_op_data_req.
\item If the VIRTIO_CRYPTO_F_HASH_STATELESS_MODE feature bit is negotiated, 1) if the driver uses the stateless mode, then the driver MUST set the \field{flag} field in struct virtio_crypto_op_header
      to VIRTIO_CRYPTO_FLAG_STATELESS_MODE and MUST set the fields in struct virtio_crypto_hash_para_statelession.sess_para, 2) if the driver uses the session mode, then the driver MUST set the \field{flag} field in struct virtio_crypto_op_header to VIRTIO_CRYPTO_FLAG_STATE_MODE.
\item The driver MUST set \field{opcode} in struct virtio_crypto_op_header to VIRTIO_CRYPTO_HASH.
\end{itemize*}
"""

If we drop the VIRTIO_CRYPTO_F_STATELESS_MODE feature bit, and the 
VIRTIO_CRYPTO_F_HASH_STATELESS_MODE feature bit is not negotiated, 
then the driver doesn't to know use which structure to store the crypto request: 
is struct virtio_crypto_op_data_req_mux ? or struct virtio_crypto_op_data_req.

We assume the driver uses struct virtio_crypto_op_data_req, what about the device?
The device doesn't know how to parse the request in the virtio_crypto_handle_request()
of virito-crypto.c in Qemu.

static int
virtio_crypto_handle_request(VirtIOCryptoReq *request)
{
    VirtIOCrypto *vcrypto = request->vcrypto;
    VirtIODevice *vdev = VIRTIO_DEVICE(vcrypto);
    VirtQueueElement *elem = &request->elem;
    int queue_index = virtio_crypto_vq2q(virtio_get_queue_index(request->vq));
    struct virtio_crypto_op_data_req req; ???

    ///or struct virtio_crypto_op_data_req_mux req; ???

Thanks,
-Gonglei