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

[akira hayakawa <hayakawa.akira@xxxxxxxxxxxxxx>]

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
>scsi-driver
>>  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.

>Thanks,
>Ian

Best Regards,
Aki


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel