Add ACPI support for Xen Dom0 on ARM64
Subsystems (10)
cover Add ACPI support for Xen Dom0 on ARM64
From: Shannon Zhao <[email protected]>
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
Signature · 1 line
2.1.0
PATCH 1/13 Xen : Hide UART used by Xen
From: Shannon Zhao <[email protected]>
According to the STAO table, hide UART used by Xen from Dom0.
--- drivers/acpi/bus.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
drivers/acpi/bus.c +22 -0
@@ -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 , + &addr); +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 **)&stao_ptr); +if (stao_ptr->ignore_uart) + { +struct acpi_table_spcr *spcr_ptr; +acpi_get_table (ACPI_SIG_SPCR ,1 , + (struct acpi_table_header **)&spcr_ptr); + uart_addr = spcr_ptr->serial_port.address; + } +init_acpi_device_notify (); result =acpi_bus_init ();if (result) {
Signature · 1 line
2.1.0
A message that is not in the archive (sent off-list or not yet received): 1447754231-7772-2-git-send-email-shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
Re: [PATCH 01/13] Xen : Hide UART used by Xen
CC'ing ACPI maintainers.
Please use ./scripts/get_maintainer.pl to retrieve a list of maintainers to CC for each patch.
Quoted 14 lines · On Tue, 17 Nov 2015, [email protected] wrote:
From: Shannon Zhao <[email protected]>
According to the STAO table, hide UART used by Xen from Dom0.
Signed-off-by Shannon Zhao <[email protected]>--- drivers/acpi/bus.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)drivers/acpi/bus.c +0
-0
drivers/acpi/bus.c ACPI_MODULE_NAME("bus"); · line 49
Quoted 4 lines
drivers/acpi/bus.c +1
-0@@ -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;
I would call this spcr_addr or spcr_uart_addr because there are many uarts on the system but only one spcr. It might make sense to initialize this to 0xffffffffffffffff rather than 0, which could actually be a correct uart address.
Quoted 28 lines
drivers/acpi/bus.c +11
-0#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 , + &addr); +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");
drivers/acpi/bus.c static int __init acpi_init(void) · line 1099
Quoted 7 lines
drivers/acpi/bus.c +4
-0@@ -1081,6 +1093,16 @@ static int __init acpi_init(void) acpi_kobj =NULL ; } +acpi_get_table (ACPI_SIG_STAO ,1 , + (struct acpi_table_header **)&stao_ptr); +if (stao_ptr->ignore_uart) + {
Please follow the linux coding style. You can use ./scripts/checkpatch.pl to check for coding style errors.
Quoted 12 lines
drivers/acpi/bus.c +6
-0+struct acpi_table_spcr *spcr_ptr; +acpi_get_table (ACPI_SIG_SPCR ,1 , + (struct acpi_table_header **)&spcr_ptr); + uart_addr = spcr_ptr->serial_port.address; + } +init_acpi_device_notify (); result =acpi_bus_init ();if (result) {Signature · 1 line
2.1.0
Re: [PATCH 01/13] Xen : Hide UART used by Xen
In reply to shannon.zhao at linaro.orgCC'ing ACPI maintainers.
Please use ./scripts/get_maintainer.pl to retrieve a list of maintainers to CC for each patch.
Quoted 14 lines · On Tue, 17 Nov 2015, [email protected] wrote:
From: Shannon Zhao <[email protected]>
According to the STAO table, hide UART used by Xen from Dom0.
Signed-off-by Shannon Zhao <[email protected]>--- drivers/acpi/bus.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)drivers/acpi/bus.c +0
-0
drivers/acpi/bus.c ACPI_MODULE_NAME("bus"); · line 49
Quoted 4 lines
drivers/acpi/bus.c +1
-0@@ -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;
I would call this spcr_addr or spcr_uart_addr because there are many uarts on the system but only one spcr. It might make sense to initialize this to 0xffffffffffffffff rather than 0, which could actually be a correct uart address.
Quoted 28 lines
drivers/acpi/bus.c +11
-0#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 , + &addr); +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");
drivers/acpi/bus.c static int __init acpi_init(void) · line 1099
Quoted 7 lines
drivers/acpi/bus.c +4
-0@@ -1081,6 +1093,16 @@ static int __init acpi_init(void) acpi_kobj =NULL ; } +acpi_get_table (ACPI_SIG_STAO ,1 , + (struct acpi_table_header **)&stao_ptr); +if (stao_ptr->ignore_uart) + {
Please follow the linux coding style. You can use ./scripts/checkpatch.pl to check for coding style errors.
Quoted 12 lines
drivers/acpi/bus.c +6
-0+struct acpi_table_spcr *spcr_ptr; +acpi_get_table (ACPI_SIG_SPCR ,1 , + (struct acpi_table_header **)&spcr_ptr); + uart_addr = spcr_ptr->serial_port.address; + } +init_acpi_device_notify (); result =acpi_bus_init ();if (result) {Signature · 1 line
2.1.0
PATCH 1/13 Xen : Hide UART used by Xen
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
According to the STAO table, hide UART used by Xen from Dom0.
--- drivers/acpi/bus.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
drivers/acpi/bus.c +22 -0
@@ -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 , + &addr); +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 **)&stao_ptr); +if (stao_ptr->ignore_uart) + { +struct acpi_table_spcr *spcr_ptr; +acpi_get_table (ACPI_SIG_SPCR ,1 , + (struct acpi_table_header **)&spcr_ptr); + uart_addr = spcr_ptr->serial_port.address; + } +init_acpi_device_notify (); result =acpi_bus_init ();if (result) {
Signature · 1 line
2.1.0
PATCH 2/13 xen/grant-table: Move xlated_setup_gnttab_pages to common place
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
Move xlated_setup_gnttab_pages to common place, so it can be reused by ARM to setup grant table when booting with ACPI.
--- 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(-)
arch/x86/xen/grant-table.c +0 -51
@@ -111,57 +111,6 @@ int arch_gnttab_init(unsigned long nr_shared) }#ifdef CONFIG_XEN_PVH -#include <xen/balloon.h> -#include <xen/events.h> -#include <linux/slab.h> -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 ())
drivers/xen/grant-table.c +49 -0
55 lines not on this page · raw message
include/xen/grant_table.h +1 -0
@@ -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))
Signature · 1 line
2.1.0
PATCH 2/13 xen/grant-table: Move xlated_setup_gnttab_pages to common place
Quoted 4 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Move
xlated_setup_gnttab_pagesto common place, so it can be reused by ARM to setup grant table when booting with ACPI.
[...]
Quoted 36 lines
drivers/xen/grant-table.c +30
-0@@ -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]); +
drivers/xen/grant-table.c int gnttab_setup_auto_xlat_frames(phys_addr_t addr) · line 706
Quoted 10 lines
drivers/xen/grant-table.c +10
-0+ 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
PATCH 2/13 xen/grant-table: Move xlated_setup_gnttab_pages to common place
Quoted 56 lines · David Vrabel
Quoted 4 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Move
xlated_setup_gnttab_pagesto common place, so it can be reused by ARM to setup grant table when booting with ACPI.[...]
Quoted 36 lines
drivers/xen/grant-table.c +30
-0@@ -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]); +drivers/xen/grant-table.c int gnttab_setup_auto_xlat_frames(phys_addr_t addr) · line 706
Quoted 10 lines
drivers/xen/grant-table.c +10
-0+ 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.cin a function like:
Quoted 15 lines
/**
*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,
Signature · 1 line
Shannon
PATCH 2/13 xen/grant-table: Move xlated_setup_gnttab_pages to common place
Quoted 72 lines · Shannon Zhao
Quoted 56 lines · David Vrabel
Quoted 4 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Move
xlated_setup_gnttab_pagesto common place, so it can be reused by ARM to setup grant table when booting with ACPI.[...]
Quoted 36 lines
drivers/xen/grant-table.c +30
-0@@ -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]); +drivers/xen/grant-table.c int gnttab_setup_auto_xlat_frames(phys_addr_t addr) · line 706
Quoted 10 lines
drivers/xen/grant-table.c +10
-0+ 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.cin a function like:Quoted 15 lines
/**
*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);
Quoted 3 lines
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_frameseither. Right?
Yes.
David
Re: [PATCH 02/13] xen/grant-table: Move xlated_setup_gnttab_pages to common place
In reply to Shannon ZhaoQuoted 72 lines · Shannon Zhao
Quoted 56 lines · David Vrabel
Quoted 4 lines · On 17/11/15 09:57, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Move
xlated_setup_gnttab_pagesto common place, so it can be reused by ARM to setup grant table when booting with ACPI.[...]
Quoted 36 lines
drivers/xen/grant-table.c +30
-0@@ -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]); +drivers/xen/grant-table.c int gnttab_setup_auto_xlat_frames(phys_addr_t addr) · line 706
Quoted 10 lines
drivers/xen/grant-table.c +10
-0+ 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.cin a function like:Quoted 15 lines
/**
*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);
Quoted 3 lines
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_frameseither. Right?
Yes.
David
Re: [PATCH 02/13] xen/grant-table: Move xlated_setup_gnttab_pages to common place
In reply to David VrabelQuoted 56 lines · David Vrabel
Quoted 4 lines · On 17/11/15 09:57, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Move
xlated_setup_gnttab_pagesto common place, so it can be reused by ARM to setup grant table when booting with ACPI.[...]
Quoted 36 lines
drivers/xen/grant-table.c +30
-0@@ -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]); +drivers/xen/grant-table.c int gnttab_setup_auto_xlat_frames(phys_addr_t addr) · line 706
Quoted 10 lines
drivers/xen/grant-table.c +10
-0+ 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.cin a function like:
Quoted 15 lines
/**
*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,
Signature · 1 line
Shannon
Re: [PATCH 02/13] xen/grant-table: Move xlated_setup_gnttab_pages to common place
In reply to shannon.zhao at linaro.orgQuoted 4 lines · On 17/11/15 09:57, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Move
xlated_setup_gnttab_pagesto common place, so it can be reused by ARM to setup grant table when booting with ACPI.
[...]
Quoted 36 lines
drivers/xen/grant-table.c +30
-0@@ -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]); +
drivers/xen/grant-table.c int gnttab_setup_auto_xlat_frames(phys_addr_t addr) · line 706
Quoted 10 lines
drivers/xen/grant-table.c +10
-0+ 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
PATCH 2/13 xen/grant-table: Move xlated_setup_gnttab_pages to common place
In reply to shannon.zhao at linaro.orgHi Shannon,
Quoted 18 lines · shannon.zhao at linaro.org
drivers/xen/grant-table.c +10
-0@@ -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 );
drivers/xen/grant-table.c int gnttab_setup_auto_xlat_frames(phys_addr_t addr) · line 686
Quoted 10 lines
drivers/xen/grant-table.c +10
-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 */ );
Can you rebase your patch on top of linux/master? The 3rd parameters has been dropped for alloc_xenballooned_pages.
drivers/xen/grant-table.c int gnttab_setup_auto_xlat_frames(phys_addr_t addr) · line 695
Quoted 9 lines
drivers/xen/grant-table.c +9
-0+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]);
This code needs to be adapt for 64KB page granularity. Please use page_to_xen_pfn here.
Quoted 29 lines
drivers/xen/grant-table.c +20
-0+ + 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)include/xen/grant_table.h +0
-0
include/xen/grant_table.h struct grant_frames { · line 183
Quoted 7 lines
include/xen/grant_table.h +1
-0@@ -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))
Regards,
Signature · 1 line
Julien Grall
PATCH 2/13 xen/grant-table: Move xlated_setup_gnttab_pages to common place
Quoted 26 lines · Julien Grall
Hi Shannon,
Quoted 23 lines · shannon.zhao at linaro.org
drivers/xen/grant-table.c +15
-0@@ -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 );
Quoted 9 lines
drivers/xen/grant-table.c int gnttab_setup_auto_xlat_frames(phys_addr_t addr) · line 686
Quoted 5 lines
drivers/xen/grant-table.c +5
-0+if (!pfns) { +kfree (pages); +return -ENOMEM ; + } + rc =alloc_xenballooned_pages (nr_grant_frames, pages,0 /* lowmem */ );Can you rebase your patch on top of linux/master? The 3rd parameters has been dropped for
alloc_xenballooned_pages.
Sure, I rebase this patchset on Linux 4.3 and will rebase on master at next version.
Quoted 4 lines
Quoted 4 lines
drivers/xen/grant-table.c +4
-0+if (rc) { +pr_warn ("%s Couldn't balloon alloc %ld pfns rc:%d\n" , __func__, + nr_grant_frames, rc); +kfree (pages);
Quoted 9 lines
drivers/xen/grant-table.c int gnttab_setup_auto_xlat_frames(phys_addr_t addr) · line 695
Quoted 5 lines
drivers/xen/grant-table.c +5
-0+kfree (pfns); +return rc; + } +for (i =0 ; i < nr_grant_frames; i++) + pfns[i] =page_to_pfn (pages[i]);This code needs to be adapt for 64KB page granularity. Please use
page_to_xen_pfnhere.
Ok.
Quoted 40 lines
Quoted 29 lines
drivers/xen/grant-table.c +20
-0+ + 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)include/xen/grant_table.h +0
-0include/xen/grant_table.h struct grant_frames { · line 183
Quoted 7 lines
include/xen/grant_table.h +1
-0@@ -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))Regards,
Signature · 1 line
Shannon
Re: [PATCH 02/13] xen/grant-table: Move xlated_setup_gnttab_pages to common place
In reply to Julien GrallQuoted 26 lines · Julien Grall
Hi Shannon,
Quoted 23 lines · On 17/11/15 09:57, [email protected] wrote:
drivers/xen/grant-table.c +15
-0@@ -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 );
Quoted 9 lines
drivers/xen/grant-table.c int gnttab_setup_auto_xlat_frames(phys_addr_t addr) · line 686
Quoted 5 lines
drivers/xen/grant-table.c +5
-0+if (!pfns) { +kfree (pages); +return -ENOMEM ; + } + rc =alloc_xenballooned_pages (nr_grant_frames, pages,0 /* lowmem */ );Can you rebase your patch on top of linux/master? The 3rd parameters has been dropped for
alloc_xenballooned_pages.
Sure, I rebase this patchset on Linux 4.3 and will rebase on master at next version.
Quoted 4 lines
Quoted 4 lines
drivers/xen/grant-table.c +4
-0+if (rc) { +pr_warn ("%s Couldn't balloon alloc %ld pfns rc:%d\n" , __func__, + nr_grant_frames, rc); +kfree (pages);
Quoted 9 lines
drivers/xen/grant-table.c int gnttab_setup_auto_xlat_frames(phys_addr_t addr) · line 695
Quoted 5 lines
drivers/xen/grant-table.c +5
-0+kfree (pfns); +return rc; + } +for (i =0 ; i < nr_grant_frames; i++) + pfns[i] =page_to_pfn (pages[i]);This code needs to be adapt for 64KB page granularity. Please use
page_to_xen_pfnhere.
Ok.
Quoted 40 lines
Quoted 29 lines
drivers/xen/grant-table.c +20
-0+ + 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)include/xen/grant_table.h +0
-0include/xen/grant_table.h struct grant_frames { · line 183
Quoted 7 lines
include/xen/grant_table.h +1
-0@@ -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))Regards,
Signature · 1 line
Shannon
Re: [PATCH 02/13] xen/grant-table: Move xlated_setup_gnttab_pages to common place
In reply to shannon.zhao at linaro.orgHi Shannon,
Quoted 18 lines · On 17/11/15 09:57, [email protected] wrote:
drivers/xen/grant-table.c +10
-0@@ -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 );
drivers/xen/grant-table.c int gnttab_setup_auto_xlat_frames(phys_addr_t addr) · line 686
Quoted 10 lines
drivers/xen/grant-table.c +10
-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 */ );
Can you rebase your patch on top of linux/master? The 3rd parameters has been dropped for alloc_xenballooned_pages.
drivers/xen/grant-table.c int gnttab_setup_auto_xlat_frames(phys_addr_t addr) · line 695
Quoted 9 lines
drivers/xen/grant-table.c +9
-0+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]);
This code needs to be adapt for 64KB page granularity. Please use page_to_xen_pfn here.
Quoted 29 lines
drivers/xen/grant-table.c +20
-0+ + 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)include/xen/grant_table.h +0
-0
include/xen/grant_table.h struct grant_frames { · line 183
Quoted 7 lines
include/xen/grant_table.h +1
-0@@ -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))
Regards,
Signature · 1 line
Julien Grall
PATCH 2/13 xen/grant-table: Move xlated_setup_gnttab_pages to common place
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
Move xlated_setup_gnttab_pages to common place, so it can be reused by ARM to setup grant table when booting with ACPI.
--- 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(-)
arch/x86/xen/grant-table.c +0 -51
@@ -111,57 +111,6 @@ int arch_gnttab_init(unsigned long nr_shared) }#ifdef CONFIG_XEN_PVH -#include <xen/balloon.h> -#include <xen/events.h> -#include <linux/slab.h> -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 ())
drivers/xen/grant-table.c +49 -0
55 lines not on this page · raw message
include/xen/grant_table.h +1 -0
@@ -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))
Signature · 1 line
2.1.0
PATCH 3/13 arm/xen: Use xlated_setup_gnttab_pages to setup grant table
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
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.
--- arch/arm/xen/enlighten.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-)
arch/arm/xen/enlighten.c +1 -9
@@ -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 , &res)) { -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 ; }
Signature · 1 line
2.1.0
PATCH 3/13 arm/xen: Use xlated_setup_gnttab_pages to setup grant table
Quoted 6 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Use
xlated_setup_gnttab_pagesto 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 <[email protected]>
It looks good. I'll wait for the final version of xlated_setup_gnttab_pages before acking it, but it is fine in principle.
Quoted 38 lines
arch/arm/xen/enlighten.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-)arch/arm/xen/enlighten.c +1
-9@@ -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 , &res)) { -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 ; }Signature · 1 line
2.1.0
Re: [PATCH 03/13] arm/xen: Use xlated_setup_gnttab_pages to setup grant table
In reply to shannon.zhao at linaro.orgQuoted 6 lines · On Tue, 17 Nov 2015, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Use
xlated_setup_gnttab_pagesto 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 <[email protected]>
It looks good. I'll wait for the final version of xlated_setup_gnttab_pages before acking it, but it is fine in principle.
Quoted 38 lines
arch/arm/xen/enlighten.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-)arch/arm/xen/enlighten.c +1
-9@@ -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 , &res)) { -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 ; }Signature · 1 line
2.1.0
PATCH 3/13 arm/xen: Use xlated_setup_gnttab_pages to setup grant table
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
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.
--- arch/arm/xen/enlighten.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-)
arch/arm/xen/enlighten.c +1 -9
@@ -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 , &res)) { -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 ; }
Signature · 1 line
2.1.0
PATCH 4/13 xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
--- include/xen/interface/memory.h | 1 + 1 file changed, 1 insertion(+)
include/xen/interface/memory.h +1 -0
@@ -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
Signature · 1 line
2.1.0
PATCH 4/13 xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
Quoted 2 lines · On 17 November 2015 at 10:57, <[email protected]> wrote:
From: Shannon Zhao <[email protected]>
No empty commit logs please.
Quoted 20 lines
Signed-off-by Shannon Zhao <[email protected]>--- include/xen/interface/memory.h | 1 + 1 file changed, 1 insertion(+)include/xen/interface/memory.h +1
-1@@ -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
Re: [PATCH 04/13] xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
In reply to shannon.zhao at linaro.orgQuoted 2 lines · On 17 November 2015 at 10:57, <[email protected]> wrote:
From: Shannon Zhao <[email protected]>
No empty commit logs please.
Quoted 20 lines
Signed-off-by Shannon Zhao <[email protected]>--- include/xen/interface/memory.h | 1 + 1 file changed, 1 insertion(+)include/xen/interface/memory.h +1
-1@@ -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
PATCH 4/13 xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
--- include/xen/interface/memory.h | 1 + 1 file changed, 1 insertion(+)
include/xen/interface/memory.h +1 -0
@@ -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
Signature · 1 line
2.1.0
PATCH 5/13 Xen: ARM: Add support for mapping platform device mmio
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
Add a bus_notifier for platform bus device in order to map the device mmio regions when DOM0 booting with ACPI.
--- drivers/xen/Makefile | 1 + drivers/xen/platform.c | 104 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 105 insertions(+) create mode 100644 drivers/xen/platform.c
drivers/xen/Makefile +1 -0
@@ -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)
drivers/xen/platform.c new file +104 -0
104 lines not on this page · raw message
Signature · 1 line
2.1.0
Re: [PATCH 05/13] Xen: ARM: Add support for mapping platform device mmio
Quoted 49 lines · On Tue, Nov 17, 2015 at 05:57:03PM +0800, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Add a
bus_notifierfor platform bus device in order to map the device mmio regions when DOM0 booting with ACPI.Signed-off-by Shannon Zhao <[email protected]>--- drivers/xen/Makefile | 1 + drivers/xen/platform.c | 104 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 105 insertions(+) create mode 100644 drivers/xen/platform.cdrivers/xen/Makefile +1
-0@@ -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)drivers/xen/platform.c new file +19
-0@@ -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 <[email protected]> +*/ +
drivers/xen/platform.c line 29
Quoted 10 lines
drivers/xen/platform.c new file +10
-0+#include <linux/platform_device.h> +#include <linux/acpi.h> +#include <xen/xen.h> +#include <xen/interface/memory.h> +#include <asm/xen/hypervisor.h> +#include <asm/xen/hypercall.h> + +static int xen_map_platform_device_mmio (struct platform_device *pdev) +{ +int i, rc =0 ;
unsigned int i;
drivers/xen/platform.c line 35
Quoted 6 lines
drivers/xen/platform.c new file +6
-0+ +for (i =0 ; i < pdev->num_resources; i++) + { +struct resource *r = &pdev->resource[i]; + +if (resource_type (r) ==IORESOURCE_MEM )
Make this:
if (resource_type(r) != IORESOURCE_MEM) continue;
drivers/xen/platform.c line 36
Quoted 1 line
drivers/xen/platform.c new file +1
-0+ {
And then you don't have to move all of this code to the right.
drivers/xen/platform.c line 37
Quoted 1 line
drivers/xen/platform.c new file +1
-0+int j;
unsigned int
drivers/xen/platform.c line 38
Quoted 1 line
drivers/xen/platform.c new file +1
-0+int nr =DIV_ROUND_UP (resource_size (r),PAGE_SIZE );
unsigned int
drivers/xen/platform.c line 43
Quoted 5 lines
drivers/xen/platform.c new file +5
-0+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.
drivers/xen/platform.c line 44
Quoted 1 line
drivers/xen/platform.c new file +1
-0+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'.
drivers/xen/platform.c line 49
Quoted 5 lines
drivers/xen/platform.c new file +5
-0+ +for (j =0 ; j < nr; j++) { + gpfns[j] = (r->start >>PAGE_SHIFT ) + j; + idxs[j] = (r->start >>PAGE_SHIFT ) + j; + errs[j] =0 ;
Then this can go away (because of kzalloc)
Quoted 63 lines
drivers/xen/platform.c new file +55
-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, + &xatp); +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 (&pdev->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 (&platform_bus_type, &platform_device_nb); +} + +arch_initcall (register_xen_platform_notifier);Signature · 7 lines
2.1.0 _______________________________________________ Xen-devel mailing list [email protected] http://lists.xen.org/xen-devel
PATCH 5/13 Xen: ARM: Add support for mapping platform device mmio
Quoted 90 lines · Konrad Rzeszutek Wilk
Quoted 49 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Add a
bus_notifierfor platform bus device in order to map the device mmio regions when DOM0 booting with ACPI.Signed-off-by Shannon Zhao <[email protected]>--- drivers/xen/Makefile | 1 + drivers/xen/platform.c | 104 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 105 insertions(+) create mode 100644 drivers/xen/platform.cdrivers/xen/Makefile +1
-0@@ -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)drivers/xen/platform.c new file +19
-0@@ -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 <[email protected]> +*/ +drivers/xen/platform.c line 29
Quoted 10 lines
drivers/xen/platform.c new file +10
-0+#include <linux/platform_device.h> +#include <linux/acpi.h> +#include <xen/xen.h> +#include <xen/interface/memory.h> +#include <asm/xen/hypervisor.h> +#include <asm/xen/hypercall.h> + +static int xen_map_platform_device_mmio (struct platform_device *pdev) +{ +int i, rc =0 ;unsigned int i;
drivers/xen/platform.c line 35
Quoted 6 lines
drivers/xen/platform.c new file +6
-0+ +for (i =0 ; i < pdev->num_resources; i++) + { +struct resource *r = &pdev->resource[i]; + +if (resource_type (r) ==IORESOURCE_MEM )Make this:
if (resource_type(r) != IORESOURCE_MEM) continue;drivers/xen/platform.c line 36
Quoted 1 line
drivers/xen/platform.c new file +1
-0+ {And then you don't have to move all of this code to the right.
drivers/xen/platform.c line 37
Quoted 1 line
drivers/xen/platform.c new file +1
-0+int j;unsigned int
drivers/xen/platform.c line 38
Quoted 1 line
drivers/xen/platform.c new file +1
-0+int nr =DIV_ROUND_UP (resource_size (r),PAGE_SIZE );unsigned int
drivers/xen/platform.c line 43
Quoted 5 lines
drivers/xen/platform.c new file +5
-0+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.
Quoted 6 lines
drivers/xen/platform.c line 44
Quoted 1 line
drivers/xen/platform.c new file +1
-0+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,
Signature · 1 line
Shannon
Re: [PATCH 05/13] Xen: ARM: Add support for mapping platform device mmio
In reply to Konrad Rzeszutek WilkQuoted 90 lines · Konrad Rzeszutek Wilk
Quoted 49 lines · On Tue, Nov 17, 2015 at 05:57:03PM +0800, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Add a
bus_notifierfor platform bus device in order to map the device mmio regions when DOM0 booting with ACPI.Signed-off-by Shannon Zhao <[email protected]>--- drivers/xen/Makefile | 1 + drivers/xen/platform.c | 104 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 105 insertions(+) create mode 100644 drivers/xen/platform.cdrivers/xen/Makefile +1
-0@@ -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)drivers/xen/platform.c new file +19
-0@@ -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 <[email protected]> +*/ +drivers/xen/platform.c line 29
Quoted 10 lines
drivers/xen/platform.c new file +10
-0+#include <linux/platform_device.h> +#include <linux/acpi.h> +#include <xen/xen.h> +#include <xen/interface/memory.h> +#include <asm/xen/hypervisor.h> +#include <asm/xen/hypercall.h> + +static int xen_map_platform_device_mmio (struct platform_device *pdev) +{ +int i, rc =0 ;unsigned int i;
drivers/xen/platform.c line 35
Quoted 6 lines
drivers/xen/platform.c new file +6
-0+ +for (i =0 ; i < pdev->num_resources; i++) + { +struct resource *r = &pdev->resource[i]; + +if (resource_type (r) ==IORESOURCE_MEM )Make this:
if (resource_type(r) != IORESOURCE_MEM) continue;drivers/xen/platform.c line 36
Quoted 1 line
drivers/xen/platform.c new file +1
-0+ {And then you don't have to move all of this code to the right.
drivers/xen/platform.c line 37
Quoted 1 line
drivers/xen/platform.c new file +1
-0+int j;unsigned int
drivers/xen/platform.c line 38
Quoted 1 line
drivers/xen/platform.c new file +1
-0+int nr =DIV_ROUND_UP (resource_size (r),PAGE_SIZE );unsigned int
drivers/xen/platform.c line 43
Quoted 5 lines
drivers/xen/platform.c new file +5
-0+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.
Quoted 6 lines
drivers/xen/platform.c line 44
Quoted 1 line
drivers/xen/platform.c new file +1
-0+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,
Signature · 1 line
Shannon
PATCH 5/13 Xen: ARM: Add support for mapping platform device mmio
In reply to shannon.zhao at linaro.orgQuoted 4 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Add a
bus_notifierfor platform bus device in order to map the device mmio regions when DOM0 booting with ACPI.
[...]
Quoted 8 lines
drivers/xen/platform.c new file +5
-0@@ -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,
drivers/xen/platform.c line 15
Quoted 10 lines
drivers/xen/platform.c new file +10
-0+* 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 <http://www.gnu.org/licenses/>."
drivers/xen/platform.c line 17
Quoted 2 lines
drivers/xen/platform.c new file +2
-0+* +* Author: Shannon Zhao <[email protected]>
Omit this since it just becomes stale and git will know the correct authorship.
drivers/xen/platform.c line 80
Quoted 8 lines
drivers/xen/platform.c new file +8
-0+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?
drivers/xen/platform.c line 86
Quoted 6 lines
drivers/xen/platform.c new file +6
-0+ +if (r) + { +dev_err (&pdev->dev,"Failed to add_to_physmap device (%s) mmio!\n" , + pdev->name); +return NOTIFY_OK ;
Return NOTIFY_BAD here? The device will be unusable.
Quoted 5 lines
drivers/xen/platform.c new file +5
-0+ } + +return NOTIFY_DONE ; +} +
drivers/xen/platform.c line 101
Quoted 10 lines
drivers/xen/platform.c new file +10
-0+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 (&platform_bus_type, &platform_device_nb);
Why only platform busses? What about PCI devices? Where will they get added to dom0's physmap?
David
PATCH 5/13 Xen: ARM: Add support for mapping platform device mmio
Quoted 64 lines · David Vrabel
Quoted 4 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Add a
bus_notifierfor platform bus device in order to map the device mmio regions when DOM0 booting with ACPI.[...]
Quoted 8 lines
drivers/xen/platform.c new file +5
-0@@ -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, drivers/xen/platform.c line 15
Quoted 10 lines
drivers/xen/platform.c new file +10
-0+* 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 <http://www.gnu.org/licenses/>."
drivers/xen/platform.c line 17
Quoted 2 lines
drivers/xen/platform.c new file +2
-0+* +* Author: Shannon Zhao <[email protected]> Omit this since it just becomes stale and git will know the correct authorship.
drivers/xen/platform.c line 80
Quoted 8 lines
drivers/xen/platform.c new file +8
-0+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?drivers/xen/platform.c line 86
Quoted 6 lines
drivers/xen/platform.c new file +6
-0+ +if (r) + { +dev_err (&pdev->dev,"Failed to add_to_physmap device (%s) mmio!\n" , + pdev->name); +return NOTIFY_OK ;Return
NOTIFY_BADhere? The device will be unusable.Quoted 10 lines
drivers/xen/platform.c new file +10
-0+ } + +return NOTIFY_DONE ; +} + +static struct notifier_block platform_device_nb = { + .notifier_call = xen_platform_notifier, +}; + +static int __init register_xen_platform_notifier (void )
Quoted 9 lines
drivers/xen/platform.c line 101
Quoted 5 lines
drivers/xen/platform.c new file +5
-0+{ +if (!xen_initial_domain ()) +return 0 ; + +return bus_register_notifier (&platform_bus_type, &platform_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
Signature · 1 line
Shannon
Re: [PATCH 05/13] Xen: ARM: Add support for mapping platform device mmio
In reply to David VrabelQuoted 64 lines · David Vrabel
Quoted 4 lines · On 17/11/15 09:57, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Add a
bus_notifierfor platform bus device in order to map the device mmio regions when DOM0 booting with ACPI.[...]
Quoted 8 lines
drivers/xen/platform.c new file +5
-0@@ -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, drivers/xen/platform.c line 15
Quoted 10 lines
drivers/xen/platform.c new file +10
-0+* 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 <http://www.gnu.org/licenses/>."
drivers/xen/platform.c line 17
Quoted 2 lines
drivers/xen/platform.c new file +2
-0+* +* Author: Shannon Zhao <[email protected]> Omit this since it just becomes stale and git will know the correct authorship.
drivers/xen/platform.c line 80
Quoted 8 lines
drivers/xen/platform.c new file +8
-0+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?drivers/xen/platform.c line 86
Quoted 6 lines
drivers/xen/platform.c new file +6
-0+ +if (r) + { +dev_err (&pdev->dev,"Failed to add_to_physmap device (%s) mmio!\n" , + pdev->name); +return NOTIFY_OK ;Return
NOTIFY_BADhere? The device will be unusable.Quoted 10 lines
drivers/xen/platform.c new file +10
-0+ } + +return NOTIFY_DONE ; +} + +static struct notifier_block platform_device_nb = { + .notifier_call = xen_platform_notifier, +}; + +static int __init register_xen_platform_notifier (void )
Quoted 9 lines
drivers/xen/platform.c line 101
Quoted 5 lines
drivers/xen/platform.c new file +5
-0+{ +if (!xen_initial_domain ()) +return 0 ; + +return bus_register_notifier (&platform_bus_type, &platform_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
Signature · 1 line
Shannon
Re: [PATCH 05/13] Xen: ARM: Add support for mapping platform device mmio
In reply to shannon.zhao at linaro.orgQuoted 4 lines · On 17/11/15 09:57, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Add a
bus_notifierfor platform bus device in order to map the device mmio regions when DOM0 booting with ACPI.
[...]
Quoted 8 lines
drivers/xen/platform.c new file +5
-0@@ -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,
drivers/xen/platform.c line 15
Quoted 10 lines
drivers/xen/platform.c new file +10
-0+* 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 <http://www.gnu.org/licenses/>."
drivers/xen/platform.c line 17
Quoted 2 lines
drivers/xen/platform.c new file +2
-0+* +* Author: Shannon Zhao <[email protected]>
Omit this since it just becomes stale and git will know the correct authorship.
drivers/xen/platform.c line 80
Quoted 8 lines
drivers/xen/platform.c new file +8
-0+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?
drivers/xen/platform.c line 86
Quoted 6 lines
drivers/xen/platform.c new file +6
-0+ +if (r) + { +dev_err (&pdev->dev,"Failed to add_to_physmap device (%s) mmio!\n" , + pdev->name); +return NOTIFY_OK ;
Return NOTIFY_BAD here? The device will be unusable.
Quoted 5 lines
drivers/xen/platform.c new file +5
-0+ } + +return NOTIFY_DONE ; +} +
drivers/xen/platform.c line 101
Quoted 10 lines
drivers/xen/platform.c new file +10
-0+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 (&platform_bus_type, &platform_device_nb);
Why only platform busses? What about PCI devices? Where will they get added to dom0's physmap?
David
PATCH 5/13 Xen: ARM: Add support for mapping platform device mmio
In reply to shannon.zhao at linaro.orgQuoted 63 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Add a
bus_notifierfor platform bus device in order to map the device mmio regions when DOM0 booting with ACPI.Signed-off-by Shannon Zhao <[email protected]>--- drivers/xen/Makefile | 1 + drivers/xen/platform.c | 104 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 105 insertions(+) create mode 100644 drivers/xen/platform.cdrivers/xen/Makefile +1
-0@@ -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)drivers/xen/platform.c new file +33
-0@@ -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 <[email protected]> +*/ + +#include <linux/platform_device.h> +#include <linux/acpi.h> +#include <xen/xen.h> +#include <xen/interface/memory.h> +#include <asm/xen/hypervisor.h> +#include <asm/xen/hypercall.h> + +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 = &pdev->resource[i];
drivers/xen/platform.c line 43
Quoted 10 lines
drivers/xen/platform.c new file +10
-0+ +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 );
please check for kmalloc returning NULL and return -ENOMEM
drivers/xen/platform.c line 48
Quoted 5 lines
drivers/xen/platform.c new file +5
-0+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;
XEN_PFN_DOWN
Quoted 59 lines
drivers/xen/platform.c new file +56
-0+ 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, + &xatp); +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 (&pdev->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 (&platform_bus_type, &platform_device_nb); +} + +arch_initcall (register_xen_platform_notifier);Signature · 1 line
2.1.0
Re: [PATCH 05/13] Xen: ARM: Add support for mapping platform device mmio
In reply to shannon.zhao at linaro.orgQuoted 63 lines · On Tue, 17 Nov 2015, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Add a
bus_notifierfor platform bus device in order to map the device mmio regions when DOM0 booting with ACPI.Signed-off-by Shannon Zhao <[email protected]>--- drivers/xen/Makefile | 1 + drivers/xen/platform.c | 104 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 105 insertions(+) create mode 100644 drivers/xen/platform.cdrivers/xen/Makefile +1
-0@@ -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)drivers/xen/platform.c new file +33
-0@@ -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 <[email protected]> +*/ + +#include <linux/platform_device.h> +#include <linux/acpi.h> +#include <xen/xen.h> +#include <xen/interface/memory.h> +#include <asm/xen/hypervisor.h> +#include <asm/xen/hypercall.h> + +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 = &pdev->resource[i];
drivers/xen/platform.c line 43
Quoted 10 lines
drivers/xen/platform.c new file +10
-0+ +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 );
please check for kmalloc returning NULL and return -ENOMEM
drivers/xen/platform.c line 48
Quoted 5 lines
drivers/xen/platform.c new file +5
-0+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;
XEN_PFN_DOWN
Quoted 59 lines
drivers/xen/platform.c new file +56
-0+ 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, + &xatp); +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 (&pdev->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 (&platform_bus_type, &platform_device_nb); +} + +arch_initcall (register_xen_platform_notifier);Signature · 1 line
2.1.0
PATCH 5/13 Xen: ARM: Add support for mapping platform device mmio
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
Add a bus_notifier for platform bus device in order to map the device mmio regions when DOM0 booting with ACPI.
--- drivers/xen/Makefile | 1 + drivers/xen/platform.c | 104 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 105 insertions(+) create mode 100644 drivers/xen/platform.c
drivers/xen/Makefile +1 -0
@@ -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)
drivers/xen/platform.c new file +104 -0
104 lines not on this page · raw message
Signature · 1 line
2.1.0
PATCH 6/13 Xen: ARM: Add support for mapping amba device mmio
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
Add a bus_notifier for AMBA bus device in order to map the device mmio regions when DOM0 booting with ACPI.
--- drivers/xen/Makefile | 1 + drivers/xen/amba.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 100 insertions(+) create mode 100644 drivers/xen/amba.c
drivers/xen/Makefile +1 -0
@@ -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)
drivers/xen/amba.c new file +99 -0
99 lines not on this page · raw message
Signature · 1 line
2.1.0
Re: [PATCH 06/13] Xen: ARM: Add support for mapping amba device mmio
Quoted 52 lines · On Tue, Nov 17, 2015 at 05:57:04PM +0800, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Add a
bus_notifierfor AMBA bus device in order to map the device mmio regions when DOM0 booting with ACPI.Signed-off-by Shannon Zhao <[email protected]>--- drivers/xen/Makefile | 1 + drivers/xen/amba.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 100 insertions(+) create mode 100644 drivers/xen/amba.cdrivers/xen/Makefile +1
-0@@ -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)drivers/xen/amba.c new file +22
-0@@ -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 <[email protected]> +*/ + +#include <linux/amba/bus.h> +#include <linux/acpi.h> +#include <xen/xen.h>
drivers/xen/amba.c line 32
Quoted 10 lines
drivers/xen/amba.c new file +10
-0+#include <xen/interface/memory.h> +#include <asm/xen/hypervisor.h> +#include <asm/xen/hypercall.h> + +static int xen_map_amba_device_mmio (struct amba_device *adev) +{ +int rc =0 ; +struct resource *r = &adev->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.
Quoted 34 lines
drivers/xen/amba.c new file +34
-0+ { +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, &xatp); + +kfree (gpfns); +kfree (idxs); +kfree (errs); +if (rc !=0 ) +return rc; + } + +return rc; +}
drivers/xen/amba.c line 76
Quoted 10 lines
drivers/xen/amba.c new file +10
-0+ +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?
Quoted 31 lines
drivers/xen/amba.c new file +23
-0+if (r) + { +dev_err (&adev->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 (&amba_bustype, &amba_device_nb); +} + +arch_initcall (register_xen_amba_notifier);Signature · 7 lines
2.1.0 _______________________________________________ Xen-devel mailing list [email protected] http://lists.xen.org/xen-devel
PATCH 6/13 Xen: ARM: Add support for mapping amba device mmio
Quoted 59 lines · Konrad Rzeszutek Wilk
Quoted 58 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Add a
bus_notifierfor AMBA bus device in order to map the device mmio regions when DOM0 booting with ACPI.Signed-off-by Shannon Zhao <[email protected]>--- drivers/xen/Makefile | 1 + drivers/xen/amba.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 100 insertions(+) create mode 100644 drivers/xen/amba.cdrivers/xen/Makefile +1
-0@@ -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)drivers/xen/amba.c new file +28
-0@@ -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 <[email protected]> +*/ + +#include <linux/amba/bus.h> +#include <linux/acpi.h> +#include <xen/xen.h> +#include <xen/interface/memory.h> +#include <asm/xen/hypervisor.h> +#include <asm/xen/hypercall.h> + +static int xen_map_amba_device_mmio (struct amba_device *adev) +{
Quoted 9 lines
drivers/xen/amba.c line 32
Quoted 4 lines
drivers/xen/amba.c new file +4
-0+int rc =0 ; +struct resource *r = &adev->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.
Quoted 38 lines
Quoted 38 lines
drivers/xen/amba.c new file +38
-0+ { +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, &xatp); + +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) +{
Quoted 9 lines
drivers/xen/amba.c line 76
Quoted 6 lines
drivers/xen/amba.c new file +6
-0+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,
Signature · 1 line
Shannon
PATCH 6/13 Xen: ARM: Add support for mapping amba device mmio
Quoted 7 lines · Shannon Zhao
Quoted 3 lines
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.
What about the platform device passthrough case?
In anycase, if the AMBA platform provides a removal method, there is harmless to implement it.
Regards,
Signature · 1 line
Julien Grall
PATCH 6/13 Xen: ARM: Add support for mapping amba device mmio
Quoted 11 lines · Julien Grall
Quoted 7 lines · Shannon Zhao
Quoted 3 lines
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.What about the platform device passthrough case?
No, it will add the platform passthrough device at booting step while it's only removed when Dom0 shutdowns unless it supports platform device hot-unplug.
Quoted 3 lines
In anycase, if the AMBA platform provides a removal method, there is harmless to implement it.
Sure, as you said, it's harmless to add.
Thanks,
Signature · 1 line
Shannon
Re: [PATCH 06/13] Xen: ARM: Add support for mapping amba device mmio
In reply to Julien GrallQuoted 11 lines · Julien Grall
Quoted 7 lines · Shannon Zhao
Quoted 3 lines
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.What about the platform device passthrough case?
No, it will add the platform passthrough device at booting step while it's only removed when Dom0 shutdowns unless it supports platform device hot-unplug.
Quoted 3 lines
In anycase, if the AMBA platform provides a removal method, there is harmless to implement it.
Sure, as you said, it's harmless to add.
Thanks,
Signature · 1 line
Shannon
Re: [PATCH 06/13] Xen: ARM: Add support for mapping amba device mmio
In reply to Shannon ZhaoQuoted 7 lines · Shannon Zhao
Quoted 3 lines
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.
What about the platform device passthrough case?
In anycase, if the AMBA platform provides a removal method, there is harmless to implement it.
Regards,
Signature · 1 line
Julien Grall
Re: [PATCH 06/13] Xen: ARM: Add support for mapping amba device mmio
In reply to Konrad Rzeszutek WilkQuoted 59 lines · Konrad Rzeszutek Wilk
Quoted 58 lines · On Tue, Nov 17, 2015 at 05:57:04PM +0800, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Add a
bus_notifierfor AMBA bus device in order to map the device mmio regions when DOM0 booting with ACPI.Signed-off-by Shannon Zhao <[email protected]>--- drivers/xen/Makefile | 1 + drivers/xen/amba.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 100 insertions(+) create mode 100644 drivers/xen/amba.cdrivers/xen/Makefile +1
-0@@ -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)drivers/xen/amba.c new file +28
-0@@ -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 <[email protected]> +*/ + +#include <linux/amba/bus.h> +#include <linux/acpi.h> +#include <xen/xen.h> +#include <xen/interface/memory.h> +#include <asm/xen/hypervisor.h> +#include <asm/xen/hypercall.h> + +static int xen_map_amba_device_mmio (struct amba_device *adev) +{
Quoted 9 lines
drivers/xen/amba.c line 32
Quoted 4 lines
drivers/xen/amba.c new file +4
-0+int rc =0 ; +struct resource *r = &adev->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.
Quoted 38 lines
Quoted 38 lines
drivers/xen/amba.c new file +38
-0+ { +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, &xatp); + +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) +{
Quoted 9 lines
drivers/xen/amba.c line 76
Quoted 6 lines
drivers/xen/amba.c new file +6
-0+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,
Signature · 1 line
Shannon
PATCH 6/13 Xen: ARM: Add support for mapping amba device mmio
In reply to shannon.zhao at linaro.orgQuoted 4 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Add a
bus_notifierfor AMBA bus device in order to map the device mmio regions when DOM0 booting with ACPI.
[...]
drivers/xen/amba.c line 33
Quoted 7 lines
drivers/xen/amba.c new file +7
-0+static int xen_map_amba_device_mmio (struct amba_device *adev) +{ +int rc =0 ; +struct resource *r = &adev->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
Re: [PATCH 06/13] Xen: ARM: Add support for mapping amba device mmio
In reply to shannon.zhao at linaro.orgQuoted 4 lines · On 17/11/15 09:57, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Add a
bus_notifierfor AMBA bus device in order to map the device mmio regions when DOM0 booting with ACPI.
[...]
drivers/xen/amba.c line 33
Quoted 7 lines
drivers/xen/amba.c new file +7
-0+static int xen_map_amba_device_mmio (struct amba_device *adev) +{ +int rc =0 ; +struct resource *r = &adev->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
PATCH 6/13 Xen: ARM: Add support for mapping amba device mmio
In reply to shannon.zhao at linaro.orgQuoted 6 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Add a
bus_notifierfor AMBA bus device in order to map the device mmio regions when DOM0 booting with ACPI.Signed-off-by Shannon Zhao <[email protected]>
Please use scripts/checkpatch.pl to check the coding style
Quoted 58 lines
drivers/xen/Makefile | 1 + drivers/xen/amba.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 100 insertions(+) create mode 100644 drivers/xen/amba.cdrivers/xen/Makefile +1
-0@@ -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)drivers/xen/amba.c new file +35
-0@@ -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 <[email protected]> +*/ + +#include <linux/amba/bus.h> +#include <linux/acpi.h> +#include <xen/xen.h> +#include <xen/interface/memory.h> +#include <asm/xen/hypervisor.h> +#include <asm/xen/hypercall.h> + +static int xen_map_amba_device_mmio (struct amba_device *adev) +{ +int rc =0 ; +struct resource *r = &adev->res; + +if (resource_type (r) ==IORESOURCE_MEM ) + { +int j; +int nr =DIV_ROUND_UP (resource_size (r),PAGE_SIZE );
drivers/xen/amba.c line 45
Quoted 10 lines
drivers/xen/amba.c new file +10
-0+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 ;
same comments as before: use XEN_PFN_DOWN and check for return errors from kmalloc
Quoted 57 lines
drivers/xen/amba.c new file +54
-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, &xatp); + +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 (&adev->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 (&amba_bustype, &amba_device_nb); +} + +arch_initcall (register_xen_amba_notifier);Signature · 1 line
2.1.0
Re: [PATCH 06/13] Xen: ARM: Add support for mapping amba device mmio
In reply to shannon.zhao at linaro.orgQuoted 6 lines · On Tue, 17 Nov 2015, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Add a
bus_notifierfor AMBA bus device in order to map the device mmio regions when DOM0 booting with ACPI.Signed-off-by Shannon Zhao <[email protected]>
Please use scripts/checkpatch.pl to check the coding style
Quoted 58 lines
drivers/xen/Makefile | 1 + drivers/xen/amba.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 100 insertions(+) create mode 100644 drivers/xen/amba.cdrivers/xen/Makefile +1
-0@@ -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)drivers/xen/amba.c new file +35
-0@@ -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 <[email protected]> +*/ + +#include <linux/amba/bus.h> +#include <linux/acpi.h> +#include <xen/xen.h> +#include <xen/interface/memory.h> +#include <asm/xen/hypervisor.h> +#include <asm/xen/hypercall.h> + +static int xen_map_amba_device_mmio (struct amba_device *adev) +{ +int rc =0 ; +struct resource *r = &adev->res; + +if (resource_type (r) ==IORESOURCE_MEM ) + { +int j; +int nr =DIV_ROUND_UP (resource_size (r),PAGE_SIZE );
drivers/xen/amba.c line 45
Quoted 10 lines
drivers/xen/amba.c new file +10
-0+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 ;
same comments as before: use XEN_PFN_DOWN and check for return errors from kmalloc
Quoted 57 lines
drivers/xen/amba.c new file +54
-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, &xatp); + +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 (&adev->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 (&amba_bustype, &amba_device_nb); +} + +arch_initcall (register_xen_amba_notifier);Signature · 1 line
2.1.0
PATCH 6/13 Xen: ARM: Add support for mapping amba device mmio
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
Add a bus_notifier for AMBA bus device in order to map the device mmio regions when DOM0 booting with ACPI.
--- drivers/xen/Makefile | 1 + drivers/xen/amba.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 100 insertions(+) create mode 100644 drivers/xen/amba.c
drivers/xen/Makefile +1 -0
@@ -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)
drivers/xen/amba.c new file +99 -0
99 lines not on this page · raw message
Signature · 1 line
2.1.0
PATCH 7/13 ARM: Xen: Document UEFI support on Xen ARM virtual platforms
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could scan this to get the UEFI information.
--- Documentation/devicetree/bindings/arm/xen.txt | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
Documentation/devicetree/bindings/arm/xen.txt +25 -0
@@ -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 0xb0000000 0 0x20000>; interrupts = <1 15 0xf08>; + uefi { + xen,uefi-system-table = <0xXXXXXXXX>; + xen,uefi-mmap-start = <0xXXXXXXXX>; + xen,uefi-mmap-size = <0xXXXXXXXX>; + xen,uefi-mmap-desc-size = <0xXXXXXXXX>; + xen,uefi-mmap-desc-ver = <0xXXXXXXXX>; + }; };
Signature · 1 line
2.1.0
PATCH 7/13 ARM: Xen: Document UEFI support on Xen ARM virtual platforms
Quoted 4 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could scan this to get the UEFI information.
[...]
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 19
Quoted 8 lines
Documentation/devicetree/bindings/arm/xen.txt +2
-0@@ -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?
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 27
Quoted 7 lines
Documentation/devicetree/bindings/arm/xen.txt +7
-0+________________________________________________________________________________ +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.
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 35
Quoted 8 lines
Documentation/devicetree/bindings/arm/xen.txt +8
-0+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
PATCH 7/13 ARM: Xen: Document UEFI support on Xen ARM virtual platforms
Quoted 18 lines · David Vrabel
Quoted 4 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could scan this to get the UEFI information.
[...]
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 19
Quoted 8 lines
Documentation/devicetree/bindings/arm/xen.txt +2
-0@@ -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.
Quoted 4 lines
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.
Quoted 25 lines
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 27
Quoted 7 lines
Documentation/devicetree/bindings/arm/xen.txt +7
-0+________________________________________________________________________________ +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.
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 35
Quoted 8 lines
Documentation/devicetree/bindings/arm/xen.txt +8
-0+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
.
Signature · 1 line
Shannon
Re: [PATCH 07/13] ARM: Xen: Document UEFI support on Xen ARM virtual platforms
In reply to David VrabelQuoted 18 lines · David Vrabel
Quoted 4 lines · On 17/11/15 09:57, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could scan this to get the UEFI information.
[...]
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 19
Quoted 8 lines
Documentation/devicetree/bindings/arm/xen.txt +2
-0@@ -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.
Quoted 4 lines
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.
Quoted 25 lines
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 27
Quoted 7 lines
Documentation/devicetree/bindings/arm/xen.txt +7
-0+________________________________________________________________________________ +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.
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 35
Quoted 8 lines
Documentation/devicetree/bindings/arm/xen.txt +8
-0+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
.
Signature · 1 line
Shannon
PATCH 7/13 ARM: Xen: Document UEFI support on Xen ARM virtual platforms
In reply to David VrabelQuoted 12 lines · David Vrabel
Quoted 4 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could scan this to get the UEFI information.
[...]
Quoted 6 lines
Documentation/devicetree/bindings/arm/xen.txt +0
-0@@ -15,6 +15,24 @@ the following properties: - interrupts: the interrupt used by Xen to inject event notifications. A GIC node is also required.
Quoted 5 lines
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 19
Quoted 2 lines
Documentation/devicetree/bindings/arm/xen.txt +2
-0+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.
There was a very long discussion about this, see http://marc.info/?l=xen-devel&m=144321258920213
Quoted 27 lines
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?
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 27
Quoted 7 lines
Documentation/devicetree/bindings/arm/xen.txt +7
-0+________________________________________________________________________________ +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.
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 35
Quoted 8 lines
Documentation/devicetree/bindings/arm/xen.txt +8
-0+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
Re: [PATCH 07/13] ARM: Xen: Document UEFI support on Xen ARM virtual platforms
In reply to David VrabelQuoted 12 lines · David Vrabel
Quoted 4 lines · On 17/11/15 09:57, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could scan this to get the UEFI information.
[...]
Quoted 6 lines
Documentation/devicetree/bindings/arm/xen.txt +0
-0@@ -15,6 +15,24 @@ the following properties: - interrupts: the interrupt used by Xen to inject event notifications. A GIC node is also required.
Quoted 5 lines
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 19
Quoted 2 lines
Documentation/devicetree/bindings/arm/xen.txt +2
-0+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.
There was a very long discussion about this, see http://marc.info/?l=xen-devel&m=144321258920213
Quoted 27 lines
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?
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 27
Quoted 7 lines
Documentation/devicetree/bindings/arm/xen.txt +7
-0+________________________________________________________________________________ +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.
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 35
Quoted 8 lines
Documentation/devicetree/bindings/arm/xen.txt +8
-0+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
Re: [PATCH 07/13] ARM: Xen: Document UEFI support on Xen ARM virtual platforms
In reply to shannon.zhao at linaro.orgQuoted 4 lines · On 17/11/15 09:57, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could scan this to get the UEFI information.
[...]
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 19
Quoted 8 lines
Documentation/devicetree/bindings/arm/xen.txt +2
-0@@ -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?
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 27
Quoted 7 lines
Documentation/devicetree/bindings/arm/xen.txt +7
-0+________________________________________________________________________________ +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.
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 35
Quoted 8 lines
Documentation/devicetree/bindings/arm/xen.txt +8
-0+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
Rob Herring
maintainerPATCH 7/13 ARM: Xen: Document UEFI support on Xen ARM virtual platforms
In reply to shannon.zhao at linaro.orgQuoted 26 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- Documentation/devicetree/bindings/arm/xen.txt | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)Documentation/devicetree/bindings/arm/xen.txt +8
-0@@ -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. +--------------------------------------------------------------------------------
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 35
Quoted 10 lines
Documentation/devicetree/bindings/arm/xen.txt +10
-0+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
PATCH 7/13 ARM: Xen: Document UEFI support on Xen ARM virtual platforms
Quoted 32 lines · Rob Herring
Quoted 31 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- Documentation/devicetree/bindings/arm/xen.txt | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)Documentation/devicetree/bindings/arm/xen.txt +13
-0@@ -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. +--------------------------------------------------------------------------------
Quoted 9 lines
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 35
Quoted 5 lines
Documentation/devicetree/bindings/arm/xen.txt +5
-0+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,
Signature · 1 line
Shannon
Re: [PATCH 07/13] ARM: Xen: Document UEFI support on Xen ARM virtual platforms
In reply to Rob HerringQuoted 32 lines · Rob Herring
Quoted 31 lines · On Tue, Nov 17, 2015 at 05:57:05PM +0800, [email protected] wrote:
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- Documentation/devicetree/bindings/arm/xen.txt | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)Documentation/devicetree/bindings/arm/xen.txt +13
-0@@ -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. +--------------------------------------------------------------------------------
Quoted 9 lines
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 35
Quoted 5 lines
Documentation/devicetree/bindings/arm/xen.txt +5
-0+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,
Signature · 1 line
Shannon
Rob Herring
maintainerRe: [PATCH 07/13] ARM: Xen: Document UEFI support on Xen ARM virtual platforms
In reply to shannon.zhao at linaro.orgQuoted 26 lines · On Tue, Nov 17, 2015 at 05:57:05PM +0800, [email protected] wrote:
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- Documentation/devicetree/bindings/arm/xen.txt | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)Documentation/devicetree/bindings/arm/xen.txt +8
-0@@ -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. +--------------------------------------------------------------------------------
Documentation/devicetree/bindings/arm/xen.txt the following properties: · line 35
Quoted 10 lines
Documentation/devicetree/bindings/arm/xen.txt +10
-0+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
PATCH 7/13 ARM: Xen: Document UEFI support on Xen ARM virtual platforms
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could scan this to get the UEFI information.
--- Documentation/devicetree/bindings/arm/xen.txt | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
Documentation/devicetree/bindings/arm/xen.txt +25 -0
@@ -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 0xb0000000 0 0x20000>; interrupts = <1 15 0xf08>; + uefi { + xen,uefi-system-table = <0xXXXXXXXX>; + xen,uefi-mmap-start = <0xXXXXXXXX>; + xen,uefi-mmap-size = <0xXXXXXXXX>; + xen,uefi-mmap-desc-size = <0xXXXXXXXX>; + xen,uefi-mmap-desc-ver = <0xXXXXXXXX>; + }; };
Signature · 1 line
2.1.0
PATCH 8/13 Xen: EFI: Parse DT parameters for Xen specific UEFI
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
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.
--- drivers/firmware/efi/efi.c | 67 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 62 insertions(+), 5 deletions(-)
drivers/firmware/efi/efi.c +62 -5
@@ -24,6 +24,7 @@#include <linux/of_fdt.h> #include <linux/io.h> #include <linux/platform_device.h> +#include <xen/xen.h> 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, + &len); +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, &info); -if (!info.found) +if (xen_initial_domain ()) + ret =of_scan_flat_dt (fdt_find_xen_uefi_params, &info); +else + ret =of_scan_flat_dt (fdt_find_uefi_params, &info); +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; }
Signature · 1 line
2.1.0
PATCH 8/13 Xen: EFI: Parse DT parameters for Xen specific UEFI
Quoted 29 lines · On 17 November 2015 at 10:57, <[email protected]> wrote:
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- drivers/firmware/efi/efi.c | 67 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 62 insertions(+), 5 deletions(-)drivers/firmware/efi/efi.c +4
-0@@ -24,6 +24,7 @@#include <linux/of_fdt.h> #include <linux/io.h> #include <linux/platform_device.h> +#include <xen/xen.h> 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];
drivers/firmware/efi/efi.c static __initdata struct { · line 504
Quoted 10 lines
drivers/firmware/efi/efi.c +10
-0+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.
Quoted 56 lines
drivers/firmware/efi/efi.c +40
-2struct 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, + &len); +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, &info); -if (!info.found) +if (xen_initial_domain ()) + ret =of_scan_flat_dt (fdt_find_xen_uefi_params, &info); +else + ret =of_scan_flat_dt (fdt_find_uefi_params, &info); +if (!info.found) {pr_info ("UEFI not found.\n" );
drivers/firmware/efi/efi.c int __init efi_get_fdt_params(struct efi_fdt_params *params, int verbose) · line 602
Quoted 10 lines
drivers/firmware/efi/efi.c +7
-3-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
Quoted 7 lines
drivers/firmware/efi/efi.c +1
-1+ }return ret; } --2.1.0
Mark Rutland
reviewerPATCH 8/13 Xen: EFI: Parse DT parameters for Xen specific UEFI
Quoted 37 lines · Ard Biesheuvel
Quoted 36 lines · On 17 November 2015 at 10:57, <[email protected]> wrote:
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- drivers/firmware/efi/efi.c | 67 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 62 insertions(+), 5 deletions(-)drivers/firmware/efi/efi.c +11
-0@@ -24,6 +24,7 @@#include <linux/of_fdt.h> #include <linux/io.h> #include <linux/platform_device.h> +#include <xen/xen.h> 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),
Quoted 8 lines
drivers/firmware/efi/efi.c static __initdata struct { · line 504
Quoted 3 lines
drivers/firmware/efi/efi.c +3
-0+ 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.
PATCH 8/13 Xen: EFI: Parse DT parameters for Xen specific UEFI
Quoted 50 lines · Mark Rutland
Quoted 37 lines · Ard Biesheuvel
Quoted 36 lines · On 17 November 2015 at 10:57, <[email protected]> wrote:
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- drivers/firmware/efi/efi.c | 67 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 62 insertions(+), 5 deletions(-)drivers/firmware/efi/efi.c +11
-0@@ -24,6 +24,7 @@#include <linux/of_fdt.h> #include <linux/io.h> #include <linux/platform_device.h> +#include <xen/xen.h> 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),Quoted 8 lines
drivers/firmware/efi/efi.c static __initdata struct { · line 504
Quoted 3 lines
drivers/firmware/efi/efi.c +3
-0+ 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.
Quoted 8 lines
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()
PATCH 8/13 Xen: EFI: Parse DT parameters for Xen specific UEFI
Quoted 54 lines · Ard Biesheuvel
Quoted 53 lines · Mark Rutland
Quoted 37 lines · Ard Biesheuvel
Quoted 36 lines · On 17 November 2015 at 10:57, <[email protected]> wrote:
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- drivers/firmware/efi/efi.c | 67 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 62 insertions(+), 5 deletions(-)drivers/firmware/efi/efi.c +11
-0@@ -24,6 +24,7 @@#include <linux/of_fdt.h> #include <linux/io.h> #include <linux/platform_device.h> +#include <xen/xen.h> 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),Quoted 8 lines
drivers/firmware/efi/efi.c static __initdata struct { · line 504
Quoted 3 lines
drivers/firmware/efi/efi.c +3
-0+ 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.
Quoted 8 lines
Quoted 5 lines
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,
Signature · 1 line
Shannon
Re: [PATCH 08/13] Xen: EFI: Parse DT parameters for Xen specific UEFI
In reply to Ard BiesheuvelQuoted 54 lines · Ard Biesheuvel
Quoted 53 lines · Mark Rutland
Quoted 37 lines · Ard Biesheuvel
Quoted 36 lines · On 17 November 2015 at 10:57, <[email protected]> wrote:
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- drivers/firmware/efi/efi.c | 67 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 62 insertions(+), 5 deletions(-)drivers/firmware/efi/efi.c +11
-0@@ -24,6 +24,7 @@#include <linux/of_fdt.h> #include <linux/io.h> #include <linux/platform_device.h> +#include <xen/xen.h> 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),Quoted 8 lines
drivers/firmware/efi/efi.c static __initdata struct { · line 504
Quoted 3 lines
drivers/firmware/efi/efi.c +3
-0+ 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.
Quoted 8 lines
Quoted 5 lines
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,
Signature · 1 line
Shannon
Re: [PATCH 08/13] Xen: EFI: Parse DT parameters for Xen specific UEFI
In reply to Mark RutlandQuoted 50 lines · Mark Rutland
Quoted 37 lines · Ard Biesheuvel
Quoted 36 lines · On 17 November 2015 at 10:57, <[email protected]> wrote:
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- drivers/firmware/efi/efi.c | 67 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 62 insertions(+), 5 deletions(-)drivers/firmware/efi/efi.c +11
-0@@ -24,6 +24,7 @@#include <linux/of_fdt.h> #include <linux/io.h> #include <linux/platform_device.h> +#include <xen/xen.h> 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),Quoted 8 lines
drivers/firmware/efi/efi.c static __initdata struct { · line 504
Quoted 3 lines
drivers/firmware/efi/efi.c +3
-0+ 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.
Quoted 8 lines
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()
Mark Rutland
reviewerRe: [PATCH 08/13] Xen: EFI: Parse DT parameters for Xen specific UEFI
In reply to Ard BiesheuvelQuoted 37 lines · Ard Biesheuvel
Quoted 36 lines · On 17 November 2015 at 10:57, <[email protected]> wrote:
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- drivers/firmware/efi/efi.c | 67 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 62 insertions(+), 5 deletions(-)drivers/firmware/efi/efi.c +11
-0@@ -24,6 +24,7 @@#include <linux/of_fdt.h> #include <linux/io.h> #include <linux/platform_device.h> +#include <xen/xen.h> 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),
Quoted 8 lines
drivers/firmware/efi/efi.c static __initdata struct { · line 504
Quoted 3 lines
drivers/firmware/efi/efi.c +3
-0+ 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.
Re: [PATCH 08/13] Xen: EFI: Parse DT parameters for Xen specific UEFI
In reply to shannon.zhao at linaro.orgQuoted 29 lines · On 17 November 2015 at 10:57, <[email protected]> wrote:
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- drivers/firmware/efi/efi.c | 67 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 62 insertions(+), 5 deletions(-)drivers/firmware/efi/efi.c +4
-0@@ -24,6 +24,7 @@#include <linux/of_fdt.h> #include <linux/io.h> #include <linux/platform_device.h> +#include <xen/xen.h> 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];
drivers/firmware/efi/efi.c static __initdata struct { · line 504
Quoted 10 lines
drivers/firmware/efi/efi.c +10
-0+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.
Quoted 56 lines
drivers/firmware/efi/efi.c +40
-2struct 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, + &len); +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, &info); -if (!info.found) +if (xen_initial_domain ()) + ret =of_scan_flat_dt (fdt_find_xen_uefi_params, &info); +else + ret =of_scan_flat_dt (fdt_find_uefi_params, &info); +if (!info.found) {pr_info ("UEFI not found.\n" );
drivers/firmware/efi/efi.c int __init efi_get_fdt_params(struct efi_fdt_params *params, int verbose) · line 602
Quoted 10 lines
drivers/firmware/efi/efi.c +7
-3-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
Quoted 7 lines
drivers/firmware/efi/efi.c +1
-1+ }return ret; } --2.1.0
PATCH 8/13 Xen: EFI: Parse DT parameters for Xen specific UEFI
In reply to shannon.zhao at linaro.orgQuoted 95 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- drivers/firmware/efi/efi.c | 67 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 62 insertions(+), 5 deletions(-)drivers/firmware/efi/efi.c +54
-2@@ -24,6 +24,7 @@#include <linux/of_fdt.h> #include <linux/io.h> #include <linux/platform_device.h> +#include <xen/xen.h> 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, + &len); +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, &info); -if (!info.found) +if (xen_initial_domain ()) + ret =of_scan_flat_dt (fdt_find_xen_uefi_params, &info); +else + ret =of_scan_flat_dt (fdt_find_uefi_params, &info); +if (!info.found) {pr_info ("UEFI not found.\n" );
drivers/firmware/efi/efi.c int __init efi_get_fdt_params(struct efi_fdt_params *params, int verbose) · line 602
Quoted 10 lines
drivers/firmware/efi/efi.c +7
-3-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);
xen_dt_params is obviously wrong here
Re: [PATCH 08/13] Xen: EFI: Parse DT parameters for Xen specific UEFI
In reply to shannon.zhao at linaro.orgQuoted 95 lines · On Tue, 17 Nov 2015, [email protected] wrote:
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- drivers/firmware/efi/efi.c | 67 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 62 insertions(+), 5 deletions(-)drivers/firmware/efi/efi.c +54
-2@@ -24,6 +24,7 @@#include <linux/of_fdt.h> #include <linux/io.h> #include <linux/platform_device.h> +#include <xen/xen.h> 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, + &len); +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, &info); -if (!info.found) +if (xen_initial_domain ()) + ret =of_scan_flat_dt (fdt_find_xen_uefi_params, &info); +else + ret =of_scan_flat_dt (fdt_find_uefi_params, &info); +if (!info.found) {pr_info ("UEFI not found.\n" );
drivers/firmware/efi/efi.c int __init efi_get_fdt_params(struct efi_fdt_params *params, int verbose) · line 602
Quoted 10 lines
drivers/firmware/efi/efi.c +7
-3-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);
xen_dt_params is obviously wrong here
PATCH 8/13 Xen: EFI: Parse DT parameters for Xen specific UEFI
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
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.
--- drivers/firmware/efi/efi.c | 67 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 62 insertions(+), 5 deletions(-)
drivers/firmware/efi/efi.c +62 -5
@@ -24,6 +24,7 @@#include <linux/of_fdt.h> #include <linux/io.h> #include <linux/platform_device.h> +#include <xen/xen.h> 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, + &len); +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, &info); -if (!info.found) +if (xen_initial_domain ()) + ret =of_scan_flat_dt (fdt_find_xen_uefi_params, &info); +else + ret =of_scan_flat_dt (fdt_find_uefi_params, &info); +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; }
Signature · 1 line
2.1.0
PATCH 9/13 ARM: Xen: Initialize Xen specific UEFI runtime services
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
When running on Xen hypervisor, runtime services are supported through hypercall. So call Xen specific function to initialize runtime services.
--- 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(-)
arch/arm/include/asm/xen/hypercall.h +1 -0
@@ -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)
arch/arm/xen/enlighten.c +1 -0
@@ -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);
arch/arm/xen/hypercall.S +1 -0
@@ -90,6 +90,7 @@ HYPERCALL2(physdev_op); HYPERCALL3(vcpu_op); HYPERCALL1(tmem_op); HYPERCALL2(multicall); +HYPERCALL1(dom0_op); ENTRY(privcmd_call) stmdb sp!, {r4}
arch/arm64/kernel/efi.c +14 -6
@@ -34,6 +34,9 @@#include <asm/mmu.h> #include <asm/pgtable.h> +#include <xen/xen.h> +#include <xen/xen-ops.h> +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 , &efi.flags); -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.flags); efi.runtime_version = efi.systab->hdr.revision;
arch/arm64/xen/hypercall.S +1 -0
@@ -81,6 +81,7 @@ HYPERCALL2(physdev_op); HYPERCALL3(vcpu_op); HYPERCALL1(tmem_op); HYPERCALL2(multicall); +HYPERCALL1(dom0_op); ENTRY(privcmd_call) mov x16, x0
drivers/xen/Kconfig +1 -1
@@ -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
drivers/xen/efi.c +22 -0
@@ -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_x86static 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; + efi.set_wakeup_time = xen_efi_set_wakeup_time; + efi.get_variable = xen_efi_get_variable; + efi.get_next_variable = xen_efi_get_next_variable; + efi.set_variable = xen_efi_set_variable; + efi.query_variable_info = xen_efi_query_variable_info; + efi.update_capsule = xen_efi_update_capsule; + efi.query_capsule_caps = xen_efi_query_capsule_caps; + efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count; +} +#endif + +#ifdef CONFIG_X86 efi_system_table_t __init *xen_efi_probe (void ) { struct xen_platform_op op = {
@@ -369,3 +390,4 @@ efi_system_table_t __init *xen_efi_probe(void) return &efi_systab_xen; } +#endif
include/xen/xen-ops.h +10 -0
@@ -84,13 +84,23 @@ int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,bool xen_running_on_version_or_later (unsigned int major,unsigned int minor);#ifdef CONFIG_XEN_EFI +#ifdef CONFIG_X86 extern efi_system_table_t *xen_efi_probe (void ); +#endif +#ifdef CONFIG_ARM64 +extern void xen_efi_runtime_setup (void ); +#endif #else +#ifdef CONFIG_X86 static inline efi_system_table_t __init *xen_efi_probe (void ) {return NULL ; }#endif +#ifdef CONFIG_ARM64 +static inline void xen_efi_runtime_setup (void ) { } +#endif +#endif #ifdef CONFIG_PREEMPT
Signature · 1 line
2.1.0
PATCH 9/13 ARM: Xen: Initialize Xen specific UEFI runtime services
Quoted 68 lines · On 17 November 2015 at 10:57, <[email protected]> wrote:
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- 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(-)arch/arm/include/asm/xen/hypercall.h +1
-0@@ -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)arch/arm/xen/enlighten.c +1
-0@@ -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);arch/arm/xen/hypercall.S +1
-0@@ -90,6 +90,7 @@ HYPERCALL2(physdev_op); HYPERCALL3(vcpu_op); HYPERCALL1(tmem_op); HYPERCALL2(multicall); +HYPERCALL1(dom0_op); ENTRY(privcmd_call) stmdb sp!, {r4}arch/arm64/kernel/efi.c +3
-0@@ -34,6 +34,9 @@#include <asm/mmu.h> #include <asm/pgtable.h> +#include <xen/xen.h> +#include <xen/xen-ops.h> +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 , &efi.flags);
arch/arm64/kernel/efi.c static int __init arm64_enable_runtime_services(void) · line 319
Quoted 10 lines
arch/arm64/kernel/efi.c +5
-4-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.
Quoted 119 lines
arch/arm64/kernel/efi.c +6
-2-/* 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.flags); efi.runtime_version = efi.systab->hdr.revision;arch/arm64/xen/hypercall.S +1
-0@@ -81,6 +81,7 @@ HYPERCALL2(physdev_op); HYPERCALL3(vcpu_op); HYPERCALL1(tmem_op); HYPERCALL2(multicall); +HYPERCALL1(dom0_op); ENTRY(privcmd_call) mov x16, x0drivers/xen/Kconfig +1
-1@@ -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 ydrivers/xen/efi.c +22
-0@@ -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_x86static 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; + efi.set_wakeup_time = xen_efi_set_wakeup_time; + efi.get_variable = xen_efi_get_variable; + efi.get_next_variable = xen_efi_get_next_variable; + efi.set_variable = xen_efi_set_variable; + efi.query_variable_info = xen_efi_query_variable_info; + efi.update_capsule = xen_efi_update_capsule; + efi.query_capsule_caps = xen_efi_query_capsule_caps; + efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count; +} +#endif + +#ifdef CONFIG_X86 efi_system_table_t __init *xen_efi_probe (void ) { struct xen_platform_op op = {@@ -369,3 +390,4 @@ efi_system_table_t __init *xen_efi_probe(void) return &efi_systab_xen; } +#endif include/xen/xen-ops.h +10
-1@@ -84,13 +84,23 @@ int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,bool xen_running_on_version_or_later (unsigned int major,unsigned int minor);#ifdef CONFIG_XEN_EFI +#ifdef CONFIG_X86 extern efi_system_table_t *xen_efi_probe (void ); +#endif +#ifdef CONFIG_ARM64 +extern void xen_efi_runtime_setup (void ); +#endif #else +#ifdef CONFIG_X86 static inline efi_system_table_t __init *xen_efi_probe (void ) {return NULL ; }#endif +#ifdef CONFIG_ARM64 +static inline void xen_efi_runtime_setup (void ) { } +#endif +#endif #ifdef CONFIG_PREEMPT --2.1.0
PATCH 9/13 ARM: Xen: Initialize Xen specific UEFI runtime services
Quoted 14 lines · Ard Biesheuvel
Quoted 4 lines
(quoted diff) +0
-0@@ -308,13 +311,18 @@ static int __init arm64_enable_runtime_services(void) > } > set_bit(EFI_SYSTEM_TABLES, &efi.flags);Quoted 1 line
Quoted 10 lines
arch/arm64/kernel/efi.c static int __init arm64_enable_runtime_services(void) · line 318
Quoted 10 lines
arch/arm64/kernel/efi.c +5
-4-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 ; + }
Quoted 8 lines
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_PARAVIRTflag, 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.
Signature · 1 line
Shannon
Re: [PATCH 09/13] ARM: Xen: Initialize Xen specific UEFI runtime services
In reply to shannon.zhao at linaro.orgQuoted 68 lines · On 17 November 2015 at 10:57, <[email protected]> wrote:
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- 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(-)arch/arm/include/asm/xen/hypercall.h +1
-0@@ -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)arch/arm/xen/enlighten.c +1
-0@@ -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);arch/arm/xen/hypercall.S +1
-0@@ -90,6 +90,7 @@ HYPERCALL2(physdev_op); HYPERCALL3(vcpu_op); HYPERCALL1(tmem_op); HYPERCALL2(multicall); +HYPERCALL1(dom0_op); ENTRY(privcmd_call) stmdb sp!, {r4}arch/arm64/kernel/efi.c +3
-0@@ -34,6 +34,9 @@#include <asm/mmu.h> #include <asm/pgtable.h> +#include <xen/xen.h> +#include <xen/xen-ops.h> +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 , &efi.flags);
arch/arm64/kernel/efi.c static int __init arm64_enable_runtime_services(void) · line 319
Quoted 10 lines
arch/arm64/kernel/efi.c +5
-4-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.
Quoted 119 lines
arch/arm64/kernel/efi.c +6
-2-/* 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.flags); efi.runtime_version = efi.systab->hdr.revision;arch/arm64/xen/hypercall.S +1
-0@@ -81,6 +81,7 @@ HYPERCALL2(physdev_op); HYPERCALL3(vcpu_op); HYPERCALL1(tmem_op); HYPERCALL2(multicall); +HYPERCALL1(dom0_op); ENTRY(privcmd_call) mov x16, x0drivers/xen/Kconfig +1
-1@@ -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 ydrivers/xen/efi.c +22
-0@@ -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_x86static 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; + efi.set_wakeup_time = xen_efi_set_wakeup_time; + efi.get_variable = xen_efi_get_variable; + efi.get_next_variable = xen_efi_get_next_variable; + efi.set_variable = xen_efi_set_variable; + efi.query_variable_info = xen_efi_query_variable_info; + efi.update_capsule = xen_efi_update_capsule; + efi.query_capsule_caps = xen_efi_query_capsule_caps; + efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count; +} +#endif + +#ifdef CONFIG_X86 efi_system_table_t __init *xen_efi_probe (void ) { struct xen_platform_op op = {@@ -369,3 +390,4 @@ efi_system_table_t __init *xen_efi_probe(void) return &efi_systab_xen; } +#endif include/xen/xen-ops.h +10
-1@@ -84,13 +84,23 @@ int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,bool xen_running_on_version_or_later (unsigned int major,unsigned int minor);#ifdef CONFIG_XEN_EFI +#ifdef CONFIG_X86 extern efi_system_table_t *xen_efi_probe (void ); +#endif +#ifdef CONFIG_ARM64 +extern void xen_efi_runtime_setup (void ); +#endif #else +#ifdef CONFIG_X86 static inline efi_system_table_t __init *xen_efi_probe (void ) {return NULL ; }#endif +#ifdef CONFIG_ARM64 +static inline void xen_efi_runtime_setup (void ) { } +#endif +#endif #ifdef CONFIG_PREEMPT --2.1.0
PATCH 9/13 ARM: Xen: Initialize Xen specific UEFI runtime services
In reply to shannon.zhao at linaro.orgQuoted 6 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
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 <[email protected]>
You can drop the dom0_op part of the patch and based on top of
http://marc.info/?l=xen-devel&m=144802905409775&w=2
Quoted 99 lines
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(-)arch/arm/include/asm/xen/hypercall.h +1
-0@@ -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)arch/arm/xen/enlighten.c +1
-0@@ -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);arch/arm/xen/hypercall.S +1
-0@@ -90,6 +90,7 @@ HYPERCALL2(physdev_op); HYPERCALL3(vcpu_op); HYPERCALL1(tmem_op); HYPERCALL2(multicall); +HYPERCALL1(dom0_op); ENTRY(privcmd_call) stmdb sp!, {r4}arch/arm64/kernel/efi.c +14
-6@@ -34,6 +34,9 @@#include <asm/mmu.h> #include <asm/pgtable.h> +#include <xen/xen.h> +#include <xen/xen-ops.h> +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 , &efi.flags); -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.flags); efi.runtime_version = efi.systab->hdr.revision;arch/arm64/xen/hypercall.S +1
-0@@ -81,6 +81,7 @@ HYPERCALL2(physdev_op); HYPERCALL3(vcpu_op); HYPERCALL1(tmem_op); HYPERCALL2(multicall); +HYPERCALL1(dom0_op); ENTRY(privcmd_call) mov x16, x0drivers/xen/Kconfig +0
-0
drivers/xen/Kconfig config XEN_HAVE_PVMMU · line 271
Quoted 5 lines
drivers/xen/Kconfig +1
-1@@ -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
Please use brackets
drivers/xen/efi.c line 38
Quoted 13 lines
drivers/xen/Kconfig +0
-0config XEN_AUTO_XLATE def_bool ydrivers/xen/efi.c +1
-0@@ -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}
This change won't be needed anymore if you rebase on
Quoted 36 lines
drivers/xen/efi.c +20
-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_x86static 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; + efi.set_wakeup_time = xen_efi_set_wakeup_time; + efi.get_variable = xen_efi_get_variable; + efi.get_next_variable = xen_efi_get_next_variable; + efi.set_variable = xen_efi_set_variable; + efi.query_variable_info = xen_efi_query_variable_info; + efi.update_capsule = xen_efi_update_capsule; + efi.query_capsule_caps = xen_efi_query_capsule_caps; + efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count; +} +#endif + +#ifdef CONFIG_X86 efi_system_table_t __init *xen_efi_probe (void ) { struct xen_platform_op op = {
drivers/xen/efi.c efi_system_table_t __init *xen_efi_probe(void) · line 393
Quoted 4 lines
drivers/xen/efi.c +1
-0@@ -369,3 +390,4 @@ efi_system_table_t __init *xen_efi_probe(void) return &efi_systab_xen; } +#endif
Instead of using #ifdef's I would move the x86 specific code into arch/x86/xen/efi.c. In particular xen_efi_probe, efi_xen, and efi_systab_xen. I think it is OK for the initialization to be arch specific.
Quoted 17 lines
include/xen/xen-ops.h +6
-0@@ -84,13 +84,23 @@ int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,bool xen_running_on_version_or_later (unsigned int major,unsigned int minor);#ifdef CONFIG_XEN_EFI +#ifdef CONFIG_X86 extern efi_system_table_t *xen_efi_probe (void ); +#endif +#ifdef CONFIG_ARM64 +extern void xen_efi_runtime_setup (void ); +#endif #else +#ifdef CONFIG_X86 static inline efi_system_table_t __init *xen_efi_probe (void )
include/xen/xen-ops.h int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma, · line 105
Quoted 10 lines
include/xen/xen-ops.h +4
-0{return NULL ; }#endif +#ifdef CONFIG_ARM64 +static inline void xen_efi_runtime_setup (void ) { } +#endif +#endif #ifdef CONFIG_PREEMPT
I would get rid of this mess and instead I would export the functions defined in drivers/xen/efi.c. Then I would use them in arch/{arm,x86}/xen/efi.c.
Re: [PATCH 09/13] ARM: Xen: Initialize Xen specific UEFI runtime services
In reply to shannon.zhao at linaro.orgQuoted 6 lines · On Tue, 17 Nov 2015, [email protected] wrote:
From: Shannon Zhao <[email protected]>
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 <[email protected]>
You can drop the dom0_op part of the patch and based on top of
http://marc.info/?l=xen-devel&m=144802905409775&w=2
Quoted 99 lines
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(-)arch/arm/include/asm/xen/hypercall.h +1
-0@@ -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)arch/arm/xen/enlighten.c +1
-0@@ -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);arch/arm/xen/hypercall.S +1
-0@@ -90,6 +90,7 @@ HYPERCALL2(physdev_op); HYPERCALL3(vcpu_op); HYPERCALL1(tmem_op); HYPERCALL2(multicall); +HYPERCALL1(dom0_op); ENTRY(privcmd_call) stmdb sp!, {r4}arch/arm64/kernel/efi.c +14
-6@@ -34,6 +34,9 @@#include <asm/mmu.h> #include <asm/pgtable.h> +#include <xen/xen.h> +#include <xen/xen-ops.h> +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 , &efi.flags); -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.flags); efi.runtime_version = efi.systab->hdr.revision;arch/arm64/xen/hypercall.S +1
-0@@ -81,6 +81,7 @@ HYPERCALL2(physdev_op); HYPERCALL3(vcpu_op); HYPERCALL1(tmem_op); HYPERCALL2(multicall); +HYPERCALL1(dom0_op); ENTRY(privcmd_call) mov x16, x0drivers/xen/Kconfig +0
-0
drivers/xen/Kconfig config XEN_HAVE_PVMMU · line 271
Quoted 5 lines
drivers/xen/Kconfig +1
-1@@ -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
Please use brackets
drivers/xen/efi.c line 38
Quoted 13 lines
drivers/xen/Kconfig +0
-0config XEN_AUTO_XLATE def_bool ydrivers/xen/efi.c +1
-0@@ -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}
This change won't be needed anymore if you rebase on
Quoted 36 lines
drivers/xen/efi.c +20
-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_x86static 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; + efi.set_wakeup_time = xen_efi_set_wakeup_time; + efi.get_variable = xen_efi_get_variable; + efi.get_next_variable = xen_efi_get_next_variable; + efi.set_variable = xen_efi_set_variable; + efi.query_variable_info = xen_efi_query_variable_info; + efi.update_capsule = xen_efi_update_capsule; + efi.query_capsule_caps = xen_efi_query_capsule_caps; + efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count; +} +#endif + +#ifdef CONFIG_X86 efi_system_table_t __init *xen_efi_probe (void ) { struct xen_platform_op op = {
drivers/xen/efi.c efi_system_table_t __init *xen_efi_probe(void) · line 393
Quoted 4 lines
drivers/xen/efi.c +1
-0@@ -369,3 +390,4 @@ efi_system_table_t __init *xen_efi_probe(void) return &efi_systab_xen; } +#endif
Instead of using #ifdef's I would move the x86 specific code into arch/x86/xen/efi.c. In particular xen_efi_probe, efi_xen, and efi_systab_xen. I think it is OK for the initialization to be arch specific.
Quoted 17 lines
include/xen/xen-ops.h +6
-0@@ -84,13 +84,23 @@ int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,bool xen_running_on_version_or_later (unsigned int major,unsigned int minor);#ifdef CONFIG_XEN_EFI +#ifdef CONFIG_X86 extern efi_system_table_t *xen_efi_probe (void ); +#endif +#ifdef CONFIG_ARM64 +extern void xen_efi_runtime_setup (void ); +#endif #else +#ifdef CONFIG_X86 static inline efi_system_table_t __init *xen_efi_probe (void )
include/xen/xen-ops.h int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma, · line 105
Quoted 10 lines
include/xen/xen-ops.h +4
-0{return NULL ; }#endif +#ifdef CONFIG_ARM64 +static inline void xen_efi_runtime_setup (void ) { } +#endif +#endif #ifdef CONFIG_PREEMPT
I would get rid of this mess and instead I would export the functions defined in drivers/xen/efi.c. Then I would use them in arch/{arm,x86}/xen/efi.c.
PATCH 9/13 ARM: Xen: Initialize Xen specific UEFI runtime services
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
When running on Xen hypervisor, runtime services are supported through hypercall. So call Xen specific function to initialize runtime services.
--- 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(-)
arch/arm/include/asm/xen/hypercall.h +1 -0
@@ -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)
arch/arm/xen/enlighten.c +1 -0
@@ -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);
arch/arm/xen/hypercall.S +1 -0
@@ -90,6 +90,7 @@ HYPERCALL2(physdev_op); HYPERCALL3(vcpu_op); HYPERCALL1(tmem_op); HYPERCALL2(multicall); +HYPERCALL1(dom0_op); ENTRY(privcmd_call) stmdb sp!, {r4}
arch/arm64/kernel/efi.c +14 -6
@@ -34,6 +34,9 @@#include <asm/mmu.h> #include <asm/pgtable.h> +#include <xen/xen.h> +#include <xen/xen-ops.h> +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 , &efi.flags); -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.flags); efi.runtime_version = efi.systab->hdr.revision;
arch/arm64/xen/hypercall.S +1 -0
@@ -81,6 +81,7 @@ HYPERCALL2(physdev_op); HYPERCALL3(vcpu_op); HYPERCALL1(tmem_op); HYPERCALL2(multicall); +HYPERCALL1(dom0_op); ENTRY(privcmd_call) mov x16, x0
drivers/xen/Kconfig +1 -1
@@ -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
drivers/xen/efi.c +22 -0
@@ -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_x86static 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; + efi.set_wakeup_time = xen_efi_set_wakeup_time; + efi.get_variable = xen_efi_get_variable; + efi.get_next_variable = xen_efi_get_next_variable; + efi.set_variable = xen_efi_set_variable; + efi.query_variable_info = xen_efi_query_variable_info; + efi.update_capsule = xen_efi_update_capsule; + efi.query_capsule_caps = xen_efi_query_capsule_caps; + efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count; +} +#endif + +#ifdef CONFIG_X86 efi_system_table_t __init *xen_efi_probe (void ) { struct xen_platform_op op = {
@@ -369,3 +390,4 @@ efi_system_table_t __init *xen_efi_probe(void) return &efi_systab_xen; } +#endif
include/xen/xen-ops.h +10 -0
@@ -84,13 +84,23 @@ int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,bool xen_running_on_version_or_later (unsigned int major,unsigned int minor);#ifdef CONFIG_XEN_EFI +#ifdef CONFIG_X86 extern efi_system_table_t *xen_efi_probe (void ); +#endif +#ifdef CONFIG_ARM64 +extern void xen_efi_runtime_setup (void ); +#endif #else +#ifdef CONFIG_X86 static inline efi_system_table_t __init *xen_efi_probe (void ) {return NULL ; }#endif +#ifdef CONFIG_ARM64 +static inline void xen_efi_runtime_setup (void ) { } +#endif +#endif #ifdef CONFIG_PREEMPT
Signature · 1 line
2.1.0
PATCH 10/13 ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
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.
--- arch/arm64/kernel/acpi.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
arch/arm64/kernel/acpi.c +8 -4
@@ -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 )))
Signature · 1 line
2.1.0
PATCH 10/13 ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
Quoted 15 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- arch/arm64/kernel/acpi.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)arch/arm64/kernel/acpi.c +0
-0
arch/arm64/kernel/acpi.c static int __init dt_scan_depth1_nodes(unsigned long node, · line 66
Quoted 6 lines
arch/arm64/kernel/acpi.c +2
-1@@ -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.
* not the /chosen node, or /hypervisor node when running on Xen.
arch/arm64/kernel/acpi.c static int __init dt_scan_depth1_nodes(unsigned long node, · line 70
Quoted 5 lines
arch/arm64/kernel/acpi.c +2
-1*/ if (depth ==1 && (strcmp (uname,"chosen" ) !=0 )) -return 1 ; +if (!xen_initial_domain () || (strcmp (uname,"hypervisor" ) !=0 )) +return 1 ;
Please add { } around the inner if statement.
arch/arm64/kernel/acpi.c void __init acpi_boot_table_init(void) · line 187
Quoted 12 lines
arch/arm64/kernel/acpi.c +3
-2return 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)
the device tree is not empty (it has more than just a /chosen node, and an /hypervisor node when running on Xen
Quoted 6 lines
arch/arm64/kernel/acpi.c +0
-0*/ if (param_acpi_off || (!param_acpi_force &&of_scan_flat_dt (dt_scan_depth1_nodes,NULL )))Signature · 1 line
2.1.0
Re: [PATCH 10/13] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
In reply to shannon.zhao at linaro.orgQuoted 15 lines · On Tue, 17 Nov 2015, [email protected] wrote:
From: Shannon Zhao <[email protected]>
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 <[email protected]>--- arch/arm64/kernel/acpi.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)arch/arm64/kernel/acpi.c +0
-0
arch/arm64/kernel/acpi.c static int __init dt_scan_depth1_nodes(unsigned long node, · line 66
Quoted 6 lines
arch/arm64/kernel/acpi.c +2
-1@@ -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.
* not the /chosen node, or /hypervisor node when running on Xen.
arch/arm64/kernel/acpi.c static int __init dt_scan_depth1_nodes(unsigned long node, · line 70
Quoted 5 lines
arch/arm64/kernel/acpi.c +2
-1*/ if (depth ==1 && (strcmp (uname,"chosen" ) !=0 )) -return 1 ; +if (!xen_initial_domain () || (strcmp (uname,"hypervisor" ) !=0 )) +return 1 ;
Please add { } around the inner if statement.
arch/arm64/kernel/acpi.c void __init acpi_boot_table_init(void) · line 187
Quoted 12 lines
arch/arm64/kernel/acpi.c +3
-2return 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)
the device tree is not empty (it has more than just a /chosen node, and an /hypervisor node when running on Xen
Quoted 6 lines
arch/arm64/kernel/acpi.c +0
-0*/ if (param_acpi_off || (!param_acpi_force &&of_scan_flat_dt (dt_scan_depth1_nodes,NULL )))Signature · 1 line
2.1.0
PATCH 10/13 ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
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.
--- arch/arm64/kernel/acpi.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
arch/arm64/kernel/acpi.c +8 -4
@@ -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 )))
Signature · 1 line
2.1.0
PATCH 11/13 xen/hvm/params: Add a new dilivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
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).
--- include/xen/interface/hvm/params.h | 5 +++++ 1 file changed, 5 insertions(+)
include/xen/interface/hvm/params.h +5 -0
@@ -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
Signature · 1 line
2.1.0
PATCH 11/13 xen/hvm/params: Add a new dilivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
Quoted 3 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Add a new dilivery type:
delivery
Quoted 28 lines
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 <[email protected]>--- include/xen/interface/hvm/params.h | 5 +++++ 1 file changed, 5 insertions(+)include/xen/interface/hvm/params.h +5
-0@@ -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 0Signature · 1 line
2.1.0
PATCH 11/13 xen/hvm/params: Add a new dilivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
Quoted 15 lines · Stefano Stabellini
Quoted 3 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Add a new dilivery type:
delivery
Quoted 9 lines
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 <[email protected]>--- include/xen/interface/hvm/params.h | 5 +++++ 1 file changed, 5 insertions(+)
Quoted 16 lines
Quoted 6 lines
include/xen/interface/hvm/params.h +0
-0@@ -34,6 +34,11 @@* Domain = val[47:32], Bus = val[31:16], include/xen/interface/hvm/params.h line 44
Quoted 10 lines
include/xen/interface/hvm/params.h +5
-0* 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
Sadly NACK in this form.
This is not your fault, but this particular field has hidden ABI which the original submitter neglected to put into public API.
Bits 63:56 of this field currently have a hidden ABI with:
xen/include/asm-x86/hvm/irq.h
enum {
HVMIRQ_callback_none,
HVMIRQ_callback_gsi,
HVMIRQ_callback_pci_intx,
HVMIRQ_callback_vector
} callback_via_type;
I will submit a patch to fix this this properly.
~Andrew
PATCH 11/13 xen/hvm/params: Add a new dilivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
Quoted 40 lines · Andrew Cooper
Quoted 15 lines · Stefano Stabellini
Quoted 3 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Add a new dilivery type:
delivery
Quoted 9 lines
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 <[email protected]>--- include/xen/interface/hvm/params.h | 5 +++++ 1 file changed, 5 insertions(+)Quoted 16 lines
Quoted 6 lines
include/xen/interface/hvm/params.h +0
-0@@ -34,6 +34,11 @@* Domain = val[47:32], Bus = val[31:16], include/xen/interface/hvm/params.h line 44
Quoted 10 lines
include/xen/interface/hvm/params.h +5
-0* 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 0Sadly NACK in this form.
This is not your fault, but this particular field has hidden ABI which the original submitter neglected to put into public API.
Bits 63:56 of this field currently have a hidden ABI with:
Quoted 7 lines
xen/include/asm-x86/hvm/irq.h
enum {
HVMIRQ_callback_none,
HVMIRQ_callback_gsi,
HVMIRQ_callback_pci_intx,
HVMIRQ_callback_vector
}callback_via_type;
I take the value should be "4" then?
Quoted 1 line
I will submit a patch to fix this this properly.
Re: [PATCH 11/13] xen/hvm/params: Add a new dilivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
In reply to Andrew CooperQuoted 40 lines · Andrew Cooper
Quoted 15 lines · Stefano Stabellini
Quoted 3 lines · On Tue, 17 Nov 2015, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Add a new dilivery type:
delivery
Quoted 9 lines
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 <[email protected]>--- include/xen/interface/hvm/params.h | 5 +++++ 1 file changed, 5 insertions(+)Quoted 16 lines
Quoted 6 lines
include/xen/interface/hvm/params.h +0
-0@@ -34,6 +34,11 @@* Domain = val[47:32], Bus = val[31:16], include/xen/interface/hvm/params.h line 44
Quoted 10 lines
include/xen/interface/hvm/params.h +5
-0* 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 0Sadly NACK in this form.
This is not your fault, but this particular field has hidden ABI which the original submitter neglected to put into public API.
Bits 63:56 of this field currently have a hidden ABI with:
Quoted 7 lines
xen/include/asm-x86/hvm/irq.h
enum {
HVMIRQ_callback_none,
HVMIRQ_callback_gsi,
HVMIRQ_callback_pci_intx,
HVMIRQ_callback_vector
}callback_via_type;
I take the value should be "4" then?
Quoted 1 line
I will submit a patch to fix this this properly.
Re: [PATCH 11/13] xen/hvm/params: Add a new dilivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
In reply to Stefano StabelliniQuoted 15 lines · Stefano Stabellini
Quoted 3 lines · On Tue, 17 Nov 2015, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Add a new dilivery type:
delivery
Quoted 9 lines
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 <[email protected]>--- include/xen/interface/hvm/params.h | 5 +++++ 1 file changed, 5 insertions(+)
Quoted 16 lines
Quoted 6 lines
include/xen/interface/hvm/params.h +0
-0@@ -34,6 +34,11 @@* Domain = val[47:32], Bus = val[31:16], include/xen/interface/hvm/params.h line 44
Quoted 10 lines
include/xen/interface/hvm/params.h +5
-0* 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
Sadly NACK in this form.
This is not your fault, but this particular field has hidden ABI which the original submitter neglected to put into public API.
Bits 63:56 of this field currently have a hidden ABI with:
xen/include/asm-x86/hvm/irq.h
enum {
HVMIRQ_callback_none,
HVMIRQ_callback_gsi,
HVMIRQ_callback_pci_intx,
HVMIRQ_callback_vector
} callback_via_type;
I will submit a patch to fix this this properly.
~Andrew
Re: [PATCH 11/13] xen/hvm/params: Add a new dilivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
In reply to shannon.zhao at linaro.orgQuoted 3 lines · On Tue, 17 Nov 2015, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Add a new dilivery type:
delivery
Quoted 28 lines
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 <[email protected]>--- include/xen/interface/hvm/params.h | 5 +++++ 1 file changed, 5 insertions(+)include/xen/interface/hvm/params.h +5
-0@@ -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 0Signature · 1 line
2.1.0
PATCH 11/13 xen/hvm/params: Add a new dilivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
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).
--- include/xen/interface/hvm/params.h | 5 +++++ 1 file changed, 5 insertions(+)
include/xen/interface/hvm/params.h +5 -0
@@ -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
Signature · 1 line
2.1.0
PATCH 12/13 arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
When booting with ACPI, it could get the event-channel irq through HVM_PARAM_CALLBACK_IRQ.
--- arch/arm/xen/enlighten.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)
arch/arm/xen/enlighten.c +19 -4
@@ -25,6 +25,7 @@#include <linux/cpufreq.h> #include <linux/cpu.h> #include <linux/console.h> +#include <linux/acpi.h> #include <linux/mm.h>
@@ -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, &a)) { +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 );
Signature · 1 line
2.1.0
PATCH 12/13 arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
Quoted 26 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
When booting with ACPI, it could get the event-channel irq through
HVM_PARAM_CALLBACK_IRQ.Signed-off-by Shannon Zhao <[email protected]>--- arch/arm/xen/enlighten.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)arch/arm/xen/enlighten.c +1
-0@@ -25,6 +25,7 @@#include <linux/cpufreq.h> #include <linux/cpu.h> #include <linux/console.h> +#include <linux/acpi.h> #include <linux/mm.h> @@ -190,10 +191,24 @@ static int __init xen_guest_init(void)if (!xen_domain ())return 0 ;
arch/arm/xen/enlighten.c static int __init xen_guest_init(void) · line 199
Quoted 10 lines
arch/arm/xen/enlighten.c +6
-4- 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, &a)) {
If HYPERVISOR_hvm_op returns an error (ret != 0), I wouldn't bother checking for the returned value and simply return error.
On the other hand, if HYPERVISOR_hvm_op is successful (ret == 0), then it might make sense to check for (a.value >> 56) == 3.
arch/arm/xen/enlighten.c static int __init xen_guest_init(void) · line 210
Quoted 11 lines
arch/arm/xen/enlighten.c +11
-0+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 ;
Please make the error message common and move it out of the if/else.
Quoted 7 lines
arch/arm/xen/enlighten.c +1
-0+ } } shared_info_page = (struct shared_info *)get_zeroed_page (GFP_KERNEL );Signature · 1 line
2.1.0
PATCH 12/13 arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
Quoted 41 lines · Stefano Stabellini
Quoted 26 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
When booting with ACPI, it could get the event-channel irq through
HVM_PARAM_CALLBACK_IRQ.Signed-off-by Shannon Zhao <[email protected]>--- arch/arm/xen/enlighten.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)arch/arm/xen/enlighten.c +1
-0@@ -25,6 +25,7 @@#include <linux/cpufreq.h> #include <linux/cpu.h> #include <linux/console.h> +#include <linux/acpi.h> #include <linux/mm.h> @@ -190,10 +191,24 @@ static int __init xen_guest_init(void)if (!xen_domain ())return 0 ;arch/arm/xen/enlighten.c static int __init xen_guest_init(void) · line 199
Quoted 10 lines
arch/arm/xen/enlighten.c +6
-4- 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, &a)) {If
HYPERVISOR_hvm_opreturns an error (ret != 0), I wouldn't bother checking for the returned value and simply return error.
Quoted 3 lines
On the other hand, if
HYPERVISOR_hvm_opis successful (ret == 0), then it might make sense to check for (a.value >> 56) == 3.
Ok.
Quoted 15 lines
arch/arm/xen/enlighten.c static int __init xen_guest_init(void) · line 210
Quoted 12 lines
arch/arm/xen/enlighten.c +11
-0+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 ;Please make the error message common and move it out of the if/else.
Sure. Thanks.
Quoted 11 lines
Quoted 8 lines
arch/arm/xen/enlighten.c +1
-0+ } } shared_info_page = (struct shared_info *)get_zeroed_page (GFP_KERNEL );Signature · 1 line
2.1.0.
Signature · 1 line
Shannon
Re: [PATCH 12/13] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
In reply to shannon.zhao at linaro.orgQuoted 26 lines · On Tue, 17 Nov 2015, [email protected] wrote:
From: Shannon Zhao <[email protected]>
When booting with ACPI, it could get the event-channel irq through
HVM_PARAM_CALLBACK_IRQ.Signed-off-by Shannon Zhao <[email protected]>--- arch/arm/xen/enlighten.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)arch/arm/xen/enlighten.c +1
-0@@ -25,6 +25,7 @@#include <linux/cpufreq.h> #include <linux/cpu.h> #include <linux/console.h> +#include <linux/acpi.h> #include <linux/mm.h> @@ -190,10 +191,24 @@ static int __init xen_guest_init(void)if (!xen_domain ())return 0 ;
arch/arm/xen/enlighten.c static int __init xen_guest_init(void) · line 199
Quoted 10 lines
arch/arm/xen/enlighten.c +6
-4- 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, &a)) {
If HYPERVISOR_hvm_op returns an error (ret != 0), I wouldn't bother checking for the returned value and simply return error.
On the other hand, if HYPERVISOR_hvm_op is successful (ret == 0), then it might make sense to check for (a.value >> 56) == 3.
arch/arm/xen/enlighten.c static int __init xen_guest_init(void) · line 210
Quoted 11 lines
arch/arm/xen/enlighten.c +11
-0+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 ;
Please make the error message common and move it out of the if/else.
Quoted 7 lines
arch/arm/xen/enlighten.c +1
-0+ } } shared_info_page = (struct shared_info *)get_zeroed_page (GFP_KERNEL );Signature · 1 line
2.1.0
PATCH 12/13 arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
When booting with ACPI, it could get the event-channel irq through HVM_PARAM_CALLBACK_IRQ.
--- arch/arm/xen/enlighten.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)
arch/arm/xen/enlighten.c +19 -4
@@ -25,6 +25,7 @@#include <linux/cpufreq.h> #include <linux/cpu.h> #include <linux/console.h> +#include <linux/acpi.h> #include <linux/mm.h>
@@ -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, &a)) { +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 );
Signature · 1 line
2.1.0
PATCH 13/13 ARM: XEN: Move xen_early_init() before efi_init()
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
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.
--- arch/arm/xen/enlighten.c | 62 ++++++++++++++++++++++++++++++++++++----------- arch/arm64/kernel/setup.c | 2 +- 2 files changed, 49 insertions(+), 15 deletions(-)
arch/arm/xen/enlighten.c +48 -14
@@ -19,6 +19,7 @@#include <linux/irqreturn.h> #include <linux/module.h> #include <linux/of.h> +#include <linux/of_fdt.h> #include <linux/of_irq.h> #include <linux/of_address.h> #include <linux/cpuidle.h>
@@ -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" , &len); +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 0void __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, &info); +if (!info.found) {pr_debug ("No Xen support\n" );return ; } - s =of_get_property (xen_node,"compatible" , &len); -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" );
arch/arm64/kernel/setup.c +1 -1
@@ -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 ();
Signature · 1 line
2.1.0
PATCH 13/13 ARM: XEN: Move xen_early_init() before efi_init()
Quoted 72 lines · shannon.zhao at linaro.org
From: Shannon Zhao <[email protected]>
Move
xen_early_init()beforeefi_init(), then when callingefi_init()could initialize Xen specific UEFI.Check if it runs on Xen hypervisor through the flat dts.
Signed-off-by Shannon Zhao <[email protected]>--- arch/arm/xen/enlighten.c | 62 ++++++++++++++++++++++++++++++++++++----------- arch/arm64/kernel/setup.c | 2 +- 2 files changed, 49 insertions(+), 15 deletions(-)arch/arm/xen/enlighten.c +28
-2@@ -19,6 +19,7 @@#include <linux/irqreturn.h> #include <linux/module.h> #include <linux/of.h> +#include <linux/of_fdt.h> #include <linux/of_irq.h> #include <linux/of_address.h> #include <linux/cpuidle.h> @@ -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" , &len); +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 0void __init xen_early_init (void ) {
arch/arm/xen/enlighten.c static irqreturn_t xen_arm_callback(int irq, void *arg) · line 184
Quoted 10 lines
arch/arm/xen/enlighten.c +6
-4-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;
Can you initialize the fields directly when you define xen_node_info and make it static?
The rest looks good.
Quoted 62 lines
arch/arm/xen/enlighten.c +13
-8- xen_node =of_find_compatible_node (NULL ,NULL ,"xen,xen" ); -if (!xen_node) { +of_scan_flat_dt (fdt_find_xen_node, &info); +if (!info.found) {pr_debug ("No Xen support\n" );return ; } - s =of_get_property (xen_node,"compatible" , &len); -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" );arch/arm64/kernel/setup.c +1
-1@@ -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 ();Signature · 1 line
2.1.0
PATCH 13/13 ARM: XEN: Move xen_early_init() before efi_init()
Quoted 38 lines · Stefano Stabellini
Quoted 38 lines
+struct
xen_node_info{Quoted 37 lines
arch/arm/xen/enlighten.c +26
-4+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" , &len); +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 0void __init xen_early_init (void ) { -int len; -const char *s =NULL ; -const char *version =NULL ; -const char *xen_prefix ="xen,xen-" ;
Quoted 8 lines
Quoted 6 lines
arch/arm/xen/enlighten.c static irqreturn_t xen_arm_callback(int irq, void *arg) · line 184
Quoted 6 lines
arch/arm/xen/enlighten.c +6
-0+struct xen_node_info info; + + info.compat ="xen,xen" ; + info.prefix ="xen,xen-" ; + info.version =NULL ; + info.found = false;Can you initialize the fields directly when you define
xen_node_infoand make it static?
Sure.
Thanks,
Signature · 1 line
Shannon
Re: [PATCH 13/13] ARM: XEN: Move xen_early_init() before efi_init()
In reply to shannon.zhao at linaro.orgQuoted 72 lines · On Tue, 17 Nov 2015, [email protected] wrote:
From: Shannon Zhao <[email protected]>
Move
xen_early_init()beforeefi_init(), then when callingefi_init()could initialize Xen specific UEFI.Check if it runs on Xen hypervisor through the flat dts.
Signed-off-by Shannon Zhao <[email protected]>--- arch/arm/xen/enlighten.c | 62 ++++++++++++++++++++++++++++++++++++----------- arch/arm64/kernel/setup.c | 2 +- 2 files changed, 49 insertions(+), 15 deletions(-)arch/arm/xen/enlighten.c +28
-2@@ -19,6 +19,7 @@#include <linux/irqreturn.h> #include <linux/module.h> #include <linux/of.h> +#include <linux/of_fdt.h> #include <linux/of_irq.h> #include <linux/of_address.h> #include <linux/cpuidle.h> @@ -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" , &len); +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 0void __init xen_early_init (void ) {
arch/arm/xen/enlighten.c static irqreturn_t xen_arm_callback(int irq, void *arg) · line 184
Quoted 10 lines
arch/arm/xen/enlighten.c +6
-4-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;
Can you initialize the fields directly when you define xen_node_info and make it static?
The rest looks good.
Quoted 62 lines
arch/arm/xen/enlighten.c +13
-8- xen_node =of_find_compatible_node (NULL ,NULL ,"xen,xen" ); -if (!xen_node) { +of_scan_flat_dt (fdt_find_xen_node, &info); +if (!info.found) {pr_debug ("No Xen support\n" );return ; } - s =of_get_property (xen_node,"compatible" , &len); -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" );arch/arm64/kernel/setup.c +1
-1@@ -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 ();Signature · 1 line
2.1.0
PATCH 13/13 ARM: XEN: Move xen_early_init() before efi_init()
In reply to shannon.zhao at linaro.orgFrom: Shannon Zhao <[email protected]>
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.
--- arch/arm/xen/enlighten.c | 62 ++++++++++++++++++++++++++++++++++++----------- arch/arm64/kernel/setup.c | 2 +- 2 files changed, 49 insertions(+), 15 deletions(-)
arch/arm/xen/enlighten.c +48 -14
@@ -19,6 +19,7 @@#include <linux/irqreturn.h> #include <linux/module.h> #include <linux/of.h> +#include <linux/of_fdt.h> #include <linux/of_irq.h> #include <linux/of_address.h> #include <linux/cpuidle.h>
@@ -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" , &len); +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 0void __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, &info); +if (!info.found) {pr_debug ("No Xen support\n" );return ; } - s =of_get_property (xen_node,"compatible" , &len); -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" );
arch/arm64/kernel/setup.c +1 -1
@@ -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 ();
Signature · 1 line
2.1.0