>
>
> 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-85f9b03b3...@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
