On Fri, 2019-07-05 at 13:10 +0200, Max Reitz wrote: > On 05.07.19 13:09, Max Reitz wrote: > > On 03.07.19 17:59, Maxim Levitsky wrote: > > > Fix the math involving non standard doorbell stride > > > > > > Signed-off-by: Maxim Levitsky <mlevi...@redhat.com> > > > --- > > > block/nvme.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/block/nvme.c b/block/nvme.c > > > index 6d4e7f3d83..52798081b2 100644 > > > --- a/block/nvme.c > > > +++ b/block/nvme.c > > > @@ -217,7 +217,7 @@ static NVMeQueuePair > > > *nvme_create_queue_pair(BlockDriverState *bs, > > > error_propagate(errp, local_err); > > > goto fail; > > > } > > > - q->cq.doorbell = &s->regs->doorbells[idx * 2 * s->doorbell_scale + > > > 1]; > > > + q->cq.doorbell = &s->regs->doorbells[(idx * 2 + 1) * > > > s->doorbell_scale]; > > > > > > return q; > > > fail: > > > > Hm. How has this ever worked? > > (Ah, because CAP.DSTRD has probably been 0 in most devices.) > Exactly, and I used cache line stride in my nvme-mdev, which broke this and I spend an evening figuring out what is going on. I was sure that there is some memory ordering bug or something even weirder before (as usual) finding that this is a very simple bug. I tested nvme-mdev pretty much with everything I could get my hands on, including this driver.
Best regards, Maxim Levitsky