xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xen.org, sstanisi@cbnco.com,
	Fabio Fantoni <fabio.fantoni@m2r.biz>,
	Anthony Perard <anthony.perard@citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>,
	"Simon (Bo) Cao" <caobosimon@gmail.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH v7 RFC 1/2] libxl: Introduce functions to add and remove USB devices to an HVM guest
Date: Wed, 18 Jun 2014 14:22:12 +0100	[thread overview]
Message-ID: <53A19284.5070505@eu.citrix.com> (raw)
In-Reply-To: <1403096886.32540.22.camel@kazak.uk.xensource.com>

On 06/18/2014 02:08 PM, Ian Campbell wrote:
> On Mon, 2014-06-02 at 14:44 +0100, George Dunlap wrote:
>> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
>> index c7aa817..963e650 100644
>> --- a/tools/libxl/libxl.h
>> +++ b/tools/libxl/libxl.h
>> @@ -82,6 +82,12 @@
>>   #define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1
>>   
>>   /*
>> + * LIBXL_HAVE_DEVICE_USB indicates the functions for doing hot-plug of
>> + * USB devices.
>> + */
>> +#define LIBXL_HAVE_DEVICE_USB 1
>> +
>> +/*
>>    * LIBXL_HAVE_BUILDINFO_HVM_VENDOR_DEVICE indicates that the
>>    * libxl_vendor_device field is present in the hvm sections of
>>    * libxl_domain_build_info. This field tells libxl which
>> @@ -924,6 +930,40 @@ 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 implemented is HOSTDEV.
>> + *
>> + * This uses the qmp functionality, and is thus only available for
>> + * qemu-xen, not qemu-traditional.
>> + */
>> +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;
>> +int libxl_device_usb_destroy(libxl_ctx *ctx, uint32_t domid,
>> +                             libxl_device_usb *dev,
>> +                             const libxl_asyncop_how *ao_how)
>> +                             LIBXL_EXTERNAL_CALLERS_ONLY;
>> +libxl_device_usb *libxl_device_usb_list(libxl_ctx *ctx, uint32_t domid,
>> +                                        int *num)
>> +                          LIBXL_EXTERNAL_CALLERS_ONLY;
> No _getinfo? (Might only make sense with the PV stuff I guess)

IIRC the pattern I saw for other devices was:
* libxl_device_$FOO struct is used to add, remove, destroy
* libl_device_$FOO_list returns an array of libxl_device_$FOO
* libl_device_$FOO_getinfo is only used when there's information you 
need which is not in libxl_device_$FOO struct (and hence isn't returned 
by _list).


>> +        ("backend_domid",    libxl_domid),
>> +        ("backend_domname",  string),
>> +        ("u", KeyedUnion(None, libxl_device_usb_type, "type",
>> +                         [("hostdev", Struct(None, [
>> +                                ("hostbus",   integer),
>> +                                ("hostaddr",  integer) ]))
> No need to express the host topology I think (because you can build that
> from the bus,addr tuples)?

I don't really follow.  You mean, we can drop 'host' from the last two 
elements, and just call them "bus" and "addr"?

  -George

  reply	other threads:[~2014-06-18 13:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1401716658-22393-1-git-send-email-george.dunlap@eu.citrix.com>
2014-06-02 13:44 ` [PATCH v7 RFC 1/2] libxl: Introduce functions to add and remove USB devices to an HVM guest George Dunlap
2014-06-18 13:08   ` Ian Campbell
2014-06-18 13:22     ` George Dunlap [this message]
2014-06-18 13:49       ` Ian Campbell
2014-06-18 13:58         ` George Dunlap
2014-06-18 14:30           ` Ian Campbell
2014-06-18 14:47             ` George Dunlap
2014-06-02 13:44 ` [PATCH v7 RFC 2/2] xl: Add commands for usb hot-plug George Dunlap
2014-06-05 10:14 ` [PATCH v7 RFC 0/2] libxl USB prototype and design discussion Daniel P. Berrange
     [not found] ` <20140605101438.GD19077@redhat.com>
2014-06-05 15:04   ` George Dunlap
2014-06-18 12:57 ` Ian Campbell
     [not found] ` <1403096222.32540.14.camel@kazak.uk.xensource.com>
2014-06-18 13:15   ` George Dunlap
2014-06-18 14:04   ` George Dunlap
     [not found]   ` <53A19C67.3070809@eu.citrix.com>
2014-06-30 14:41     ` Simon Cao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53A19284.5070505@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=caobosimon@gmail.com \
    --cc=fabio.fantoni@m2r.biz \
    --cc=ian.jackson@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=sstanisi@cbnco.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).