|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6 1/2] libxl: Introduce functions to add and remove USB devices to an HVM guest
On Fri, 2013-04-19 at 16:59 +0100, George Dunlap wrote:
> This patch exposes a generic interface which can be expanded in the
> future to implement USB for PVUSB, qemu, and stubdoms. It can also be
> extended to include other types of USB other than host USB (for example,
> tablets, mice, or keyboards).
>
> For each device removed or added, one of two protocols is available:
> * PVUSB
> * qemu (DEVICEMODEL)
>
> The caller can additionally specify "AUTO", in which case the library will
> try to determine the best protocol automatically.
>
> At the moment, the only protocol implemented is DEVICEMODEL, and the only
> device type impelmented is HOSTDEV.
>
> This uses the qmp functionality, and is thus only available for
> qemu-xen, not qemu-traditional.
>
> History:
> v6:
> - Return a proper error code if libxl__xs_mkdir fails
> - Make casts cuddly
> - Add a space after switch statements
> v5:
> - fix erroneous use of NOGC in qmp functions
> - Don't check return of libxl__sprintf in libxl_create.c
> - Check return values of new xs actions in libxl_create.c
> - Use updated template for xenstore transactions, do checks
> - use xs_read_checked
> - Fixed if (x) spacing to match coding style
> - use GCSFPRINTF
> - use libxl__calloc
> - Fix comment for LIBXL_HAVE_USB
> - use idl-generated *_from_string() and *_to_string() functions
>
> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
> CC: Ian Jackson <ian.jackson@xxxxxxxxxx>
> CC: Roger Pau Monne <roger.pau@xxxxxxxxxx>
> CC: sstanisi@xxxxxxxxx
> ---
> tools/libxl/Makefile | 2 +-
> tools/libxl/libxl.h | 37 +++
> tools/libxl/libxl_create.c | 13 +-
> tools/libxl/libxl_internal.h | 18 ++
> tools/libxl/libxl_qmp.c | 65 +++++
> tools/libxl/libxl_types.idl | 22 ++
> tools/libxl/libxl_usb.c | 526
> ++++++++++++++++++++++++++++++++++++++++
> tools/ocaml/libs/xl/genwrap.py | 1 +
I've only commented on the interface bits (libxl.h, libxl_types.idl)
here. I'll go over the implementation next.
> 8 files changed, 682 insertions(+), 2 deletions(-)
> create mode 100644 tools/libxl/libxl_usb.c
>
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 4922313..b6edd15 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -75,6 +75,12 @@
> #define LIBXL_HAVE_FIRMWARE_PASSTHROUGH 1
>
> /*
> + * LIBXL_HAVE_USB indicates the functions for doing hot-plug of
> + * USB devices.
> + */
> +#define LIBXL_HAVE_USB 1
LIBXL_HAVE_DEVICE_USB would be consistent with the struct/interface
naming. Not that I expect this to be ambiguous I guess.
> +
> +/*
> * libxl ABI compatibility
> *
> * The only guarantee which libxl makes regarding ABI compatibility
> @@ -735,6 +741,37 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid,
> libxl_device_disk *disk,
> const libxl_asyncop_how *ao_how)
> LIBXL_EXTERNAL_CALLERS_ONLY;
>
> +/*
> + * USB
> + *
> + * For each device removed or added, one of these protocols is available:
> + * - PV (i.e., PVUSB)
> + * - DEVICEMODEL (i.e, qemu)
> + *
> + * PV is available for either PV or HVM domains. DEVICEMODEL is only
> + * available for HVM domains. The caller can additionally specify
> + * "AUTO", in which case the library will try to determine the best
> + * protocol automatically.
> + *
> + * At the moment, the only protocol implemented is DEVICEMODEL, and the only
> + * device type impelmented is HOSTDEV.
implemented
If PV isn't implemented I think we should leave it out of the API for
now, when it is implemented it will need a LIBXL_HAVE_DEVICE_USB_TYPE_PV
or whatever anyway.
> + *
> + * This uses the qmp functionality, and is thus only available for
> + * qemu-xen, not qemu-traditional.
> + */
> +#define LIBXL_DEVICE_USB_BACKEND_DEFAULT (-1)
> +int libxl_device_usb_add(libxl_ctx *ctx, uint32_t domid,
> + libxl_device_usb *dev,
> + const libxl_asyncop_how *ao_how)
> + LIBXL_EXTERNAL_CALLERS_ONLY;
> +int libxl_device_usb_remove(libxl_ctx *ctx, uint32_t domid,
> + libxl_device_usb *dev,
> + const libxl_asyncop_how *ao_how)
> + LIBXL_EXTERNAL_CALLERS_ONLY;
No _destroy or _getinfo?
_getinfo might be optional if there isn't any interesting info, but
_destroy is a must IMHO.
> +libxl_device_usb *libxl_device_usb_list(libxl_ctx *ctx, uint32_t domid,
> + int *num)
> + LIBXL_EXTERNAL_CALLERS_ONLY;
> +
> /* Network Interfaces */
> int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic
> *nic,
> const libxl_asyncop_how *ao_how)
[...]
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index fcb1ecd..3c6a709 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -408,6 +408,28 @@ libxl_device_vtpm = Struct("device_vtpm", [
> ("uuid", libxl_uuid),
> ])
>
> +libxl_device_usb_protocol = Enumeration("usb_protocol", [
> + (0, "AUTO"),
> + (1, "PV"),
> + (2, "DEVICEMODEL"),
> + ])
> +
> +libxl_device_usb_type = Enumeration("device_usb_type", [
> + (1, "HOSTDEV"),
> + ])
> +
> +libxl_device_usb = Struct("device_usb", [
> + ("protocol", libxl_device_usb_protocol,
> + {'init_val': 'LIBXL_USB_PROTOCOL_AUTO'}),
> + ("backend_domid", libxl_domid,
> + {'init_val': 'LIBXL_DEVICE_USB_BACKEND_DEFAULT'}),
I think now that ef496b81f0336f09968a318e7f81151dd4f5a0cc has gone in we
should have a backend_domname (and appropriate handling) for new
devices.
I don't think you need to set a default for a libxl_domid, the implicit
default is 0 and if we wanted to be explicit we should do it on the
libxl_domid type so it is consistent for all devices. Likewise I don't
think you need LIBXL_DEVICE_USB_BACKEND_DEFAULT == -1 and the handling
to make that 0 internally -- just make the default 0 and let the user
change if they like (this is how the other devices work).
> + ("u", KeyedUnion(None, libxl_device_usb_type, "type",
> + [("hostdev", Struct(None, [
> + ("hostbus", integer),
> + ("hostaddr", integer) ]))
> + ]))
> + ])
> +
> libxl_domain_config = Struct("domain_config", [
> ("c_info", libxl_domain_create_info),
> ("b_info", libxl_domain_build_info),
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |