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.
>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
>> * 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.
Xen-devel mailing list