Hi Hannes, >>> Hannes Reinecke <h...@suse.de> 2017/2/16 星期四 下午 5:56 >>> >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. Does it mean we dont need to provide '-drive' and '-device scsi-hd' option in qemu command line? so the guest can get its own LUNs through fc switch, right?
>That should be enough to get proper NPIV passthrough working. Lin
