Re: [Xen-devel] [RFC 14/19] xen/passthrough: dt: Add new domctl XEN_DOMCTL_assign_dt_device

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.06.14 at 18:18, <julien.grall@xxxxxxxxxx> wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h

I think you should be Cc-ing all relevant maintainers for common code
(here: interface) changes.

> @@ -936,6 +936,14 @@ typedef struct xen_domctl_vcpu_msrs 
> xen_domctl_vcpu_msrs_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vcpu_msrs_t);
>  #endif
>  
> +/* Device Tree: Assign a non-PCI device to a guest */
> +struct xen_domctl_assign_dt_device {
> +    uint32_t size; /* IN: Length of the path */
> +    XEN_GUEST_HANDLE_64(char) path; /* IN: path to the device tree node */

Are paths (encoded as strings) indeed the canonical way of
representing devices? How does the tool stack know what is valid
to be passed in here?

> +};
> +typedef struct xen_domctl_assign_dt_device xen_domctl_assign_dt_device_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_dt_device_t);
> +
>  struct xen_domctl {
>      uint32_t cmd;
>  #define XEN_DOMCTL_createdomain                   1
> @@ -1008,6 +1016,7 @@ struct xen_domctl {
>  #define XEN_DOMCTL_cacheflush                    71
>  #define XEN_DOMCTL_get_vcpu_msrs                 72
>  #define XEN_DOMCTL_set_vcpu_msrs                 73
> +#define XEN_DOMCTL_assign_dt_device              74

How come you get away with just one operation here, when for PCI
pass-through we have three (assign, test-assign, and deassign)?

Jan


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