Hi Mikulas, > > Windows Guest <--> Vhost-Scsi <--> LIO(scsi/target/blockio) <--> dm-crypt > <--> iSCSI block device > > > > One real example out of my debugging: Windows sends a I/O request with > > 6656 bytes to vhost-scsi interface. Vhost-scsi uses translate_desc() in > > drivers/vhost/vhost.c to convert windows user space memory buffers to > > kernel iovecs. Vhost-scsi then converts the iovecs to sg entries in > > vhost_scsi_mapal() which is then handed over to "target" subsystem and > > eventually submitted to dm-crypt. This 6656 bytes IO has got 3 segments, > > first segment had 1584, second 4096 and the last had 976 bytes. Dm-crypt > > rejects the I/O after seeing the first segment length 1584 which is not > > a 512 byte multiple. > > > > Let me know if there are further questions. > > > > Thanks > > Sudhakar > > Hi > > I think it should be fixed in vhost-scsi. In the above example of 6656 bytes I/O, windows allocates 6656 bytes virtually contiguous I/O. This IO, when it lands in the kernel, translates to 3 physically discontiguous pages, that's why translate_desc() had to create 3 iovecs to handle this I/O. I don't understand how vhost-scsi could have solved this issue. Only other possibility I see is to have windows fix it by always sending 512 byte aligned buffer lengths, but going with my earlier point that every other component in the Linux IO path handles this case well except for dm-crypt, so it make more sense to fix it in dm-crypt. Thanks Sudhakar > > Mikulas > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
