|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] [Patch 0/7] pvSCSI driver
> Hi,
>
> Problems discussed in this context, what the portion of whole SCSI
> tree should be exposed to guest and how the numbering logic of guest's
> tree should be, is very fundamental and difficult, I think.
>
> In my current thought, following two options are reasonable solutions.
> How do you think about them? Could you please comment me?
>
> Option 1 (LUN assignment)
> - Specify the assignment like below:
> "host1:channel1:id1:lun1"(Dom0) -> "host2:channel2:id2:lun2"(guest)
> The lun1 must be same as the lun2.
> - Munging :-) REPORT LUNS command on Dom0 according to the number of
> LUNs actually attached to the guest.
>
> Option 2 (Target Assignment)
> - Specify the assignment like below:
> "host1:channel1:id1"(Dom0) -> "host2:channel2:id2"(guest)
> All LUNs under id1 are assigned to one guest.
> - Munging for LUN is not needed.
I think it would help to have some real-life examples about where each
option would and wouldn't make sense. It may be that you need to
implement both options. I'm not familiar enough with the variety of scsi
devices out there to be able to judge.
> For each option, how host/bus/device reset command should be?
I have thought about this some more. Normally, a reset will be issued
because of some error, normally a timeout I assume. You could implement
something like:
. if the reset requested is a device reset, and the DomU 'owns' all luns
attached to the device, then allow the device reset.
. if the reset requested is a device reset, and the DomU 'owns' only
some of the luns attached to the device, then only allow the device
reset if all the other 'owners' have requested a device reset also.
. the above two rules might work for host and bus resets too, as long as
all 'owners' agree to a reset.
The problem might be if you had a device with three luns, and three
DomU's with a single lun each. If the device had hung and required a
reset, then any DomU using it would notice the timeout and issue a
reset, but if one DomU wasn't using its lun at the time it might not
notice. Maybe you need another communication channel where Dom0 can ask
each DomU for permission to do the reset.
This reset stuff seems like a lot of extra work for probably not much
benefit though.
James
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Xen-devel] [Patch 0/7] pvSCSI driver, Steven Smith
- Re: [Xen-devel] [Patch 0/7] pvSCSI driver, Jun Kamada
- RE: [Xen-devel] [Patch 0/7] pvSCSI driver,
James Harper <=
- Re: [Xen-devel] [Patch 0/7] pvSCSI driver, James Smart
- Re: [Xen-devel] [Patch 0/7] pvSCSI driver, Steven Smith
- Re: [Xen-devel] [Patch 0/7] pvSCSI driver, Jun Kamada
- Re: [Xen-devel] [Patch 0/7] pvSCSI driver, Steven Smith
- Re: [Xen-devel] [Patch 0/7] pvSCSI driver, Jun Kamada
- Re: [Xen-devel] [Patch 0/7] pvSCSI driver, Steven Smith
- Re: [Xen-devel] [Patch 0/7] pvSCSI driver, James Smart
- Re: [Xen-devel] [Patch 0/7] pvSCSI driver, Jun Kamada
|
|
|
|
|