Re: [PATCH] hw/block/nvme: fix prp mapping status codes

[Keith Busch]

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.