On Thu, 2014-03-13 at 10:03 +0200, Sagi Grimberg wrote: > On 3/12/2014 4:16 AM, Martin K. Petersen wrote: > >>>>>> "Sagi" == Sagi Grimberg <sagig@xxxxxxxxxxxxxxxxxx> writes: > >>> The real question is whether there is actually an I/O path to > >>> protect? It seems somewhat pointless to generate CRCs and then hand > >>> the resulting buffer to a "target" function call that then does a > >>> pass to verify it without any real data movement taking place in > >>> between. The corruption window in that case is fairly small. > > Sagi> I agree, it does seem too pedantic, but ignoring scsi_cmnd prot_op > > Sagi> feels somewhat wrong to me. > > > > I'm not talking about ignoring the prot_op. The kernel is not going to > > request PI transfers (prot_op > 0) unless both initiator and target > > agree on the protection mode. > > > > And if you are both initiator and target you are also in control over > > the host's prot_capabilities mask and whether you report PROT_EN=1 in > > READ CAPACITY(16) for the target. > > > > The kernel may also request the LLD to WRITE_INSERT/READ_STRIP > protection. if I turn > off write_generate/read_verify integrity sysfs attributes. For "real" > device LLDs we know > what to expect but what do we expect from the vhost_scsi LLD to do in > this case? > So the vhost-scsi fabric driver will be receiving a virtio header from the virtio-scsi LLD to signal that a protection buffer is available or not available. AFAICT for the two READ_10s that come down with prot_op == READ_STRIP, there is no associated scsi_prot_sglist() or scsi_prot_sg_count(), so from vhost-scsi's perspective, the virtio header will signal no protection SGLs are available, and that the operation should function like a normal unprotected operation. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
