On 02/16/2017 09:39 AM, Paolo Bonzini wrote: > > > On 16/02/2017 08:16, Lin Ma wrote: >>> What are the benefits of having FC access from the guest? >> >> Actually, I havn't dug it too much, Just thought that from virtualization's >> perspective, when interact with FC storage, having complete FC access >> from the guest is the way it should use. > > How much of this requires a completely new spec? Could we get enough of > the benefit (e.g. the ability to issue rescans or LIPs on the host) by > extending virtio-scsi? > I guess I'd need to chime in with my favourite topic :-)
Initially I really would go with extending the virtio-scsi spec, as 'real' virtio-fc suffers from some issues: While it's of course possible to implement a full fc stack in qemu itself, it's not easily possible assign 'real' FC devices to the guest. Problem here is that any virtio-fc would basically have to use the standard FC frame format for virtio itself, but all 'real' FC HBAs (excluding FCoE drivers) do _not_ allow access to the actual FC frames, but rather present you with a 'cooked' version of them. So if you were attempting to pass FC devices to the guest you would have to implement yet-another conversion between raw FC frames and the version the HBA would like. And that doesn't even deal with the real complexity like generating correct OXID/RXIDs etc. So initially I would propose to update the virtio spec to include: - Full 64bit LUNs - A 64bit target port ID (well, _actually_ it should be a SCSI-compliant target port ID, but as this essentially is a free text field I'd restrict it to something sensible) For full compability we'd also need a (64-bit) initiator ID, but that is essentially a property of the virtio queue, so we don't need to transmit it with every command; once during queue setup is enough. And if we restrict virtio-scsi to point-to-point topology we can even associate the target port ID with the virtio queue, making implementation even easier. I'm not sure if that is a good idea long-term, as one might want to identify an NPIV host with a virtio device, in which case we're having a 1-M topology and that model won't work anymore. To be precise: I'd propose to update struct virtio_scsi_config with a field 'u8 initiator_id[8]' and struct virtio_scsi_req_cmd with a field 'u8 target_id[8]' and do away with the weird LUN remapping qemu has nowadays. That should be enough to get proper NPIV passthrough working. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
