On Wed, Sep 28, 2016 at 05:08:24PM +0800, Gonglei wrote:
> +For scatter/gather list support, a buffer can be represented by virtio_crypto_iovec structure.
> +
> +The structure is defined as follows:
> +
> +\begin{lstlisting}
> +struct virtio_crypto_iovec {
> +    /* Guest physical address */
> +    le64 addr;
> +    /* Length of guest physical address */
> +    le32 len;
> +/* This marks a buffer as continuing via the next field */
> +#define VIRTIO_CRYPTO_IOVEC_F_NEXT 1
> +    /* The flags as indicated above VIRTIO_CRYPTO_IOVEC_F_*. */
> +    le32 flags;
> +    /* Pointer to next struct virtio_crypto_iovec if flags & NEXT */
> +    le64 next_iovec;
> +};
> +\end{lstlisting}

The vring already provides scatter-gather I/O.  It is usually not
necessary to define scatter-gather I/O at the device level.  Addresses
can be translated by the virtio transport (PCI, MMIO, CCW).  For example
PCI bus addresses with IO-MMU.  Therefore it's messy to use guest
physical addresses in the device specification.

> +Each data request uses virtio_crypto_hash_data_req structure to store information
> +used to run the HASH operations. The request only occupies one entry
> +in the Vring Descriptor Table in the virtio crypto device's dataq, which improves
> +the throughput of data transmitted for the HASH service, so that the virtio crypto
> +device can be better accelerated.

Indirect vrings also only require one entry in the descriptor table.  I
don't understand why you are reinventing scatter-gather I/O.

Am I missing something?

Stefan