Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
On 6/17/2015 at 07:06 PM, in message 1434539195.13744.321.ca...@citrix.com, Ian Campbell ian.campb...@citrix.com wrote: On Thu, 2015-05-21 at 18:07 +0100, 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. Chun Yan and Jeurgen: I was hoping we could come to some sort of agreement on this such that it can be used as the basis for both the pvusb and pvscsi interfaces. As such your feedback here is important... Signed-off-by: George Dunlap george.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Juergen Gross jgr...@suse.com CC: Chun Yan Liu cy...@suse.com CC: Olaf Hering o...@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 typectrl for the device name, and using ctrl as the field name for the devid of the controller in the individual devices. * I've said that having an index (port, lun, whatever) is optional. Do we want to make that requred? Do we want it to have a consistent name? In the case of emulated USB, we can't really specify to qemu what port the device gets attached to, so I'm tempted to say it's not required; but even there we could always give it a port number just for name's sake. * Naming sub-devices. We need to have a way to uniquely name both controllers and subdevices. Here I've said that we will have both typectrl and type devid namespaces, mainly because in the previous point I opted not to require an index. Another option would be not to have another devid namespace, but to use ctrl,index as the unique identifier. (This would mean requiring the index/port/lun specification above.) * libxl_device_type_list listing devices across all controllers. I think this is the most practical thing to do, but one could imagine wanting to query by controller ID instead. Feedback welcome. --- tools/libxl/libxl.h | 46 ++ 1 file changed, 46 insertions(+) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 2ed7194..d757845 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -1234,6 +1234,52 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms); * * This function does not interact with the guest and therefore * cannot block on the guest. + * + * Controllers + * --- + * + * Most devices are treated individually. Some devices however, like + * USB or SCSI, inherently have the need to have busses or + * controllers to which individual devices can be attached. + * + * In that case, for each type, there will be two sets of the + * functions, types, and devid namespaces outlined above: one based on + * 'type', and one based on 'typectrl'. + * + * In those cases, libxl_device_typectrl_function will act more or + * less like top-level non-bus devices: they will either create or + * accept a libxl_devid which will be unique within the + * typectrl libxl_devid namespace. + * + * Second-level devices which will be attached to a controller will + * include in their libxl_device_type a field called ctrl, which + * will be the libxl_devid of the corresponding controller. It may also + * include an index onto that bus, that represents (for example) a USB + * port or a SCSI LUN. + * + * These second-level devices will also have their own devid which + * will be unique within the type devid namespace, and will be used + * for queries or removals. All other description is agreed except here: For pvusb, currently we uses ctrl, port instead of devid. It seems to be more straightforward. To add a USB device info to xenstore, it only writes the USB busid to controller/port. To remove a USB device, just remove USB busid from xenstore controller/port. - Chunyan + * + * In the case where there are multiple different ways to implement a + * given device -- for instance, one which is fully PV and one which + * uses an emulator -- the controller will contain a field which + * specifies what type of implementation is used. The implementations + * of individual devices will be known by
Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
On Wed, Jun 17, Ian Campbell wrote: So, Olaf, ping... I will return to pvscsi work next week. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
On 06/17/2015 01:06 PM, Ian Campbell wrote: On Thu, 2015-05-21 at 18:07 +0100, 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. Chun Yan and Jeurgen: I was hoping we could come to some sort of agreement on this such that it can be used as the basis for both the pvusb and pvscsi interfaces. As such your feedback here is important... I already gave some feedback. As everything regarding this feedback has been discussed: Acked-by: Juergen Gross jgr...@suse.com Signed-off-by: George Dunlap george.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Juergen Gross jgr...@suse.com CC: Chun Yan Liu cy...@suse.com CC: Olaf Hering o...@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 typectrl for the device name, and using ctrl as the field name for the devid of the controller in the individual devices. * I've said that having an index (port, lun, whatever) is optional. Do we want to make that requred? Do we want it to have a consistent name? In the case of emulated USB, we can't really specify to qemu what port the device gets attached to, so I'm tempted to say it's not required; but even there we could always give it a port number just for name's sake. * Naming sub-devices. We need to have a way to uniquely name both controllers and subdevices. Here I've said that we will have both typectrl and type devid namespaces, mainly because in the previous point I opted not to require an index. Another option would be not to have another devid namespace, but to use ctrl,index as the unique identifier. (This would mean requiring the index/port/lun specification above.) * libxl_device_type_list listing devices across all controllers. I think this is the most practical thing to do, but one could imagine wanting to query by controller ID instead. Feedback welcome. --- tools/libxl/libxl.h | 46 ++ 1 file changed, 46 insertions(+) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 2ed7194..d757845 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -1234,6 +1234,52 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms); * * This function does not interact with the guest and therefore * cannot block on the guest. + * + * Controllers + * --- + * + * Most devices are treated individually. Some devices however, like + * USB or SCSI, inherently have the need to have busses or + * controllers to which individual devices can be attached. + * + * In that case, for each type, there will be two sets of the + * functions, types, and devid namespaces outlined above: one based on + * 'type', and one based on 'typectrl'. + * + * In those cases, libxl_device_typectrl_function will act more or + * less like top-level non-bus devices: they will either create or + * accept a libxl_devid which will be unique within the + * typectrl libxl_devid namespace. + * + * Second-level devices which will be attached to a controller will + * include in their libxl_device_type a field called ctrl, which + * will be the libxl_devid of the corresponding controller. It may also + * include an index onto that bus, that represents (for example) a USB + * port or a SCSI LUN. + * + * These second-level devices will also have their own devid which + * will be unique within the type devid namespace, and will be used + * for queries or removals. + * + * In the case where there are multiple different ways to implement a + * given device -- for instance, one which is fully PV and one which + * uses an emulator -- the controller will contain a field which + * specifies what type of implementation is used. The implementations + * of individual devices will be known by the controller to which they are + * attached. + * + * If libxl_device_type_add receives an uninitialized ctrl devid, it + * may return an error. Or it may (but is not required to) choose to + * automatically choose a suitable controller to which to attach the + * new device. It may also (but is not required to) automatically + * create a new controller if no suitable controllers exist. + * Individual devices should document their behavior. + * + * libxl_device_typectrl_list will list all controllers for the domain. + * + *
Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
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 targetss 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
On Thu, 2015-05-21 at 18:07 +0100, 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. Chun Yan and Jeurgen: I was hoping we could come to some sort of agreement on this such that it can be used as the basis for both the pvusb and pvscsi interfaces. As such your feedback here is important... Signed-off-by: George Dunlap george.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Juergen Gross jgr...@suse.com CC: Chun Yan Liu cy...@suse.com CC: Olaf Hering o...@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 typectrl for the device name, and using ctrl as the field name for the devid of the controller in the individual devices. * I've said that having an index (port, lun, whatever) is optional. Do we want to make that requred? Do we want it to have a consistent name? In the case of emulated USB, we can't really specify to qemu what port the device gets attached to, so I'm tempted to say it's not required; but even there we could always give it a port number just for name's sake. * Naming sub-devices. We need to have a way to uniquely name both controllers and subdevices. Here I've said that we will have both typectrl and type devid namespaces, mainly because in the previous point I opted not to require an index. Another option would be not to have another devid namespace, but to use ctrl,index as the unique identifier. (This would mean requiring the index/port/lun specification above.) * libxl_device_type_list listing devices across all controllers. I think this is the most practical thing to do, but one could imagine wanting to query by controller ID instead. Feedback welcome. --- tools/libxl/libxl.h | 46 ++ 1 file changed, 46 insertions(+) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 2ed7194..d757845 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -1234,6 +1234,52 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms); * * This function does not interact with the guest and therefore * cannot block on the guest. + * + * Controllers + * --- + * + * Most devices are treated individually. Some devices however, like + * USB or SCSI, inherently have the need to have busses or + * controllers to which individual devices can be attached. + * + * In that case, for each type, there will be two sets of the + * functions, types, and devid namespaces outlined above: one based on + * 'type', and one based on 'typectrl'. + * + * In those cases, libxl_device_typectrl_function will act more or + * less like top-level non-bus devices: they will either create or + * accept a libxl_devid which will be unique within the + * typectrl libxl_devid namespace. + * + * Second-level devices which will be attached to a controller will + * include in their libxl_device_type a field called ctrl, which + * will be the libxl_devid of the corresponding controller. It may also + * include an index onto that bus, that represents (for example) a USB + * port or a SCSI LUN. + * + * These second-level devices will also have their own devid which + * will be unique within the type devid namespace, and will be used + * for queries or removals. + * + * In the case where there are multiple different ways to implement a + * given device -- for instance, one which is fully PV and one which + * uses an emulator -- the controller will contain a field which + * specifies what type of implementation is used. The implementations + * of individual devices will be known by the controller to which they are + * attached. + * + * If libxl_device_type_add receives an uninitialized ctrl devid, it + * may return an error. Or it may (but is not required to) choose to + * automatically choose a suitable controller to which to attach the + * new device. It may also (but is not required to) automatically + * create a new controller if no suitable controllers exist. + * Individual devices should document their behavior. + * + * libxl_device_typectrl_list will list all controllers for the domain. + * + * libxl_device_type_list will list all devices for all controllers + * for the domain. The individual
Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
On Wed, 2015-06-17 at 13:28 +0200, Juergen Gross wrote: On 06/17/2015 01:06 PM, Ian Campbell wrote: On Thu, 2015-05-21 at 18:07 +0100, 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. Chun Yan and Jeurgen: I was hoping we could come to some sort of agreement on this such that it can be used as the basis for both the pvusb and pvscsi interfaces. As such your feedback here is important... I already gave some feedback. As everything regarding this feedback has been discussed: Acked-by: Juergen Gross jgr...@suse.com Actually, maybe I really meant to ping Olaf instead/as well since he's doing the libxl side of pvscsi (you're doing the driver upstreaming, right?). So, Olaf, ping... Signed-off-by: George Dunlap george.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Juergen Gross jgr...@suse.com CC: Chun Yan Liu cy...@suse.com CC: Olaf Hering o...@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 typectrl for the device name, and using ctrl as the field name for the devid of the controller in the individual devices. * I've said that having an index (port, lun, whatever) is optional. Do we want to make that requred? Do we want it to have a consistent name? In the case of emulated USB, we can't really specify to qemu what port the device gets attached to, so I'm tempted to say it's not required; but even there we could always give it a port number just for name's sake. * Naming sub-devices. We need to have a way to uniquely name both controllers and subdevices. Here I've said that we will have both typectrl and type devid namespaces, mainly because in the previous point I opted not to require an index. Another option would be not to have another devid namespace, but to use ctrl,index as the unique identifier. (This would mean requiring the index/port/lun specification above.) * libxl_device_type_list listing devices across all controllers. I think this is the most practical thing to do, but one could imagine wanting to query by controller ID instead. Feedback welcome. --- tools/libxl/libxl.h | 46 ++ 1 file changed, 46 insertions(+) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 2ed7194..d757845 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -1234,6 +1234,52 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms); * * This function does not interact with the guest and therefore * cannot block on the guest. + * + * Controllers + * --- + * + * Most devices are treated individually. Some devices however, like + * USB or SCSI, inherently have the need to have busses or + * controllers to which individual devices can be attached. + * + * In that case, for each type, there will be two sets of the + * functions, types, and devid namespaces outlined above: one based on + * 'type', and one based on 'typectrl'. + * + * In those cases, libxl_device_typectrl_function will act more or + * less like top-level non-bus devices: they will either create or + * accept a libxl_devid which will be unique within the + * typectrl libxl_devid namespace. + * + * Second-level devices which will be attached to a controller will + * include in their libxl_device_type a field called ctrl, which + * will be the libxl_devid of the corresponding controller. It may also + * include an index onto that bus, that represents (for example) a USB + * port or a SCSI LUN. + * + * These second-level devices will also have their own devid which + * will be unique within the type devid namespace, and will be used + * for queries or removals. + * + * In the case where there are multiple different ways to implement a + * given device -- for instance, one which is fully PV and one which + * uses an emulator -- the controller will contain a field which + * specifies what type of implementation is used. The implementations + * of individual devices will be known by the controller to which they are + * attached. + * + * If libxl_device_type_add receives an uninitialized ctrl devid,
Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
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 jgr...@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.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Juergen Gross jgr...@suse.com CC: Chun Yan Liu cy...@suse.com CC: Olaf Hering o...@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 typectrl 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 (typedevgoup)? 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 targetss 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
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 targetss 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? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
On Thu, 2015-05-21 at 18:07 +0100, 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. Thanks for taking this on! Signed-off-by: George Dunlap george.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Juergen Gross jgr...@suse.com CC: Chun Yan Liu cy...@suse.com CC: Olaf Hering o...@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 typectrl for the device name, and using ctrl as the field name for the devid of the controller in the individual devices. Controllers/ctrl is fine, as would Bus/bus. Or paint it pink ;-) * I've said that having an index (port, lun, whatever) is optional. Do we want to make that requred? Do we want it to have a consistent name? In the case of emulated USB, we can't really specify to qemu what port the device gets attached to, so I'm tempted to say it's not required; but even there we could always give it a port number just for name's sake. At the moment devid is not universally used, e.g. disk has (vdev, string), instead. For devices (or controllers) where a flat integer devid space doesn't make sense I think it would be fine to have something else, like a type-specific devid type and a corresponding typectrl specific ctrlid type, which might be a (small) struct in either case and need not be uniform across type and typectrl nor among different types. Having this option of a more structured type might also help with the conversation (in a subthread) regarding where in the controller/bus/device/function the split between the two id spaces is, since you aren't constrained to a single int at two levels trying to describe 4 levels. Using a string as disks do is probably best not considered as a precedent here, but could be appropriate on a device-by-device basis. * Naming sub-devices. We need to have a way to uniquely name both controllers and subdevices. Here I've said that we will have both typectrl and type devid namespaces, mainly because in the previous point I opted not to require an index. Another option would be not to have another devid namespace, but to use ctrl,index as the unique identifier. (This would mean requiring the index/port/lun specification above.) I'm not quite sure what you are getting at here, in particular where we will have both typectrl and type devid namespaces, in the structs or in the protoptyes. I was imaging that where the current templates have (ctx, domid, device) that a controller related function would be (ctx, domid, ctrl) and the device related function would become (ctx, domid, ctrlid, device). ctrl and device would contain their respective ctrlid and devid fields. Perhaps it might be clearer if the proposal included specific function prototype templates along the lines of the existing libxl_device_type_add(ctx, domid, device). I think you were trying to avoid duplication by presenting this new scheme as an extension to what is currently written there. It might be clearer to simply present it as a separate alternative or to list both possible prototypes next to the current section where things differ in the two schemes? (and describe it in the text) Or perhaps to insert some optional parameters into the existing ones where it makes sense: libxl_device_type_add(ctx, domid, [ctrlid, ]device) Not sure which would be least confusing... * libxl_device_type_list listing devices across all controllers. I think this is the most practical thing to do, but one could imagine wanting to query by controller ID instead. I agree with listing everything, I think. If we find a need to only list per controller ID then we can add an alternative (list_by_ctrl, device_typectrl_list_devices, or whatever). Feedback welcome. Having said all that I don't seem to have any more comments on the actual text itself, apart from one typo. --- tools/libxl/libxl.h | 46 ++ 1 file changed, 46 insertions(+) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 2ed7194..d757845 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -1234,6 +1234,52 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms); * * This function does not interact with the guest and therefore * cannot
Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
On Fri, May 22, 2015 at 5:21 AM, Juergen Gross jgr...@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.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Juergen Gross jgr...@suse.com CC: Chun Yan Liu cy...@suse.com CC: Olaf Hering o...@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 typectrl 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 (typedevgoup)? 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? 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 targetss to it, and have the LUNs for any given target automatically assigned when the target is assigned? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
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.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Juergen Gross jgr...@suse.com CC: Chun Yan Liu cy...@suse.com CC: Olaf Hering o...@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 typectrl for the device name, and using ctrl as the field name for the devid of the controller in the individual devices. * I've said that having an index (port, lun, whatever) is optional. Do we want to make that requred? Do we want it to have a consistent name? In the case of emulated USB, we can't really specify to qemu what port the device gets attached to, so I'm tempted to say it's not required; but even there we could always give it a port number just for name's sake. * Naming sub-devices. We need to have a way to uniquely name both controllers and subdevices. Here I've said that we will have both typectrl and type devid namespaces, mainly because in the previous point I opted not to require an index. Another option would be not to have another devid namespace, but to use ctrl,index as the unique identifier. (This would mean requiring the index/port/lun specification above.) * libxl_device_type_list listing devices across all controllers. I think this is the most practical thing to do, but one could imagine wanting to query by controller ID instead. Feedback welcome. --- tools/libxl/libxl.h | 46 ++ 1 file changed, 46 insertions(+) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 2ed7194..d757845 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -1234,6 +1234,52 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms); * * This function does not interact with the guest and therefore * cannot block on the guest. + * + * Controllers + * --- + * + * Most devices are treated individually. Some devices however, like + * USB or SCSI, inherently have the need to have busses or + * controllers to which individual devices can be attached. + * + * In that case, for each type, there will be two sets of the + * functions, types, and devid namespaces outlined above: one based on + * 'type', and one based on 'typectrl'. + * + * In those cases, libxl_device_typectrl_function will act more or + * less like top-level non-bus devices: they will either create or + * accept a libxl_devid which will be unique within the + * typectrl libxl_devid namespace. + * + * Second-level devices which will be attached to a controller will + * include in their libxl_device_type a field called ctrl, which + * will be the libxl_devid of the corresponding controller. It may also + * include an index onto that bus, that represents (for example) a USB + * port or a SCSI LUN. + * + * These second-level devices will also have their own devid which + * will be unique within the type devid namespace, and will be used + * for queries or removals. + * + * In the case where there are multiple different ways to implement a + * given device -- for instance, one which is fully PV and one which + * uses an emulator -- the controller will contain a field which + * specifies what type of implementation is used. The implementations + * of individual devices will be known by the controller to which they are + * attached. + * + * If libxl_device_type_add receives an uninitialized ctrl devid, it + * may return an error. Or it may (but is not required to) choose to + * automatically choose a suitable controller to which to attach the + * new device. It may also (but is not required to) automatically + * create a new controller if no suitable controllers exist. + * Individual devices should document their behavior. + * + * libxl_device_typectrl_list will list all controllers for the domain. + * + * libxl_device_type_list will list all devices for all controllers + * for the domain. The individual libxl_device_type will include + * the devid of the controller to which it is attached. */ /* Disks */ -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
On 05/21/2015 06: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.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Juergen Gross jgr...@suse.com CC: Chun Yan Liu cy...@suse.com CC: Olaf Hering o...@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 typectrl for the device name, and using ctrl as the field name for the devid of the controller in the individual devices. * I've said that having an index (port, lun, whatever) is optional. Do we want to make that requred? Do we want it to have a consistent name? In the case of emulated USB, we can't really specify to qemu what port the device gets attached to, so I'm tempted to say it's not required; but even there we could always give it a port number just for name's sake. * Naming sub-devices. We need to have a way to uniquely name both controllers and subdevices. Here I've said that we will have both typectrl and type devid namespaces, mainly because in the previous point I opted not to require an index. Another option would be not to have another devid namespace, but to use ctrl,index as the unique identifier. (This would mean requiring the index/port/lun specification above.) * libxl_device_type_list listing devices across all controllers. I think this is the most practical thing to do, but one could imagine wanting to query by controller ID instead. Feedback welcome. --- tools/libxl/libxl.h | 46 ++ 1 file changed, 46 insertions(+) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 2ed7194..d757845 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -1234,6 +1234,52 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms); * * This function does not interact with the guest and therefore * cannot block on the guest. + * + * Controllers + * --- + * + * Most devices are treated individually. Some devices however, like + * USB or SCSI, inherently have the need to have busses or + * controllers to which individual devices can be attached. + * + * In that case, for each type, there will be two sets of the + * functions, types, and devid namespaces outlined above: one based on + * 'type', and one based on 'typectrl'. + * + * In those cases, libxl_device_typectrl_function will act more or + * less like top-level non-bus devices: they will either create or + * accept a libxl_devid which will be unique within the + * typectrl libxl_devid namespace. + * + * Second-level devices which will be attached to a controller will + * include in their libxl_device_type a field called ctrl, which + * will be the libxl_devid of the corresponding controller. It may also + * include an index onto that bus, that represents (for example) a USB + * port or a SCSI LUN. + * + * These second-level devices will also have their own devid which + * will be unique within the type devid namespace, and will be used + * for queries or removals. + * + * In the case where there are multiple different ways to implement a + * given device -- for instance, one which is fully PV and one which + * uses an emulator -- the controller will contain a field which + * specifies what type of implementation is used. The implementations + * of individual devices will be known by the controller to which they are + * attached. + * + * If libxl_device_type_add receives an uninitialized ctrl devid, it + * may return an error. Or it may (but is not required to) choose to + * automatically choose a suitable controller to which to attach the + * new device. It may also (but is not required to) automatically + * create a new controller if no suitable controllers exist. + * Individual devices should document their behavior. + * + * libxl_device_typectrl_list will list all controllers for the domain. + * + * libxl_device_type_list will list all devices for all controllers + * for the domain. The individual libxl_device_type will include + * the devid of the controller to which it is attached. */ So just for concreteness, here is a somewhat dumb conversion of the most recently-posted pvscsi IDL using this template:
Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
On 05/21/2015 06: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.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Juergen Gross jgr...@suse.com CC: Chun Yan Liu cy...@suse.com CC: Olaf Hering o...@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 typectrl for the device name, and using ctrl as the field name for the devid of the controller in the individual devices. * I've said that having an index (port, lun, whatever) is optional. Do we want to make that requred? Do we want it to have a consistent name? In the case of emulated USB, we can't really specify to qemu what port the device gets attached to, so I'm tempted to say it's not required; but even there we could always give it a port number just for name's sake. * Naming sub-devices. We need to have a way to uniquely name both controllers and subdevices. Here I've said that we will have both typectrl and type devid namespaces, mainly because in the previous point I opted not to require an index. Another option would be not to have another devid namespace, but to use ctrl,index as the unique identifier. (This would mean requiring the index/port/lun specification above.) * libxl_device_type_list listing devices across all controllers. I think this is the most practical thing to do, but one could imagine wanting to query by controller ID instead. Feedback welcome. --- tools/libxl/libxl.h | 46 ++ 1 file changed, 46 insertions(+) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 2ed7194..d757845 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -1234,6 +1234,52 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms); * * This function does not interact with the guest and therefore * cannot block on the guest. + * + * Controllers + * --- + * + * Most devices are treated individually. Some devices however, like + * USB or SCSI, inherently have the need to have busses or + * controllers to which individual devices can be attached. + * + * In that case, for each type, there will be two sets of the + * functions, types, and devid namespaces outlined above: one based on + * 'type', and one based on 'typectrl'. + * + * In those cases, libxl_device_typectrl_function will act more or + * less like top-level non-bus devices: they will either create or + * accept a libxl_devid which will be unique within the + * typectrl libxl_devid namespace. + * + * Second-level devices which will be attached to a controller will + * include in their libxl_device_type a field called ctrl, which + * will be the libxl_devid of the corresponding controller. It may also + * include an index onto that bus, that represents (for example) a USB + * port or a SCSI LUN. + * + * These second-level devices will also have their own devid which + * will be unique within the type devid namespace, and will be used + * for queries or removals. + * + * In the case where there are multiple different ways to implement a + * given device -- for instance, one which is fully PV and one which + * uses an emulator -- the controller will contain a field which + * specifies what type of implementation is used. The implementations + * of individual devices will be known by the controller to which they are + * attached. + * + * If libxl_device_type_add receives an uninitialized ctrl devid, it + * may return an error. Or it may (but is not required to) choose to + * automatically choose a suitable controller to which to attach the + * new device. It may also (but is not required to) automatically + * create a new controller if no suitable controllers exist. + * Individual devices should document their behavior. + * + * libxl_device_typectrl_list will list all controllers for the domain. + * + * libxl_device_type_list will list all devices for all controllers + * for the domain. The individual libxl_device_type will include + * the devid of the controller to which it is attached. Hmm, I also meant to add: --- For each type, the domain config file will contain a single list of controllers, and a single list of
Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
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.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Juergen Gross jgr...@suse.com CC: Chun Yan Liu cy...@suse.com CC: Olaf Hering o...@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 typectrl 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 (typedevgoup)? 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. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
