This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] [RFC] pv-scsi driver (scsiback/scsifront)

Thank you for your comment.
I'm sorry for delaying response.

I work in same group Tomonari Horikoshi works.

>>  We developped a pv-scsi driver that we refered Fujita-san's
>>  and blkback.
>>  (see,
>> http://www.xensource.com/files/xensummit_4/Xen_Summit_8_Matsumoto.pdf)
>This is good work, and we'd certainly like to get it polished and in
>mainline -- thanks! 
>>  The pv-scsi driver's feature is as follow:
>>   * Guest has dedicated SCSI-HBAs of Dom0.
>Is it really the case that you must dedicate a HBA to the guest? 

Yes, and we are planning to use NPIV function so that more than one
guest can use a HBA.

>Surely we can extend it to enable an individual LUN to be mapped
>through to a guest, translating the host:bus:id etc accordingly?
>>  * We consider about configfile format...
>>    scsihost = ['fc,0', 'scsi,1', 'type,num']
>>                type = "fc" or "scsi"
>Why do you need to select between fc and scsi?

Please refer "Re: [RFC] pv-scsi driver(scsiback/scsifront)"(respose
to James.Smart@xxxxxxxxxxx).

>>  * We have no idea how to implement suspend/resume feature.
>>    ex. Physical HBA mapping for resumed guest.
>>        Pending I/O.
>>        The WWN within FC mode for resumed guest.
>>        Influence of migration.
>>   Could you suggest to us about this?
>The blkfront/back code is obviously a good crib for this. Basically, the
>front end driver needs to store enough information to be able to reissue
>any uncompleted requests across a migration. This is accomplished with a
>'shadow ring'. The frontend needs to be capable of reconnecting if the
>backend goes out of state connected, and then reissue the requests.  For
>migration write-after-write safety, the backend shouldn't close until
>all outstanding requests have either been completed or aborted.

Thank you so much, your advise is very helpful to us.

>One other thing I notice is that you've kept the blk ring protocol's 11
>page limit per request. The blkring kinda gets away with this because
>(at least in principle) we could merge consecutive requests in blkback
>to create larger IOs. I guess we could do that with scsi requests too,
>but I'd feel more comfortable if we didn't mess with the request stream
>that the guest is generating. We probably need to make the number of
>pages in an SG list variable, and hence have variable sized requests
>across the ring. We should defintiely make the ring multi-page too.
>What do you think?

I agree with you. We try to defintiely make the ring multi-page.


Best Regards,

Xen-devel mailing list