Re: [Qemu-devel] 答复： Re: [RFC] virtio-fc: draft idea of virtual fibre channel HBA

[Hannes Reinecke]

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
address@hidden                                 +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)