qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 12/16] scsi-generic: use plain ioctl


From: Nicholas A. Bellinger
Subject: Re: [Qemu-devel] [PATCH 12/16] scsi-generic: use plain ioctl
Date: Fri, 19 Nov 2010 16:41:38 -0800

On Fri, 2010-11-19 at 19:39 +0100, Christoph Hellwig wrote:
> On Thu, Nov 18, 2010 at 03:47:36PM +0100, Hannes Reinecke wrote:
> > 
> > aio_ioctl is emulated anyway and currently broken.
> 
> What's broken about it currently?

Mmmmmm, I do not recall this being broken in the first place..?  There
was a single issue with megasas+bdrv_aio_ioctl() with WinXP (that did
not appear with lsi53c895a) that was mentioned on the list earlier in
the year that required a patch to use bdev_ioctl(), but last I recall
Hannes had already fixed this in recent megasas.c code w/ 32-bit MSFT
guests.  Also, this is what I have been with scsi_generic.c and
scsi_bsg.c into TCM_loop in my v0.12.5 megasas tree, and I am not
observing any obvious issues with AIO IOCTLs for SG_IO/BSG into Linux
guests.

I will give AIO IOCTL ops a run with these on v2.6.37-rc2 lock-less KVM
host mode <-> TCM_Loop to verify against the v0.12.5 megasas tree.

> 
> > So better use 'normal' ioctl here as there are no benefits
> > on using the emulated async I/O call.
> 
> There are huge benefits.  Without it the whole scsi command execution
> happens synchronously in the qemu main loop, blocking guest execution.
> 

Indeed.  Using bdrv_ioctl() in execute_command() will very effectively
disable TCQ > 1 into the backend struct scsi_device.

Hannes, did you run into another scenario why you needed to do this for
megasas..? 

Other than this one piece the rest of the series looks very good.  Thank
you for putting these pieces together.

--nab




reply via email to

[Prev in Thread] Current Thread [Next in Thread]