On Mon, Mar 21, 2022, at 18:01, Keith Busch wrote:
> On Mon, Mar 21, 2022 at 05:50:46PM +0100, Sven Peter wrote:
>> +static bool apple_nvme_poll_cq(struct apple_nvme_queue *q,
>> + struct io_comp_batch *iob)
>> +{
>> + bool found = false;
>> +
>> + while (apple_nvme_cqe_pending(q)) {
>> + found = true;
>> +
>> + /*
>> + * load-load control dependency between phase and the rest of
>> + * the cqe requires a full read memory barrier
>> + */
>> + dma_rmb();
>> + apple_nvme_handle_cqe(q, iob, q->cq_head);
>> + apple_nvme_update_cq_head(q);
>> + }
>> +
>> + if (found)
>> + writel_relaxed(q->cq_head, q->cq_db);
>
> Doesn't a relaxed write mean that a subsequent write can bypass the previous?
> If so, that sounds like it can corrupt the cq head.
No, writel_relaxed just means there's no synchronization barrier for writes to
normal memory and that those could bypass the store to device memory and only
become visible later.
The underlying memory (q->cq_db) is still mapped as Device-nGnRnE which prevents
reordering of writes to the same endpoint such that the N-th CQ update is still
guaranteed to be visible to the device before the N+1-th CQ update.
I'll either add a comment why it's okay to use _relaxed here or just use writel
instead since there doesn't seem to be any performance difference.
Sven
