All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Penny Zheng <Penny.Zheng@arm.com>
Cc: nd@arm.com, Penny Zheng <penzhe01@a011292.shanghai.arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 02/13] xen/arm: introduce a special domain DOMID_SHARED
Date: Fri, 18 Mar 2022 09:53:24 +0100	[thread overview]
Message-ID: <eefa9cf2-a04c-ba8d-74cb-0d2aaa35badb@suse.com> (raw)
In-Reply-To: <20220311061123.1883189-3-Penny.Zheng@arm.com>

On 11.03.2022 07:11, Penny Zheng wrote:
> In case to own statically shared pages when owner domain is not
> explicitly defined, this commits propose a special domain DOMID_SHARED,
> and we assign it 0x7FF5, as one of the system domains.
> 
> Statically shared memory reuses the same way of initialization with static
> memory, hence this commits proposes a new Kconfig CONFIG_STATIC_SHM to wrap
> related codes, and this option depends on static memory(CONFIG_STATIC_MEMORY).
> 
> We intends to do shared domain creation after setup_virt_paging so shared
> domain could successfully do p2m initialization.

There's nothing said here, in the earlier patch, or in the cover letter
about the security aspects of this. There is a reason we haven't been
allowing arbitrary, un-supervised sharing of memory between domains. It
wants clarifying why e.g. grants aren't an option to achieve what you
need, and how you mean to establish which domains are / aren't permitted
to access any individual page owned by this domain.

> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -106,6 +106,13 @@ config TEE
>  
>  source "arch/arm/tee/Kconfig"
>  
> +config STATIC_SHM
> +       bool "Statically shared memory on a dom0less system" if UNSUPPORTED
> +       depends on STATIC_MEMORY
> +       default n

Nit: "default n" is redundant and hence would imo better be omitted.

> @@ -712,12 +716,16 @@ int arch_domain_create(struct domain *d,
>      d->arch.directmap = flags & CDF_directmap;
>  
>      /* p2m_init relies on some value initialized by the IOMMU subsystem */
> -    if ( (rc = iommu_domain_init(d, config->iommu_opts)) != 0 )
> +    if ( (rc = iommu_domain_init(d, is_shared_domain(d) ? 0 : config->iommu_opts)) != 0 )

Nit: Overlong line.

> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -855,6 +855,20 @@ static bool __init is_dom0less_mode(void)
>      return ( !dom0found && domUfound );
>  }
>  
> +#ifdef CONFIG_STATIC_SHM
> +static void __init setup_shared_domain(void)
> +{
> +    /*
> +     * Initialise our DOMID_SHARED domain.
> +     * This domain owns statically shared pages when owner domain is not
> +     * explicitly defined.
> +     */
> +    dom_shared = domain_create(DOMID_SHARED, NULL, CDF_directmap);
> +    if ( IS_ERR(dom_shared) )
> +        panic("Failed to create d[SHARED]: %ld\n", PTR_ERR(dom_shared));

I don't think this should be a panic - the system ought to be able to
come up fine, just without actually using this domain. After all this
is an optional feature which may not actually be used.

Also, along the lines of what Stefano has said, this setting up of
the domain would also better live next to where the other special
domains are set up. And even if it was to remain here, ...

> @@ -1022,6 +1036,14 @@ void __init start_xen(unsigned long boot_phys_offset,
>      apply_alternatives_all();
>      enable_errata_workarounds();
>  
> +#ifdef CONFIG_STATIC_SHM
> +    /*
> +     * This needs to be called **after** setup_virt_paging so shared
> +     * domains could successfully do p2m initialization.
> +     */
> +    setup_shared_domain();
> +#endif

... the #ifdef-ary here should be avoided by moving the other
#ifdef inside the function body.

> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -643,11 +643,14 @@ struct domain *domain_create(domid_t domid,
>  
>      rangeset_domain_initialise(d);
>  
> -    /* DOMID_{XEN,IO,etc} (other than IDLE) are sufficiently constructed. */
> -    if ( is_system_domain(d) && !is_idle_domain(d) )
> +    /*
> +     * DOMID_{XEN,IO,etc} (other than IDLE and DOMID_shared) are
> +     * sufficiently constructed.
> +     */
> +    if ( is_system_domain(d) && !is_idle_domain(d) && !is_shared_domain(d) )
>          return d;
>  
> -    if ( !is_idle_domain(d) )
> +    if ( !is_idle_domain(d) && !is_shared_domain(d) )
>      {
>          if ( !is_hardware_domain(d) )
>              d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
> @@ -663,7 +666,7 @@ struct domain *domain_create(domid_t domid,
>          goto fail;
>      init_status |= INIT_arch;
>  
> -    if ( !is_idle_domain(d) )
> +    if ( !is_idle_domain(d) && !is_shared_domain(d) )
>      {
>          watchdog_domain_init(d);
>          init_status |= INIT_watchdog;

All of these extra is_shared_domain() are quite ugly to see added.
First and foremost going this route doesn't scale very well - consider
how the code will look like when two more special domains with special
needs would be added. I think you want to abstract this some by
introducing one (or a small set of) new is_...() or e.g. needs_...()
predicates.

Further (there's no particularly good place to mention this) I'm
afraid I don't view "shared" as a good name: It's not the domain
which is shared, but it's the domain to hold shared memory. For this
my first consideration would be to see whether an existing special
domain can be re-used; after all the set of reserved domain IDs is
a very limited one, and hence each value taken from there should come
with a very good reason. We did such re-use e.g. when introducing
quarantining for PCI devices, by associating them with DOM_IO rather
than inventing a new DOM_QUARANTINE. If there are good reasons
speaking against such re-use, then I'd like to ask to consider e.g.
DOMID_SHM / DOMID_SHMEM plus associated predicate.

> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -2616,6 +2616,11 @@ struct domain *get_pg_owner(domid_t domid)
>  
>      switch ( domid )
>      {
> +#ifdef CONFIG_STATIC_SHM
> +    case DOMID_SHARED:
> +        pg_owner = rcu_lock_domain(dom_shared);
> +        break;
> +#endif

Please can you avoid #ifdef in cases like this one, by instead using

    case DOMID_SHMEM:
        pg_owner = dom_shared ? rcu_lock_domain(dom_shared) : NULL;
        break;

> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -618,6 +618,8 @@ static inline bool is_system_domain(const struct domain *d)
>      return d->domain_id >= DOMID_FIRST_RESERVED;
>  }
>  
> +#define is_shared_domain(d) ((d)->domain_id == DOMID_SHARED)

Would this better evaluate to "false" when !STATIC_SHM, such that
the compiler can eliminate respective conditionals and/or code?

Jan



  parent reply	other threads:[~2022-03-18  8:53 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-11  6:11 [PATCH v1 00/13] Static shared memory on dom0less system Penny Zheng
2022-03-11  6:11 ` [PATCH v1 01/13] xen/arm: introduce static shared memory Penny Zheng
2022-03-18  1:59   ` Stefano Stabellini
2022-03-11  6:11 ` [PATCH v1 02/13] xen/arm: introduce a special domain DOMID_SHARED Penny Zheng
2022-03-18  1:59   ` Stefano Stabellini
2022-03-18  6:43     ` Penny Zheng
2022-03-18 22:02       ` Stefano Stabellini
2022-03-18  8:53   ` Jan Beulich [this message]
2022-03-18 21:50     ` Stefano Stabellini
2022-03-21  8:48       ` Jan Beulich
2022-03-21 20:03         ` Stefano Stabellini
2022-04-09  9:11           ` Julien Grall
2022-04-15  8:08             ` Penny Zheng
2022-04-15 22:18               ` Stefano Stabellini
2022-04-15 23:45                 ` Julien Grall
2022-03-18 22:20     ` Stefano Stabellini
2022-04-15  9:52     ` Penny Zheng
2022-04-15 23:34       ` Julien Grall
2022-04-19  8:10       ` Jan Beulich
2022-03-11  6:11 ` [PATCH v1 03/13] xen/arm: allocate static shared memory to dom_shared Penny Zheng
2022-03-18  1:59   ` Stefano Stabellini
2022-03-18  8:35     ` Penny Zheng
2022-03-18 22:27       ` Stefano Stabellini
2022-03-11  6:11 ` [PATCH v1 04/13] xen/arm: add P2M type parameter in guest_physmap_add_pages Penny Zheng
2022-03-11  6:11 ` [PATCH v1 05/13] xen/arm: introduce get_pages_from_gfn Penny Zheng
2022-03-11  6:11 ` [PATCH v1 06/13] xen/arm: set up shared memory foreign mapping for borrower domain Penny Zheng
2022-03-18  2:00   ` Stefano Stabellini
2022-03-29  3:44     ` Penny Zheng
2022-04-08 22:18       ` Stefano Stabellini
2022-04-08 22:50         ` Julien Grall
2022-04-08 23:18           ` Stefano Stabellini
2022-04-08 22:59   ` Julien Grall
2022-04-09  9:30     ` Julien Grall
2022-04-20  8:53       ` Penny Zheng
2022-04-20  8:51     ` Penny Zheng
2022-03-11  6:11 ` [PATCH v1 07/13] xen/arm: create shared memory nodes in guest device tree Penny Zheng
2022-03-18  2:00   ` Stefano Stabellini
2022-03-11  6:11 ` [PATCH v1 08/13] xen/arm: destroy static shared memory when de-construct domain Penny Zheng
2022-04-09  9:25   ` Julien Grall
2022-04-21  7:00     ` Penny Zheng
2022-03-11  6:11 ` [PATCH v1 09/13] xen/arm: enable statically shared memory on Dom0 Penny Zheng
2022-03-11  6:11 ` [PATCH v1 10/13] xen/arm: allocate static shared memory to a specific owner domain Penny Zheng
2022-03-18  2:00   ` Stefano Stabellini
2022-03-11  6:11 ` [PATCH v1 11/13] xen/arm: store shm-info for deferred foreign memory map Penny Zheng
2022-03-18  2:01   ` Stefano Stabellini
2022-03-29  8:37     ` Penny Zheng
2022-04-08 22:46       ` Stefano Stabellini
2022-04-09  9:14         ` Julien Grall
2022-03-11  6:11 ` [PATCH v1 12/13] xen/arm: defer foreign memory map in shm_init_late Penny Zheng
2022-03-11  6:11 ` [PATCH v1 13/13] xen/arm: unmap foreign memory mapping when destroyed domain is owner domain Penny Zheng
2022-04-09  9:44   ` Julien Grall

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=eefa9cf2-a04c-ba8d-74cb-0d2aaa35badb@suse.com \
    --to=jbeulich@suse.com \
    --cc=Penny.Zheng@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bertrand.marquis@arm.com \
    --cc=george.dunlap@citrix.com \
    --cc=julien@xen.org \
    --cc=nd@arm.com \
    --cc=penzhe01@a011292.shanghai.arm.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.