xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Shannon Zhao <zhaoshenglong@huawei.com>
Cc: sstabellini@kernel.org, Keir Fraser <keir@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	peter.huangpeng@huawei.com, xen-devel@lists.xen.org,
	julien.grall@arm.com, stefano.stabellini@citrix.com,
	shannon.zhao@linaro.org, Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v8 20/21] xen/arm: Add a hypercall for device mmio mapping
Date: Wed, 30 Mar 2016 12:11:12 -0400	[thread overview]
Message-ID: <20160330161112.GC8720@char.us.oracle.com> (raw)
In-Reply-To: <1459332494-18964-21-git-send-email-zhaoshenglong@huawei.com>

On Wed, Mar 30, 2016 at 06:08:13PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> It needs to map platform or amba device mmio to Dom0 on ARM. But when
> booting with ACPI, it can't get the mmio region in Xen due to lack of
> AML interpreter to parse DSDT table. Therefore, let Dom0 call a
> hypercall to map mmio region when it adds the devices.
> 
> Here we add a new map space like the XEN_DOMCTL_memory_mapping to map
> mmio region for Dom0. Also add a helper to combine the
> xsm_add_to_physmap and XENMAPSPACE_dev_mmio space check together.
> 
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> v8: add a helper to combine xsm_add_to_physmap and XENMAPSPACE_dev_mmio
> space check together

I was by accident reviewing the earlier ersion. So let me give comments
here as well.
.. snipp.
> +int map_dev_mmio_region(struct domain *d,
> +                        unsigned long start_gfn,
> +                        unsigned long nr,
> +                        unsigned long mfn)
> +{
> +    int res;
> +
> +    if ( !(nr && iomem_access_permitted(d, start_gfn, start_gfn + nr - 1)) )
> +        return 0;
> +
> +    res = map_mmio_regions(d, start_gfn, nr, mfn);
> +    if ( res < 0 )
> +    {
> +        printk(XENLOG_ERR "Unable to map [%#lx - %#lx] in Dom%d\n",

Should this be printk ratelimited?
> +               start_gfn, start_gfn + nr - 1, d->domain_id);
> +        return res;
> +    }
> +
> +    return 0;
> +}
> +
>  int guest_physmap_add_entry(struct domain *d,
>                              unsigned long gpfn,
>                              unsigned long mfn,
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index c7fca96..644f81a 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -834,6 +834,19 @@ static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
>  }
>  #endif
>  
> +static long xatp_permission_check(struct domain *d, unsigned int space)
> +{
> +    /*
> +     * XENMAPSPACE_dev_mmio mapping is only supported for hardware Domain

s/Domain/domain/
> +     * to map this kind of space to itself.
> +     */
> +    if ( (space == XENMAPSPACE_dev_mmio) &&
> +         (!is_hardware_domain(current->domain) || (d != current->domain)) )
> +        return -EACCES;

Why not -EPERM?

> +
> +    return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
> +}
> +
>  long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>      struct domain *d;
> @@ -980,7 +993,7 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          if ( d == NULL )
>              return -ESRCH;
>  
> -        rc = xsm_add_to_physmap(XSM_TARGET, current->domain, d);
> +        rc = xatp_permission_check(d, xatp.space);

Ah, which nicely takes care of rcu_unlock_domain.
>          if ( rc )
>          {
>              rcu_unlock_domain(d);
> @@ -1024,7 +1037,7 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          if ( d == NULL )
>              return -ESRCH;
>  
> -        rc = xsm_add_to_physmap(XSM_TARGET, current->domain, d);
> +        rc = xatp_permission_check(d, xatpb.space);
>          if ( rc )
>          {
>              rcu_unlock_domain(d);
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index 55626b4..d240d1e 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -154,6 +154,11 @@ int unmap_regions_rw_cache(struct domain *d,
>                             unsigned long nr_mfns,
>                             unsigned long mfn);
>  
> +int map_dev_mmio_region(struct domain *d,
> +                        unsigned long start_gfn,
> +                        unsigned long nr,
> +                        unsigned long mfn);
> +
>  int guest_physmap_add_entry(struct domain *d,
>                              unsigned long gfn,
>                              unsigned long mfn,
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index f69e92f..fe52ee1 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -220,6 +220,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
>  #define XENMAPSPACE_gmfn_range   3 /* GMFN range, XENMEM_add_to_physmap only. */
>  #define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
>                                      * XENMEM_add_to_physmap_batch only. */
> +#define XENMAPSPACE_dev_mmio     5 /* device mmio region */

s/device/Device/ And maybe an full stop at the end?

>  /* ` } */
>  
>  /*
> -- 
> 2.0.4
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

  parent reply	other threads:[~2016-03-30 16:11 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-30 10:07 [PATCH v8 00/21] Prepare UEFI and ACPI tables for Dom0 on ARM64 Shannon Zhao
2016-03-30 10:07 ` [PATCH v8 01/21] arm/acpi: Estimate memory required for acpi/efi tables Shannon Zhao
2016-03-30 10:07 ` [PATCH v8 02/21] arm/acpi: Add a helper function to get the acpi table offset Shannon Zhao
2016-03-30 10:07 ` [PATCH v8 03/21] arm/acpi: Prepare FADT table for Dom0 Shannon Zhao
2016-03-30 10:07 ` [PATCH v8 04/21] arm/gic: Add a new callback for creating MADT " Shannon Zhao
2016-03-30 10:07 ` [PATCH v8 05/21] arm/acpi: Prepare " Shannon Zhao
2016-03-30 10:07 ` [PATCH v8 06/21] arm/acpi: Prepare STAO " Shannon Zhao
2016-03-30 10:08 ` [PATCH v8 07/21] arm/acpi: Prepare XSDT " Shannon Zhao
2016-03-30 10:08 ` [PATCH v8 08/21] arm/acpi: Prepare RSDP " Shannon Zhao
2016-03-30 10:08 ` [PATCH v8 09/21] arm/p2m: Add helper functions to map memory regions Shannon Zhao
2016-03-30 10:08 ` [PATCH v8 10/21] arm/acpi: Map all other tables for Dom0 Shannon Zhao
2016-03-30 10:08 ` [PATCH v8 11/21] arm/acpi: Prepare EFI system table " Shannon Zhao
2016-03-30 10:08 ` [PATCH v8 12/21] arm/acpi: Prepare EFI memory descriptor " Shannon Zhao
2016-03-30 10:08 ` [PATCH v8 13/21] arm/acpi: Map the new created EFI and ACPI tables to Dom0 Shannon Zhao
2016-03-30 10:08 ` [PATCH v8 14/21] arm/acpi: Create min DT stub for Dom0 Shannon Zhao
2016-03-30 10:08 ` [PATCH v8 15/21] arm/acpi: Permit access all Xen unused SPIs " Shannon Zhao
2016-03-30 10:08 ` [PATCH v8 16/21] arm/acpi: Configure SPI interrupt type and route to Dom0 dynamically Shannon Zhao
2016-03-30 10:08 ` [PATCH v8 17/21] arm/gic: Add a new callback to deny Dom0 access to GIC regions Shannon Zhao
2016-03-30 10:08 ` [PATCH v8 18/21] arm/acpi: Permit MMIO access of Xen unused devices for Dom0 Shannon Zhao
2016-03-30 10:08 ` [PATCH v8 19/21] xen/acpi: Fix event-channel interrupt when booting with ACPI Shannon Zhao
2016-03-30 10:08 ` [PATCH v8 20/21] xen/arm: Add a hypercall for device mmio mapping Shannon Zhao
2016-03-30 11:33   ` Jan Beulich
2016-03-30 16:11   ` Konrad Rzeszutek Wilk [this message]
2016-03-30 16:47     ` Julien Grall
2016-03-31  8:39       ` Shannon Zhao
2016-03-30 10:08 ` [PATCH v8 21/21] xen/arm64: Add ACPI support Shannon Zhao
2016-03-30 11:58 ` [PATCH v8 00/21] Prepare UEFI and ACPI tables for Dom0 on ARM64 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=20160330161112.GC8720@char.us.oracle.com \
    --to=konrad.wilk@oracle.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien.grall@arm.com \
    --cc=keir@xen.org \
    --cc=peter.huangpeng@huawei.com \
    --cc=shannon.zhao@linaro.org \
    --cc=sstabellini@kernel.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    --cc=zhaoshenglong@huawei.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).