On Jul 29 16:57, Maxim Levitsky wrote:
> On Mon, 2020-07-20 at 13:37 +0200, Klaus Jensen wrote:
> > From: Klaus Jensen <k.jen...@samsung.com>
> >
> > Add nvme_map_addr, nvme_map_addr_cmb and nvme_addr_to_cmb helpers and
> > use them in nvme_map_prp.
> >
> > This fixes a bug where in the case of a CMB transfer, the device would
> > map to the buffer with a wrong length.
> >
> > Fixes: b2b2b67a00574 ("nvme: Add support for Read Data and Write Data in
> > CMBs.")
> > Signed-off-by: Klaus Jensen <k.jen...@samsung.com>
> > ---
> > hw/block/nvme.c | 109 +++++++++++++++++++++++++++++++++++-------
> > hw/block/trace-events | 2 +
> > 2 files changed, 94 insertions(+), 17 deletions(-)
> >
> > diff --git a/hw/block/nvme.c b/hw/block/nvme.c
> > index 4d7b730a62b6..9b1a080cdc70 100644
> > --- a/hw/block/nvme.c
> > +++ b/hw/block/nvme.c
> > @@ -109,6 +109,11 @@ static uint16_t nvme_sqid(NvmeRequest *req)
> > return le16_to_cpu(req->sq->sqid);
> > }
> >
> > +static inline void *nvme_addr_to_cmb(NvmeCtrl *n, hwaddr addr)
> > +{
> > + return &n->cmbuf[addr - n->ctrl_mem.addr];
> I would add an assert here just in case we do out of bounds array access.
We never end up in nvme_addr_to_cmb without nvme_addr_is_cmb checking
the bounds. But an assert cant hurt if someone decides to use it in
error.
I'll add it!
