Re: [PATCH 2/2] hw/nvme: fix copy cmd for pi enabled namespaces

[Klaus Jensen <its@irrelevant.dk>]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]