qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 4/4] hw/nvme: add polling support


From: Klaus Jensen
Subject: Re: [PATCH v3 4/4] hw/nvme: add polling support
Date: Thu, 3 Nov 2022 13:10:53 +0100

On Nov  3 10:18, Jinhao Fan wrote:
> at 7:10 PM, Klaus Jensen <its@irrelevant.dk> wrote:
> 
> > This doesn't do what you expect it to. By not updaring the eventidx it
> > will fall behind the actual head, causing the host to think that the
> > device is not processing events (but it is!), resulting in doorbell
> > ringing.
> 
> I’m not sure I understand this correctly. 
> 
> In 7.13.1 in NVMe Spec 1.4c it says "If updating an entry in the Shadow
> Doorbell buffer **changes** the value from being less than or equal to the
> value of the corresponding EventIdx buffer entry to being greater than that
> value, then the host shall also update the controller's corresponding
> doorbell register to match the value of that entry in the Shadow Doorbell
> buffer.”
> 
> So my understanding is that once the eventidx falls behind the actual head,
> the host will only ring the doorbell once but *not* for future submissions.
> 
> Is this not what real hosts are doing?

I agree that the spec is a little unclear on this point. In any case, in
Linux, when the driver has decided that the sq tail must be updated,
it will use this check:

  (new_idx - event_idx - 1) < (new_idx - old)

So it doesn't account for if or not eventidx was already behind.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]