From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH RFC v1] libxl: Introduce a template for devices with a controller Date: Wed, 17 Jun 2015 13:33:12 +0200 Message-ID: <55815AF8.4060707@suse.com> References: <1432228052-15667-1-git-send-email-george.dunlap@eu.citrix.com> <555EAEAD.2040103@suse.com> <556597DA.6090306@suse.com> <5565CD4D.4020306@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5565CD4D.4020306@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Olaf Hering , Wei Liu , Ian Campbell , Chun Yan Liu , "xen-devel@lists.xen.org" , Ian Jackson List-Id: xen-devel@lists.xenproject.org On 05/27/2015 03:57 PM, George Dunlap wrote: > On 05/27/2015 11:09 AM, Juergen Gross wrote: >> 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. :-) > > Then quit reading your work e-mail and get back to the important stuff! :-) > >>> 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. > > OK, so it sounds like in the vscsi case, it would be useful to assign > either an entire target, or an individual LUN. > > In the case of assigning a target, you'll want to assign all the LUNs as > well, such that the virtual LUNs mirror the real LUNs. > > In the case of assigning a LUN, I assume you'll still need a virtual > target. Will you be wanting an interface for creating virtual targets, > so that you can assign several real LUNs to the same target? Or will > you just want one virtual target per LUN if you're not assigning an > entire target? Nearly missed this question. Hmm, I think the first option would be better. Otherwise it could be difficult to assign a just created LUN of a target to the same virtual target while the system is running. Juergen