Re: [PATCH RFC v1] libxl: Introduce a template for devices with a controller

[Juergen Gross <jgross@suse.com>]

George,

I'm on vacation this and the next week with only limited email access.
So please don't expect fast reaction on any further questions during
this time. :-)

On 05/26/2015 07:56 PM, George Dunlap wrote:
> On Fri, May 22, 2015 at 5:21 AM, Juergen Gross <jgross@suse.com> wrote:
>> On 05/21/2015 07:07 PM, George Dunlap wrote:
>>>
>>> We have several outstanding patch series which add devices that have
>>> two levels: a controller and individual devices attached to that
>>> controller.
>>>
>>> In the interest of consistency, this patch introduces a section that
>>> sketches out a template for interfaces for such devices.
>>>
>>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>>> ---
>>> CC: Ian Campbell <ian.campbell@citrix.com>
>>> CC: Ian Jackson <ian.jackson@citrix.com>
>>> CC: Wei Liu <wei.liu2@citrix.com>
>>> CC: Juergen Gross <jgross@suse.com>
>>> CC: Chun Yan Liu <cyliu@suse.com>
>>> CC: Olaf Hering <olaf@aepfle.de>
>>>
>>> So, this is definitely RFC -- I tried to spec things out in a way that
>>> made sense, but I often just chose something that I thought would be a
>>> sensible starting point for discussion.
>>>
>>> This spec looks a lot more like the PVUSB spec than the PVSCSI spec,
>>> in part because I think the PVUSB spec has already had a lot more
>>> thought that's gone into it.
>>>
>>> A couple of random points to discuss:
>>>
>>> * Calling things "controllers", using <type>ctrl for the device name,
>>>     and using "ctrl" as the field name for the devid of the controller
>>>     in the individual devices.
>>
>>
>> Hmm, what about "device group" (<type>devgoup)? In the scsi world
>> "controller" would be one level higher in the hierarchy. And the scsi
>> controller is at least visible in the configuration syntax "h:c:t:l".
>> Using "controller" for the "c" in this item and for the "t" internally
>> could lead to confusion.
>
> OK, so I looked it up[1] and the full address seems to be:
> * adapter number / host
> * channel number / bus
> * id number / target
> * LUN
>
> In which case, "controller" would correspond to "adapter / host", right?
>
> In the vscsi world, what levels of what can you make?  I know you
> mentioned before that some devices have multiple LUNs, and those need
> to be grouped together, with the same LUNs as they do on real
> hardware, to work properly -- is that right?

Not all of the devices have this requirement, but some.

> The USB case actually has something somewhat similar:
> * USB controller
> * USB bus
> * USB device
> * USB function
>
> So far, there's not really a controller/bus distinction: each
> controller has exactly one bus.  When we assign a USB device to a bus,
> we automatically go through and assign each function fo that device
> individually.
>
> Would it make sense to treat vscsi the same way -- i.e., to make a
> "bus", and then attach "targets"s to it, and have the LUNs for any
> given target automatically assigned when the target is assigned?

As long as it is still possible to assign individual LUNs as well.
If dom0 is controlling e.g. a RAID system you might want to assign
one LUN of a target to domU A and one LUN of the same target to domU B.


Juergen