[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH v3 1/6] block/nvme: don't touch the completion e
Re: [Qemu-block] [PATCH v3 1/6] block/nvme: don't touch the completion entries
Mon, 8 Jul 2019 14:23:58 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
On 07.07.19 10:43, Maxim Levitsky wrote:
> On Fri, 2019-07-05 at 13:03 +0200, Max Reitz wrote:
>> On 03.07.19 17:59, Maxim Levitsky wrote:
>>> Completion entries are meant to be only read by the host and written by the
>>> The driver is supposed to scan the completions from the last point where it
>>> and until it sees a completion with non flipped phase bit.
>> (Disclaimer: This is the first time I read the nvme driver, or really
>> something in the nvme spec.)
>> Well, no, completion entries are also meant to be initialized by the
>> host. To me it looks like this is the place where that happens:
>> Everything that has been processed by the device is immediately being
>> Maybe we shouldn’t do that here but in nvme_submit_command(). But
>> currently we don’t, and I don’t see any other place where we currently
>> initialize the CQ entries.
> I couldn't find any place in the spec that says that completion entries
> should be initialized.
> It is probably wise to initialize that area to 0 on driver initialization,
> but nothing beyond that.
Ah, you’re right, I misread. I didn’t pay as much attention to the
“...prior to setting CC.EN to ‘1’” as I should have. Yep, and that is
done in nvme_init_queue().
OK, I cease my wrongful protest:
Reviewed-by: Max Reitz <address@hidden>
> In particular that is what the kernel nvme driver does.
> Other that allocating a zeroed memory (and even that I am not sure it does),
> it doesn't write to the completion entrie
Description: OpenPGP digital signature
[Qemu-block] [PATCH v3 2/6] block/nvme: fix doorbell stride, Maxim Levitsky, 2019/07/03
[Qemu-block] [PATCH v3 3/6] block/nvme: support larger that 512 bytes sector devices, Maxim Levitsky, 2019/07/03