[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] hw/block/nvme: fix prp mapping status codes
From: |
Keith Busch |
Subject: |
Re: [PATCH] hw/block/nvme: fix prp mapping status codes |
Date: |
Mon, 19 Oct 2020 09:34:55 -0700 |
On Mon, Oct 19, 2020 at 01:30:39PM +0200, Klaus Jensen wrote:
> @@ -328,7 +328,7 @@ static uint16_t nvme_map_prp(NvmeCtrl *n, uint64_t prp1,
> uint64_t prp2,
> trace_pci_nvme_map_prp(trans_len, len, prp1, prp2, num_prps);
>
> if (unlikely(!prp1)) {
> - trace_pci_nvme_err_invalid_prp();
> + trace_pci_nvme_err_invalid_prp1_missing();
Why is address 0 considered a missing entry? Some embedded systems
consider that a valid address.
Otherwise, the offset checks look correct. And I realize the check for 0
predates this patch anyway, but it's not the correct thing to do: as
long as the host requests a properly aligned address, and 0 is aligned,
the controller should attempt to use it.