On Tue, 2015-01-13 at 14:25 +0000, Julien Grall wrote:
> TODO: Update the commit message
> 
> A device node is described by a path. It will be used to retrieved the
> node in the device tree and assign the related device to the domain.
> 
> Only device protected by an IOMMU can be assigned to a guest.
> 
> Signed-off-by: Julien Grall <julien.gr...@linaro.org>
> Cc: Ian Jackson <ian.jack...@eu.citrix.com>
> Cc: Wei Liu <wei.l...@citrix.com>
> Cc: Jan Beulich <jbeul...@suse.com>
> 
> ---
>     Changes in v2:
>         - Use a different number for XEN_DOMCTL_assign_dt_device
> ---
>  tools/libxc/include/xenctrl.h         | 10 ++++
>  tools/libxc/xc_domain.c               | 95 ++++++++++++++++++++++++++++++++--

These bits all look fine.

> +int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
> +                       XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> +{
> +    int ret;
> +    struct dt_device_node *dev;
> +
> +    /* TODO: How to deal with XSM? */

Adding Daniel.

It seems the PCI ones are protected by 
        xsm_test_assign_device(XSM_HOOK, domctl->u.assign_device.machine_sbdf);

So it seem that either this needs to become "test_assign_pci_device" and
a similar "test_assign_dt_device" needs to be added and plumbed through
or it needs to grow a type parameter and take the union for the
identifier.

The code to apply an XSM context to a DT node would need consideration
too I suppose?

> +    /* TODO: Do we need to check is_dying? Mostly to protect against
> +     * hypercall trying to passthrough a device while we are
> +     * dying.

FWIW the PCI case appears not to care...

> +     */
> +
> +    switch ( domctl->cmd )
> +    {
> +    case XEN_DOMCTL_assign_device:
> +        ret = -ENOSYS;
> +        if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT )
> +            break;

You added something similar to iommu_do_pci_domctl, would it not be
preferable for the caller to switch on domctl->u.assign_device.dev and
call the correct iommu_do_*_domctl?

Ian.


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

Reply via email to