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

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


  • To: "Tomonari Horikoshi" <t.horikoshi@xxxxxxxxxxxxxx>, "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>
  • Date: Thu, 17 May 2007 12:49:33 +0100
  • Delivery-date: Thu, 17 May 2007 04:48:33 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AceXmhuX+vTpiQt/SliwFxGWFHsvuAA3b+Bg
  • Thread-topic: [Xen-devel] [RFC] pv-scsi driver (scsiback/scsifront)

>  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? 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?

>  * 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.

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?

Thanks,
Ian









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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.