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
