On Sun, Feb 07, 2021 at 10:49:36PM +0100, Klaus Jensen wrote:
> From: Klaus Jensen <k.jen...@samsung.com>
>
> Introduce NvmeSg and try to deal with that pesky qsg/iov duality that
> haunts all the memory-related functions.
>
> Signed-off-by: Klaus Jensen <k.jen...@samsung.com>
> ---
> hw/block/nvme.h | 8 ++-
> hw/block/nvme.c | 171 ++++++++++++++++++++++++------------------------
> 2 files changed, 90 insertions(+), 89 deletions(-)
>
> diff --git a/hw/block/nvme.h b/hw/block/nvme.h
> index cb2b5175f1a1..0e4fbd6990ad 100644
> --- a/hw/block/nvme.h
> +++ b/hw/block/nvme.h
> @@ -29,6 +29,11 @@ typedef struct NvmeAsyncEvent {
> NvmeAerResult result;
> } NvmeAsyncEvent;
>
> +typedef struct NvmeSg {
> + QEMUSGList qsg;
> + QEMUIOVector iov;
> +} NvmeSg;
It's always one or the other, right? If so, this could be a 'union'
type, and then you'd just need an indicator field to say which type it
is. There may be a meaninful memory savings that way since we
potentially allocate thousands of these.
