On 3/11/20 7:22 AM, Christoph Hellwig wrote: > On Tue, Mar 10, 2020 at 09:08:56PM +0000, John Garry wrote: >> On 10/03/2020 18:32, Christoph Hellwig wrote: >>> On Wed, Mar 11, 2020 at 12:25:28AM +0800, John Garry wrote: >>>> From: Hannes Reinecke <[email protected]> >>>> >>>> Allocate a separate 'reserved_cmd_q' for sending reserved commands. >>> >>> Why? Reserved command specifically are not in any way tied to queues. >>> . >>> >> >> So the v1 series used a combination of the sdev queue and the per-host >> reserved_cmd_q. Back then you questioned using the sdev queue for virtio >> scsi, and the unconfirmed conclusion was to use a common per-host q. This is >> the best link I can find now: >> >> https://www.mail-archive.com/[email protected]/msg83177.html > > That was just a question on why virtio uses the per-device tags, which > didn't look like it made any sense. What I'm worried about here is > mixing up the concept of reserved tags in the tagset, and queues to use > them. Note that we already have the scsi_get_host_dev to allocate > a scsi_device and thus a request_queue for the host itself. That seems > like the better interface to use a tag for a host wide command vs > introducing a parallel path. > Thinking about it some more, I don't think that scsi_get_host_dev() is the best way of handling it. Problem is that it'll create a new scsi_device with <hostno:this_id:0>, which will then show up via eg 'lsscsi'. This would be okay if 'this_id' would have been defined by the driver; sadly, most drivers which are affected here do set 'this_id' to -1. So we wouldn't have a nice target ID to allocate the device from, let alone the problem that we would have to emulate a complete scsi device with all required minimal command support etc. And I'm not quite sure how well that would play with the exising SCSI host template; the device we'll be allocating would have basically nothing in common with the 'normal' SCSI devices.
What we could do, though, is to try it the other way round: Lift the request queue from scsi_get_host_dev() into the scsi host itself, so that scsi_get_host_dev() can use that queue, but we also would be able to use it without a SCSI device attached. Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect [email protected] +49 911 74053 688 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), GF: Felix Imendörffer _______________________________________________ Virtualization mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/virtualization
