Re: [PATCH 04/13] xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio

[Ard Biesheuvel]

On 17 November 2015 at 10:57,   wrote:
> From: Shannon Zhao 
>

No empty commit logs please.

> Signed-off-by: Shannon Zhao 
> ---
>  include/xen/interface/memory.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index 2ecfe4f..9aa8988 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -160,6 +160,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
>  #define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
> * XENMEM_add_to_physmap_range only.
> */
> +#define XENMAPSPACE_dev_mmio 5 /* device mmio region */
>
>  /*
>   * Sets the GPFN at which a particular page appears in the specified guest's
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/13] ARM: Xen: Initialize Xen specific UEFI runtime services

[Ard Biesheuvel]

On 17 November 2015 at 10:57,   wrote:
> From: Shannon Zhao 
>
> When running on Xen hypervisor, runtime services are supported through
> hypercall. So call Xen specific function to initialize runtime services.
>
> Signed-off-by: Shannon Zhao 
> ---
>  arch/arm/include/asm/xen/hypercall.h |  1 +
>  arch/arm/xen/enlighten.c |  1 +
>  arch/arm/xen/hypercall.S |  1 +
>  arch/arm64/kernel/efi.c  | 20 ++--
>  arch/arm64/xen/hypercall.S   |  1 +
>  drivers/xen/Kconfig  |  2 +-
>  drivers/xen/efi.c| 22 ++
>  include/xen/xen-ops.h| 10 ++
>  8 files changed, 51 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/include/asm/xen/hypercall.h 
> b/arch/arm/include/asm/xen/hypercall.h
> index 712b50e..0de6074 100644
> --- a/arch/arm/include/asm/xen/hypercall.h
> +++ b/arch/arm/include/asm/xen/hypercall.h
> @@ -50,6 +50,7 @@ int HYPERVISOR_physdev_op(int cmd, void *arg);
>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>  int HYPERVISOR_tmem_op(void *arg);
>  int HYPERVISOR_multicall(struct multicall_entry *calls, uint32_t nr);
> +int HYPERVISOR_dom0_op(void *arg);
>
>  static inline int
>  HYPERVISOR_suspend(unsigned long start_info_mfn)
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 7cb82f7..1373d6d 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -289,3 +289,4 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
>  EXPORT_SYMBOL_GPL(privcmd_call);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> index 10fd99c..16fc153 100644
> --- a/arch/arm/xen/hypercall.S
> +++ b/arch/arm/xen/hypercall.S
> @@ -90,6 +90,7 @@ HYPERCALL2(physdev_op);
>  HYPERCALL3(vcpu_op);
>  HYPERCALL1(tmem_op);
>  HYPERCALL2(multicall);
> +HYPERCALL1(dom0_op);
>
>  ENTRY(privcmd_call)
> stmdb sp!, {r4}
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index 13671a9..ab1c9e9 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -34,6 +34,9 @@
>  #include 
>  #include 
>
> +#include 
> +#include 
> +
>  struct efi_memory_map memmap;
>
>  static u64 efi_system_table;
> @@ -308,13 +311,18 @@ static int __init arm64_enable_runtime_services(void)
> }
> set_bit(EFI_SYSTEM_TABLES, );
>
> -   if (!efi_virtmap_init()) {
> -   pr_err("No UEFI virtual mapping was installed -- runtime 
> services will not be available\n");
> -   return -1;
> -   }
> +   if (!xen_initial_domain()) {
> +   if (!efi_virtmap_init()) {
> +   pr_err("No UEFI virtual mapping was installed -- 
> runtime services will not be available\n");
> +   return -1;
> +   }
>

I'd prefer it if we could separate the code logically, rather than
putting xen_initial_domain() tests in all the code paths.

For instance, we could re-use the EFI_PARAVIRT flag, and set if from
the Xen init code. Then, we could simply test it here, and bail early.
That way, you can have a Xen specific alternative (which does not use
the virtmap etc anyway) in a xen source file.

> -   /* Set up runtime services function pointers */
> -   efi_native_runtime_setup();
> +   /* Set up runtime services function pointers */
> +   efi_native_runtime_setup();
> +   } else {
> +   /* Set up runtime services function pointers for Xen UEFI */
> +   xen_efi_runtime_setup();
> +   }
> set_bit(EFI_RUNTIME_SERVICES, );
>
> efi.runtime_version = efi.systab->hdr.revision;
> diff --git a/arch/arm64/xen/hypercall.S b/arch/arm64/xen/hypercall.S
> index 8bbe940..f6e15aa 100644
> --- a/arch/arm64/xen/hypercall.S
> +++ b/arch/arm64/xen/hypercall.S
> @@ -81,6 +81,7 @@ HYPERCALL2(physdev_op);
>  HYPERCALL3(vcpu_op);
>  HYPERCALL1(tmem_op);
>  HYPERCALL2(multicall);
> +HYPERCALL1(dom0_op);
>
>  ENTRY(privcmd_call)
> mov x16, x0
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 73708ac..59aec8b 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -268,7 +268,7 @@ config XEN_HAVE_PVMMU
>
>  config XEN_EFI
> def_bool y
> -   depends on X86_64 && EFI
> +   depends on ARM64 || X86_64 && EFI
>
>  config XEN_AUTO_XLATE
> def_bool y
> diff --git a/drivers/xen/efi.c b/drivers/xen/efi.c
> index f745db2..5246d89 100644
> --- a/drivers/xen/efi.c
> +++ b/drivers/xen/efi.c
> @@ -33,6 +33,7 @@
>
>  #define INIT_EFI_OP(name) \
> {.cmd = XENPF_efi_runtime_call, \
> +.interface_version = XENPF_INTERFACE_VERSION, \
>  .u.efi_runtime_call.function = XEN_EFI_##name, \
>  .u.efi_runtime_call.misc = 0}
>
> @@ -261,6 

Re: [PATCH 1/3] efi/libstub: move FDT sanity check out of allocation loop

[Ard Biesheuvel]

On 17 November 2015 at 12:47, Mark Rutland  wrote:
> On Wed, Oct 07, 2015 at 09:35:27AM +0100, Ard Biesheuvel wrote:
>> The memory allocation for the updated FDT may execute several times
>> if the allocation turns out to be insufficiently large. There is no
>> need to sanity check the original FDT each time, so take it out of
>> the loop.
>>
>> Signed-off-by: Ard Biesheuvel 
>
> Acked-by: Mark Rutland 
>

Thanks.

In the mean time, I noticed that this could be refactored even
further, since checking the size only makes sense if the FDT was
loaded from a file, and checking the header is redundant if the FDT
was loaded from a config table.

-- 
Ard.


>> ---
>>  drivers/firmware/efi/libstub/fdt.c | 42 
>>  1 file changed, 26 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/firmware/efi/libstub/fdt.c 
>> b/drivers/firmware/efi/libstub/fdt.c
>> index ef5d764e2a27..354172bee81c 100644
>> --- a/drivers/firmware/efi/libstub/fdt.c
>> +++ b/drivers/firmware/efi/libstub/fdt.c
>> @@ -16,6 +16,26 @@
>>
>>  #include "efistub.h"
>>
>> +static efi_status_t sanity_check_fdt(efi_system_table_t *sys_table,
>> +  void *fdt, unsigned long fdt_size)
>> +{
>> + if (fdt_check_header(fdt)) {
>> + pr_efi_err(sys_table, "Device Tree header not valid!\n");
>> + return EFI_LOAD_ERROR;
>> + }
>> +
>> + /*
>> +  * We don't get the size of the FDT if we get if from a
>> +  * configuration table.
>> +  */
>> + if (fdt_size && fdt_totalsize(fdt) > fdt_size) {
>> + pr_efi_err(sys_table, "Truncated device tree! foo!\n");
>> + return EFI_LOAD_ERROR;
>> + }
>> +
>> + return EFI_SUCCESS;
>> +}
>> +
>>  efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
>>   unsigned long orig_fdt_size,
>>   void *fdt, int new_fdt_size, char *cmdline_ptr,
>> @@ -29,22 +49,6 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, 
>> void *orig_fdt,
>>   u32 fdt_val32;
>>   u64 fdt_val64;
>>
>> - /* Do some checks on provided FDT, if it exists*/
>> - if (orig_fdt) {
>> - if (fdt_check_header(orig_fdt)) {
>> - pr_efi_err(sys_table, "Device Tree header not 
>> valid!\n");
>> - return EFI_LOAD_ERROR;
>> - }
>> - /*
>> -  * We don't get the size of the FDT if we get if from a
>> -  * configuration table.
>> -  */
>> - if (orig_fdt_size && fdt_totalsize(orig_fdt) > orig_fdt_size) {
>> - pr_efi_err(sys_table, "Truncated device tree! foo!\n");
>> - return EFI_LOAD_ERROR;
>> - }
>> - }
>> -
>>   if (orig_fdt)
>>   status = fdt_open_into(orig_fdt, fdt, new_fdt_size);
>>   else
>> @@ -213,6 +217,12 @@ efi_status_t 
>> allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
>>   return status;
>>   }
>>
>> + if (fdt_addr) {
>> + status = sanity_check_fdt(sys_table, (void*)fdt_addr, 
>> fdt_size);
>> + if (status != EFI_SUCCESS)
>> + goto fail;
>> + }
>> +
>>   pr_efi(sys_table,
>>  "Exiting boot services and installing virtual address 
>> map...\n");
>>
>> --
>> 1.9.1
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/13] Xen: EFI: Parse DT parameters for Xen specific UEFI

[Ard Biesheuvel]

On 17 November 2015 at 10:57,   wrote:
> From: Shannon Zhao 
>
> Add a new function to parse DT parameters for Xen specific UEFI just
> like the way for normal UEFI. Then it could reuse the existing codes.
>
> Signed-off-by: Shannon Zhao 
> ---
>  drivers/firmware/efi/efi.c | 67 
> ++
>  1 file changed, 62 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index d6144e3..629bd06 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  struct efi __read_mostly efi = {
> .mps= EFI_INVALID_TABLE_ADDR,
> @@ -488,12 +489,60 @@ static __initdata struct {
> UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", 
> desc_ver)
>  };
>
> +static __initdata struct {
> +   const char name[32];
> +   const char propname[32];
> +   int offset;
> +   int size;
> +} xen_dt_params[] = {
> +   UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
> +   UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
> +   UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
> +   UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", desc_size),
> +   UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", desc_ver)
> +};
> +

We discussed (and agreed afair) that dropping the "linux," prefix from
the DT properties was an acceptable change. If we do that, and reuse
the same names in the xen version (i.e., drop the "xen," prefix), we
could make this change a *lot* simpler.

>  struct param_info {
> int verbose;
> int found;
> void *params;
>  };
>
> +static int __init fdt_find_xen_uefi_params(unsigned long node,
> +  const char *uname, int depth,
> +  void *data)
> +{
> +   struct param_info *info = data;
> +   const void *prop;
> +   void *dest;
> +   u64 val;
> +   int i, len;
> +
> +   if (xen_initial_domain() && (depth != 2 || strcmp(uname, "uefi") != 
> 0))
> +   return 0;
> +
> +   for (i = 0; i < ARRAY_SIZE(xen_dt_params); i++) {
> +   prop = of_get_flat_dt_prop(node, xen_dt_params[i].propname,
> +  );
> +   if (!prop)
> +   return 0;
> +   dest = info->params + xen_dt_params[i].offset;
> +   info->found++;
> +
> +   val = of_read_number(prop, len / sizeof(u32));
> +
> +   if (dt_params[i].size == sizeof(u32))
> +   *(u32 *)dest = val;
> +   else
> +   *(u64 *)dest = val;
> +
> +   if (info->verbose)
> +   pr_info("  %s: 0x%0*llx\n", xen_dt_params[i].name,
> +   xen_dt_params[i].size * 2, val);
> +   }
> +
> +   return 1;
> +}
>  static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
>int depth, void *data)
>  {
> @@ -538,12 +587,20 @@ int __init efi_get_fdt_params(struct efi_fdt_params 
> *params, int verbose)
> info.found = 0;
> info.params = params;
>
> -   ret = of_scan_flat_dt(fdt_find_uefi_params, );
> -   if (!info.found)
> +   if (xen_initial_domain())
> +   ret = of_scan_flat_dt(fdt_find_xen_uefi_params, );
> +   else
> +   ret = of_scan_flat_dt(fdt_find_uefi_params, );
> +   if (!info.found) {
> pr_info("UEFI not found.\n");
> -   else if (!ret)
> -   pr_err("Can't find '%s' in device tree!\n",
> -  dt_params[info.found].name);
> +   } else if (!ret) {
> +   if (xen_initial_domain())
> +   pr_err("Can't find '%s' in device tree!\n",
> +  xen_dt_params[info.found].name);
> +   else
> +   pr_err("Can't find '%s' in device tree!\n",
> +  xen_dt_params[info.found].name);

Wrong array here

> +   }
>
> return ret;
>  }
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/13] Xen: EFI: Parse DT parameters for Xen specific UEFI

[Mark Rutland]

On Tue, Nov 17, 2015 at 12:25:58PM +0100, Ard Biesheuvel wrote:
> On 17 November 2015 at 10:57,   wrote:
> > From: Shannon Zhao 
> >
> > Add a new function to parse DT parameters for Xen specific UEFI just
> > like the way for normal UEFI. Then it could reuse the existing codes.
> >
> > Signed-off-by: Shannon Zhao 
> > ---
> >  drivers/firmware/efi/efi.c | 67 
> > ++
> >  1 file changed, 62 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index d6144e3..629bd06 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -24,6 +24,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  struct efi __read_mostly efi = {
> > .mps= EFI_INVALID_TABLE_ADDR,
> > @@ -488,12 +489,60 @@ static __initdata struct {
> > UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", 
> > desc_ver)
> >  };
> >
> > +static __initdata struct {
> > +   const char name[32];
> > +   const char propname[32];
> > +   int offset;
> > +   int size;
> > +} xen_dt_params[] = {
> > +   UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
> > +   UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
> > +   UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
> > +   UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", 
> > desc_size),
> > +   UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", 
> > desc_ver)
> > +};
> > +
> 
> We discussed (and agreed afair) that dropping the "linux," prefix from
> the DT properties was an acceptable change. If we do that, and reuse
> the same names in the xen version (i.e., drop the "xen," prefix), we
> could make this change a *lot* simpler.

Regardless of if we drop the "linux," prefix from the existing strings,
I think we need the "xen," prefix here.

The xen EFI interface comes with additional caveats, and we need to
treat it separately.

Unless you're suggesting that /hypervisor/uefi-* is handled differently
to /chosen/uefi-*?

I think I'd still prefer the "xen," prefix regardless.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/13] ARM: Xen: Initialize Xen specific UEFI runtime services

[Shannon Zhao]

On 2015/11/17 19:28, Ard Biesheuvel wrote:
>> @@ -308,13 +311,18 @@ static int __init arm64_enable_runtime_services(void)
>> > }
>> > set_bit(EFI_SYSTEM_TABLES, );
>> >
>> > -   if (!efi_virtmap_init()) {
>> > -   pr_err("No UEFI virtual mapping was installed -- runtime 
>> > services will not be available\n");
>> > -   return -1;
>> > -   }
>> > +   if (!xen_initial_domain()) {
>> > +   if (!efi_virtmap_init()) {
>> > +   pr_err("No UEFI virtual mapping was installed -- 
>> > runtime services will not be available\n");
>> > +   return -1;
>> > +   }
>> >
> I'd prefer it if we could separate the code logically, rather than
> putting xen_initial_domain() tests in all the code paths.
> 
> For instance, we could re-use the EFI_PARAVIRT flag, and set if from
> the Xen init code. Then, we could simply test it here, and bail early.
> That way, you can have a Xen specific alternative (which does not use
> the virtmap etc anyway) in a xen source file.
> 
Ok, will do. Thanks.

-- 
Shannon

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Xen-devel] [PATCH 02/13] xen/grant-table: Move xlated_setup_gnttab_pages to common place

[David Vrabel]

On 17/11/15 09:57, shannon.z...@linaro.org wrote:
> From: Shannon Zhao 
> 
> Move xlated_setup_gnttab_pages to common place, so it can be reused by
> ARM to setup grant table when booting with ACPI.
[...]
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -664,6 +664,55 @@ int gnttab_setup_auto_xlat_frames(phys_addr_t addr)
>  }
>  EXPORT_SYMBOL_GPL(gnttab_setup_auto_xlat_frames);
>  
> +int __init xlated_setup_gnttab_pages(void)
> +{
> + struct page **pages;
> + xen_pfn_t *pfns;
> + void *vaddr;
> + int rc;
> + unsigned int i;
> + unsigned long nr_grant_frames = gnttab_max_grant_frames();
> +
> + BUG_ON(nr_grant_frames == 0);
> + pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
> + if (!pages)
> + return -ENOMEM;
> +
> + pfns = kcalloc(nr_grant_frames, sizeof(pfns[0]), GFP_KERNEL);
> + if (!pfns) {
> + kfree(pages);
> + return -ENOMEM;
> + }
> + rc = alloc_xenballooned_pages(nr_grant_frames, pages, 0 /* lowmem */);
> + if (rc) {
> + pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
> + nr_grant_frames, rc);
> + kfree(pages);
> + kfree(pfns);
> + return rc;
> + }
> + for (i = 0; i < nr_grant_frames; i++)
> + pfns[i] = page_to_pfn(pages[i]);
> +
> + vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
> + if (!vaddr) {
> + pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
> + nr_grant_frames, rc);
> + free_xenballooned_pages(nr_grant_frames, pages);
> + kfree(pages);
> + kfree(pfns);
> + return -ENOMEM;
> + }
> + kfree(pages);

Can you move most of this function into drivers/xen/xlate_mmu.c in a
function like:

/**
 * xen_xlate_map_ballooned_pages - map a new set of ballooned pages
 * count: number of GFNs.
 * pages: returns the array of (now) ballooned pages.
 * gfns: returns the array of corresponding GFNs.
 * virt: returns the virtual address of the mapped region.
 *
 * This allocate a set of ballooned pages and maps them into the
 * kernel's address space.
 */
void *xen_xlate_map_ballooned_pages(
unsigned int count,
struct page **pages,
xen_pfn_t **gfns);

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Xen-devel] [PATCH 05/13] Xen: ARM: Add support for mapping platform device mmio

[David Vrabel]

On 17/11/15 09:57, shannon.z...@linaro.org wrote:
> From: Shannon Zhao 
> 
> Add a bus_notifier for platform bus device in order to map the device
> mmio regions when DOM0 booting with ACPI.
[...]
> --- /dev/null
> +++ b/drivers/xen/platform.c
> @@ -0,0 +1,104 @@
> +/*
> + * Copyright (c) 2015, Linaro Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program; if not, write to the Free Software Foundation, Inc., 59 
> Temple
> + * Place - Suite 330, Boston, MA 02111-1307 USA.

"You should have received a copy of the GNU General Public License
along with this program.  If not, see ."

> + *
> + * Author: Shannon Zhao 

Omit this since it just becomes stale and git will know the correct
authorship.

> +static int xen_platform_notifier(struct notifier_block *nb,
> +  unsigned long action, void *data)
> +{
> + struct platform_device *pdev = to_platform_device(data);
> + int r = 0;
> +
> + if (!acpi_disabled && (action == BUS_NOTIFY_ADD_DEVICE))
> + r = xen_map_platform_device_mmio(pdev);

Why even register the notifier if acpi_disabled?

> +
> + if (r)
> + {
> + dev_err(>dev, "Failed to add_to_physmap device (%s) 
> mmio!\n",
> + pdev->name);
> + return NOTIFY_OK;

Return NOTIFY_BAD here?  The device will be unusable.

> + }
> +
> + return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block platform_device_nb = {
> + .notifier_call = xen_platform_notifier,
> +};
> +
> +static int __init register_xen_platform_notifier(void)
> +{
> + if (!xen_initial_domain())
> + return 0;
> +
> + return bus_register_notifier(_bus_type, _device_nb);

Why only platform busses?  What about PCI devices?  Where will they get
added to dom0's physmap?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Xen-devel] [PATCH 06/13] Xen: ARM: Add support for mapping amba device mmio

[David Vrabel]

On 17/11/15 09:57, shannon.z...@linaro.org wrote:
> From: Shannon Zhao 
> 
> Add a bus_notifier for AMBA bus device in order to map the device
> mmio regions when DOM0 booting with ACPI.
[...]
> +static int xen_map_amba_device_mmio(struct amba_device *adev)
> +{
> + int rc = 0;
> + struct resource *r = >res;
> +
> + if (resource_type(r) == IORESOURCE_MEM)
> + {

Haven't I seen something like this before...?

This is (almost) identical to the code added for platform devices.  This
needs to be generic.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Xen-devel] [PATCH 07/13] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

[David Vrabel]

On 17/11/15 09:57, shannon.z...@linaro.org wrote:
> From: Shannon Zhao 
> 
> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
> scan this to get the UEFI information.
[...]
> --- a/Documentation/devicetree/bindings/arm/xen.txt
> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> @@ -15,6 +15,24 @@ the following properties:
>  - interrupts: the interrupt used by Xen to inject event notifications.
>A GIC node is also required.
>  
> +To support UEFI on Xen ARM virtual platforms, Xen pupulates the FDT "uefi" 
> node
> +under /hypervisor with following parameters:

It's not really clear why this is under /hypervisor and why xen needs to
define its own nodes.

The handling of the existing linux standard nodes can be made
Xen-specific by the presence of the /hypervisor/compatible == "xen" node
(or similar), right?

> +
> +Name  | Size   | Description
> +
> +xen,uefi-system-table | 64-bit | Physical address of the UEFI System 
> Table.
> +
> +xen,uefi-mmap-start   | 64-bit | Physical address of the UEFI memory map.
> +

I would probably say "Guest physical address..." just to be clear.

> +xen,uefi-mmap-size| 32-bit | Size in bytes of the UEFI memory map
> +  || pointed to in previous entry.
> +
> +xen,uefi-mmap-desc-size   | 32-bit | Size in bytes of each entry in the UEFI
> +  || memory map.
> +
> +xen,uefi-mmap-desc-ver| 32-bit | Version of the mmap descriptor format.
> +

Need a reference to the mmap descriptor format here.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/13] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

[Rob Herring]

On Tue, Nov 17, 2015 at 05:57:05PM +0800, shannon.z...@linaro.org wrote:
> From: Shannon Zhao 
> 
> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
> scan this to get the UEFI information.
> 
> Signed-off-by: Shannon Zhao 
> ---
>  Documentation/devicetree/bindings/arm/xen.txt | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
> b/Documentation/devicetree/bindings/arm/xen.txt
> index 0f7b9c2..c375d67 100644
> --- a/Documentation/devicetree/bindings/arm/xen.txt
> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> @@ -15,6 +15,24 @@ the following properties:
>  - interrupts: the interrupt used by Xen to inject event notifications.
>A GIC node is also required.
>  
> +To support UEFI on Xen ARM virtual platforms, Xen pupulates the FDT "uefi" 
> node
> +under /hypervisor with following parameters:
> +
> +
> +Name  | Size   | Description
> +
> +xen,uefi-system-table | 64-bit | Physical address of the UEFI System 
> Table.
> +
> +xen,uefi-mmap-start   | 64-bit | Physical address of the UEFI memory map.
> +
> +xen,uefi-mmap-size| 32-bit | Size in bytes of the UEFI memory map
> +  || pointed to in previous entry.
> +
> +xen,uefi-mmap-desc-size   | 32-bit | Size in bytes of each entry in the UEFI
> +  || memory map.
> +
> +xen,uefi-mmap-desc-ver| 32-bit | Version of the mmap descriptor format.
> +

Why aren't you using what is already populated by UEFI as defined in 
Documentation/arm/uefi.txt? Seems to be about the same thing.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] Remove EFI memmap quirk for UV

[Alex Thorlton]

On Tue, Nov 17, 2015 at 08:32:59PM +0100, Borislav Petkov wrote:
> On Mon, Nov 16, 2015 at 11:59:40AM -0600, Alex Thorlton wrote:
> > Commit a5d90c923bcf ("x86/efi: Quirk out SGI UV") added a quirk to
> > efi_apply_memmap_quirks to force SGI UV systems to fall back to the old
> > EFI memmap mechanism.  We have a BIOS fix for this issue now, so we no
> > longer need this quirk in the kernel.
> 
> So does that mean that all UV systems out there will get the BIOS update
> or at least will have a BIOS update available so that we won't need the
> quirk at all?

Essentially, yes.  The BIOS fix isn't available on UV1, but that's older
hardware at this point, and the distro kernels that run on it will
still have the quirk.  This change is mainly so that we can get the
un-quirked code pulled in for the next major distro release.

We won't be checking this down into the stable branches.  Mainly just
planning ahead here for future UV and distro releases.

- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Xen-devel] [PATCH 05/13] Xen: ARM: Add support for mapping platform device mmio

[Shannon Zhao]

On 2015/11/17 22:38, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 17, 2015 at 05:57:03PM +0800, shannon.z...@linaro.org wrote:
>> From: Shannon Zhao 
>>
>> Add a bus_notifier for platform bus device in order to map the device
>> mmio regions when DOM0 booting with ACPI.
>>
>> Signed-off-by: Shannon Zhao 
>> ---
>>  drivers/xen/Makefile   |   1 +
>>  drivers/xen/platform.c | 104 
>> +
>>  2 files changed, 105 insertions(+)
>>  create mode 100644 drivers/xen/platform.c
>>
>> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
>> index e293bc5..2f867e7 100644
>> --- a/drivers/xen/Makefile
>> +++ b/drivers/xen/Makefile
>> @@ -11,6 +11,7 @@ CFLAGS_features.o  := $(nostackp)
>>  
>>  CFLAGS_efi.o+= -fshort-wchar
>>  
>> +dom0-$(CONFIG_ARM64) += platform.o
>>  dom0-$(CONFIG_PCI) += pci.o
>>  dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
>>  dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
>> diff --git a/drivers/xen/platform.c b/drivers/xen/platform.c
>> new file mode 100644
>> index 000..0f95e7f
>> --- /dev/null
>> +++ b/drivers/xen/platform.c
>> @@ -0,0 +1,104 @@
>> +/*
>> + * Copyright (c) 2015, Linaro Limited.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along 
>> with
>> + * this program; if not, write to the Free Software Foundation, Inc., 59 
>> Temple
>> + * Place - Suite 330, Boston, MA 02111-1307 USA.
>> + *
>> + * Author: Shannon Zhao 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static int xen_map_platform_device_mmio(struct platform_device *pdev)
>> +{
>> +int i, rc = 0;
> 
> unsigned int i;
>> +
>> +for (i = 0; i < pdev->num_resources; i++)
>> +{
>> +struct resource *r = >resource[i];
>> +
>> +if (resource_type(r) == IORESOURCE_MEM)
> 
> Make this:
> 
>   if (resource_type(r) != IORESOURCE_MEM)
>   continue;
> 
>> +{
> 
> And then you don't have to move all of this code to the right.
> 
>> +int j;
> unsigned int
>> +int nr = DIV_ROUND_UP(resource_size(r), PAGE_SIZE);
> 
> unsigned int
>> +xen_pfn_t *gpfns = kmalloc(sizeof(xen_pfn_t) * nr,
>> +   GFP_KERNEL);
>> +xen_ulong_t *idxs = kmalloc(sizeof(xen_ulong_t) * nr,
>> +GFP_KERNEL);
>> +int *errs = kmalloc(sizeof(int) * nr, GFP_KERNEL);
> 
> You can use kzalloc.
>> +struct xen_add_to_physmap_range xatp;
> 
> This declaration of variables and then setting does not look like that
> pretty to my mind. (And it is a headache to debug if for example 'nr' ends up
> being zero for example). Or worst -1U since you had it as 'int'.
> 
Yes, a little. Maybe I can add a check for nr. Would that be fine?

Thanks,
-- 
Shannon

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Xen-devel] [PATCH 06/13] Xen: ARM: Add support for mapping amba device mmio

[Shannon Zhao]

On 2015/11/17 22:40, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 17, 2015 at 05:57:04PM +0800, shannon.z...@linaro.org wrote:
>> From: Shannon Zhao 
>>
>> Add a bus_notifier for AMBA bus device in order to map the device
>> mmio regions when DOM0 booting with ACPI.
>>
>> Signed-off-by: Shannon Zhao 
>> ---
>>  drivers/xen/Makefile |  1 +
>>  drivers/xen/amba.c   | 99 
>> 
>>  2 files changed, 100 insertions(+)
>>  create mode 100644 drivers/xen/amba.c
>>
>> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
>> index 2f867e7..139bd0b 100644
>> --- a/drivers/xen/Makefile
>> +++ b/drivers/xen/Makefile
>> @@ -12,6 +12,7 @@ CFLAGS_features.o  := $(nostackp)
>>  CFLAGS_efi.o+= -fshort-wchar
>>  
>>  dom0-$(CONFIG_ARM64) += platform.o
>> +dom0-$(CONFIG_ARM_AMBA) += amba.o
>>  dom0-$(CONFIG_PCI) += pci.o
>>  dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
>>  dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
>> diff --git a/drivers/xen/amba.c b/drivers/xen/amba.c
>> new file mode 100644
>> index 000..e491c8e
>> --- /dev/null
>> +++ b/drivers/xen/amba.c
>> @@ -0,0 +1,99 @@
>> +/*
>> + * Copyright (c) 2015, Linaro Limited.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along 
>> with
>> + * this program; if not, write to the Free Software Foundation, Inc., 59 
>> Temple
>> + * Place - Suite 330, Boston, MA 02111-1307 USA.
>> + *
>> + * Author: Shannon Zhao 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static int xen_map_amba_device_mmio(struct amba_device *adev)
>> +{
>> +int rc = 0;
>> +struct resource *r = >res;
>> +
>> +if (resource_type(r) == IORESOURCE_MEM)
> 
> This is like the 'xen_map_platform_device_mmio' code. Why don't you call
> that? Or at least make the 'xen_map_platform_device_mmio' internal parts be
> visible to both of these functions.
> 
Ok, will do.

>> +{
>> +int j;
>> +int nr = DIV_ROUND_UP(resource_size(r), PAGE_SIZE);
>> +xen_pfn_t *gpfns = kmalloc(sizeof(xen_pfn_t) * nr, GFP_KERNEL);
>> +xen_ulong_t *idxs = kmalloc(sizeof(xen_ulong_t) * nr,
>> +GFP_KERNEL);
>> +int *errs = kmalloc(sizeof(int) * nr, GFP_KERNEL);
>> +struct xen_add_to_physmap_range xatp;
>> +
>> +for (j = 0; j < nr; j++) {
>> +gpfns[j] = (r->start >> PAGE_SHIFT) + j;
>> +idxs[j] = (r->start >> PAGE_SHIFT) + j;
>> +errs[j] = 0;
>> +}
>> +
>> +xatp.domid = DOMID_SELF;
>> +xatp.size = nr;
>> +xatp.space = XENMAPSPACE_dev_mmio;
>> +
>> +set_xen_guest_handle(xatp.gpfns, gpfns);
>> +set_xen_guest_handle(xatp.idxs, idxs);
>> +set_xen_guest_handle(xatp.errs, errs);
>> +
>> +rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, );
>> +
>> +kfree(gpfns);
>> +kfree(idxs);
>> +kfree(errs);
>> +if (rc != 0)
>> +return rc;
>> +}
>> +
>> +return rc;
>> +}
>> +
>> +static int xen_amba_notifier(struct notifier_block *nb,
>> + unsigned long action, void *data)
>> +{
>> +struct amba_device *adev = to_amba_device(data);
>> +int r = 0;
>> +
>> +if (!acpi_disabled && (action == BUS_NOTIFY_ADD_DEVICE))
>> +r = xen_map_amba_device_mmio(adev);
>> +
> 
> What about the removal of a bus device? No need to handle that?
> 
I have thought about removal before. I think there is little(or no)
chance for AMBA and platform bus devices to be removed. It's not like
the PCI devices which will be hot-unplug.
Maybe I'm not right. If so, it's fine to add a case to handle the removal.

Thanks,
-- 
Shannon

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Xen-devel] [PATCH 02/13] xen/grant-table: Move xlated_setup_gnttab_pages to common place

[Shannon Zhao]

On 2015/11/18 0:02, David Vrabel wrote:
> On 17/11/15 09:57, shannon.z...@linaro.org wrote:
>> From: Shannon Zhao 
>>
>> Move xlated_setup_gnttab_pages to common place, so it can be reused by
>> ARM to setup grant table when booting with ACPI.
> [...]
>> --- a/drivers/xen/grant-table.c
>> +++ b/drivers/xen/grant-table.c
>> @@ -664,6 +664,55 @@ int gnttab_setup_auto_xlat_frames(phys_addr_t addr)
>>  }
>>  EXPORT_SYMBOL_GPL(gnttab_setup_auto_xlat_frames);
>>  
>> +int __init xlated_setup_gnttab_pages(void)
>> +{
>> +struct page **pages;
>> +xen_pfn_t *pfns;
>> +void *vaddr;
>> +int rc;
>> +unsigned int i;
>> +unsigned long nr_grant_frames = gnttab_max_grant_frames();
>> +
>> +BUG_ON(nr_grant_frames == 0);
>> +pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
>> +if (!pages)
>> +return -ENOMEM;
>> +
>> +pfns = kcalloc(nr_grant_frames, sizeof(pfns[0]), GFP_KERNEL);
>> +if (!pfns) {
>> +kfree(pages);
>> +return -ENOMEM;
>> +}
>> +rc = alloc_xenballooned_pages(nr_grant_frames, pages, 0 /* lowmem */);
>> +if (rc) {
>> +pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
>> +nr_grant_frames, rc);
>> +kfree(pages);
>> +kfree(pfns);
>> +return rc;
>> +}
>> +for (i = 0; i < nr_grant_frames; i++)
>> +pfns[i] = page_to_pfn(pages[i]);
>> +
>> +vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
>> +if (!vaddr) {
>> +pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
>> +nr_grant_frames, rc);
>> +free_xenballooned_pages(nr_grant_frames, pages);
>> +kfree(pages);
>> +kfree(pfns);
>> +return -ENOMEM;
>> +}
>> +kfree(pages);
> 
> Can you move most of this function into drivers/xen/xlate_mmu.c in a
> function like:
> 
> /**
>  * xen_xlate_map_ballooned_pages - map a new set of ballooned pages
>  * count: number of GFNs.
>  * pages: returns the array of (now) ballooned pages.
>  * gfns: returns the array of corresponding GFNs.
>  * virt: returns the virtual address of the mapped region.
>  *
>  * This allocate a set of ballooned pages and maps them into the
>  * kernel's address space.
>  */
> void *xen_xlate_map_ballooned_pages(
> unsigned int count,
> struct page **pages,
> xen_pfn_t **gfns);
> 
Sure, but the parameter "pages" is not necessary I think, since the
pages has been freed in the function and it doesn't need in
xen_auto_xlat_grant_frames either. Right?

Thanks,
-- 
Shannon

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/5] x86/mm/pageattr: Ensure cpa->pfn only contains page frame numbers

[Thomas Gleixner]

On Mon, 16 Nov 2015, Thomas Gleixner wrote:
> On Mon, 16 Nov 2015, Borislav Petkov wrote:
> > On Mon, Nov 16, 2015 at 09:19:01PM +0100, Thomas Gleixner wrote:
> > > On Sat, 14 Nov 2015, Matt Fleming wrote:
> > > > The x86 pageattr code is confused about the data that is stored
> > > > cpa->pfn, sometimes it's treated as a page frame number, sometimes
> > > > it's treated as an unshifted physical address, and in one place it's
> > > > treated as a pte.
> > > 
> > > Yuck.
> > 
> > This paragraph should read like this instead:
> > 
> > "Boris used cpa->pfn as a scratch variable to contain the physical
> > address. He realizes now that he should've added a separate
> > cpa_data.phys_addr then, instead of confusing everybody."
> > 
> > > > The result of this is that the mapping functions do not map the
> > > > intended physical address.
> > > > 
> > > > This isn't a problem in practice because most of the addresses we're
> > > > mapping in the EFI code paths are already mapped in 'trampoline_pgd'
> > > > and so the pageattr mappings functions don't actually do anything in
> > > > this case. But when we move to using a separate page table for the EFI
> > > > runtime this will be an issue.
> > > 
> > > Are you sure that this does not affect existing kernel versions?
> > 
> > Shouldn't because with this new patchset we're copying all the PGDs from
> > the kernel page table before doing an EFI call, see
> > efi_sync_low_kernel_mappings() in patch 5.
> > 
> > > > while (num_pages-- && start < end) {
> > > > -
> > > > -   /* deal with the NX bit */
> > > > -   if (!(pgprot_val(pgprot) & _PAGE_NX))
> > > > -   cpa->pfn &= ~_PAGE_NX;
> > > 
> > > That should be a seperate patch because this is just bogus code and
> > > has nothing to do with the pfn confusion.
> > 
> > Why bogus?
> 
> Even with cpa->pfn used as an address it cannot ever be set as the
> address is page aligned 

Gah. Misread it. _PAGE_NX is bit 63 and it can be set when cpa->pfn is
abused as an address. So yes, it should go away with that patch.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 04/12] arm64/efi: split off EFI init and runtime code for reuse by 32-bit ARM

[Ard Biesheuvel]

On 16 November 2015 at 19:48, Russell King - ARM Linux
 wrote:
> On Mon, Nov 16, 2015 at 07:32:29PM +0100, Ard Biesheuvel wrote:
>> +/*
>> + * Enable the UEFI Runtime Services if all prerequisites are in place, i.e.,
>> + * non-early mapping of the UEFI system table and virtual mappings for all
>> + * EFI_MEMORY_RUNTIME regions.
>> + */
>> +static int __init arm64_enable_runtime_services(void)
>> +{
>> + u64 mapsize;
>> +
>> + if (!efi_enabled(EFI_BOOT)) {
>> + pr_info("EFI services will not be available.\n");
>> + return -1;
>> + }
>> +
>> + if (efi_runtime_disabled()) {
>> + pr_info("EFI runtime services will be disabled.\n");
>> + return -1;
>> + }
>> +
>> + pr_info("Remapping and enabling EFI services.\n");
>> +
>> + mapsize = memmap.map_end - memmap.map;
>> + memmap.map = (__force void *)ioremap_cache(memmap.phys_map,
>> +mapsize);
>> + if (!memmap.map) {
>> + pr_err("Failed to remap EFI memory map\n");
>> + return -1;
>> + }
>> + memmap.map_end = memmap.map + mapsize;
>> + efi.memmap = 
>> +
>> + efi.systab = (__force void *)ioremap_cache(efi_system_table,
>> +sizeof(efi_system_table_t));
>> + if (!efi.systab) {
>> + pr_err("Failed to remap EFI System Table\n");
>> + return -1;
>> + }
>> + set_bit(EFI_SYSTEM_TABLES, );
>> +
>> + if (!efi_virtmap_init()) {
>> + pr_err("No UEFI virtual mapping was installed -- runtime 
>> services will not be available\n");
>> + return -1;
>> + }
>> +
>> + /* Set up runtime services function pointers */
>> + efi_native_runtime_setup();
>> + set_bit(EFI_RUNTIME_SERVICES, );
>> +
>> + efi.runtime_version = efi.systab->hdr.revision;
>> +
>> + return 0;
>> +}
>> +early_initcall(arm64_enable_runtime_services);
>
> The above ought to be fixed - initcalls return negative errno numbers,
> so returning -1 from them is really not acceptable.  (The original code
> was doing the same - so it should be fixed as a separate patch.)
>

Indeed. I will add a patch to v3 to address this.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/5] x86/mm/pageattr: Ensure cpa->pfn only contains page frame numbers

[Matt Fleming]

On Mon, 16 Nov, at 07:56:17AM, Dave Hansen wrote:
> I'm glad you're looking at this. It obviously needed some love. :)
> 
> On 11/14/2015 02:00 PM, Matt Fleming wrote:
> > +   npages = (_end - _text) >> PAGE_SHIFT;
> > +   text = __pa(_text);
> > +   pfn = text >> PAGE_SHIFT;
> > +
> > +   if (kernel_map_pages_in_pgd(pgd, pfn, text, npages, 0)) {
> > +   pr_err("Failed to map kernel text 1:1\n");
> > +   return 1;
> > +   }
> 
> Are _end and _text guaranteed to be aligned?  If not, I think the
> calculation might be wrong.  Just for fun, imagine that _end=0xfff and
> _text=0x1001.  npages would be 0.
 
Bugger. Good catch, thanks.

> Some other code like set_kernel_text_rw() does alignment on _text.
> 
> One nit is that there's quite a bit going on here, like rearranging the
> phys_stack arithmetic ordering that is far beyond just simplifying the
> paddr vs. pfn issue, but that isn't called out in the changelog at all.
 
Yeah, the phys_stack hunk actually slipped into this patch by
accident. It ensures the stack is mapped into the EFI page tables.
I'll split this out.

> Your fixes all look correct to me, fwiw.

Thanks! If you could respond to the next version with an ACK or
Reviewed-by tag, that'd be great.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/5] x86/mm/pageattr: Ensure cpa->pfn only contains page frame numbers

[Matt Fleming]

On Mon, 16 Nov, at 09:19:01PM, Thomas Gleixner wrote:
> On Sat, 14 Nov 2015, Matt Fleming wrote:
> > The x86 pageattr code is confused about the data that is stored
> > cpa->pfn, sometimes it's treated as a page frame number, sometimes
> > it's treated as an unshifted physical address, and in one place it's
> > treated as a pte.
> 
> Yuck.
>  
> > The result of this is that the mapping functions do not map the
> > intended physical address.
> > 
> > This isn't a problem in practice because most of the addresses we're
> > mapping in the EFI code paths are already mapped in 'trampoline_pgd'
> > and so the pageattr mappings functions don't actually do anything in
> > this case. But when we move to using a separate page table for the EFI
> > runtime this will be an issue.
> 
> Are you sure that this does not affect existing kernel versions?
 
This code only gets called for the EFI code paths (because it's
guarded by the "if (cpa->pgd)" calls).

The code is so wrong that if people were hitting it we would have seen
reports of weird boot and runtime crashes. I'm not aware of any that
could be caused by this, which is why I didn't mark it for stable.

> > while (num_pages-- && start < end) {
> > -
> > -   /* deal with the NX bit */
> > -   if (!(pgprot_val(pgprot) & _PAGE_NX))
> > -   cpa->pfn &= ~_PAGE_NX;
> 
> That should be a seperate patch because this is just bogus code and
> has nothing to do with the pfn confusion.
 
I'm OK either way, but Boris asked me to fold this hunk into this
patch. It was originally a separate patch,

  
https://lkml.kernel.org/r/1447342823-3612-3-git-send-email-m...@codeblueprint.co.uk

> > -
> > -   set_pte(pte, pfn_pte(cpa->pfn >> PAGE_SHIFT, pgprot));
> > +   set_pte(pte, pfn_pte(cpa->pfn, pgprot));
> 
> > diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
> > index a0ac0f9c307f..c8b58ac47b77 100644
> > --- a/arch/x86/platform/efi/efi_64.c
> > +++ b/arch/x86/platform/efi/efi_64.c
> > @@ -143,7 +143,7 @@ void efi_sync_low_kernel_mappings(void)
> >  
> >  int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned 
> > num_pages)
> >  {
> > -   unsigned long text;
> > +   unsigned long pfn, text;
> > struct page *page;
> > unsigned npages;
> > pgd_t *pgd;
> > @@ -160,7 +160,8 @@ int __init efi_setup_page_tables(unsigned long 
> > pa_memmap, unsigned num_pages)
> >  * and ident-map those pages containing the map before calling
> >  * phys_efi_set_virtual_address_map().
> >  */
> > -   if (kernel_map_pages_in_pgd(pgd, pa_memmap, pa_memmap, num_pages, 
> > _PAGE_NX)) {
> > +   pfn = pa_memmap >> PAGE_SHIFT;
> > +   if (kernel_map_pages_in_pgd(pgd, pfn, pa_memmap, num_pages, _PAGE_NX)) {
> > pr_err("Error ident-mapping new memmap (0x%lx)!\n", pa_memmap);
> > return 1;
> > }
> > @@ -176,21 +177,29 @@ int __init efi_setup_page_tables(unsigned long 
> > pa_memmap, unsigned num_pages)
> > if (!IS_ENABLED(CONFIG_EFI_MIXED))
> > return 0;
> >  
> > +   npages = (_end - _text) >> PAGE_SHIFT;
> 
> You really need to PFN_ALIGN _end and _text. Has been wrong in the
> existing code as well.
 
Hmm... very good point.

> > +   text = __pa(_text);
> > +   pfn = text >> PAGE_SHIFT;
> > +
> > +   if (kernel_map_pages_in_pgd(pgd, pfn, text, npages, 0)) {
> > +   pr_err("Failed to map kernel text 1:1\n");
> > +   return 1;
> > +   }
> > +
> > page = alloc_page(GFP_KERNEL|__GFP_DMA32);
> > if (!page)
> > panic("Unable to allocate EFI runtime stack < 4GB\n");
> >  
> > efi_scratch.phys_stack = virt_to_phys(page_address(page));
> > -   efi_scratch.phys_stack += PAGE_SIZE; /* stack grows down */
> > -
> > -   npages = (_end - _text) >> PAGE_SHIFT;
> > -   text = __pa(_text);
> > +   pfn = page_to_pfn(page);
> >  
> > -   if (kernel_map_pages_in_pgd(pgd, text >> PAGE_SHIFT, text, npages, 0)) {
> > -   pr_err("Failed to map kernel text 1:1\n");
> > +   if (kernel_map_pages_in_pgd(pgd, pfn, efi_scratch.phys_stack, 1, 0)) {
> 
> This looks like an unrelated change, hmm?

Dave picked up on this too. Yeah, this hunk should really be part of
PATCH 2 (or a separate patch entirely) because it ensures that the
stack is mapped into the EFI page tables instead of relying on it
being around in 'trampoline_pgd'.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/13] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

[shannon . zhao]

From: Shannon Zhao 

Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
scan this to get the UEFI information.

Signed-off-by: Shannon Zhao 
---
 Documentation/devicetree/bindings/arm/xen.txt | 25 +
 1 file changed, 25 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
b/Documentation/devicetree/bindings/arm/xen.txt
index 0f7b9c2..c375d67 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -15,6 +15,24 @@ the following properties:
 - interrupts: the interrupt used by Xen to inject event notifications.
   A GIC node is also required.
 
+To support UEFI on Xen ARM virtual platforms, Xen pupulates the FDT "uefi" node
+under /hypervisor with following parameters:
+
+
+Name  | Size   | Description
+
+xen,uefi-system-table | 64-bit | Physical address of the UEFI System Table.
+
+xen,uefi-mmap-start   | 64-bit | Physical address of the UEFI memory map.
+
+xen,uefi-mmap-size| 32-bit | Size in bytes of the UEFI memory map
+  || pointed to in previous entry.
+
+xen,uefi-mmap-desc-size   | 32-bit | Size in bytes of each entry in the UEFI
+  || memory map.
+
+xen,uefi-mmap-desc-ver| 32-bit | Version of the mmap descriptor format.
+
 
 Example (assuming #address-cells = <2> and #size-cells = <2>):
 
@@ -22,4 +40,11 @@ hypervisor {
compatible = "xen,xen-4.3", "xen,xen";
reg = <0 0xb000 0 0x2>;
interrupts = <1 15 0xf08>;
+   uefi {
+   xen,uefi-system-table = <0x>;
+   xen,uefi-mmap-start = <0x>;
+   xen,uefi-mmap-size = <0x>;
+   xen,uefi-mmap-desc-size = <0x>;
+   xen,uefi-mmap-desc-ver = <0x>;
+};
 };
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 06/13] Xen: ARM: Add support for mapping amba device mmio

[shannon . zhao]

From: Shannon Zhao 

Add a bus_notifier for AMBA bus device in order to map the device
mmio regions when DOM0 booting with ACPI.

Signed-off-by: Shannon Zhao 
---
 drivers/xen/Makefile |  1 +
 drivers/xen/amba.c   | 99 
 2 files changed, 100 insertions(+)
 create mode 100644 drivers/xen/amba.c

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 2f867e7..139bd0b 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -12,6 +12,7 @@ CFLAGS_features.o := $(nostackp)
 CFLAGS_efi.o   += -fshort-wchar
 
 dom0-$(CONFIG_ARM64) += platform.o
+dom0-$(CONFIG_ARM_AMBA) += amba.o
 dom0-$(CONFIG_PCI) += pci.o
 dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
 dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
diff --git a/drivers/xen/amba.c b/drivers/xen/amba.c
new file mode 100644
index 000..e491c8e
--- /dev/null
+++ b/drivers/xen/amba.c
@@ -0,0 +1,99 @@
+/*
+ * Copyright (c) 2015, Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * Author: Shannon Zhao 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int xen_map_amba_device_mmio(struct amba_device *adev)
+{
+   int rc = 0;
+   struct resource *r = >res;
+
+   if (resource_type(r) == IORESOURCE_MEM)
+   {
+   int j;
+   int nr = DIV_ROUND_UP(resource_size(r), PAGE_SIZE);
+   xen_pfn_t *gpfns = kmalloc(sizeof(xen_pfn_t) * nr, GFP_KERNEL);
+   xen_ulong_t *idxs = kmalloc(sizeof(xen_ulong_t) * nr,
+   GFP_KERNEL);
+   int *errs = kmalloc(sizeof(int) * nr, GFP_KERNEL);
+   struct xen_add_to_physmap_range xatp;
+
+   for (j = 0; j < nr; j++) {
+   gpfns[j] = (r->start >> PAGE_SHIFT) + j;
+   idxs[j] = (r->start >> PAGE_SHIFT) + j;
+   errs[j] = 0;
+   }
+
+   xatp.domid = DOMID_SELF;
+   xatp.size = nr;
+   xatp.space = XENMAPSPACE_dev_mmio;
+
+   set_xen_guest_handle(xatp.gpfns, gpfns);
+   set_xen_guest_handle(xatp.idxs, idxs);
+   set_xen_guest_handle(xatp.errs, errs);
+
+   rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, );
+
+   kfree(gpfns);
+   kfree(idxs);
+   kfree(errs);
+   if (rc != 0)
+   return rc;
+   }
+
+   return rc;
+}
+
+static int xen_amba_notifier(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+   struct amba_device *adev = to_amba_device(data);
+   int r = 0;
+
+   if (!acpi_disabled && (action == BUS_NOTIFY_ADD_DEVICE))
+   r = xen_map_amba_device_mmio(adev);
+
+   if (r)
+   {
+   dev_err(>dev, "Failed to add_to_physmap device (%s) 
mmio!\n",
+   adev->dev.init_name);
+   return NOTIFY_OK;
+   }
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block amba_device_nb = {
+   .notifier_call = xen_amba_notifier,
+};
+
+static int __init register_xen_amba_notifier(void)
+{
+   if (!xen_initial_domain())
+   return 0;
+
+   return bus_register_notifier(_bustype, _device_nb);
+}
+
+arch_initcall(register_xen_amba_notifier);
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 11/13] xen/hvm/params: Add a new dilivery type for event-channel in HVM_PARAM_CALLBACK_IRQ

[shannon . zhao]

From: Shannon Zhao 

Add a new dilivery type:
val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI.
To the flag, bit 0 stands the interrupt mode is edge(1) or level(0) and
bit 1 stands the interrupt polarity is active low(1) or high(0).

Signed-off-by: Shannon Zhao 
---
 include/xen/interface/hvm/params.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/xen/interface/hvm/params.h 
b/include/xen/interface/hvm/params.h
index a6c7991..550688a 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -34,6 +34,11 @@
  *  Domain = val[47:32], Bus  = val[31:16],
  *  DevFn  = val[15: 8], IntX = val[ 1: 0]
  * val[63:56] == 2: val[7:0] is a vector number.
+ * val[63:56] == 3: val[15:8] is flag of event-channel interrupt:
+ *  bit 0: interrupt is edge(1) or level(0) triggered
+ *  bit 1: interrupt is active low(1) or high(0)
+ *  val[7:0] is PPI number used by event-channel.
+ *  This is only used by ARM/ARM64.
  * If val == 0 then CPU0 event-channel notifications are not delivered.
  */
 #define HVM_PARAM_CALLBACK_IRQ 0
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 12/13] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI

[shannon . zhao]

From: Shannon Zhao 

When booting with ACPI, it could get the event-channel irq through
HVM_PARAM_CALLBACK_IRQ.

Signed-off-by: Shannon Zhao 
---
 arch/arm/xen/enlighten.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 1373d6d..b8e9db8 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -190,10 +191,24 @@ static int __init xen_guest_init(void)
if (!xen_domain())
return 0;
 
-   xen_events_irq = irq_of_parse_and_map(xen_node, 0);
-   if (!xen_events_irq) {
-   pr_err("Xen event channel interrupt not found\n");
-   return -ENODEV;
+   if (!acpi_disabled) {
+   struct xen_hvm_param a;
+
+   a.domid = DOMID_SELF;
+   a.index = HVM_PARAM_CALLBACK_IRQ;
+   if (HYPERVISOR_hvm_op(HVMOP_get_param, )) {
+   if ((a.value >> 56) != 3) {
+   pr_err("Can't get Xen event-channel irq\n");
+   return -ENODEV;
+   }
+   }
+   xen_events_irq = a.value & 0xff;
+   } else {
+   xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+   if (!xen_events_irq) {
+   pr_err("Xen event channel interrupt not found\n");
+   return -ENODEV;
+   }
}
 
shared_info_page = (struct shared_info *)get_zeroed_page(GFP_KERNEL);
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 13/13] ARM: XEN: Move xen_early_init() before efi_init()

[shannon . zhao]

From: Shannon Zhao 

Move xen_early_init() before efi_init(), then when calling efi_init()
could initialize Xen specific UEFI.

Check if it runs on Xen hypervisor through the flat dts.

Signed-off-by: Shannon Zhao 
---
 arch/arm/xen/enlighten.c  | 62 ---
 arch/arm64/kernel/setup.c |  2 +-
 2 files changed, 49 insertions(+), 15 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index b8e9db8..d4f884c 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -48,8 +49,6 @@ struct xen_memory_region 
xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 
 static __read_mostly unsigned int xen_events_irq;
 
-static __initdata struct device_node *xen_node;
-
 int xen_remap_domain_gfn_array(struct vm_area_struct *vma,
   unsigned long addr,
   xen_pfn_t *gfn, int nr,
@@ -142,6 +141,34 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
return IRQ_HANDLED;
 }
 
+struct xen_node_info {
+   const char *compat;
+   const char *prefix;
+   const char *version;
+   bool found;
+};
+
+static int __init fdt_find_xen_node(unsigned long node, const char *uname,
+   int depth, void *data)
+{
+   struct xen_node_info *info = data;
+   const void *s = NULL;
+   int len;
+
+   if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+   return 0;
+
+   if (of_flat_dt_is_compatible(node, info->compat))
+   info->found = true;
+
+   s = of_get_flat_dt_prop(node, "compatible", );
+   if (strlen(info->prefix) + 3  < len &&
+!strncmp(info->prefix, s, strlen(info->prefix)))
+info->version = s + strlen(info->prefix);
+
+   return 0;
+}
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
@@ -149,26 +176,25 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
 #define GRANT_TABLE_PHYSADDR 0
 void __init xen_early_init(void)
 {
-   int len;
-   const char *s = NULL;
-   const char *version = NULL;
-   const char *xen_prefix = "xen,xen-";
+   struct xen_node_info info;
+
+   info.compat = "xen,xen";
+   info.prefix = "xen,xen-";
+   info.version = NULL;
+   info.found = false;
 
-   xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
-   if (!xen_node) {
+   of_scan_flat_dt(fdt_find_xen_node, );
+   if (!info.found) {
pr_debug("No Xen support\n");
return;
}
-   s = of_get_property(xen_node, "compatible", );
-   if (strlen(xen_prefix) + 3  < len &&
-   !strncmp(xen_prefix, s, strlen(xen_prefix)))
-   version = s + strlen(xen_prefix);
-   if (version == NULL) {
+
+   if (info.version == NULL) {
pr_debug("Xen version not found\n");
return;
}
 
-   pr_info("Xen %s support found\n", version);
+   pr_info("Xen %s support found\n", info.version);
 
xen_domain_type = XEN_HVM_DOMAIN;
 
@@ -204,6 +230,14 @@ static int __init xen_guest_init(void)
}
xen_events_irq = a.value & 0xff;
} else {
+   struct device_node *xen_node;
+
+   xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
+   if (!xen_node) {
+   pr_debug("No Xen support\n");
+   return -ENODEV;
+   }
+
xen_events_irq = irq_of_parse_and_map(xen_node, 0);
if (!xen_events_irq) {
pr_err("Xen event channel interrupt not found\n");
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 2322479..ee95593 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -428,6 +428,7 @@ void __init setup_arch(char **cmdline_p)
 */
local_async_enable();
 
+   xen_early_init();
efi_init();
arm64_memblock_init();
 
@@ -446,7 +447,6 @@ void __init setup_arch(char **cmdline_p)
} else {
psci_acpi_init();
}
-   xen_early_init();
 
cpu_read_bootcpu_ops();
smp_init_cpus();
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/13] Xen: EFI: Parse DT parameters for Xen specific UEFI

[shannon . zhao]

From: Shannon Zhao 

Add a new function to parse DT parameters for Xen specific UEFI just
like the way for normal UEFI. Then it could reuse the existing codes.

Signed-off-by: Shannon Zhao 
---
 drivers/firmware/efi/efi.c | 67 ++
 1 file changed, 62 insertions(+), 5 deletions(-)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index d6144e3..629bd06 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct efi __read_mostly efi = {
.mps= EFI_INVALID_TABLE_ADDR,
@@ -488,12 +489,60 @@ static __initdata struct {
UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
 };
 
+static __initdata struct {
+   const char name[32];
+   const char propname[32];
+   int offset;
+   int size;
+} xen_dt_params[] = {
+   UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
+   UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
+   UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
+   UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", desc_size),
+   UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", desc_ver)
+};
+
 struct param_info {
int verbose;
int found;
void *params;
 };
 
+static int __init fdt_find_xen_uefi_params(unsigned long node,
+  const char *uname, int depth,
+  void *data)
+{
+   struct param_info *info = data;
+   const void *prop;
+   void *dest;
+   u64 val;
+   int i, len;
+
+   if (xen_initial_domain() && (depth != 2 || strcmp(uname, "uefi") != 0))
+   return 0;
+
+   for (i = 0; i < ARRAY_SIZE(xen_dt_params); i++) {
+   prop = of_get_flat_dt_prop(node, xen_dt_params[i].propname,
+  );
+   if (!prop)
+   return 0;
+   dest = info->params + xen_dt_params[i].offset;
+   info->found++;
+
+   val = of_read_number(prop, len / sizeof(u32));
+
+   if (dt_params[i].size == sizeof(u32))
+   *(u32 *)dest = val;
+   else
+   *(u64 *)dest = val;
+
+   if (info->verbose)
+   pr_info("  %s: 0x%0*llx\n", xen_dt_params[i].name,
+   xen_dt_params[i].size * 2, val);
+   }
+
+   return 1;
+}
 static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
   int depth, void *data)
 {
@@ -538,12 +587,20 @@ int __init efi_get_fdt_params(struct efi_fdt_params 
*params, int verbose)
info.found = 0;
info.params = params;
 
-   ret = of_scan_flat_dt(fdt_find_uefi_params, );
-   if (!info.found)
+   if (xen_initial_domain())
+   ret = of_scan_flat_dt(fdt_find_xen_uefi_params, );
+   else
+   ret = of_scan_flat_dt(fdt_find_uefi_params, );
+   if (!info.found) {
pr_info("UEFI not found.\n");
-   else if (!ret)
-   pr_err("Can't find '%s' in device tree!\n",
-  dt_params[info.found].name);
+   } else if (!ret) {
+   if (xen_initial_domain())
+   pr_err("Can't find '%s' in device tree!\n",
+  xen_dt_params[info.found].name);
+   else
+   pr_err("Can't find '%s' in device tree!\n",
+  xen_dt_params[info.found].name);
+   }
 
return ret;
 }
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/12] arm64/efi: refactor EFI init and runtime code for reuse by 32-bit ARM

[Ard Biesheuvel]

On 16 November 2015 at 19:49, Russell King - ARM Linux
 wrote:
> On Mon, Nov 16, 2015 at 07:32:30PM +0100, Ard Biesheuvel wrote:
>> diff --git a/drivers/firmware/efi/arm-runtime.c 
>> b/drivers/firmware/efi/arm-runtime.c
>> index e62ee5df96ca..ad11ba6964f6 100644
>> --- a/drivers/firmware/efi/arm-runtime.c
>> +++ b/drivers/firmware/efi/arm-runtime.c
>> @@ -23,18 +23,15 @@
>>
>>  #include 
>>  #include 
>> -#include 
>> -#include 
>> +#include 
>
> Shouldn't this be linux/io.h ?
>

Yes. Will change it for v3
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/13] Add ACPI support for Xen Dom0 on ARM64

[shannon . zhao]

From: Shannon Zhao 

This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen
ACPI on ARM64 design document could be found from [1].

This patch set adds a new FDT node "uefi" under /hypervisor to pass UEFI
information. Introduce a bus notifier of AMBA and Platform bus to map
the new added device's MMIO space. Make Xen domain use
xlated_setup_gnttab_pages to setup grant table and a new hypercall to
get event-channel irq.

Regarding the initialization flow of Linux kernel, it needs to move
xen_early_init() before efi_init(). Then xen_early_init() will check
whether it runs on Xen through the /hypervisor node and efi_init() will
call a new function fdt_find_xen_uefi_params(), to parse those
xen,uefi-* parameters just like the existing efi_get_fdt_params().

And in arm64_enable_runtime_services() it will check whether it runs on
Xen and call another new function xen_efi_runtime_setup() to setup
runtime service instead of efi_native_runtime_setup(). The
xen_efi_runtime_setup() will assign the runtime function pointers with
the functions of driver/xen/efi.c.

And since we pass a /hypervisor node and a /chosen node to Dom0, it
needs to check whether the DTS only contains a /hypervisor node and a
/chosen node in acpi_boot_table_init().

Patches are tested on FVP base model. This patch set can be found from
[2] and the corresponding Xen patches can be found from [3].

Thanks,
Shannon

[1] http://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html
[2] http://git.linaro.org/people/shannon.zhao/linux-mainline.git  
ACPI_XEN_ARM_Linux_V1
[3] http://git.linaro.org/people/shannon.zhao/xen.git  ACPI_XEN_ARM_V3

Shannon Zhao (13):
  Xen : Hide UART used by Xen
  xen/grant-table: Move xlated_setup_gnttab_pages to common place
  arm/xen: Use xlated_setup_gnttab_pages to setup grant table
  xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
  Xen: ARM: Add support for mapping platform device mmio
  Xen: ARM: Add support for mapping amba device mmio
  ARM: Xen: Document UEFI support on Xen ARM virtual platforms
  Xen: EFI: Parse DT parameters for Xen specific UEFI
  ARM: Xen: Initialize Xen specific UEFI runtime services
  ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
  xen/hvm/params: Add a new dilivery type for event-channel in
HVM_PARAM_CALLBACK_IRQ
  arm/xen: Get event-channel irq through HVM_PARAM when booting with
ACPI
  ARM: XEN: Move xen_early_init() before efi_init()

 Documentation/devicetree/bindings/arm/xen.txt |  25 +++
 arch/arm/include/asm/xen/hypercall.h  |   1 +
 arch/arm/xen/enlighten.c  |  96 +---
 arch/arm/xen/hypercall.S  |   1 +
 arch/arm64/kernel/acpi.c  |  12 ++-
 arch/arm64/kernel/efi.c   |  20 +++--
 arch/arm64/kernel/setup.c |   2 +-
 arch/arm64/xen/hypercall.S|   1 +
 arch/x86/xen/grant-table.c|  51 -
 drivers/acpi/bus.c|  22 ++
 drivers/firmware/efi/efi.c|  67 +++--
 drivers/xen/Kconfig   |   2 +-
 drivers/xen/Makefile  |   2 +
 drivers/xen/amba.c|  99 
 drivers/xen/efi.c |  22 ++
 drivers/xen/grant-table.c |  49 
 drivers/xen/platform.c| 104 ++
 include/xen/grant_table.h |   1 +
 include/xen/interface/hvm/params.h|   5 ++
 include/xen/interface/memory.h|   1 +
 include/xen/xen-ops.h |  10 +++
 21 files changed, 498 insertions(+), 95 deletions(-)
 create mode 100644 drivers/xen/amba.c
 create mode 100644 drivers/xen/platform.c

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 05/13] Xen: ARM: Add support for mapping platform device mmio

[shannon . zhao]

From: Shannon Zhao 

Add a bus_notifier for platform bus device in order to map the device
mmio regions when DOM0 booting with ACPI.

Signed-off-by: Shannon Zhao 
---
 drivers/xen/Makefile   |   1 +
 drivers/xen/platform.c | 104 +
 2 files changed, 105 insertions(+)
 create mode 100644 drivers/xen/platform.c

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index e293bc5..2f867e7 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -11,6 +11,7 @@ CFLAGS_features.o := $(nostackp)
 
 CFLAGS_efi.o   += -fshort-wchar
 
+dom0-$(CONFIG_ARM64) += platform.o
 dom0-$(CONFIG_PCI) += pci.o
 dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
 dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
diff --git a/drivers/xen/platform.c b/drivers/xen/platform.c
new file mode 100644
index 000..0f95e7f
--- /dev/null
+++ b/drivers/xen/platform.c
@@ -0,0 +1,104 @@
+/*
+ * Copyright (c) 2015, Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * Author: Shannon Zhao 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int xen_map_platform_device_mmio(struct platform_device *pdev)
+{
+   int i, rc = 0;
+
+   for (i = 0; i < pdev->num_resources; i++)
+   {
+   struct resource *r = >resource[i];
+
+   if (resource_type(r) == IORESOURCE_MEM)
+   {
+   int j;
+   int nr = DIV_ROUND_UP(resource_size(r), PAGE_SIZE);
+   xen_pfn_t *gpfns = kmalloc(sizeof(xen_pfn_t) * nr,
+  GFP_KERNEL);
+   xen_ulong_t *idxs = kmalloc(sizeof(xen_ulong_t) * nr,
+   GFP_KERNEL);
+   int *errs = kmalloc(sizeof(int) * nr, GFP_KERNEL);
+   struct xen_add_to_physmap_range xatp;
+
+   for (j = 0; j < nr; j++) {
+   gpfns[j] = (r->start >> PAGE_SHIFT) + j;
+   idxs[j] = (r->start >> PAGE_SHIFT) + j;
+   errs[j] = 0;
+   }
+
+   xatp.domid = DOMID_SELF;
+   xatp.size = nr;
+   xatp.space = XENMAPSPACE_dev_mmio;
+
+   set_xen_guest_handle(xatp.gpfns, gpfns);
+   set_xen_guest_handle(xatp.idxs, idxs);
+   set_xen_guest_handle(xatp.errs, errs);
+
+   rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range,
+ );
+   kfree(gpfns);
+   kfree(idxs);
+   kfree(errs);
+   if (rc != 0)
+   return rc;
+   }
+   }
+
+   return rc;
+}
+
+static int xen_platform_notifier(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+   struct platform_device *pdev = to_platform_device(data);
+   int r = 0;
+
+   if (!acpi_disabled && (action == BUS_NOTIFY_ADD_DEVICE))
+   r = xen_map_platform_device_mmio(pdev);
+
+   if (r)
+   {
+   dev_err(>dev, "Failed to add_to_physmap device (%s) 
mmio!\n",
+   pdev->name);
+   return NOTIFY_OK;
+   }
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block platform_device_nb = {
+   .notifier_call = xen_platform_notifier,
+};
+
+static int __init register_xen_platform_notifier(void)
+{
+   if (!xen_initial_domain())
+   return 0;
+
+   return bus_register_notifier(_bus_type, _device_nb);
+}
+
+arch_initcall(register_xen_platform_notifier);
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/13] Xen : Hide UART used by Xen

[shannon . zhao]

From: Shannon Zhao 

According to the STAO table, hide UART used by Xen from Dom0.

Signed-off-by: Shannon Zhao 
---
 drivers/acpi/bus.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index a212cef..e93806b 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -46,6 +46,7 @@ ACPI_MODULE_NAME("bus");
 struct acpi_device *acpi_root;
 struct proc_dir_entry *acpi_root_dir;
 EXPORT_SYMBOL(acpi_root_dir);
+static u64 uart_addr;
 
 #ifdef CONFIG_X86
 #ifdef CONFIG_ACPI_CUSTOM_DSDT
@@ -93,6 +94,16 @@ acpi_status acpi_bus_get_status_handle(acpi_handle handle,
 {
acpi_status status;
 
+   if (uart_addr) {
+   u64 addr;
+   status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL,
+  );
+   if (ACPI_SUCCESS(status) && (addr == uart_addr)) {
+   *sta = 0;
+   return AE_OK;
+   }
+   }
+
status = acpi_evaluate_integer(handle, "_STA", NULL, sta);
if (ACPI_SUCCESS(status))
return AE_OK;
@@ -1069,6 +1080,7 @@ EXPORT_SYMBOL_GPL(acpi_kobj);
 static int __init acpi_init(void)
 {
int result;
+   struct acpi_table_stao *stao_ptr;
 
if (acpi_disabled) {
printk(KERN_INFO PREFIX "Interpreter disabled.\n");
@@ -1081,6 +1093,16 @@ static int __init acpi_init(void)
acpi_kobj = NULL;
}
 
+   acpi_get_table(ACPI_SIG_STAO, 1,
+  (struct acpi_table_header **)_ptr);
+   if(stao_ptr->ignore_uart)
+   {
+   struct acpi_table_spcr *spcr_ptr;
+   acpi_get_table(ACPI_SIG_SPCR, 1,
+  (struct acpi_table_header **)_ptr);
+   uart_addr = spcr_ptr->serial_port.address;
+   }
+
init_acpi_device_notify();
result = acpi_bus_init();
if (result) {
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/13] xen/grant-table: Move xlated_setup_gnttab_pages to common place

[shannon . zhao]

From: Shannon Zhao 

Move xlated_setup_gnttab_pages to common place, so it can be reused by
ARM to setup grant table when booting with ACPI.

Signed-off-by: Shannon Zhao 
---
 arch/x86/xen/grant-table.c | 51 --
 drivers/xen/grant-table.c  | 49 
 include/xen/grant_table.h  |  1 +
 3 files changed, 50 insertions(+), 51 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index 1580e7a..2a99a9a 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -111,57 +111,6 @@ int arch_gnttab_init(unsigned long nr_shared)
 }
 
 #ifdef CONFIG_XEN_PVH
-#include 
-#include 
-#include 
-static int __init xlated_setup_gnttab_pages(void)
-{
-   struct page **pages;
-   xen_pfn_t *pfns;
-   void *vaddr;
-   int rc;
-   unsigned int i;
-   unsigned long nr_grant_frames = gnttab_max_grant_frames();
-
-   BUG_ON(nr_grant_frames == 0);
-   pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
-   if (!pages)
-   return -ENOMEM;
-
-   pfns = kcalloc(nr_grant_frames, sizeof(pfns[0]), GFP_KERNEL);
-   if (!pfns) {
-   kfree(pages);
-   return -ENOMEM;
-   }
-   rc = alloc_xenballooned_pages(nr_grant_frames, pages, 0 /* lowmem */);
-   if (rc) {
-   pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
-   kfree(pages);
-   kfree(pfns);
-   return rc;
-   }
-   for (i = 0; i < nr_grant_frames; i++)
-   pfns[i] = page_to_pfn(pages[i]);
-
-   vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
-   if (!vaddr) {
-   pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
-   free_xenballooned_pages(nr_grant_frames, pages);
-   kfree(pages);
-   kfree(pfns);
-   return -ENOMEM;
-   }
-   kfree(pages);
-
-   xen_auto_xlat_grant_frames.pfn = pfns;
-   xen_auto_xlat_grant_frames.count = nr_grant_frames;
-   xen_auto_xlat_grant_frames.vaddr = vaddr;
-
-   return 0;
-}
-
 static int __init xen_pvh_gnttab_setup(void)
 {
if (!xen_pvh_domain())
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 62f591f..c084ba6 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -664,6 +664,55 @@ int gnttab_setup_auto_xlat_frames(phys_addr_t addr)
 }
 EXPORT_SYMBOL_GPL(gnttab_setup_auto_xlat_frames);
 
+int __init xlated_setup_gnttab_pages(void)
+{
+   struct page **pages;
+   xen_pfn_t *pfns;
+   void *vaddr;
+   int rc;
+   unsigned int i;
+   unsigned long nr_grant_frames = gnttab_max_grant_frames();
+
+   BUG_ON(nr_grant_frames == 0);
+   pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
+   if (!pages)
+   return -ENOMEM;
+
+   pfns = kcalloc(nr_grant_frames, sizeof(pfns[0]), GFP_KERNEL);
+   if (!pfns) {
+   kfree(pages);
+   return -ENOMEM;
+   }
+   rc = alloc_xenballooned_pages(nr_grant_frames, pages, 0 /* lowmem */);
+   if (rc) {
+   pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
+   nr_grant_frames, rc);
+   kfree(pages);
+   kfree(pfns);
+   return rc;
+   }
+   for (i = 0; i < nr_grant_frames; i++)
+   pfns[i] = page_to_pfn(pages[i]);
+
+   vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
+   if (!vaddr) {
+   pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
+   nr_grant_frames, rc);
+   free_xenballooned_pages(nr_grant_frames, pages);
+   kfree(pages);
+   kfree(pfns);
+   return -ENOMEM;
+   }
+   kfree(pages);
+
+   xen_auto_xlat_grant_frames.pfn = pfns;
+   xen_auto_xlat_grant_frames.count = nr_grant_frames;
+   xen_auto_xlat_grant_frames.vaddr = vaddr;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(xlated_setup_gnttab_pages);
+
 void gnttab_free_auto_xlat_frames(void)
 {
if (!xen_auto_xlat_grant_frames.count)
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 4478f4b..fa31e66 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -177,6 +177,7 @@ struct grant_frames {
 extern struct grant_frames xen_auto_xlat_grant_frames;
 unsigned int gnttab_max_grant_frames(void);
 int gnttab_setup_auto_xlat_frames(phys_addr_t addr);
+int xlated_setup_gnttab_pages(void);
 void gnttab_free_auto_xlat_frames(void);
 
 #define gnttab_map_vaddr(map) ((void *)(map.host_virt_addr))
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to 

[PATCH 03/13] arm/xen: Use xlated_setup_gnttab_pages to setup grant table

[shannon . zhao]

From: Shannon Zhao 

Use xlated_setup_gnttab_pages to setup grant table. Then it doesn't rely
on DT or ACPI to pass the start address and size of grant table.

Signed-off-by: Shannon Zhao 
---
 arch/arm/xen/enlighten.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index eeeab07..7cb82f7 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -186,18 +186,10 @@ static int __init xen_guest_init(void)
 {
struct xen_add_to_physmap xatp;
struct shared_info *shared_info_page = NULL;
-   struct resource res;
-   phys_addr_t grant_frames;
 
if (!xen_domain())
return 0;
 
-   if (of_address_to_resource(xen_node, GRANT_TABLE_PHYSADDR, )) {
-   pr_err("Xen grant table base address not found\n");
-   return -ENODEV;
-   }
-   grant_frames = res.start;
-
xen_events_irq = irq_of_parse_and_map(xen_node, 0);
if (!xen_events_irq) {
pr_err("Xen event channel interrupt not found\n");
@@ -232,7 +224,7 @@ static int __init xen_guest_init(void)
if (xen_vcpu_info == NULL)
return -ENOMEM;
 
-   if (gnttab_setup_auto_xlat_frames(grant_frames)) {
+   if (xlated_setup_gnttab_pages()) {
free_percpu(xen_vcpu_info);
return -ENOMEM;
}
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/12] UEFI boot and runtime services support for 32-bit ARM

[Ard Biesheuvel]

On 16 November 2015 at 20:50, Ryan Harkin  wrote:
> Hi Ard,
>
> On 16 November 2015 at 18:32, Ard Biesheuvel  
> wrote:
>> This series adds support for booting the 32-bit ARM kernel directly from
>> UEFI firmware using a builtin UEFI stub. It mostly reuses refactored arm64
>> code, and the differences (primarily the PE/COFF header and entry point and
>> the efi_create_mapping() implementation) are split out into arm64 and ARM
>> versions.
>>
>> Changes since v1:
>> - The primary difference between this version and the first one is that all
>>   prerequisites have either been merged, dropped for now (early FDT handling)
>>   or folded into this series (MEMBLOCK_NOMAP). IOW, this series can be 
>> applied
>>   on top of v4.4-rc1 directly.
>> - Dropped handling of UEFI permission bits. The reason is that the UEFIv2.5
>>   approach (EFI_PROPERTIES_TABLE) is flawed, and will be replaced by 
>> something
>>   better in the next version of the spec.
>>
>> Patch #1 adds support for the MEMBLOCK_NOMAP attribute to the generic 
>> memblock
>> code. Its purpose is to annotate memory regions as normal memory even if they
>> are removed from the kernel direct mapping.
>>
>> Patch #2 implements MEMBLOCK_NOMAP support for arm64
>>
>> Patch #3 updates the EFI init code to remove UEFI reserved regions and 
>> regions
>> used by runtime services from the kernel direct mapping
>>
>> Patch #4 splits off most of arch/arm64/kernel/efi.c into arch agnostic files
>> arm-init.c and arm-runtime.c under drivers/firmware/efi.
>>
>> Patch #5 refactors the code split off in patch #1 to isolate the arm64 
>> specific
>> pieces, and change a couple of arm64-isms that ARM handles slightly 
>> differently.
>>
>> Patch #6 enables the generic early_ioremap and early_memremap implementations
>> for ARM. It reuses the kmap fixmap region, which is not used that early 
>> anyway.
>>
>> Patch #7 splits off the core functionality of create_mapping() into a new
>> function __create_mapping() that we can reuse for mapping UEFI runtime 
>> regions.
>>
>> Patch #8 factors out the early_alloc() routine so we can invoke 
>> __create_mapping
>> using another (late) allocator.
>>
>> Patch #9 implements create_mapping_late() that uses a late allocator.
>>
>> Patch #10 implements MEMBLOCK_NOMAP support for ARM
>>
>> Patch #11 implements the UEFI support in the kernel proper to probe the UEFI
>> memory map and map the runtime services.
>>
>> Patch #12 ties together all of the above, by implementing the UEFI stub, and
>> introducing the Kconfig symbols that allow all of this to be built.
>>
>> Instructions how to build and run the 32-bit ARM UEFI firmware can be found 
>> here:
>> https://wiki.linaro.org/LEG/UEFIforQEMU
>>
>> Ard Biesheuvel (11):
>>   mm/memblock: add MEMBLOCK_NOMAP attribute to memblock memory table
>>   arm64: only consider memblocks with NOMAP cleared for linear mapping
>>   arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP
>>   arm64/efi: split off EFI init and runtime code for reuse by 32-bit ARM
>>   arm64/efi: refactor EFI init and runtime code for reuse by 32-bit ARM
>>   ARM: add support for generic early_ioremap/early_memremap
>>   ARM: split off core mapping logic from create_mapping
>>   ARM: factor out allocation routine from __create_mapping()
>>   ARM: implement create_mapping_late() for EFI use
>>   ARM: only consider memblocks with NOMAP cleared for linear mapping
>>   ARM: wire up UEFI init and runtime support
>>
>> Roy Franz (1):
>>   ARM: add UEFI stub support
>>
>>  arch/arm/Kconfig  |  20 ++
>>  arch/arm/boot/compressed/Makefile |   4 +-
>>  arch/arm/boot/compressed/efi-header.S | 130 
>>  arch/arm/boot/compressed/head.S   |  54 +++-
>>  arch/arm/boot/compressed/vmlinux.lds.S|   7 +
>>  arch/arm/include/asm/Kbuild   |   1 +
>>  arch/arm/include/asm/efi.h|  90 ++
>>  arch/arm/include/asm/fixmap.h |  29 +-
>>  arch/arm/include/asm/mach/map.h   |   1 +
>>  arch/arm/kernel/Makefile  |   1 +
>>  arch/arm/kernel/efi.c |  38 +++
>>  arch/arm/kernel/setup.c   |  10 +-
>>  arch/arm/mm/init.c|   5 +-
>>  arch/arm/mm/ioremap.c |   9 +
>>  arch/arm/mm/mmu.c | 110 ---
>>  arch/arm64/include/asm/efi.h  |  16 +
>>  arch/arm64/kernel/efi.c   | 331 ++--
>>  arch/arm64/mm/init.c  |   2 +-
>>  arch/arm64/mm/mmu.c   |   2 +
>>  drivers/firmware/efi/Makefile |   4 +
>>  drivers/firmware/efi/arm-init.c   | 197 
>>  drivers/firmware/efi/arm-runtime.c| 134 
>>  drivers/firmware/efi/efi.c|   2 +
>>  drivers/firmware/efi/libstub/Makefile |   9 +
>>  drivers/firmware/efi/libstub/arm-stub.c   |   4 +-
>>  

[PATCH 10/13] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI

[shannon . zhao]

From: Shannon Zhao 

When it's a Xen domain0 booting with ACPI, it will supply a /chosen and
a /hypervisor node in DT. So check if it needs to enable ACPI.

Signed-off-by: Shannon Zhao 
---
 arch/arm64/kernel/acpi.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 19de753..7b67426 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -62,10 +62,13 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
 {
/*
 * Return 1 as soon as we encounter a node at depth 1 that is
-* not the /chosen node.
+* not the /chosen node or to Xen initial domain that is not
+* either /chosen or /hypervisor node.
 */
if (depth == 1 && (strcmp(uname, "chosen") != 0))
-   return 1;
+   if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
+   return 1;
+
return 0;
 }
 
@@ -179,8 +182,9 @@ void __init acpi_boot_table_init(void)
/*
 * Enable ACPI instead of device tree unless
 * - ACPI has been disabled explicitly (acpi=off), or
-* - the device tree is not empty (it has more than just a /chosen node)
-*   and ACPI has not been force enabled (acpi=force)
+* - the device tree is not empty (it has more than just a /chosen node
+*   or to Xen initial domain it has more than a /chosen node and
+*   /hypervisor node) and ACPI has not been force enabled (acpi=force)
 */
if (param_acpi_off ||
(!param_acpi_force && of_scan_flat_dt(dt_scan_depth1_nodes, NULL)))
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/13] ARM: Xen: Initialize Xen specific UEFI runtime services

[shannon . zhao]

From: Shannon Zhao 

When running on Xen hypervisor, runtime services are supported through
hypercall. So call Xen specific function to initialize runtime services.

Signed-off-by: Shannon Zhao 
---
 arch/arm/include/asm/xen/hypercall.h |  1 +
 arch/arm/xen/enlighten.c |  1 +
 arch/arm/xen/hypercall.S |  1 +
 arch/arm64/kernel/efi.c  | 20 ++--
 arch/arm64/xen/hypercall.S   |  1 +
 drivers/xen/Kconfig  |  2 +-
 drivers/xen/efi.c| 22 ++
 include/xen/xen-ops.h| 10 ++
 8 files changed, 51 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h 
b/arch/arm/include/asm/xen/hypercall.h
index 712b50e..0de6074 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -50,6 +50,7 @@ int HYPERVISOR_physdev_op(int cmd, void *arg);
 int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
 int HYPERVISOR_tmem_op(void *arg);
 int HYPERVISOR_multicall(struct multicall_entry *calls, uint32_t nr);
+int HYPERVISOR_dom0_op(void *arg);
 
 static inline int
 HYPERVISOR_suspend(unsigned long start_info_mfn)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 7cb82f7..1373d6d 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -289,3 +289,4 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
 EXPORT_SYMBOL_GPL(privcmd_call);
+EXPORT_SYMBOL_GPL(HYPERVISOR_dom0_op);
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index 10fd99c..16fc153 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -90,6 +90,7 @@ HYPERCALL2(physdev_op);
 HYPERCALL3(vcpu_op);
 HYPERCALL1(tmem_op);
 HYPERCALL2(multicall);
+HYPERCALL1(dom0_op);
 
 ENTRY(privcmd_call)
stmdb sp!, {r4}
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 13671a9..ab1c9e9 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -34,6 +34,9 @@
 #include 
 #include 
 
+#include 
+#include 
+
 struct efi_memory_map memmap;
 
 static u64 efi_system_table;
@@ -308,13 +311,18 @@ static int __init arm64_enable_runtime_services(void)
}
set_bit(EFI_SYSTEM_TABLES, );
 
-   if (!efi_virtmap_init()) {
-   pr_err("No UEFI virtual mapping was installed -- runtime 
services will not be available\n");
-   return -1;
-   }
+   if (!xen_initial_domain()) {
+   if (!efi_virtmap_init()) {
+   pr_err("No UEFI virtual mapping was installed -- 
runtime services will not be available\n");
+   return -1;
+   }
 
-   /* Set up runtime services function pointers */
-   efi_native_runtime_setup();
+   /* Set up runtime services function pointers */
+   efi_native_runtime_setup();
+   } else {
+   /* Set up runtime services function pointers for Xen UEFI */
+   xen_efi_runtime_setup();
+   }
set_bit(EFI_RUNTIME_SERVICES, );
 
efi.runtime_version = efi.systab->hdr.revision;
diff --git a/arch/arm64/xen/hypercall.S b/arch/arm64/xen/hypercall.S
index 8bbe940..f6e15aa 100644
--- a/arch/arm64/xen/hypercall.S
+++ b/arch/arm64/xen/hypercall.S
@@ -81,6 +81,7 @@ HYPERCALL2(physdev_op);
 HYPERCALL3(vcpu_op);
 HYPERCALL1(tmem_op);
 HYPERCALL2(multicall);
+HYPERCALL1(dom0_op);
 
 ENTRY(privcmd_call)
mov x16, x0
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 73708ac..59aec8b 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -268,7 +268,7 @@ config XEN_HAVE_PVMMU
 
 config XEN_EFI
def_bool y
-   depends on X86_64 && EFI
+   depends on ARM64 || X86_64 && EFI
 
 config XEN_AUTO_XLATE
def_bool y
diff --git a/drivers/xen/efi.c b/drivers/xen/efi.c
index f745db2..5246d89 100644
--- a/drivers/xen/efi.c
+++ b/drivers/xen/efi.c
@@ -33,6 +33,7 @@
 
 #define INIT_EFI_OP(name) \
{.cmd = XENPF_efi_runtime_call, \
+.interface_version = XENPF_INTERFACE_VERSION, \
 .u.efi_runtime_call.function = XEN_EFI_##name, \
 .u.efi_runtime_call.misc = 0}
 
@@ -261,6 +262,7 @@ static efi_status_t 
xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
return efi_data(op).status;
 }
 
+#ifdef CONFIG_x86
 static efi_char16_t vendor[100] __initdata;
 
 static efi_system_table_t efi_systab_xen __initdata = {
@@ -319,7 +321,26 @@ static const struct efi efi_xen __initconst = {
.memmap   = NULL, /* Not used under Xen. */
.flags= 0 /* Initialized later. */
 };
+#endif
 
+#ifdef CONFIG_ARM64
+void xen_efi_runtime_setup(void)
+{
+   efi.get_time = xen_efi_get_time;
+   efi.set_time = xen_efi_set_time;
+   efi.get_wakeup_time = xen_efi_get_wakeup_time;
+   

Re: [PATCH 1/2] Remove EFI memmap quirk for UV

[Matt Fleming]

On Mon, 16 Nov, at 07:02:48PM, Thomas Gleixner wrote:
> On Mon, 16 Nov 2015, Alex Thorlton wrote:
> 
> CC'ing Matt under his correct e-mail address.
> 
> > Commit a5d90c923bcf ("x86/efi: Quirk out SGI UV") added a quirk to
> > efi_apply_memmap_quirks to force SGI UV systems to fall back to the old
> > EFI memmap mechanism.  We have a BIOS fix for this issue now, so we no
> > longer need this quirk in the kernel.  This commit removes the quirk
> > from the function in question.
> > 
> > Signed-off-by: Alex Thorlton 
> > Acked-by: Mike Travis 
> > Acked-by: Russ Anderson 
> > Cc: Matt Fleming 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: "H. Peter Anvin" 
> > Cc: Hedi Berriche 
> > Cc: Dimitri Sivanich 
> > Cc: x...@kernel.org
> > Cc: linux-efi@vger.kernel.org
> > 
> > ---
> >  arch/x86/platform/efi/quirks.c | 6 --
> >  1 file changed, 6 deletions(-)
> > 
> > diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
> > index 1c7380d..96b417c 100644
> > --- a/arch/x86/platform/efi/quirks.c
> > +++ b/arch/x86/platform/efi/quirks.c
> > @@ -259,12 +259,6 @@ void __init efi_apply_memmap_quirks(void)
> > pr_info("efi: Setup done, disabling due to 32/64-bit 
> > mismatch\n");
> > efi_unmap_memmap();
> > }
> > -
> > -   /*
> > -* UV doesn't support the new EFI pagetable mapping yet.
> > -*/
> > -   if (is_uv_system())
> > -   set_bit(EFI_OLD_MEMMAP, );

Awesome! Thanks Alex.

Can I also close https://bugzilla.kernel.org/show_bug.cgi?id=75021 ?
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] Remove EFI memmap quirk for UV

[Borislav Petkov]

On Mon, Nov 16, 2015 at 11:59:40AM -0600, Alex Thorlton wrote:
> Commit a5d90c923bcf ("x86/efi: Quirk out SGI UV") added a quirk to
> efi_apply_memmap_quirks to force SGI UV systems to fall back to the old
> EFI memmap mechanism.  We have a BIOS fix for this issue now, so we no
> longer need this quirk in the kernel.

So does that mean that all UV systems out there will get the BIOS update
or at least will have a BIOS update available so that we won't need the
quirk at all?

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Xen-devel] [PATCH 05/13] Xen: ARM: Add support for mapping platform device mmio

[Shannon Zhao]

On 2015/11/18 0:32, David Vrabel wrote:
> On 17/11/15 09:57, shannon.z...@linaro.org wrote:
>> From: Shannon Zhao 
>>
>> Add a bus_notifier for platform bus device in order to map the device
>> mmio regions when DOM0 booting with ACPI.
> [...]
>> --- /dev/null
>> +++ b/drivers/xen/platform.c
>> @@ -0,0 +1,104 @@
>> +/*
>> + * Copyright (c) 2015, Linaro Limited.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along 
>> with
>> + * this program; if not, write to the Free Software Foundation, Inc., 59 
>> Temple
>> + * Place - Suite 330, Boston, MA 02111-1307 USA.
> 
> "You should have received a copy of the GNU General Public License
> along with this program.  If not, see ."
> 
>> + *
>> + * Author: Shannon Zhao 
> 
> Omit this since it just becomes stale and git will know the correct
> authorship.
> 
>> +static int xen_platform_notifier(struct notifier_block *nb,
>> + unsigned long action, void *data)
>> +{
>> +struct platform_device *pdev = to_platform_device(data);
>> +int r = 0;
>> +
>> +if (!acpi_disabled && (action == BUS_NOTIFY_ADD_DEVICE))
>> +r = xen_map_platform_device_mmio(pdev);
> 
> Why even register the notifier if acpi_disabled?
> 
>> +
>> +if (r)
>> +{
>> +dev_err(>dev, "Failed to add_to_physmap device (%s) 
>> mmio!\n",
>> +pdev->name);
>> +return NOTIFY_OK;
> 
> Return NOTIFY_BAD here?  The device will be unusable.
> 
>> +}
>> +
>> +return NOTIFY_DONE;
>> +}
>> +
>> +static struct notifier_block platform_device_nb = {
>> +.notifier_call = xen_platform_notifier,
>> +};
>> +
>> +static int __init register_xen_platform_notifier(void)
>> +{
>> +if (!xen_initial_domain())
>> +return 0;
>> +
>> +return bus_register_notifier(_bus_type, _device_nb);
> 
> Why only platform busses?  What about PCI devices?  Where will they get
> added to dom0's physmap?
> 
I've said in the design doc[1] that "And for PCI bus devices, Linux
could reuse the existing PCI bus_notifier like X86."

Since currently Xen on ARM doesn't support PCI (IIRC) and if it adds the
support in the future, we could make the codes in drivers/xen/pci.c
common to ARM and x86 at that moment.

Thanks,

[1] http://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html

-- 
Shannon

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/13] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

[Shannon Zhao]

On 2015/11/18 4:44, Rob Herring wrote:
> On Tue, Nov 17, 2015 at 05:57:05PM +0800, shannon.z...@linaro.org wrote:
>> From: Shannon Zhao 
>>
>> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
>> scan this to get the UEFI information.
>>
>> Signed-off-by: Shannon Zhao 
>> ---
>>  Documentation/devicetree/bindings/arm/xen.txt | 25 +
>>  1 file changed, 25 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
>> b/Documentation/devicetree/bindings/arm/xen.txt
>> index 0f7b9c2..c375d67 100644
>> --- a/Documentation/devicetree/bindings/arm/xen.txt
>> +++ b/Documentation/devicetree/bindings/arm/xen.txt
>> @@ -15,6 +15,24 @@ the following properties:
>>  - interrupts: the interrupt used by Xen to inject event notifications.
>>A GIC node is also required.
>>  
>> +To support UEFI on Xen ARM virtual platforms, Xen pupulates the FDT "uefi" 
>> node
>> +under /hypervisor with following parameters:
>> +
>> +
>> +Name  | Size   | Description
>> +
>> +xen,uefi-system-table | 64-bit | Physical address of the UEFI System 
>> Table.
>> +
>> +xen,uefi-mmap-start   | 64-bit | Physical address of the UEFI memory 
>> map.
>> +
>> +xen,uefi-mmap-size| 32-bit | Size in bytes of the UEFI memory map
>> +  || pointed to in previous entry.
>> +
>> +xen,uefi-mmap-desc-size   | 32-bit | Size in bytes of each entry in the UEFI
>> +  || memory map.
>> +
>> +xen,uefi-mmap-desc-ver| 32-bit | Version of the mmap descriptor format.
>> +
> 
> Why aren't you using what is already populated by UEFI as defined in 
> Documentation/arm/uefi.txt? Seems to be about the same thing.
> 

Yes, the parameters are similar. But since we can't find a good way to
use normal UEFI for Xen Dom0 on ARM(there are some aspects which are not
consistent with the UEFI spec), we have to introduce a Xen specific
UEFI. Then we want to separate this from the normal UEFI completely and
don't affect the normal use. So we add these parameter under Xenia
specific node /hypervisor.

For details of the previous discussion, look at below link:

http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg03295.html

Thanks,
-- 
Shannon

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/13] Xen: EFI: Parse DT parameters for Xen specific UEFI

[Shannon Zhao]

On 2015/11/17 20:17, Ard Biesheuvel wrote:
> On 17 November 2015 at 12:37, Mark Rutland  wrote:
>> On Tue, Nov 17, 2015 at 12:25:58PM +0100, Ard Biesheuvel wrote:
>>> On 17 November 2015 at 10:57,   wrote:
 From: Shannon Zhao 

 Add a new function to parse DT parameters for Xen specific UEFI just
 like the way for normal UEFI. Then it could reuse the existing codes.

 Signed-off-by: Shannon Zhao 
 ---
  drivers/firmware/efi/efi.c | 67 
 ++
  1 file changed, 62 insertions(+), 5 deletions(-)

 diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
 index d6144e3..629bd06 100644
 --- a/drivers/firmware/efi/efi.c
 +++ b/drivers/firmware/efi/efi.c
 @@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
 +#include 

  struct efi __read_mostly efi = {
 .mps= EFI_INVALID_TABLE_ADDR,
 @@ -488,12 +489,60 @@ static __initdata struct {
 UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", 
 desc_ver)
  };

 +static __initdata struct {
 +   const char name[32];
 +   const char propname[32];
 +   int offset;
 +   int size;
 +} xen_dt_params[] = {
 +   UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
 +   UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
 +   UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
 +   UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", 
 desc_size),
 +   UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", 
 desc_ver)
 +};
 +
>>>
>>> We discussed (and agreed afair) that dropping the "linux," prefix from
>>> the DT properties was an acceptable change. If we do that, and reuse
>>> the same names in the xen version (i.e., drop the "xen," prefix), we
>>> could make this change a *lot* simpler.
>>
>> Regardless of if we drop the "linux," prefix from the existing strings,
>> I think we need the "xen," prefix here.
>>
>> The xen EFI interface comes with additional caveats, and we need to
>> treat it separately.
>>
>> Unless you're suggesting that /hypervisor/uefi-* is handled differently
>> to /chosen/uefi-*?
>>
>> I think I'd still prefer the "xen," prefix regardless.
>>
> 
> Well, we should still be able to reuse more of the existing code
> rather than duplicating a bunch of code in fdt_find_xen_uefi_params()

Sure, will try to reuse the codes.

Thanks,
-- 
Shannon

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Xen-devel] [PATCH 07/13] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

[Shannon Zhao]

On 2015/11/18 0:46, David Vrabel wrote:
> On 17/11/15 09:57, shannon.z...@linaro.org wrote:
>> From: Shannon Zhao 
>>
>> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
>> scan this to get the UEFI information.
> [...]
>> --- a/Documentation/devicetree/bindings/arm/xen.txt
>> +++ b/Documentation/devicetree/bindings/arm/xen.txt
>> @@ -15,6 +15,24 @@ the following properties:
>>  - interrupts: the interrupt used by Xen to inject event notifications.
>>A GIC node is also required.
>>  
>> +To support UEFI on Xen ARM virtual platforms, Xen pupulates the FDT "uefi" 
>> node
>> +under /hypervisor with following parameters:
> 
> It's not really clear why this is under /hypervisor and why xen needs to
> define its own nodes.
> 
> The handling of the existing linux standard nodes can be made
> Xen-specific by the presence of the /hypervisor/compatible == "xen" node
> (or similar), right?
> 
Right. The reason is that we want to separate this Xen specific UEFI
from the normal UEFI. Don't make them mixed together.

>> +
>> +Name  | Size   | Description
>> +
>> +xen,uefi-system-table | 64-bit | Physical address of the UEFI System 
>> Table.
>> +
>> +xen,uefi-mmap-start   | 64-bit | Physical address of the UEFI memory 
>> map.
>> +
> 
> I would probably say "Guest physical address..." just to be clear.
> 
>> +xen,uefi-mmap-size| 32-bit | Size in bytes of the UEFI memory map
>> +  || pointed to in previous entry.
>> +
>> +xen,uefi-mmap-desc-size   | 32-bit | Size in bytes of each entry in the UEFI
>> +  || memory map.
>> +
>> +xen,uefi-mmap-desc-ver| 32-bit | Version of the mmap descriptor format.
>> +
> 
> Need a reference to the mmap descriptor format here.
> 
> David
> 
> .
> 

-- 
Shannon

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html