qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Lin Ma
Subject: Re: [Qemu-devel] 答复: Re: [RFC] virtio-fc: draft idea of virtual fibre channel HBA
Date: Wed, 22 Feb 2017 01:19:15 -0700

Hi Hannes,

>>> Hannes Reinecke <address@hidden> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]