Re: [PATCH 1/2 v1] blkdrv: Add queue limits parameters for sg block drive

[Cong Meng <mc@linux.vnet.ibm.com>]

On 08/21/2012 06:14 PM, Paolo Bonzini wrote:
> Il 21/08/2012 11:52, Stefan Hajnoczi ha scritto:
>>>>>> Using /sys/dev/block or /sys/dev/char seems easier, and lets you
>>>>>> retrieve the parameters for block devices too.
>>>>>>
>>>> what do you mean with "block devices"?   Using "/dev/sda" instead of
>>>> "/dev/sg0"?
>
> Yes.
>
>>>>>> However, I'm worried of the consequences this has for migration.  You
>>>>>> could have the same physical disk accessed with two different HBAs, with
>>>>>> different limits.  So I don't know if this can really be solved at all.
>>>>>>
>>>> I know little about qemu migration now.  The pending scsi commands will be
>>>> saved and
>>>> transfered to remote machine when starting migration?
>>
>> Passthrough is already a migration blocker if both hosts do not have
>> access to the same LUNs.
>
> Yes, but requiring the exact same hardware may be too much.  I'm trying
> to understand the problem better before committing to a threefold
> spec/qemu/kernel change.
>
> Cong, what is the limit that the host HBA enforces (and what is the
> HBA)?  What commands see a problem?  Is it fixed by using scsi-block
> instead of scsi-generic (if you can use scsi-block at all, i.e. it's not
> a tape or similar device)?
>
I don't see real problem caused by the the queue limits actually. It's a 
bug which Stefan told me.

> With scsi-generic, QEMU uses a bounce buffer for non-I/O commands to a
> SCSI passthrough device, so the only problem in that case should be the
> maximum segment size.  This could change in the future, but max_segments
> and max_sectors should not yet be a problem.

about bounce buffer, do you meat the buffer allocated in 
scsi_send_command() of hw/scsi-generic.c?

Cong.

>
> With scsi-block, QEMU will use read/write on the block device and the
> host kernel will then obey the host HBA's block limits.  QEMU will still
> use a bounce buffer for non-I/O commands to a scsi-block device, but the
> payload is usually small for non-I/O commands.
>
> Paolo
>
>> When both hosts do have access to the same LUNs it's possible to
>> extract the block queue limits (using sysfs) and compare them.
>>
>> Today you can start QEMU with different image files on both hosts.
>> Migration will appear to work but the disk image on the destination
>> host could be junk.  This is a similar case, I don't see a problem
>> except that there should be a safety check (maybe at the libvirt
>> level) to make this safe.
>