Re: [Xen-devel] [PATCH v5 3/5] libxl: add support for vscsi
On 05/15/2015 10:47 AM, Ian Campbell wrote: On Fri, 2015-05-15 at 07:58 +0200, Olaf Hering wrote: On Fri, May 15, Jürgen Groß wrote: Multi-LUN devices do exist and they are required to be presented as those to the guest. Ok, this means we need the bus concept. I will see if the API for add/remove can be changed that only devices get passed to the libxl. Does a multi-LUN device require it's own bus or something? Or do the LUN numbers need to be passed through to the guest because things get upset otherwise? IOW why does multi-LUN imply multi-bus, and even if so why does that need to be exposed to the user? These are e.g. RAID-systems or tape libraries. In most cases one LUN is a control LUN via which the other LUNs can be configured and/or administrated. This implies that all of those LUNs have to share the same target and they need to have the same LUN numbers in the guest as on the real device. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/5] libxl: add support for vscsi
On Fri, 2015-05-15 at 11:35 +0200, Juergen Gross wrote: On 05/15/2015 10:47 AM, Ian Campbell wrote: On Fri, 2015-05-15 at 07:58 +0200, Olaf Hering wrote: On Fri, May 15, Jürgen Groß wrote: Multi-LUN devices do exist and they are required to be presented as those to the guest. Ok, this means we need the bus concept. I will see if the API for add/remove can be changed that only devices get passed to the libxl. Does a multi-LUN device require it's own bus or something? Or do the LUN numbers need to be passed through to the guest because things get upset otherwise? IOW why does multi-LUN imply multi-bus, and even if so why does that need to be exposed to the user? These are e.g. RAID-systems or tape libraries. In most cases one LUN is a control LUN via which the other LUNs can be configured and/or administrated. This implies that all of those LUNs have to share the same target and they need to have the same LUN numbers in the guest as on the real device. That makes sense, thanks. So it seems we do need to expose some concept of the bus itself to users. My preference would be for the API for such devices (currently USB and PVSCSI) to have broadly speaking the same shape, much like how the API for the existing busless devices all look mostly the same. (NB: Lets ignore the fact for now that PCI is in the wrong bucket...) I'd like to start with seeing an expanded version of the comment in libxl.h which begins: /* * Devices * === which covers this new style API alongside the existing one and sets out the expected pattern of naming (both struct and function) in the same way. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/5] libxl: add support for vscsi
On Fri, May 15, Jürgen Groß wrote: Multi-LUN devices do exist and they are required to be presented as those to the guest. Ok, this means we need the bus concept. I will see if the API for add/remove can be changed that only devices get passed to the libxl. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/5] libxl: add support for vscsi
On Wed, May 13, Ian Campbell wrote: On Wed, 2015-05-06 at 13:28 +, Olaf Hering wrote: +++ b/docs/man/xl.pod.1 @@ -1328,6 +1328,24 @@ List virtual trusted platform modules for a domain. =back +=head2 PVSCSI DEVICES + +=over 4 + +=item Bscsi-attach Idomain-id Ipdev Ivdev,I[feature-host] Unlike in the xl.cfg disk spec the pdev and vdev are separated with space rather than ,, is that deliberate? (I don't mind, just want to check it's intended). Yes, pdev and vdev are space separated. I have to double check how xm handled the additional feature-host option, it was most likely comma separated. +=item Bscsi-list Idomain-id I[domain-id] ... + +List vscsi devices for the domain specified by Idomain-id. Does/could omitting the domid list them all? No, at least one domid is required. Not sure how desirable (and racy) it is to walk every domain and look for vscsi devices. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/5] libxl: add support for vscsi
On Fri, 2015-05-15 at 10:46 +0100, Ian Campbell wrote: I'd like to start with seeing an expanded version of the comment in libxl.h which begins: /* * Devices * === which covers this new style API alongside the existing one and sets out the expected pattern of naming (both struct and function) in the same way. Which would need to be agreed with the PVUSB series author(s) too. In fact I think they may already incorporate such an API proposal (even if only implicitly). The first step should probably be to see if that API can be generalised to apply to pvsci first, and then hopefully write down the generalised form. Ian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/5] libxl: add support for vscsi
On 05/13/2015 07:31 PM, Olaf Hering wrote: On Wed, May 13, Ian Campbell wrote: Is it important/useful that the user be able to configure/control the number (and addresses) of the buses themselves and which devices are on which, or can we get away with the pvpci model where the libxl user just gives the individual devices and the library internally takes care of what buses need to be created? I do not know if its important for users of vscsi to build a bus with several devices. Giving each device its own bus would work as well, which would turn the whole thing into ordinary devices from libxl POV. No idea where the initial idea came from. Even if the feature-host thing is used, the raw passthrough of SCSI commands would continue to work. Are you talking about single LUNs or only targets? Multi-LUN devices do exist and they are required to be presented as those to the guest. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/5] libxl: add support for vscsi
Just looking at the API functions on this pass. General comment though: Please go through and rewrap any lines longer than 75-80, I saw quite a few as I was scrolling. @@ -3628,6 +3643,7 @@ static inline void libxl__update_config_vtpm(libxl__gc *gc, * devices have same identifier. */ #define COMPARE_DEVID(a, b) ((a)-devid == (b)-devid) #define COMPARE_DISK(a, b) (!strcmp((a)-vdev, (b)-vdev)) +#define COMPARE_VSCSI(a, b) ((a)-v_hst == (b)-v_hst) Does this end up doing the correct thing given that vscsi is a bit different and the libxl_device_vscsi is actually a bus? Shouldn't something somewhere be taking care that vscsi-vscsi_devs is up to date, not just the list of the vscsi busses? #define COMPARE_PCI(a, b) ((a)-func == (b)-func \ (a)-bus == (b)-bus \ (a)-dev == (b)-dev) libxl_vscsi_dev = Struct(vscsi_dev, [ +(vscsi_dev_id, libxl_devid), +(remove, bool), What is this remove field? A libxl_vscsi_dev describes a device, not the actions which can be performed on the device. Those are in the names of the functions. +(pdev, libxl_vscsi_pdev), +(vdev, libxl_vscsi_hctl), +]) + +libxl_device_vscsi = Struct(device_vscsi, [ +(backend_domid,libxl_domid), +(devid,libxl_devid), +(v_hst,uint32), +(vscsi_devs, Array(libxl_vscsi_dev, num_vscsi_devs)), +(next_vscsi_dev_id, libxl_devid), This one also seems odd. If you need to store state internally within libxl then you will have to arrange to store it somewhere else, the public API structs are not appropriate. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/5] libxl: add support for vscsi
On Wed, 2015-05-06 at 13:28 +, Olaf Hering wrote:
Port pvscsi support from xend to libxl:
vscsi=['pdev,vdev{,options}']
xl scsi-attach
xl scsi-detach
xl scsi-list
Signed-off-by: Olaf Hering o...@aepfle.de
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
docs/man/xl.cfg.pod.5| 55 +++
docs/man/xl.pod.1| 18 +
tools/libxl/Makefile | 2 +
tools/libxl/libxl.c | 440 +
tools/libxl/libxl.h | 27 ++
tools/libxl/libxl_create.c | 1 +
tools/libxl/libxl_device.c | 2 +
tools/libxl/libxl_internal.h | 16 +
tools/libxl/libxl_types.idl | 56 +++
tools/libxl/libxl_types_internal.idl | 1 +
tools/libxl/libxl_vscsi.c| 274 +
tools/libxl/libxlu_vscsi.c | 745
+++
tools/libxl/libxlutil.h | 18 +
tools/libxl/xl.h | 3 +
tools/libxl/xl_cmdimpl.c | 205 +-
tools/libxl/xl_cmdtable.c| 15 +
16 files changed, 1877 insertions(+), 1 deletion(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index f936dfc..6a7dc8c 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -510,6 +510,61 @@ value is optional if this is a guest domain.
=back
+=item Bvscsi=[ VSCSI_SPEC_STRING, VSCSI_SPEC_STRING, ...]
+
+Specifies the PVSCSI devices to be provided to the guest. PVSCSI passes
+SCSI devices from the backend domain to the guest.
+
+Each VSCSI_SPEC_STRING consists of pdev,vdev[,options].
+'pdev' describes the physical device, preferable in a persistent format such
as /dev/disk/by-*/*.
+'vdev' is the domU device in vHOST:CHANNEL:TARGET:LUN notation, all integers.
+'option' lists additional flags which a backend may recognize.
It's options not option in the spec, I think options is more correct
(and below too).
+The supported values for pdev and option depends on the used backend
driver:
... on the backend driver used
+
+=over 4
+
+=item BLinux
+
+=over 4
+
+=item Cpdev
+
+The backend driver in the pvops kernel is part of the Linux-IO Target
framework
+(LIO). As such the SCSI devices have to be configured first with the tools
+provided by this framework, such as a xen-scsiback aware targetcli. The
pdev
+in domU.cfg has to refer to a config item in that framework instead of the
raw
+device. Ususally this is a WWN in the form of na.WWN:LUN.
Usually.
What sort configuration is needed? I assume it is not sufficient to just
point xl at /dev/scsi/a-thing. Is the requirement something like binding
a PCI device to pciback?
A quick example of the expected usage of targetcli would go a long way,
I think.
[...]
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 16783c8..19bdbfa 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1328,6 +1328,24 @@ List virtual trusted platform modules for a domain.
=back
+=head2 PVSCSI DEVICES
+
+=over 4
+
+=item Bscsi-attach Idomain-id Ipdev Ivdev,I[feature-host]
Unlike in the xl.cfg disk spec the pdev and vdev are separated with
space rather than ,, is that deliberate? (I don't mind, just want to
check it's intended).
+Creates a new vscsi device in the domain specified by Idomain-id.
+
+=item Bscsi-detach Idomain-id Ivdev
+
+Removes the vscsi device from domain specified by Idomain-id.
+
+=item Bscsi-list Idomain-id I[domain-id] ...
+
+List vscsi devices for the domain specified by Idomain-id.
Does/could omitting the domid list them all?
I'm going to hit send now and then start again with the code portion of
this patch.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/5] libxl: add support for vscsi
On Wed, 2015-05-13 at 15:44 +0100, Ian Campbell wrote: #define COMPARE_PCI(a, b) ((a)-func == (b)-func \ (a)-bus == (b)-bus \ (a)-dev == (b)-dev) libxl_vscsi_dev = Struct(vscsi_dev, [ +(vscsi_dev_id, libxl_devid), +(remove, bool), What is this remove field? A libxl_vscsi_dev describes a device, not the actions which can be performed on the device. Those are in the names of the functions. I started reviewing the code and came across the usage of this, and I'm afraid we need to reconsider how this stuff fits together. The underlying issue is that vscsi, like pci (and maybe pvusb?), is a bit different to other devices, in that the xenstore front/back actually represent a bus and not individual devices, which are represented as subdevices. You've represented this as a libxl_vscsi_dev which is actually a bus containing an array of devices, which leads to an API where to remove a device you have to provide libxl_device_scsi_remove with a libxl_device_vscsi where the individual devices are tagged for remove or not, using a field in the dev descriptor. Really the remove API should be taking something like what you've called libxl_vscsi_dev. There are also issues around updating the json state etc which I think are made more complicated because of this (DEVICE_ADD called in dev_rm, and a new version of DEVICE_REMOVE etc). Is it important/useful that the user be able to configure/control the number (and addresses) of the buses themselves and which devices are on which, or can we get away with the pvpci model where the libxl user just gives the individual devices and the library internally takes care of what buses need to be created? If that is not an option then we may need to follow the pvusb model (Chunyan and George CC-d in case I've got it wrong) which is to have explicit/separate host and device structs in the libxl API and associated separate commands to add/remove buses vs add/remove devices on those buses. I don't think splitting the structs but not the API functions as you hae here is something we want to go with. Going the PCI route would almost certainly be less work at both the API and implementation side. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/5] libxl: add support for vscsi
On Wed, May 13, Ian Campbell wrote: You've represented this as a libxl_vscsi_dev which is actually a bus containing an array of devices, which leads to an API where to remove a device you have to provide libxl_device_scsi_remove with a libxl_device_vscsi where the individual devices are tagged for remove or not, using a field in the dev descriptor. Really the remove API should be taking something like what you've called libxl_vscsi_dev. You are right: at least the remove function should just get a device (libxl_vscsi_dev) instead of a bus (libxl_device_vscsi) with devices tagged for remove. As things are implemented now libxl_device_vscsi_list can be called by libxl itself, so the remove function can just search the provided vdev and either just remove it or wipe the entire bus. That means part of xlu_vscsi_detach goes into libxl_device_vscsi_remove. There are also issues around updating the json state etc which I think are made more complicated because of this (DEVICE_ADD called in dev_rm, and a new version of DEVICE_REMOVE etc). Yes, libxl_device_vscsi_remove has to keep both xenstore and json in sync. Is it important/useful that the user be able to configure/control the number (and addresses) of the buses themselves and which devices are on which, or can we get away with the pvpci model where the libxl user just gives the individual devices and the library internally takes care of what buses need to be created? I do not know if its important for users of vscsi to build a bus with several devices. Giving each device its own bus would work as well, which would turn the whole thing into ordinary devices from libxl POV. No idea where the initial idea came from. Even if the feature-host thing is used, the raw passthrough of SCSI commands would continue to work. If that is not an option then we may need to follow the pvusb model (Chunyan and George CC-d in case I've got it wrong) which is to have explicit/separate host and device structs in the libxl API and associated separate commands to add/remove buses vs add/remove devices on those buses. I think the backend could deal with an empty bus, which has an empty vscsi-devs/ dir in xenstore. I will think about it. I don't think splitting the structs but not the API functions as you hae here is something we want to go with. Not sure how pvusb or pci acutally looks like, but I will see how pvscsi looks like if libxl gets just libxl_vscsi_dev as input. The bus handling itself could be done within libxl, so that libxl_device_vscsi becomes internal to libxl. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/5] libxl: add support for vscsi
On Wed, May 13, Ian Campbell wrote: Just looking at the API functions on this pass. @@ -3628,6 +3643,7 @@ static inline void libxl__update_config_vtpm(libxl__gc *gc, * devices have same identifier. */ #define COMPARE_DEVID(a, b) ((a)-devid == (b)-devid) #define COMPARE_DISK(a, b) (!strcmp((a)-vdev, (b)-vdev)) +#define COMPARE_VSCSI(a, b) ((a)-v_hst == (b)-v_hst) Does this end up doing the correct thing given that vscsi is a bit different and the libxl_device_vscsi is actually a bus? Shouldn't something somewhere be taking care that vscsi-vscsi_devs is up to date, not just the list of the vscsi busses? In the usecases I have seen comparing just the index number -v_hst is ok IMO. The tricky part is to keep xenstore and the json in sync. Given your comment below, if -remove will be dropped it will be required to always keep xenstore and json in sync. I will see what needs to be done. #define COMPARE_PCI(a, b) ((a)-func == (b)-func \ (a)-bus == (b)-bus \ (a)-dev == (b)-dev) libxl_vscsi_dev = Struct(vscsi_dev, [ +(vscsi_dev_id, libxl_devid), +(remove, bool), What is this remove field? A libxl_vscsi_dev describes a device, not the actions which can be performed on the device. Those are in the names of the functions. This is also used by the JSON to not readd an already removed device. But perhaps the code should just use a dummy vhost-vdev and pass that into libxl. Which in turn searches in the list of active vdevs for the requested vdev and removes it. Sounds reasonable to do it that way. +(pdev, libxl_vscsi_pdev), +(vdev, libxl_vscsi_hctl), +]) + +libxl_device_vscsi = Struct(device_vscsi, [ +(backend_domid,libxl_domid), +(devid,libxl_devid), +(v_hst,uint32), +(vscsi_devs, Array(libxl_vscsi_dev, num_vscsi_devs)), +(next_vscsi_dev_id, libxl_devid), This one also seems odd. If you need to store state internally within libxl then you will have to arrange to store it somewhere else, the public API structs are not appropriate. Makes sense. I will rearrange the code which makes use of that member. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/5] libxl: add support for vscsi
On Wed, May 13, 2015 at 4:12 PM, Ian Campbell ian.campb...@citrix.com wrote: If that is not an option then we may need to follow the pvusb model (Chunyan and George CC-d in case I've got it wrong) which is to have explicit/separate host and device structs in the libxl API and associated separate commands to add/remove buses vs add/remove devices on those buses. I seem to recall that the end goal for pvusb was that you *could* specify busses if you wanted to, but that if you didn't, libxl would just do something sensible behind the scenes (as you are suggesting with pvscsi). One of the reasons for making this explicit was that libvirt (as I understand it) wants to be able to make it explicit. Another reason is that in the USB case we're actually trying to share two different pathways -- pvusb and dm-usb (i.e., a device passed through via qemu), each of which are only available on some guests. In the case of a PV guest, it's pretty clear which one to use; but in the case of an HVM guest, it may not be clear to the toolstack what pathway the guest OS is capable of using. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 3/5] libxl: add support for vscsi
Port pvscsi support from xend to libxl:
vscsi=['pdev,vdev{,options}']
xl scsi-attach
xl scsi-detach
xl scsi-list
Signed-off-by: Olaf Hering o...@aepfle.de
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
docs/man/xl.cfg.pod.5| 55 +++
docs/man/xl.pod.1| 18 +
tools/libxl/Makefile | 2 +
tools/libxl/libxl.c | 440 +
tools/libxl/libxl.h | 27 ++
tools/libxl/libxl_create.c | 1 +
tools/libxl/libxl_device.c | 2 +
tools/libxl/libxl_internal.h | 16 +
tools/libxl/libxl_types.idl | 56 +++
tools/libxl/libxl_types_internal.idl | 1 +
tools/libxl/libxl_vscsi.c| 274 +
tools/libxl/libxlu_vscsi.c | 745 +++
tools/libxl/libxlutil.h | 18 +
tools/libxl/xl.h | 3 +
tools/libxl/xl_cmdimpl.c | 205 +-
tools/libxl/xl_cmdtable.c| 15 +
16 files changed, 1877 insertions(+), 1 deletion(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index f936dfc..6a7dc8c 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -510,6 +510,61 @@ value is optional if this is a guest domain.
=back
+=item Bvscsi=[ VSCSI_SPEC_STRING, VSCSI_SPEC_STRING, ...]
+
+Specifies the PVSCSI devices to be provided to the guest. PVSCSI passes
+SCSI devices from the backend domain to the guest.
+
+Each VSCSI_SPEC_STRING consists of pdev,vdev[,options].
+'pdev' describes the physical device, preferable in a persistent format such
as /dev/disk/by-*/*.
+'vdev' is the domU device in vHOST:CHANNEL:TARGET:LUN notation, all integers.
+'option' lists additional flags which a backend may recognize.
+
+The supported values for pdev and option depends on the used backend
driver:
+
+=over 4
+
+=item BLinux
+
+=over 4
+
+=item Cpdev
+
+The backend driver in the pvops kernel is part of the Linux-IO Target framework
+(LIO). As such the SCSI devices have to be configured first with the tools
+provided by this framework, such as a xen-scsiback aware targetcli. The pdev
+in domU.cfg has to refer to a config item in that framework instead of the raw
+device. Ususally this is a WWN in the form of na.WWN:LUN.
+
+=item Coption
+
+No options recognized.
+
+=back
+
+=item BLinux based on classic Xen kernel
+
+=over 4
+
+=item Cpdev
+
+The dom0 device in either /dev/scsidev or pHOST:CHANNEL:TARGET:LUN notation.
+
+It's recommended to use persistent names /dev/disk/by-*/* to refer to a
pdev.
+The toolstack will translate this internally to h:c:t:l notation, which is
how
+the backend driver will access the device. Using the h:c:t:l notation for
+pdev in domU.cfg is discouraged because this value will change across
reboots,
+depending on the detection order in the OS.
+
+=item Coption
+
+Currently only the option value feature-host is recognized. SCSI command
+emulation in backend driver is bypassed when feature-host is specified.
+
+=back
+
+=back
+
=item Bvfb=[ VFB_SPEC_STRING, VFB_SPEC_STRING, ...]
Specifies the paravirtual framebuffer devices which should be supplied
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 16783c8..19bdbfa 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1328,6 +1328,24 @@ List virtual trusted platform modules for a domain.
=back
+=head2 PVSCSI DEVICES
+
+=over 4
+
+=item Bscsi-attach Idomain-id Ipdev Ivdev,I[feature-host]
+
+Creates a new vscsi device in the domain specified by Idomain-id.
+
+=item Bscsi-detach Idomain-id Ivdev
+
+Removes the vscsi device from domain specified by Idomain-id.
+
+=item Bscsi-list Idomain-id I[domain-id] ...
+
+List vscsi devices for the domain specified by Idomain-id.
+
+=back
+
=head1 PCI PASS-THROUGH
=over 4
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1b16598..79b3867 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -91,6 +91,7 @@ endif
LIBXL_LIBS += -lyajl
LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
+ libxl_vscsi.o \
libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
libxl_internal.o libxl_utils.o libxl_uuid.o \
libxl_json.o libxl_aoutils.o libxl_numa.o libxl_vnuma.o
\
@@ -122,6 +123,7 @@ AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
_paths.h \
AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
+ libxlu_vscsi.o \
libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
$(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 516713e..4c17d63 100644
---
