On Mar 25 12:58, Maxim Levitsky wrote:
> On Mon, 2020-03-16 at 07:29 -0700, Klaus Jensen wrote:
> > From: Klaus Jensen <k.jen...@samsung.com>
> >
> > Handling DMA errors gracefully is required for the device to pass the
> > block/011 test ("disable PCI device while doing I/O") in the blktests
> > suite.
> >
> > With this patch the device passes the test by retrying "critical"
> > transfers (posting of completion entries and processing of submission
> > queue entries).
> >
> > If DMA errors occur at any other point in the execution of the command
> > (say, while mapping the PRPs), the command is aborted with a Data
> > Transfer Error status code.
> >
> > Signed-off-by: Klaus Jensen <k.jen...@samsung.com>
> > Acked-by: Keith Busch <kbu...@kernel.org>
> > ---
> > hw/block/nvme.c | 45 ++++++++++++++++++++++++++++++++-----------
> > hw/block/trace-events | 2 ++
> > include/block/nvme.h | 2 +-
> > 3 files changed, 37 insertions(+), 12 deletions(-)
> >
> > diff --git a/hw/block/nvme.c b/hw/block/nvme.c
> > index 15ca2417af04..49d323566393 100644
> > --- a/hw/block/nvme.c
> > +++ b/hw/block/nvme.c
> > @@ -164,7 +164,7 @@ static uint16_t nvme_map_addr_cmb(NvmeCtrl *n,
> > QEMUIOVector *iov, hwaddr addr,
> > size_t len)
> > {
> > if (!nvme_addr_is_cmb(n, addr) || !nvme_addr_is_cmb(n, addr + len)) {
> > - return NVME_DATA_TRAS_ERROR;
> > + return NVME_DATA_TRANSFER_ERROR;
>
> Minor nitpick: this is also a non functional refactoring.
> I don't think that each piece of a refactoring should be in a separate patch,
> so I usually group all the non functional (aka cosmetic) refactoring in one
> patch, usually the first in the series.
> But I try not to leave such refactoring in the functional patches.
>
> However, since there is not that much cases like that left, I don't mind
> leaving this particular case as is.
>
Noted. Keeping it here for now ;)
>
> Reviewed-by: Maxim Levitsky <mlevi...@redhat.com>
>
> Best regards,
> Maxim Levitsky
>
