All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien@xen.org>
To: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Nick Rosbrook <rosbrookn@ainfosec.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	Juergen Gross <jgross@suse.com>, Paul Durrant <paul@xen.org>
Subject: Re: [RFC v2 6/8] tools/arm: Introduce force_assign_without_iommu option to xl.cfg
Date: Thu, 17 Feb 2022 15:20:36 +0000	[thread overview]
Message-ID: <ab6d8d13-30cf-d322-668e-f3f5aaa56824@xen.org> (raw)
In-Reply-To: <d333126d12f2281f8df92e66cfba1c9eb2425dca.1644341635.git.oleksii_moisieiev@epam.com>

Hi,

On 08/02/2022 18:00, Oleksii Moisieiev wrote:
> If set, Xen is allowed to assign the devices even if they are not under
> IOMMU.

I think you mean "not protected by an IOMMU".

> Can be confugired from dom.cfg in the following format:

s/confugired/configured/

> force_assign_without_iommu = 1
> 
> This parameter has the same purpose as xen,force-assign-without-iommu
> property in dom0less archtecture.

s/archtecture/architecture/

> 
> Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
> ---
>   docs/man/xl.cfg.5.pod.in              |  9 +++++++++
>   tools/golang/xenlight/helpers.gen.go  |  5 +++++
>   tools/golang/xenlight/types.gen.go    |  1 +
>   tools/libs/light/libxl_arm.c          |  3 +++
>   tools/libs/light/libxl_types.idl      |  1 +
>   tools/xl/xl_parse.c                   |  3 +++
>   xen/common/domain.c                   |  2 +-
>   xen/drivers/passthrough/device_tree.c | 19 +++++++++++++++++--
>   xen/drivers/passthrough/iommu.c       |  5 ++++-
>   xen/include/public/domctl.h           |  5 ++++-
>   xen/include/xen/iommu.h               |  3 +++
>   11 files changed, 51 insertions(+), 5 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index b98d161398..ddf82cb3bc 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -1614,6 +1614,15 @@ This feature is a B<technology preview>.
>   
>   =back
>   
> +=over 4
> +
> +=item B<force_assign_without_iommu=BOOLEAN>
> +
> +If set, Xen allows to assign a devices even if it is not behind an IOMMU.
> +This renders your platform *unsafe* if the device is DMA-capable.

I agree this is going to be unsafe. But the more important bit here is 
this is not going to work because the guest has no way to translate a 
GFN to an MFN.

Your guest will need to be direct map to make it usable. So I would add 
that this will *not* work with DMA-capable devices.

Also, can you explain in the commit message why you want to allow this 
setup?

>       xlu_cfg_get_defbool(config, "xend_suspend_evtchn_compat",
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 093bb4403f..f1f19bf711 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -512,7 +512,7 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config)
>   
>       if ( iommu )
>       {
> -        if ( config->iommu_opts & ~XEN_DOMCTL_IOMMU_no_sharept )
> +        if ( config->iommu_opts >> XEN_DOMCTL_IOMMU_MAX )

XEN_DOMCTL_IOMMU_MAX will be defined as:

(1U << _XEN_DOMCTL_IOMMU_force_iommu)

This means the shift will do the wrong thing. However, AFAICT, this new 
option will only be supported by Arm and likely only for platform device 
for the time being.

That said, I am not convinced this flag should be per-domain in Xen. 
Instead, I think it would be better to pass the flag via the device 
assign domctl.

>           {
>               dprintk(XENLOG_INFO, "Unknown IOMMU options %#x\n",
>                       config->iommu_opts);
> diff --git a/xen/drivers/passthrough/device_tree.c b/xen/drivers/passthrough/device_tree.c
> index 98f2aa0dad..103608dec1 100644
> --- a/xen/drivers/passthrough/device_tree.c
> +++ b/xen/drivers/passthrough/device_tree.c
> @@ -198,6 +198,7 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
>   {
>       int ret;
>       struct dt_device_node *dev;
> +    struct domain_iommu *hd = dom_iommu(d);
>   
>       switch ( domctl->cmd )
>       {
> @@ -238,6 +239,16 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
>               return -EINVAL;
>   
>           ret = iommu_add_dt_device(dev);
> +
> +        /*
> +         * iommu_add_dt_device returns 1 if iommu is disabled or device don't
> +         * have iommus property
> +         */
> +        if ( (ret == 1) && (hd->force_assign_iommu) ) {
> +            ret = -ENOSYS;
> +            break;
> +        }
> +
>           if ( ret < 0 )
>           {
>               printk(XENLOG_G_ERR "Failed to add %s to the IOMMU\n",
> @@ -275,10 +286,14 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
>   
>           ret = iommu_deassign_dt_device(d, dev);
>   
> -        if ( ret )
> -            printk(XENLOG_G_ERR "XEN_DOMCTL_assign_dt_device: assign \"%s\""
> +        if ( ret ) {
> +            if ( hd->force_assign_iommu )
> +                ret = -ENOSYS;
> +            else
> +                printk(XENLOG_G_ERR "XEN_DOMCTL_assign_dt_device: assign \"%s\""
>                      " to dom%u failed (%d)\n",
>                      dt_node_full_name(dev), d->domain_id, ret);
> +        }
>           break;
>   
>       default:
> diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
> index 6334370109..216a9058c0 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -193,6 +193,8 @@ int iommu_domain_init(struct domain *d, unsigned int opts)
>       hd->node = NUMA_NO_NODE;
>   #endif
>   
> +    hd->force_assign_iommu = opts & XEN_DOMCTL_IOMMU_force_iommu;
> +
>       ret = arch_iommu_domain_init(d);
>       if ( ret )
>           return ret;
> @@ -534,6 +536,7 @@ int iommu_do_domctl(
>   {
>       int ret = -ENODEV;
>   
> +

Spurious change.

>       if ( !is_iommu_enabled(d) )

Should not this check be updated to check force_assign?

>           return -EOPNOTSUPP;
>   
> @@ -542,7 +545,7 @@ int iommu_do_domctl(
>   #endif
>   
>   #ifdef CONFIG_HAS_DEVICE_TREE
> -    if ( ret == -ENODEV )
> +    if ( ret == -ENOSYS )

AFAICT, none of the code (including callee) before ret have been 
modified. So why are you modifying the check here?

>           ret = iommu_do_dt_domctl(domctl, d, u_domctl);
>   #endif
>   
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index b85e6170b0..bf5f8c5b6b 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -81,8 +81,11 @@ struct xen_domctl_createdomain {
>   #define _XEN_DOMCTL_IOMMU_no_sharept  0
>   #define XEN_DOMCTL_IOMMU_no_sharept   (1U << _XEN_DOMCTL_IOMMU_no_sharept)
>   
> +#define _XEN_DOMCTL_IOMMU_force_iommu 1
> +#define XEN_DOMCTL_IOMMU_force_iommu  (1U << _XEN_DOMCTL_IOMMU_force_iommu)
> +
>   /* Max XEN_DOMCTL_IOMMU_* constant.  Used for ABI checking. */
> -#define XEN_DOMCTL_IOMMU_MAX XEN_DOMCTL_IOMMU_no_sharept
> +#define XEN_DOMCTL_IOMMU_MAX XEN_DOMCTL_IOMMU_force_iommu
>   
>       uint32_t iommu_opts;
>   
> diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
> index 6b2cdffa4a..a9cf2334af 100644
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -330,6 +330,9 @@ struct domain_iommu {
>        * necessarily imply this is true.
>        */
>       bool need_sync;
> +
> +    /* Do not return error if the device without iommu is assigned */
> +    bool force_assign_iommu;
>   };
>   
>   #define dom_iommu(d)              (&(d)->iommu)

Cheers,

-- 
Julien Grall


  parent reply	other threads:[~2022-02-17 15:21 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-08 18:00 [RFC v2 0/8] Introduce SCI-mediator feature Oleksii Moisieiev
2022-02-08 18:00 ` [RFC v2 1/8] xen/hypfs: support fo nested dynamic hypfs nodes Oleksii Moisieiev
2022-02-10  7:34   ` Juergen Gross
2022-02-11  8:16     ` Oleksii Moisieiev
2022-02-11 13:28       ` Juergen Gross
2022-02-11 13:32         ` Oleksii Moisieiev
2022-02-08 18:00 ` [RFC v2 2/8] libs: libxenhypfs - handle blob properties Oleksii Moisieiev
2022-02-09 13:47   ` Oleksandr Andrushchenko
2022-02-09 14:01     ` Jan Beulich
2022-02-09 14:04       ` Oleksandr Andrushchenko
2022-02-09 14:04   ` Juergen Gross
2022-02-08 18:00 ` [RFC v2 3/8] xen/arm: Export host device-tree to hypfs Oleksii Moisieiev
2022-02-08 18:26   ` Julien Grall
2022-02-09 10:20     ` Oleksii Moisieiev
2022-02-09 12:17       ` Julien Grall
2022-02-09 14:17         ` Oleksii Moisieiev
2022-02-09 18:51         ` Oleksii Moisieiev
2022-02-09 19:34           ` Julien Grall
2022-02-10  9:38             ` Oleksii Moisieiev
2022-02-09 14:03     ` Juergen Gross
2022-02-08 18:00 ` [RFC v2 4/8] xen/arm: add generic SCI mediator framework Oleksii Moisieiev
2022-02-08 18:00 ` [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver Oleksii Moisieiev
2022-02-09 15:02   ` Oleksandr Andrushchenko
2022-02-09 15:23     ` Julien Grall
2022-02-11  8:46   ` Bertrand Marquis
2022-02-11 10:44     ` Oleksii Moisieiev
2022-02-11 11:18       ` Bertrand Marquis
2022-02-11 11:55         ` Oleksii Moisieiev
2022-02-11 23:35           ` Stefano Stabellini
2022-02-12 12:43         ` Julien Grall
2022-02-14 11:13           ` Oleksii Moisieiev
2022-02-14 11:27             ` Bertrand Marquis
2022-02-14 11:51               ` Oleksii Moisieiev
2022-02-14 22:05                 ` Stefano Stabellini
2022-02-16 17:41                   ` Oleksii Moisieiev
2022-02-08 18:00 ` [RFC v2 6/8] tools/arm: Introduce force_assign_without_iommu option to xl.cfg Oleksii Moisieiev
2022-02-17 14:52   ` Anthony PERARD
2022-02-18  8:19     ` Oleksii Moisieiev
2022-02-17 15:20   ` Julien Grall [this message]
2022-02-18  9:16     ` Oleksii Moisieiev
2022-02-18 10:17       ` Julien Grall
2022-02-21 18:39         ` Oleksii Moisieiev
2022-06-03 13:43   ` Jan Beulich
2022-02-08 18:00 ` [RFC v2 7/8] tools/arm: add "arm_sci" " Oleksii Moisieiev
2022-02-08 18:00 ` [RFC v2 8/8] xen/arm: add SCI mediator support for DomUs Oleksii Moisieiev

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=ab6d8d13-30cf-d322-668e-f3f5aaa56824@xen.org \
    --to=julien@xen.org \
    --cc=Oleksii_Moisieiev@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=paul@xen.org \
    --cc=rosbrookn@ainfosec.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.