Re: [Xen-devel] RFC: Proposed libxl USB hot-plug interface

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

George Dunlap writes ("RFC: Proposed libxl USB hot-plug interface"):
> OK, based on the feedback, what about an interface like the following?

This looks plausible.

> The idea would be that long-term, AUTO would always do PV for PV VMs, 
> and would somehow decide whether to do HVM or PV for HVM domains.

Right.

> The "type" and the "union" fields are designed to allow the interface to 
> be extended to include other types of devices, such as adding emulated 
> tablets, mice, keyboards, usb sticks, &c.

Right.

> "list" should return all available USB devices including the "handle" 
> that can be used to remove a device.

> struct libxl_device_usb {
>      uint16_t protocol; /* AUTO, PV, HVM */
>      uint16_t type; /* HOST; later can be emulated devices like tablet, 
> disk, &c */
>      uint32_t backend_domain_id; /* For PVUSB */

I don't see why the backend domain is necessarily invalid for hvm
domains.  In the stub-dm, you're going to have both an emulated
interface (at the guest-dm interface) and a PV one (at the dm-backend
interface).  (Not that this will necessarily be implemented right
away!)

>      uint64_t handle;  /* OUT: Unique (per domain) handle that must be 
> used to remove a device */

I'm not sure mixing in and out parameters in the single struct is a
good idea.

>      int
>      union {
>          struct {
>              int hostbus, hostaddr, vendorid, productid;
>          } host;

This needs some more documentation.  Why is it a union ?  What are its
other options, etc. ?

I guess you can set the values to -1 to mean "wildcard" ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel