|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] [RFC] [0/4] PV driver for FC transport layer
> We developed a prototype of para-virtual FC(Fibre Channel) SCSI
driver.
> It's a extension of the "pv-scsi" driver, that Horikoshi-san posted on
> 16 May 2007 ([Xen-devel] [RFC] pv-scsi driver (scsiback/scsifront)),
> in order to support FC transport layer.
I'm struggling slightly to understand the usage scenario planned for
this stuff. Mapping a SCSI LUN through to a guest makes perfect sense
(e.g. for performing SCSI reservations, special SCSI commands like FUA,
controlling a tape robot etc), but mapping a whole HBA through to a
guest seems less useful -- usually it's the case you want to hide all
that nastiness from the guest, taking care of multipath etc in dom0
rather than exposing it to the guest.
Have you a particular scenario in mind?
Thanks,
Ian
> The FC extension mainly performs following processes.
>
> 1. Copies FC attributes stored in Dom0 to DomU at the driver
> initialization phase. The attributes are originally stored in
> "Scsi_Host", "scsi_target" and "fc_rport" structures.
> 2. When /sys/class/fc_*/*/* on DomU is accessed from user land,
performs
> appropriate function on Dom0.
>
> We expect your helpful comments especially at following point of view.
>
> - What any other functions are required in order to behave as
"complete"
> FC driver? (We are not familiar with FC driver.)
> - This is the sub-question of above. Current prototype supports only
> "frontend driven" functions. What types of "backend driven"
functions
> we have to support?
>
> Any other comments are welcomed.
>
> Best regards
>
> -----
> Jun Kamada
> Linux Technology Development Div.
> Server Systems Unit
> Fujitsu Ltd.
> kama@xxxxxxxxxxxxxx
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|