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

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


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@xxxxxxxx> 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

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@xxxxxxxxxxxxx>
CC: Ian Campbell <ian.campbell@xxxxxxxxxx>
CC: Ian Jackson <ian.jackson@xxxxxxxxxx>
CC: Wei Liu <wei.liu2@xxxxxxxxxx>
CC: Juergen Gross <jgross@xxxxxxxx>
CC: Chun Yan Liu <cyliu@xxxxxxxx>
CC: Olaf Hering <olaf@xxxxxxxxx>

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

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

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.


Xen-devel mailing list



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