[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 2/2] hw/nvme: fix copy cmd for pi enabled namespaces
From: |
Klaus Jensen |
Subject: |
Re: [PATCH 2/2] hw/nvme: fix copy cmd for pi enabled namespaces |
Date: |
Wed, 20 Apr 2022 21:16:15 +0200 |
On Apr 20 12:04, Klaus Jensen wrote:
> On Apr 20 12:03, Dmitry Tikhov wrote:
> > Current implementation have two problems:
> > First in the read part of copy command. Because there is no metadata
> > mangling before nvme_dif_check invocation, reftag error is thrown for
> > blocks of namespace that have not been previously written to.
>
> Yes, this is definitely a bug and the fix is good, thanks!
>
> > Second in the write part. Reftag in the protection information section
> > of the source metadata should not be copied as is to the destination.
>
> Hmm, says who?
>
> > Source range start lba and destination range start lba could differ so
> > recalculation of reftag is always needed.
> >
>
> If PRACT is 0, we really should not touch the protection information. My
> interpretation of the Copy command is that it is simply just screwed if
> used with PRACT 0 and Type 1. PRACT bit is specifically to allow the
> controller to generate appropriate PI in this case.
>
> On the other hand, I can totally see your interpretation as valid as
> well. Let me ask some spec people about this, and I will get back to
> you.
Discussed this with the TP authors and, no, reftag should not be
re-computed for PRACT 0, regardless of the PI type.
signature.asc
Description: PGP signature