On 06/20/13 17:31, ronnie sahlberg wrote: > On Thu, Jun 20, 2013 at 7:47 AM, Laszlo Ersek <ler...@redhat.com> wrote:
>> First I don't understand how access_len can only be "1". But, in any >> case, if the "req->elem.in_sg[0].iov_base" pointer is stored in >> little-endian order, and the kernel (or iscsi_scsi_command_async()?) for >> whatever reason misinterprets "hdr.dxferp" to point at an actual receive >> buffer (instead of an iovec array), that would be consistent with the >> symptoms: > > Ah, that makes sense. > > block.iscsi.c (https://github.com/qemu/qemu/blob/master/block/iscsi.c) > does assume that ioh->dxferp is a pointer to the buffer and that there > is no scatter gather. > See lines 745-749. How could I miss that? :) I stopped looking at the iscsi_scsi_command_async() call on line 734. Sheesh. > I did not know that ioctl() could take a scatter/gather list. > > > I cant test now but if I understand right then > lines 745-749 should be replaced with something that does > > * check ioh->iovec_count IF if it zero then there is no scatter gather > and ioh->dxferp points to a buffer, so just do what we do today. > * IF iovec_count is > 0 then dxferp is NOT a pointer to a buffer but > a pointer to an array of iovec then > traverse the iovec array and add these as buffers to the task just > like we do for readv. For example similar to the loop to add the > iovecs in lines 449-453 Seems correct to me. > > > I will try this tonight. Thanks! Laszlo
