* [PATCH v7 00/17] Add ACPI support for Xen Dom0 on ARM64
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
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.
Thanks,
Shannon
[1] http://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html
Changes since v6:
* rebase on linux master
* refactor codes as acpi_get_spcr_uart_addr (PATCH 1)
* sync with Xen (patch 9)
Changes since v5:
* rebase on linux master
* use acpi_dev_resource_memory to parse the device memory info(patch 1)
* sync with Xen (patch 9)
Changes since v4:
* rebase on linux master
* move the check acpi_device_should_be_hidden into
acpi_bus_type_and_status (patch 1)
* use existing function fdt_subnode_offset (patch 16)
Changes since v3:
* rebase on linux master
* print a warning when there is no SPCR table
* rephase the commit message of PATCH 3
* rephase the words of PATCH 13
* use strcmp and factor the function in PATCH 16
* Add several ACKs and RBs, thanks a lot
Changes since v2:
* Use 0 to check if it should ignore the UART
* Fix the use of page_to_xen_pfn
* Factor ACPI and DT parts in xen_guest_init
* Check "uefi" node by full path
* Fix the statement of Documentation/devicetree/bindings/arm/xen.txt
Changes since v1:
* Rebase on linux mainline and wallclock patch from Stefano
* Refactor AMBA and platform device MMIO map to one file
* Use EFI_PARAVIRT to check if it supports XEN EFI
* Refactor Xen EFI codes
* Address other comments
Shannon Zhao (17):
Xen: ACPI: Hide UART used by Xen
xen/grant-table: Move xlated_setup_gnttab_pages to common place
Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
arm/xen: Use xen_xlate_map_ballooned_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
Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
xen/hvm/params: Add a new delivery 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()
ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
ARM: Xen: Document UEFI support on Xen ARM virtual platforms
XEN: EFI: Move x86 specific codes to architecture directory
ARM64: XEN: Add a function to initialize Xen specific UEFI runtime
services
FDT: Add a helper to get the subnode by given name
Xen: EFI: Parse DT parameters for Xen specific UEFI
Documentation/devicetree/bindings/arm/xen.txt | 33 +++++
arch/arm/include/asm/xen/xen-ops.h | 6 +
arch/arm/xen/Makefile | 1 +
arch/arm/xen/efi.c | 40 ++++++
arch/arm/xen/enlighten.c | 109 +++++++++++----
arch/arm64/include/asm/xen/xen-ops.h | 6 +
arch/arm64/kernel/acpi.c | 12 +-
arch/arm64/kernel/setup.c | 2 +-
arch/arm64/xen/Makefile | 1 +
arch/x86/xen/efi.c | 112 ++++++++++++++++
arch/x86/xen/grant-table.c | 57 +-------
drivers/acpi/scan.c | 68 ++++++++++
drivers/firmware/efi/arm-runtime.c | 17 ++-
drivers/firmware/efi/efi.c | 45 ++++++-
drivers/of/fdt.c | 13 ++
drivers/xen/Kconfig | 2 +-
drivers/xen/Makefile | 1 +
drivers/xen/arm-device.c | 184 ++++++++++++++++++++++++++
drivers/xen/efi.c | 174 +++++-------------------
drivers/xen/xlate_mmu.c | 67 ++++++++++
include/linux/of_fdt.h | 2 +
include/xen/interface/hvm/params.h | 40 +++++-
include/xen/interface/memory.h | 1 +
include/xen/xen-ops.h | 32 +++--
24 files changed, 778 insertions(+), 247 deletions(-)
create mode 100644 arch/arm/include/asm/xen/xen-ops.h
create mode 100644 arch/arm/xen/efi.c
create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
create mode 100644 drivers/xen/arm-device.c
--
2.1.4
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 00/17] Add ACPI support for Xen Dom0 on ARM64
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, julien.grall-5wv7dgnIgG8,
peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
zhaoshenglong-hv44wF8Li93QT0dZR+AlfA,
shannon.zhao-QSEj5FYQhm4dnm+yROfE0A
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.
Thanks,
Shannon
[1] http://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html
Changes since v6:
* rebase on linux master
* refactor codes as acpi_get_spcr_uart_addr (PATCH 1)
* sync with Xen (patch 9)
Changes since v5:
* rebase on linux master
* use acpi_dev_resource_memory to parse the device memory info(patch 1)
* sync with Xen (patch 9)
Changes since v4:
* rebase on linux master
* move the check acpi_device_should_be_hidden into
acpi_bus_type_and_status (patch 1)
* use existing function fdt_subnode_offset (patch 16)
Changes since v3:
* rebase on linux master
* print a warning when there is no SPCR table
* rephase the commit message of PATCH 3
* rephase the words of PATCH 13
* use strcmp and factor the function in PATCH 16
* Add several ACKs and RBs, thanks a lot
Changes since v2:
* Use 0 to check if it should ignore the UART
* Fix the use of page_to_xen_pfn
* Factor ACPI and DT parts in xen_guest_init
* Check "uefi" node by full path
* Fix the statement of Documentation/devicetree/bindings/arm/xen.txt
Changes since v1:
* Rebase on linux mainline and wallclock patch from Stefano
* Refactor AMBA and platform device MMIO map to one file
* Use EFI_PARAVIRT to check if it supports XEN EFI
* Refactor Xen EFI codes
* Address other comments
Shannon Zhao (17):
Xen: ACPI: Hide UART used by Xen
xen/grant-table: Move xlated_setup_gnttab_pages to common place
Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
arm/xen: Use xen_xlate_map_ballooned_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
Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
xen/hvm/params: Add a new delivery 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()
ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
ARM: Xen: Document UEFI support on Xen ARM virtual platforms
XEN: EFI: Move x86 specific codes to architecture directory
ARM64: XEN: Add a function to initialize Xen specific UEFI runtime
services
FDT: Add a helper to get the subnode by given name
Xen: EFI: Parse DT parameters for Xen specific UEFI
Documentation/devicetree/bindings/arm/xen.txt | 33 +++++
arch/arm/include/asm/xen/xen-ops.h | 6 +
arch/arm/xen/Makefile | 1 +
arch/arm/xen/efi.c | 40 ++++++
arch/arm/xen/enlighten.c | 109 +++++++++++----
arch/arm64/include/asm/xen/xen-ops.h | 6 +
arch/arm64/kernel/acpi.c | 12 +-
arch/arm64/kernel/setup.c | 2 +-
arch/arm64/xen/Makefile | 1 +
arch/x86/xen/efi.c | 112 ++++++++++++++++
arch/x86/xen/grant-table.c | 57 +-------
drivers/acpi/scan.c | 68 ++++++++++
drivers/firmware/efi/arm-runtime.c | 17 ++-
drivers/firmware/efi/efi.c | 45 ++++++-
drivers/of/fdt.c | 13 ++
drivers/xen/Kconfig | 2 +-
drivers/xen/Makefile | 1 +
drivers/xen/arm-device.c | 184 ++++++++++++++++++++++++++
drivers/xen/efi.c | 174 +++++-------------------
drivers/xen/xlate_mmu.c | 67 ++++++++++
include/linux/of_fdt.h | 2 +
include/xen/interface/hvm/params.h | 40 +++++-
include/xen/interface/memory.h | 1 +
include/xen/xen-ops.h | 32 +++--
24 files changed, 778 insertions(+), 247 deletions(-)
create mode 100644 arch/arm/include/asm/xen/xen-ops.h
create mode 100644 arch/arm/xen/efi.c
create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
create mode 100644 drivers/xen/arm-device.c
--
2.1.4
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-24 14:44 ` Shannon Zhao
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, Rafael J. Wysocki, catalin.marinas,
will.deacon, linux-kernel, peter.huangpeng, open list:ACPI,
julien.grall, shannon.zhao, zhaoshenglong, xen-devel, Len Brown
ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.
CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
CC: linux-acpi@vger.kernel.org (open list:ACPI)
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..e96a058 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
DEFINE_MUTEX(acpi_device_lock);
LIST_HEAD(acpi_wakeup_device_list);
static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
return 0;
}
+static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
+ void *context)
+{
+ struct resource *res = context;
+
+ if (acpi_dev_resource_memory(ares, res))
+ return AE_CTRL_TERMINATE;
+
+ return AE_OK;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+ acpi_status status;
+ struct resource res;
+
+ /* Check if it should ignore the UART device */
+ if (spcr_uart_addr != 0) {
+ if (!acpi_has_method(handle, METHOD_NAME__CRS))
+ return false;
+
+ status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+ acpi_get_resource_memory, &res);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ if (res.start == spcr_uart_addr) {
+ printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
{
@@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+ if (acpi_device_should_be_hidden(handle))
+ return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
return result < 0 ? result : 0;
}
+static void acpi_get_spcr_uart_addr(void)
+{
+ acpi_status status;
+ struct acpi_table_spcr *spcr_ptr;
+
+ status = acpi_get_table(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **)&spcr_ptr);
+ if (ACPI_SUCCESS(status))
+ spcr_uart_addr = spcr_ptr->serial_port.address;
+ else
+ printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
+}
+
int __init acpi_scan_init(void)
{
int result;
+ acpi_status status;
+ struct acpi_table_stao *stao_ptr;
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
acpi_scan_add_handler(&generic_device_handler);
+ /*
+ * If there is STAO table, check whether it needs to ignore the UART
+ * device in SPCR table.
+ */
+ status = acpi_get_table(ACPI_SIG_STAO, 0,
+ (struct acpi_table_header **)&stao_ptr);
+ if (ACPI_SUCCESS(status)) {
+ if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+ printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
+
+ if (stao_ptr->ignore_uart)
+ acpi_get_spcr_uart_addr();
+ }
+
mutex_lock(&acpi_scan_lock);
/*
* Enumerate devices in the ACPI namespace.
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.
CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
CC: linux-acpi at vger.kernel.org (open list:ACPI)
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..e96a058 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
DEFINE_MUTEX(acpi_device_lock);
LIST_HEAD(acpi_wakeup_device_list);
static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
return 0;
}
+static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
+ void *context)
+{
+ struct resource *res = context;
+
+ if (acpi_dev_resource_memory(ares, res))
+ return AE_CTRL_TERMINATE;
+
+ return AE_OK;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+ acpi_status status;
+ struct resource res;
+
+ /* Check if it should ignore the UART device */
+ if (spcr_uart_addr != 0) {
+ if (!acpi_has_method(handle, METHOD_NAME__CRS))
+ return false;
+
+ status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+ acpi_get_resource_memory, &res);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ if (res.start == spcr_uart_addr) {
+ printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
{
@@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+ if (acpi_device_should_be_hidden(handle))
+ return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
return result < 0 ? result : 0;
}
+static void acpi_get_spcr_uart_addr(void)
+{
+ acpi_status status;
+ struct acpi_table_spcr *spcr_ptr;
+
+ status = acpi_get_table(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **)&spcr_ptr);
+ if (ACPI_SUCCESS(status))
+ spcr_uart_addr = spcr_ptr->serial_port.address;
+ else
+ printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
+}
+
int __init acpi_scan_init(void)
{
int result;
+ acpi_status status;
+ struct acpi_table_stao *stao_ptr;
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
acpi_scan_add_handler(&generic_device_handler);
+ /*
+ * If there is STAO table, check whether it needs to ignore the UART
+ * device in SPCR table.
+ */
+ status = acpi_get_table(ACPI_SIG_STAO, 0,
+ (struct acpi_table_header **)&stao_ptr);
+ if (ACPI_SUCCESS(status)) {
+ if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+ printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
+
+ if (stao_ptr->ignore_uart)
+ acpi_get_spcr_uart_addr();
+ }
+
mutex_lock(&acpi_scan_lock);
/*
* Enumerate devices in the ACPI namespace.
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao, Rafael J. Wysocki, Len Brown,
open list:ACPI
ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.
CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
CC: linux-acpi@vger.kernel.org (open list:ACPI)
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..e96a058 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
DEFINE_MUTEX(acpi_device_lock);
LIST_HEAD(acpi_wakeup_device_list);
static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
return 0;
}
+static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
+ void *context)
+{
+ struct resource *res = context;
+
+ if (acpi_dev_resource_memory(ares, res))
+ return AE_CTRL_TERMINATE;
+
+ return AE_OK;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+ acpi_status status;
+ struct resource res;
+
+ /* Check if it should ignore the UART device */
+ if (spcr_uart_addr != 0) {
+ if (!acpi_has_method(handle, METHOD_NAME__CRS))
+ return false;
+
+ status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+ acpi_get_resource_memory, &res);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ if (res.start == spcr_uart_addr) {
+ printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
{
@@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+ if (acpi_device_should_be_hidden(handle))
+ return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
return result < 0 ? result : 0;
}
+static void acpi_get_spcr_uart_addr(void)
+{
+ acpi_status status;
+ struct acpi_table_spcr *spcr_ptr;
+
+ status = acpi_get_table(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **)&spcr_ptr);
+ if (ACPI_SUCCESS(status))
+ spcr_uart_addr = spcr_ptr->serial_port.address;
+ else
+ printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
+}
+
int __init acpi_scan_init(void)
{
int result;
+ acpi_status status;
+ struct acpi_table_stao *stao_ptr;
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
acpi_scan_add_handler(&generic_device_handler);
+ /*
+ * If there is STAO table, check whether it needs to ignore the UART
+ * device in SPCR table.
+ */
+ status = acpi_get_table(ACPI_SIG_STAO, 0,
+ (struct acpi_table_header **)&stao_ptr);
+ if (ACPI_SUCCESS(status)) {
+ if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+ printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
+
+ if (stao_ptr->ignore_uart)
+ acpi_get_spcr_uart_addr();
+ }
+
mutex_lock(&acpi_scan_lock);
/*
* Enumerate devices in the ACPI namespace.
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* Re: [PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-24 14:44 ` Shannon Zhao
(?)
@ 2016-03-24 15:08 ` Rafael J. Wysocki
-1 siblings, 0 replies; 172+ messages in thread
From: Rafael J. Wysocki @ 2016-03-24 15:08 UTC (permalink / raw)
To: Shannon Zhao
Cc: linux-arm-kernel, stefano.stabellini, david.vrabel, devicetree,
linux-efi, Linux Kernel Mailing List, Catalin Marinas,
Will Deacon, julien.grall, peter.huangpeng, xen-devel,
Shannon Zhao, Rafael J. Wysocki, Len Brown, open list:ACPI
On Thu, Mar 24, 2016 at 3:44 PM, Shannon Zhao <shannon.zhao@linaro.org> wrote:
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> CC: linux-acpi@vger.kernel.org (open list:ACPI)
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 5f28cf7..e96a058 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> DEFINE_MUTEX(acpi_device_lock);
> LIST_HEAD(acpi_wakeup_device_list);
> static DEFINE_MUTEX(acpi_hp_context_lock);
> +static u64 spcr_uart_addr;
>
> struct acpi_dep_data {
> struct list_head node;
> @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> return 0;
> }
>
> +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> + void *context)
> +{
> + struct resource *res = context;
> +
> + if (acpi_dev_resource_memory(ares, res))
> + return AE_CTRL_TERMINATE;
> +
> + return AE_OK;
> +}
> +
> +static bool acpi_device_should_be_hidden(acpi_handle handle)
> +{
> + acpi_status status;
> + struct resource res;
> +
> + /* Check if it should ignore the UART device */
> + if (spcr_uart_addr != 0) {
> + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> + return false;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> + acpi_get_resource_memory, &res);
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + if (res.start == spcr_uart_addr) {
> + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> unsigned long long *sta)
> {
> @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> switch (acpi_type) {
> case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> case ACPI_TYPE_DEVICE:
> + if (acpi_device_should_be_hidden(handle))
> + return -ENODEV;
> +
> *type = ACPI_BUS_TYPE_DEVICE;
> status = acpi_bus_get_status_handle(handle, sta);
> if (ACPI_FAILURE(status))
> @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> return result < 0 ? result : 0;
> }
>
> +static void acpi_get_spcr_uart_addr(void)
static void __init acpi_get_spcr_uart_addr(void)
I suppose?
Apart from this it looks fine.
> +{
> + acpi_status status;
> + struct acpi_table_spcr *spcr_ptr;
> +
> + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> + (struct acpi_table_header **)&spcr_ptr);
> + if (ACPI_SUCCESS(status))
> + spcr_uart_addr = spcr_ptr->serial_port.address;
> + else
> + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> +}
> +
> int __init acpi_scan_init(void)
> {
> int result;
> + acpi_status status;
> + struct acpi_table_stao *stao_ptr;
>
> acpi_pci_root_init();
> acpi_pci_link_init();
> @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
>
> acpi_scan_add_handler(&generic_device_handler);
>
> + /*
> + * If there is STAO table, check whether it needs to ignore the UART
> + * device in SPCR table.
> + */
> + status = acpi_get_table(ACPI_SIG_STAO, 0,
> + (struct acpi_table_header **)&stao_ptr);
> + if (ACPI_SUCCESS(status)) {
> + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> +
> + if (stao_ptr->ignore_uart)
> + acpi_get_spcr_uart_addr();
> + }
> +
> mutex_lock(&acpi_scan_lock);
> /*
> * Enumerate devices in the ACPI namespace.
> --
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-24 15:08 ` Rafael J. Wysocki
0 siblings, 0 replies; 172+ messages in thread
From: Rafael J. Wysocki @ 2016-03-24 15:08 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 24, 2016 at 3:44 PM, Shannon Zhao <shannon.zhao@linaro.org> wrote:
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> CC: linux-acpi at vger.kernel.org (open list:ACPI)
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 5f28cf7..e96a058 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> DEFINE_MUTEX(acpi_device_lock);
> LIST_HEAD(acpi_wakeup_device_list);
> static DEFINE_MUTEX(acpi_hp_context_lock);
> +static u64 spcr_uart_addr;
>
> struct acpi_dep_data {
> struct list_head node;
> @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> return 0;
> }
>
> +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> + void *context)
> +{
> + struct resource *res = context;
> +
> + if (acpi_dev_resource_memory(ares, res))
> + return AE_CTRL_TERMINATE;
> +
> + return AE_OK;
> +}
> +
> +static bool acpi_device_should_be_hidden(acpi_handle handle)
> +{
> + acpi_status status;
> + struct resource res;
> +
> + /* Check if it should ignore the UART device */
> + if (spcr_uart_addr != 0) {
> + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> + return false;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> + acpi_get_resource_memory, &res);
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + if (res.start == spcr_uart_addr) {
> + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> unsigned long long *sta)
> {
> @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> switch (acpi_type) {
> case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> case ACPI_TYPE_DEVICE:
> + if (acpi_device_should_be_hidden(handle))
> + return -ENODEV;
> +
> *type = ACPI_BUS_TYPE_DEVICE;
> status = acpi_bus_get_status_handle(handle, sta);
> if (ACPI_FAILURE(status))
> @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> return result < 0 ? result : 0;
> }
>
> +static void acpi_get_spcr_uart_addr(void)
static void __init acpi_get_spcr_uart_addr(void)
I suppose?
Apart from this it looks fine.
> +{
> + acpi_status status;
> + struct acpi_table_spcr *spcr_ptr;
> +
> + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> + (struct acpi_table_header **)&spcr_ptr);
> + if (ACPI_SUCCESS(status))
> + spcr_uart_addr = spcr_ptr->serial_port.address;
> + else
> + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> +}
> +
> int __init acpi_scan_init(void)
> {
> int result;
> + acpi_status status;
> + struct acpi_table_stao *stao_ptr;
>
> acpi_pci_root_init();
> acpi_pci_link_init();
> @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
>
> acpi_scan_add_handler(&generic_device_handler);
>
> + /*
> + * If there is STAO table, check whether it needs to ignore the UART
> + * device in SPCR table.
> + */
> + status = acpi_get_table(ACPI_SIG_STAO, 0,
> + (struct acpi_table_header **)&stao_ptr);
> + if (ACPI_SUCCESS(status)) {
> + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> +
> + if (stao_ptr->ignore_uart)
> + acpi_get_spcr_uart_addr();
> + }
> +
> mutex_lock(&acpi_scan_lock);
> /*
> * Enumerate devices in the ACPI namespace.
> --
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-24 15:08 ` Rafael J. Wysocki
0 siblings, 0 replies; 172+ messages in thread
From: Rafael J. Wysocki @ 2016-03-24 15:08 UTC (permalink / raw)
To: Shannon Zhao
Cc: linux-arm-kernel, stefano.stabellini, david.vrabel, devicetree,
linux-efi, Linux Kernel Mailing List, Catalin Marinas,
Will Deacon, julien.grall, peter.huangpeng, xen-devel,
Shannon Zhao, Rafael J. Wysocki, Len Brown, open list:ACPI
On Thu, Mar 24, 2016 at 3:44 PM, Shannon Zhao <shannon.zhao@linaro.org> wrote:
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> CC: linux-acpi@vger.kernel.org (open list:ACPI)
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 5f28cf7..e96a058 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> DEFINE_MUTEX(acpi_device_lock);
> LIST_HEAD(acpi_wakeup_device_list);
> static DEFINE_MUTEX(acpi_hp_context_lock);
> +static u64 spcr_uart_addr;
>
> struct acpi_dep_data {
> struct list_head node;
> @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> return 0;
> }
>
> +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> + void *context)
> +{
> + struct resource *res = context;
> +
> + if (acpi_dev_resource_memory(ares, res))
> + return AE_CTRL_TERMINATE;
> +
> + return AE_OK;
> +}
> +
> +static bool acpi_device_should_be_hidden(acpi_handle handle)
> +{
> + acpi_status status;
> + struct resource res;
> +
> + /* Check if it should ignore the UART device */
> + if (spcr_uart_addr != 0) {
> + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> + return false;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> + acpi_get_resource_memory, &res);
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + if (res.start == spcr_uart_addr) {
> + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> unsigned long long *sta)
> {
> @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> switch (acpi_type) {
> case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> case ACPI_TYPE_DEVICE:
> + if (acpi_device_should_be_hidden(handle))
> + return -ENODEV;
> +
> *type = ACPI_BUS_TYPE_DEVICE;
> status = acpi_bus_get_status_handle(handle, sta);
> if (ACPI_FAILURE(status))
> @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> return result < 0 ? result : 0;
> }
>
> +static void acpi_get_spcr_uart_addr(void)
static void __init acpi_get_spcr_uart_addr(void)
I suppose?
Apart from this it looks fine.
> +{
> + acpi_status status;
> + struct acpi_table_spcr *spcr_ptr;
> +
> + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> + (struct acpi_table_header **)&spcr_ptr);
> + if (ACPI_SUCCESS(status))
> + spcr_uart_addr = spcr_ptr->serial_port.address;
> + else
> + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> +}
> +
> int __init acpi_scan_init(void)
> {
> int result;
> + acpi_status status;
> + struct acpi_table_stao *stao_ptr;
>
> acpi_pci_root_init();
> acpi_pci_link_init();
> @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
>
> acpi_scan_add_handler(&generic_device_handler);
>
> + /*
> + * If there is STAO table, check whether it needs to ignore the UART
> + * device in SPCR table.
> + */
> + status = acpi_get_table(ACPI_SIG_STAO, 0,
> + (struct acpi_table_header **)&stao_ptr);
> + if (ACPI_SUCCESS(status)) {
> + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> +
> + if (stao_ptr->ignore_uart)
> + acpi_get_spcr_uart_addr();
> + }
> +
> mutex_lock(&acpi_scan_lock);
> /*
> * Enumerate devices in the ACPI namespace.
> --
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-24 15:08 ` Rafael J. Wysocki
(?)
(?)
@ 2016-03-25 7:38 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-25 7:38 UTC (permalink / raw)
To: Rafael J. Wysocki, Shannon Zhao
Cc: devicetree, linux-efi, Rafael J. Wysocki, Catalin Marinas,
Will Deacon, Linux Kernel Mailing List, peter.huangpeng, ACPI,
julien.grall, stefano.stabellini, david.vrabel, xen-devel,
linux-arm-kernel, Len Brown
On 2016/3/24 23:08, Rafael J. Wysocki wrote:
> On Thu, Mar 24, 2016 at 3:44 PM, Shannon Zhao <shannon.zhao@linaro.org> wrote:
>> > +static void acpi_get_spcr_uart_addr(void)
> static void __init acpi_get_spcr_uart_addr(void)
>
> I suppose?
>
> Apart from this it looks fine.
>
Thanks, I'll update this one and resend it later.
--
Shannon
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-24 15:08 ` Rafael J. Wysocki
(?)
@ 2016-03-25 7:38 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-25 7:38 UTC (permalink / raw)
To: Rafael J. Wysocki, Shannon Zhao
Cc: linux-arm-kernel, stefano.stabellini, david.vrabel, devicetree,
linux-efi, Linux Kernel Mailing List, Catalin Marinas,
Will Deacon, julien.grall, peter.huangpeng, xen-devel,
Rafael J. Wysocki, Len Brown, ACPI
On 2016/3/24 23:08, Rafael J. Wysocki wrote:
> On Thu, Mar 24, 2016 at 3:44 PM, Shannon Zhao <shannon.zhao@linaro.org> wrote:
>> > +static void acpi_get_spcr_uart_addr(void)
> static void __init acpi_get_spcr_uart_addr(void)
>
> I suppose?
>
> Apart from this it looks fine.
>
Thanks, I'll update this one and resend it later.
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread
* [PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-25 7:38 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-25 7:38 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/3/24 23:08, Rafael J. Wysocki wrote:
> On Thu, Mar 24, 2016 at 3:44 PM, Shannon Zhao <shannon.zhao@linaro.org> wrote:
>> > +static void acpi_get_spcr_uart_addr(void)
> static void __init acpi_get_spcr_uart_addr(void)
>
> I suppose?
>
> Apart from this it looks fine.
>
Thanks, I'll update this one and resend it later.
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-25 7:38 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-25 7:38 UTC (permalink / raw)
To: Rafael J. Wysocki, Shannon Zhao
Cc: linux-arm-kernel, stefano.stabellini, david.vrabel, devicetree,
linux-efi, Linux Kernel Mailing List, Catalin Marinas,
Will Deacon, julien.grall, peter.huangpeng, xen-devel,
Rafael J. Wysocki, Len Brown, ACPI,
On 2016/3/24 23:08, Rafael J. Wysocki wrote:
> On Thu, Mar 24, 2016 at 3:44 PM, Shannon Zhao <shannon.zhao@linaro.org> wrote:
>> > +static void acpi_get_spcr_uart_addr(void)
> static void __init acpi_get_spcr_uart_addr(void)
>
> I suppose?
>
> Apart from this it looks fine.
>
Thanks, I'll update this one and resend it later.
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-24 14:44 ` Shannon Zhao
` (2 preceding siblings ...)
(?)
@ 2016-03-24 15:08 ` Rafael J. Wysocki
-1 siblings, 0 replies; 172+ messages in thread
From: Rafael J. Wysocki @ 2016-03-24 15:08 UTC (permalink / raw)
To: Shannon Zhao
Cc: devicetree, linux-efi, Rafael J. Wysocki, Catalin Marinas,
Will Deacon, Linux Kernel Mailing List, peter.huangpeng,
open list:ACPI, julien.grall, stefano.stabellini, david.vrabel,
Shannon Zhao, xen-devel, linux-arm-kernel, Len Brown
On Thu, Mar 24, 2016 at 3:44 PM, Shannon Zhao <shannon.zhao@linaro.org> wrote:
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> CC: linux-acpi@vger.kernel.org (open list:ACPI)
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 5f28cf7..e96a058 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> DEFINE_MUTEX(acpi_device_lock);
> LIST_HEAD(acpi_wakeup_device_list);
> static DEFINE_MUTEX(acpi_hp_context_lock);
> +static u64 spcr_uart_addr;
>
> struct acpi_dep_data {
> struct list_head node;
> @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> return 0;
> }
>
> +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> + void *context)
> +{
> + struct resource *res = context;
> +
> + if (acpi_dev_resource_memory(ares, res))
> + return AE_CTRL_TERMINATE;
> +
> + return AE_OK;
> +}
> +
> +static bool acpi_device_should_be_hidden(acpi_handle handle)
> +{
> + acpi_status status;
> + struct resource res;
> +
> + /* Check if it should ignore the UART device */
> + if (spcr_uart_addr != 0) {
> + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> + return false;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> + acpi_get_resource_memory, &res);
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + if (res.start == spcr_uart_addr) {
> + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> unsigned long long *sta)
> {
> @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> switch (acpi_type) {
> case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> case ACPI_TYPE_DEVICE:
> + if (acpi_device_should_be_hidden(handle))
> + return -ENODEV;
> +
> *type = ACPI_BUS_TYPE_DEVICE;
> status = acpi_bus_get_status_handle(handle, sta);
> if (ACPI_FAILURE(status))
> @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> return result < 0 ? result : 0;
> }
>
> +static void acpi_get_spcr_uart_addr(void)
static void __init acpi_get_spcr_uart_addr(void)
I suppose?
Apart from this it looks fine.
> +{
> + acpi_status status;
> + struct acpi_table_spcr *spcr_ptr;
> +
> + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> + (struct acpi_table_header **)&spcr_ptr);
> + if (ACPI_SUCCESS(status))
> + spcr_uart_addr = spcr_ptr->serial_port.address;
> + else
> + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> +}
> +
> int __init acpi_scan_init(void)
> {
> int result;
> + acpi_status status;
> + struct acpi_table_stao *stao_ptr;
>
> acpi_pci_root_init();
> acpi_pci_link_init();
> @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
>
> acpi_scan_add_handler(&generic_device_handler);
>
> + /*
> + * If there is STAO table, check whether it needs to ignore the UART
> + * device in SPCR table.
> + */
> + status = acpi_get_table(ACPI_SIG_STAO, 0,
> + (struct acpi_table_header **)&stao_ptr);
> + if (ACPI_SUCCESS(status)) {
> + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> +
> + if (stao_ptr->ignore_uart)
> + acpi_get_spcr_uart_addr();
> + }
> +
> mutex_lock(&acpi_scan_lock);
> /*
> * Enumerate devices in the ACPI namespace.
> --
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread[parent not found: <1458830676-27075-2-git-send-email-shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]
* [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-24 14:44 ` Shannon Zhao
(?)
@ 2016-03-25 8:05 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-25 8:05 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA
Cc: catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
shannon.zhao-QSEj5FYQhm4dnm+yROfE0A,
peter.huangpeng-hv44wF8Li93QT0dZR+AlfA, Rafael J. Wysocki,
Len Brown, open list:ACPI
From: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.
CC: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> (supporter:ACPI)
CC: Len Brown <lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> (supporter:ACPI)
CC: linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list:ACPI)
Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..5420cc5 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
DEFINE_MUTEX(acpi_device_lock);
LIST_HEAD(acpi_wakeup_device_list);
static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
return 0;
}
+static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
+ void *context)
+{
+ struct resource *res = context;
+
+ if (acpi_dev_resource_memory(ares, res))
+ return AE_CTRL_TERMINATE;
+
+ return AE_OK;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+ acpi_status status;
+ struct resource res;
+
+ /* Check if it should ignore the UART device */
+ if (spcr_uart_addr != 0) {
+ if (!acpi_has_method(handle, METHOD_NAME__CRS))
+ return false;
+
+ status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+ acpi_get_resource_memory, &res);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ if (res.start == spcr_uart_addr) {
+ printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
{
@@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+ if (acpi_device_should_be_hidden(handle))
+ return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
return result < 0 ? result : 0;
}
+static void __init acpi_get_spcr_uart_addr(void)
+{
+ acpi_status status;
+ struct acpi_table_spcr *spcr_ptr;
+
+ status = acpi_get_table(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **)&spcr_ptr);
+ if (ACPI_SUCCESS(status))
+ spcr_uart_addr = spcr_ptr->serial_port.address;
+ else
+ printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
+}
+
int __init acpi_scan_init(void)
{
int result;
+ acpi_status status;
+ struct acpi_table_stao *stao_ptr;
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
acpi_scan_add_handler(&generic_device_handler);
+ /*
+ * If there is STAO table, check whether it needs to ignore the UART
+ * device in SPCR table.
+ */
+ status = acpi_get_table(ACPI_SIG_STAO, 0,
+ (struct acpi_table_header **)&stao_ptr);
+ if (ACPI_SUCCESS(status)) {
+ if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+ printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
+
+ if (stao_ptr->ignore_uart)
+ acpi_get_spcr_uart_addr();
+ }
+
mutex_lock(&acpi_scan_lock);
/*
* Enumerate devices in the ACPI namespace.
--
2.0.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-25 8:05 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-25 8:05 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.
CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
CC: linux-acpi at vger.kernel.org (open list:ACPI)
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..5420cc5 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
DEFINE_MUTEX(acpi_device_lock);
LIST_HEAD(acpi_wakeup_device_list);
static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
return 0;
}
+static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
+ void *context)
+{
+ struct resource *res = context;
+
+ if (acpi_dev_resource_memory(ares, res))
+ return AE_CTRL_TERMINATE;
+
+ return AE_OK;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+ acpi_status status;
+ struct resource res;
+
+ /* Check if it should ignore the UART device */
+ if (spcr_uart_addr != 0) {
+ if (!acpi_has_method(handle, METHOD_NAME__CRS))
+ return false;
+
+ status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+ acpi_get_resource_memory, &res);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ if (res.start == spcr_uart_addr) {
+ printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
{
@@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+ if (acpi_device_should_be_hidden(handle))
+ return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
return result < 0 ? result : 0;
}
+static void __init acpi_get_spcr_uart_addr(void)
+{
+ acpi_status status;
+ struct acpi_table_spcr *spcr_ptr;
+
+ status = acpi_get_table(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **)&spcr_ptr);
+ if (ACPI_SUCCESS(status))
+ spcr_uart_addr = spcr_ptr->serial_port.address;
+ else
+ printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
+}
+
int __init acpi_scan_init(void)
{
int result;
+ acpi_status status;
+ struct acpi_table_stao *stao_ptr;
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
acpi_scan_add_handler(&generic_device_handler);
+ /*
+ * If there is STAO table, check whether it needs to ignore the UART
+ * device in SPCR table.
+ */
+ status = acpi_get_table(ACPI_SIG_STAO, 0,
+ (struct acpi_table_header **)&stao_ptr);
+ if (ACPI_SUCCESS(status)) {
+ if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+ printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
+
+ if (stao_ptr->ignore_uart)
+ acpi_get_spcr_uart_addr();
+ }
+
mutex_lock(&acpi_scan_lock);
/*
* Enumerate devices in the ACPI namespace.
--
2.0.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-25 8:05 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-25 8:05 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: catalin.marinas, will.deacon, xen-devel, devicetree, linux-efi,
linux-kernel, shannon.zhao, peter.huangpeng, Rafael J. Wysocki,
Len Brown, open list:ACPI
From: Shannon Zhao <shannon.zhao@linaro.org>
ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.
CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
CC: linux-acpi@vger.kernel.org (open list:ACPI)
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..5420cc5 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
DEFINE_MUTEX(acpi_device_lock);
LIST_HEAD(acpi_wakeup_device_list);
static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
return 0;
}
+static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
+ void *context)
+{
+ struct resource *res = context;
+
+ if (acpi_dev_resource_memory(ares, res))
+ return AE_CTRL_TERMINATE;
+
+ return AE_OK;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+ acpi_status status;
+ struct resource res;
+
+ /* Check if it should ignore the UART device */
+ if (spcr_uart_addr != 0) {
+ if (!acpi_has_method(handle, METHOD_NAME__CRS))
+ return false;
+
+ status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+ acpi_get_resource_memory, &res);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ if (res.start == spcr_uart_addr) {
+ printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
{
@@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+ if (acpi_device_should_be_hidden(handle))
+ return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
return result < 0 ? result : 0;
}
+static void __init acpi_get_spcr_uart_addr(void)
+{
+ acpi_status status;
+ struct acpi_table_spcr *spcr_ptr;
+
+ status = acpi_get_table(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **)&spcr_ptr);
+ if (ACPI_SUCCESS(status))
+ spcr_uart_addr = spcr_ptr->serial_port.address;
+ else
+ printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
+}
+
int __init acpi_scan_init(void)
{
int result;
+ acpi_status status;
+ struct acpi_table_stao *stao_ptr;
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
acpi_scan_add_handler(&generic_device_handler);
+ /*
+ * If there is STAO table, check whether it needs to ignore the UART
+ * device in SPCR table.
+ */
+ status = acpi_get_table(ACPI_SIG_STAO, 0,
+ (struct acpi_table_header **)&stao_ptr);
+ if (ACPI_SUCCESS(status)) {
+ if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+ printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
+
+ if (stao_ptr->ignore_uart)
+ acpi_get_spcr_uart_addr();
+ }
+
mutex_lock(&acpi_scan_lock);
/*
* Enumerate devices in the ACPI namespace.
--
2.0.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* Re: [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-25 8:05 ` Shannon Zhao
(?)
(?)
@ 2016-03-25 17:00 ` Rafael J. Wysocki
-1 siblings, 0 replies; 172+ messages in thread
From: Rafael J. Wysocki @ 2016-03-25 17:00 UTC (permalink / raw)
To: Shannon Zhao
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, xen-devel, open list:ACPI, stefano.stabellini,
david.vrabel, peter.huangpeng, Len Brown, linux-arm-kernel,
shannon.zhao
On Friday, March 25, 2016 04:05:49 PM Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> CC: linux-acpi@vger.kernel.org (open list:ACPI)
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
So I said it looked good, but now that I think about it, I have a question. ->
> ---
> drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 5f28cf7..5420cc5 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> DEFINE_MUTEX(acpi_device_lock);
> LIST_HEAD(acpi_wakeup_device_list);
> static DEFINE_MUTEX(acpi_hp_context_lock);
> +static u64 spcr_uart_addr;
>
> struct acpi_dep_data {
> struct list_head node;
> @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> return 0;
> }
>
> +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> + void *context)
> +{
> + struct resource *res = context;
> +
> + if (acpi_dev_resource_memory(ares, res))
> + return AE_CTRL_TERMINATE;
-> It looks like this will terminate on the first memory resource found,
but what if there are more of them?
Or is it guaranteed that there will be only one for the device objects in
question?
If not, then it would better to check res.start == spcr_uart_addr here too
and only terminate if there's a match.
> +
> + return AE_OK;
> +}
> +
> +static bool acpi_device_should_be_hidden(acpi_handle handle)
> +{
> + acpi_status status;
> + struct resource res;
> +
> + /* Check if it should ignore the UART device */
> + if (spcr_uart_addr != 0) {
> + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> + return false;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> + acpi_get_resource_memory, &res);
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + if (res.start == spcr_uart_addr) {
> + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> unsigned long long *sta)
> {
> @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> switch (acpi_type) {
> case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> case ACPI_TYPE_DEVICE:
> + if (acpi_device_should_be_hidden(handle))
> + return -ENODEV;
> +
> *type = ACPI_BUS_TYPE_DEVICE;
> status = acpi_bus_get_status_handle(handle, sta);
> if (ACPI_FAILURE(status))
> @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> return result < 0 ? result : 0;
> }
>
> +static void __init acpi_get_spcr_uart_addr(void)
> +{
> + acpi_status status;
> + struct acpi_table_spcr *spcr_ptr;
> +
> + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> + (struct acpi_table_header **)&spcr_ptr);
> + if (ACPI_SUCCESS(status))
> + spcr_uart_addr = spcr_ptr->serial_port.address;
> + else
> + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> +}
> +
> int __init acpi_scan_init(void)
> {
> int result;
> + acpi_status status;
> + struct acpi_table_stao *stao_ptr;
>
> acpi_pci_root_init();
> acpi_pci_link_init();
> @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
>
> acpi_scan_add_handler(&generic_device_handler);
>
> + /*
> + * If there is STAO table, check whether it needs to ignore the UART
> + * device in SPCR table.
> + */
> + status = acpi_get_table(ACPI_SIG_STAO, 0,
> + (struct acpi_table_header **)&stao_ptr);
> + if (ACPI_SUCCESS(status)) {
> + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> +
> + if (stao_ptr->ignore_uart)
> + acpi_get_spcr_uart_addr();
> + }
> +
> mutex_lock(&acpi_scan_lock);
> /*
> * Enumerate devices in the ACPI namespace.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-25 8:05 ` Shannon Zhao
@ 2016-03-25 17:00 ` Rafael J. Wysocki
-1 siblings, 0 replies; 172+ messages in thread
From: Rafael J. Wysocki @ 2016-03-25 17:00 UTC (permalink / raw)
To: Shannon Zhao
Cc: linux-arm-kernel, stefano.stabellini, david.vrabel,
catalin.marinas, will.deacon, xen-devel, devicetree, linux-efi,
linux-kernel, shannon.zhao, peter.huangpeng, Len Brown,
open list:ACPI
On Friday, March 25, 2016 04:05:49 PM Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> CC: linux-acpi@vger.kernel.org (open list:ACPI)
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
So I said it looked good, but now that I think about it, I have a question. ->
> ---
> drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 5f28cf7..5420cc5 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> DEFINE_MUTEX(acpi_device_lock);
> LIST_HEAD(acpi_wakeup_device_list);
> static DEFINE_MUTEX(acpi_hp_context_lock);
> +static u64 spcr_uart_addr;
>
> struct acpi_dep_data {
> struct list_head node;
> @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> return 0;
> }
>
> +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> + void *context)
> +{
> + struct resource *res = context;
> +
> + if (acpi_dev_resource_memory(ares, res))
> + return AE_CTRL_TERMINATE;
-> It looks like this will terminate on the first memory resource found,
but what if there are more of them?
Or is it guaranteed that there will be only one for the device objects in
question?
If not, then it would better to check res.start == spcr_uart_addr here too
and only terminate if there's a match.
> +
> + return AE_OK;
> +}
> +
> +static bool acpi_device_should_be_hidden(acpi_handle handle)
> +{
> + acpi_status status;
> + struct resource res;
> +
> + /* Check if it should ignore the UART device */
> + if (spcr_uart_addr != 0) {
> + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> + return false;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> + acpi_get_resource_memory, &res);
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + if (res.start == spcr_uart_addr) {
> + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> unsigned long long *sta)
> {
> @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> switch (acpi_type) {
> case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> case ACPI_TYPE_DEVICE:
> + if (acpi_device_should_be_hidden(handle))
> + return -ENODEV;
> +
> *type = ACPI_BUS_TYPE_DEVICE;
> status = acpi_bus_get_status_handle(handle, sta);
> if (ACPI_FAILURE(status))
> @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> return result < 0 ? result : 0;
> }
>
> +static void __init acpi_get_spcr_uart_addr(void)
> +{
> + acpi_status status;
> + struct acpi_table_spcr *spcr_ptr;
> +
> + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> + (struct acpi_table_header **)&spcr_ptr);
> + if (ACPI_SUCCESS(status))
> + spcr_uart_addr = spcr_ptr->serial_port.address;
> + else
> + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> +}
> +
> int __init acpi_scan_init(void)
> {
> int result;
> + acpi_status status;
> + struct acpi_table_stao *stao_ptr;
>
> acpi_pci_root_init();
> acpi_pci_link_init();
> @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
>
> acpi_scan_add_handler(&generic_device_handler);
>
> + /*
> + * If there is STAO table, check whether it needs to ignore the UART
> + * device in SPCR table.
> + */
> + status = acpi_get_table(ACPI_SIG_STAO, 0,
> + (struct acpi_table_header **)&stao_ptr);
> + if (ACPI_SUCCESS(status)) {
> + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> +
> + if (stao_ptr->ignore_uart)
> + acpi_get_spcr_uart_addr();
> + }
> +
> mutex_lock(&acpi_scan_lock);
> /*
> * Enumerate devices in the ACPI namespace.
>
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-25 17:00 ` Rafael J. Wysocki
0 siblings, 0 replies; 172+ messages in thread
From: Rafael J. Wysocki @ 2016-03-25 17:00 UTC (permalink / raw)
To: linux-arm-kernel
On Friday, March 25, 2016 04:05:49 PM Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> CC: linux-acpi at vger.kernel.org (open list:ACPI)
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
So I said it looked good, but now that I think about it, I have a question. ->
> ---
> drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 5f28cf7..5420cc5 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> DEFINE_MUTEX(acpi_device_lock);
> LIST_HEAD(acpi_wakeup_device_list);
> static DEFINE_MUTEX(acpi_hp_context_lock);
> +static u64 spcr_uart_addr;
>
> struct acpi_dep_data {
> struct list_head node;
> @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> return 0;
> }
>
> +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> + void *context)
> +{
> + struct resource *res = context;
> +
> + if (acpi_dev_resource_memory(ares, res))
> + return AE_CTRL_TERMINATE;
-> It looks like this will terminate on the first memory resource found,
but what if there are more of them?
Or is it guaranteed that there will be only one for the device objects in
question?
If not, then it would better to check res.start == spcr_uart_addr here too
and only terminate if there's a match.
> +
> + return AE_OK;
> +}
> +
> +static bool acpi_device_should_be_hidden(acpi_handle handle)
> +{
> + acpi_status status;
> + struct resource res;
> +
> + /* Check if it should ignore the UART device */
> + if (spcr_uart_addr != 0) {
> + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> + return false;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> + acpi_get_resource_memory, &res);
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + if (res.start == spcr_uart_addr) {
> + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> unsigned long long *sta)
> {
> @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> switch (acpi_type) {
> case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> case ACPI_TYPE_DEVICE:
> + if (acpi_device_should_be_hidden(handle))
> + return -ENODEV;
> +
> *type = ACPI_BUS_TYPE_DEVICE;
> status = acpi_bus_get_status_handle(handle, sta);
> if (ACPI_FAILURE(status))
> @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> return result < 0 ? result : 0;
> }
>
> +static void __init acpi_get_spcr_uart_addr(void)
> +{
> + acpi_status status;
> + struct acpi_table_spcr *spcr_ptr;
> +
> + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> + (struct acpi_table_header **)&spcr_ptr);
> + if (ACPI_SUCCESS(status))
> + spcr_uart_addr = spcr_ptr->serial_port.address;
> + else
> + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> +}
> +
> int __init acpi_scan_init(void)
> {
> int result;
> + acpi_status status;
> + struct acpi_table_stao *stao_ptr;
>
> acpi_pci_root_init();
> acpi_pci_link_init();
> @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
>
> acpi_scan_add_handler(&generic_device_handler);
>
> + /*
> + * If there is STAO table, check whether it needs to ignore the UART
> + * device in SPCR table.
> + */
> + status = acpi_get_table(ACPI_SIG_STAO, 0,
> + (struct acpi_table_header **)&stao_ptr);
> + if (ACPI_SUCCESS(status)) {
> + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> +
> + if (stao_ptr->ignore_uart)
> + acpi_get_spcr_uart_addr();
> + }
> +
> mutex_lock(&acpi_scan_lock);
> /*
> * Enumerate devices in the ACPI namespace.
>
^ permalink raw reply [flat|nested] 172+ messages in thread[parent not found: <7418231.W9aSFKr1zs-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>]
* Re: [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-25 17:00 ` Rafael J. Wysocki
(?)
@ 2016-03-26 13:14 ` Stefano Stabellini
-1 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-26 13:14 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Shannon Zhao, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, xen-devel-GuqFBffKawuEi8DpZVb4nw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
shannon.zhao-QSEj5FYQhm4dnm+yROfE0A,
peter.huangpeng-hv44wF8Li93QT0dZR+AlfA, Len Brown,
open list:ACPI
On Fri, 25 Mar 2016, Rafael J. Wysocki wrote:
> On Friday, March 25, 2016 04:05:49 PM Shannon Zhao wrote:
> > From: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >
> > ACPI 6.0 introduces a new table STAO to list the devices which are used
> > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > UART is used by Xen. So here it hides UART from Dom0.
> >
> > CC: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> (supporter:ACPI)
> > CC: Len Brown <lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> (supporter:ACPI)
> > CC: linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list:ACPI)
> > Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> So I said it looked good, but now that I think about it, I have a question. ->
>
> > ---
> > drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 68 insertions(+)
> >
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 5f28cf7..5420cc5 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> > @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> > DEFINE_MUTEX(acpi_device_lock);
> > LIST_HEAD(acpi_wakeup_device_list);
> > static DEFINE_MUTEX(acpi_hp_context_lock);
> > +static u64 spcr_uart_addr;
> >
> > struct acpi_dep_data {
> > struct list_head node;
> > @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> > return 0;
> > }
> >
> > +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> > + void *context)
> > +{
> > + struct resource *res = context;
> > +
> > + if (acpi_dev_resource_memory(ares, res))
> > + return AE_CTRL_TERMINATE;
>
> -> It looks like this will terminate on the first memory resource found,
> but what if there are more of them?
>
> Or is it guaranteed that there will be only one for the device objects in
> question?
Given that spcr_uart_addr is actually the only Base Address specified by
the SPCR table, I think it is assumed that this kind of devices only
have one memory region.
> If not, then it would better to check res.start == spcr_uart_addr here too
> and only terminate if there's a match.
>
> > +
> > + return AE_OK;
> > +}
> > +
> > +static bool acpi_device_should_be_hidden(acpi_handle handle)
> > +{
> > + acpi_status status;
> > + struct resource res;
> > +
> > + /* Check if it should ignore the UART device */
> > + if (spcr_uart_addr != 0) {
> > + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> > + return false;
> > +
> > + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> > + acpi_get_resource_memory, &res);
> > + if (ACPI_FAILURE(status))
> > + return false;
> > +
> > + if (res.start == spcr_uart_addr) {
> > + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
> > + return true;
> > + }
> > + }
> > +
> > + return false;
> > +}
> > +
> > static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > unsigned long long *sta)
> > {
> > @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > switch (acpi_type) {
> > case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> > case ACPI_TYPE_DEVICE:
> > + if (acpi_device_should_be_hidden(handle))
> > + return -ENODEV;
> > +
> > *type = ACPI_BUS_TYPE_DEVICE;
> > status = acpi_bus_get_status_handle(handle, sta);
> > if (ACPI_FAILURE(status))
> > @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> > return result < 0 ? result : 0;
> > }
> >
> > +static void __init acpi_get_spcr_uart_addr(void)
> > +{
> > + acpi_status status;
> > + struct acpi_table_spcr *spcr_ptr;
> > +
> > + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> > + (struct acpi_table_header **)&spcr_ptr);
> > + if (ACPI_SUCCESS(status))
> > + spcr_uart_addr = spcr_ptr->serial_port.address;
> > + else
> > + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> > +}
> > +
> > int __init acpi_scan_init(void)
> > {
> > int result;
> > + acpi_status status;
> > + struct acpi_table_stao *stao_ptr;
> >
> > acpi_pci_root_init();
> > acpi_pci_link_init();
> > @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
> >
> > acpi_scan_add_handler(&generic_device_handler);
> >
> > + /*
> > + * If there is STAO table, check whether it needs to ignore the UART
> > + * device in SPCR table.
> > + */
> > + status = acpi_get_table(ACPI_SIG_STAO, 0,
> > + (struct acpi_table_header **)&stao_ptr);
> > + if (ACPI_SUCCESS(status)) {
> > + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> > + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> > +
> > + if (stao_ptr->ignore_uart)
> > + acpi_get_spcr_uart_addr();
> > + }
> > +
> > mutex_lock(&acpi_scan_lock);
> > /*
> > * Enumerate devices in the ACPI namespace.
> >
>
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-26 13:14 ` Stefano Stabellini
0 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-26 13:14 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 25 Mar 2016, Rafael J. Wysocki wrote:
> On Friday, March 25, 2016 04:05:49 PM Shannon Zhao wrote:
> > From: Shannon Zhao <shannon.zhao@linaro.org>
> >
> > ACPI 6.0 introduces a new table STAO to list the devices which are used
> > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > UART is used by Xen. So here it hides UART from Dom0.
> >
> > CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> > CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> > CC: linux-acpi at vger.kernel.org (open list:ACPI)
> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>
> So I said it looked good, but now that I think about it, I have a question. ->
>
> > ---
> > drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 68 insertions(+)
> >
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 5f28cf7..5420cc5 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> > @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> > DEFINE_MUTEX(acpi_device_lock);
> > LIST_HEAD(acpi_wakeup_device_list);
> > static DEFINE_MUTEX(acpi_hp_context_lock);
> > +static u64 spcr_uart_addr;
> >
> > struct acpi_dep_data {
> > struct list_head node;
> > @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> > return 0;
> > }
> >
> > +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> > + void *context)
> > +{
> > + struct resource *res = context;
> > +
> > + if (acpi_dev_resource_memory(ares, res))
> > + return AE_CTRL_TERMINATE;
>
> -> It looks like this will terminate on the first memory resource found,
> but what if there are more of them?
>
> Or is it guaranteed that there will be only one for the device objects in
> question?
Given that spcr_uart_addr is actually the only Base Address specified by
the SPCR table, I think it is assumed that this kind of devices only
have one memory region.
> If not, then it would better to check res.start == spcr_uart_addr here too
> and only terminate if there's a match.
>
> > +
> > + return AE_OK;
> > +}
> > +
> > +static bool acpi_device_should_be_hidden(acpi_handle handle)
> > +{
> > + acpi_status status;
> > + struct resource res;
> > +
> > + /* Check if it should ignore the UART device */
> > + if (spcr_uart_addr != 0) {
> > + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> > + return false;
> > +
> > + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> > + acpi_get_resource_memory, &res);
> > + if (ACPI_FAILURE(status))
> > + return false;
> > +
> > + if (res.start == spcr_uart_addr) {
> > + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
> > + return true;
> > + }
> > + }
> > +
> > + return false;
> > +}
> > +
> > static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > unsigned long long *sta)
> > {
> > @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > switch (acpi_type) {
> > case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> > case ACPI_TYPE_DEVICE:
> > + if (acpi_device_should_be_hidden(handle))
> > + return -ENODEV;
> > +
> > *type = ACPI_BUS_TYPE_DEVICE;
> > status = acpi_bus_get_status_handle(handle, sta);
> > if (ACPI_FAILURE(status))
> > @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> > return result < 0 ? result : 0;
> > }
> >
> > +static void __init acpi_get_spcr_uart_addr(void)
> > +{
> > + acpi_status status;
> > + struct acpi_table_spcr *spcr_ptr;
> > +
> > + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> > + (struct acpi_table_header **)&spcr_ptr);
> > + if (ACPI_SUCCESS(status))
> > + spcr_uart_addr = spcr_ptr->serial_port.address;
> > + else
> > + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> > +}
> > +
> > int __init acpi_scan_init(void)
> > {
> > int result;
> > + acpi_status status;
> > + struct acpi_table_stao *stao_ptr;
> >
> > acpi_pci_root_init();
> > acpi_pci_link_init();
> > @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
> >
> > acpi_scan_add_handler(&generic_device_handler);
> >
> > + /*
> > + * If there is STAO table, check whether it needs to ignore the UART
> > + * device in SPCR table.
> > + */
> > + status = acpi_get_table(ACPI_SIG_STAO, 0,
> > + (struct acpi_table_header **)&stao_ptr);
> > + if (ACPI_SUCCESS(status)) {
> > + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> > + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> > +
> > + if (stao_ptr->ignore_uart)
> > + acpi_get_spcr_uart_addr();
> > + }
> > +
> > mutex_lock(&acpi_scan_lock);
> > /*
> > * Enumerate devices in the ACPI namespace.
> >
>
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-26 13:14 ` Stefano Stabellini
0 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-26 13:14 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Shannon Zhao, linux-arm-kernel, stefano.stabellini, david.vrabel,
catalin.marinas, will.deacon, xen-devel, devicetree, linux-efi,
linux-kernel, shannon.zhao, peter.huangpeng, Len Brown,
open list:ACPI
On Fri, 25 Mar 2016, Rafael J. Wysocki wrote:
> On Friday, March 25, 2016 04:05:49 PM Shannon Zhao wrote:
> > From: Shannon Zhao <shannon.zhao@linaro.org>
> >
> > ACPI 6.0 introduces a new table STAO to list the devices which are used
> > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > UART is used by Xen. So here it hides UART from Dom0.
> >
> > CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> > CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> > CC: linux-acpi@vger.kernel.org (open list:ACPI)
> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>
> So I said it looked good, but now that I think about it, I have a question. ->
>
> > ---
> > drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 68 insertions(+)
> >
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 5f28cf7..5420cc5 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> > @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> > DEFINE_MUTEX(acpi_device_lock);
> > LIST_HEAD(acpi_wakeup_device_list);
> > static DEFINE_MUTEX(acpi_hp_context_lock);
> > +static u64 spcr_uart_addr;
> >
> > struct acpi_dep_data {
> > struct list_head node;
> > @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> > return 0;
> > }
> >
> > +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> > + void *context)
> > +{
> > + struct resource *res = context;
> > +
> > + if (acpi_dev_resource_memory(ares, res))
> > + return AE_CTRL_TERMINATE;
>
> -> It looks like this will terminate on the first memory resource found,
> but what if there are more of them?
>
> Or is it guaranteed that there will be only one for the device objects in
> question?
Given that spcr_uart_addr is actually the only Base Address specified by
the SPCR table, I think it is assumed that this kind of devices only
have one memory region.
> If not, then it would better to check res.start == spcr_uart_addr here too
> and only terminate if there's a match.
>
> > +
> > + return AE_OK;
> > +}
> > +
> > +static bool acpi_device_should_be_hidden(acpi_handle handle)
> > +{
> > + acpi_status status;
> > + struct resource res;
> > +
> > + /* Check if it should ignore the UART device */
> > + if (spcr_uart_addr != 0) {
> > + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> > + return false;
> > +
> > + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> > + acpi_get_resource_memory, &res);
> > + if (ACPI_FAILURE(status))
> > + return false;
> > +
> > + if (res.start == spcr_uart_addr) {
> > + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
> > + return true;
> > + }
> > + }
> > +
> > + return false;
> > +}
> > +
> > static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > unsigned long long *sta)
> > {
> > @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > switch (acpi_type) {
> > case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> > case ACPI_TYPE_DEVICE:
> > + if (acpi_device_should_be_hidden(handle))
> > + return -ENODEV;
> > +
> > *type = ACPI_BUS_TYPE_DEVICE;
> > status = acpi_bus_get_status_handle(handle, sta);
> > if (ACPI_FAILURE(status))
> > @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> > return result < 0 ? result : 0;
> > }
> >
> > +static void __init acpi_get_spcr_uart_addr(void)
> > +{
> > + acpi_status status;
> > + struct acpi_table_spcr *spcr_ptr;
> > +
> > + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> > + (struct acpi_table_header **)&spcr_ptr);
> > + if (ACPI_SUCCESS(status))
> > + spcr_uart_addr = spcr_ptr->serial_port.address;
> > + else
> > + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> > +}
> > +
> > int __init acpi_scan_init(void)
> > {
> > int result;
> > + acpi_status status;
> > + struct acpi_table_stao *stao_ptr;
> >
> > acpi_pci_root_init();
> > acpi_pci_link_init();
> > @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
> >
> > acpi_scan_add_handler(&generic_device_handler);
> >
> > + /*
> > + * If there is STAO table, check whether it needs to ignore the UART
> > + * device in SPCR table.
> > + */
> > + status = acpi_get_table(ACPI_SIG_STAO, 0,
> > + (struct acpi_table_header **)&stao_ptr);
> > + if (ACPI_SUCCESS(status)) {
> > + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> > + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> > +
> > + if (stao_ptr->ignore_uart)
> > + acpi_get_spcr_uart_addr();
> > + }
> > +
> > mutex_lock(&acpi_scan_lock);
> > /*
> > * Enumerate devices in the ACPI namespace.
> >
>
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-25 17:00 ` Rafael J. Wysocki
(?)
(?)
@ 2016-03-26 13:14 ` Stefano Stabellini
-1 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-26 13:14 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, xen-devel, open list:ACPI, stefano.stabellini,
david.vrabel, Shannon Zhao, peter.huangpeng, Len Brown,
linux-arm-kernel, shannon.zhao
On Fri, 25 Mar 2016, Rafael J. Wysocki wrote:
> On Friday, March 25, 2016 04:05:49 PM Shannon Zhao wrote:
> > From: Shannon Zhao <shannon.zhao@linaro.org>
> >
> > ACPI 6.0 introduces a new table STAO to list the devices which are used
> > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > UART is used by Xen. So here it hides UART from Dom0.
> >
> > CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> > CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> > CC: linux-acpi@vger.kernel.org (open list:ACPI)
> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>
> So I said it looked good, but now that I think about it, I have a question. ->
>
> > ---
> > drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 68 insertions(+)
> >
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 5f28cf7..5420cc5 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> > @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> > DEFINE_MUTEX(acpi_device_lock);
> > LIST_HEAD(acpi_wakeup_device_list);
> > static DEFINE_MUTEX(acpi_hp_context_lock);
> > +static u64 spcr_uart_addr;
> >
> > struct acpi_dep_data {
> > struct list_head node;
> > @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> > return 0;
> > }
> >
> > +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> > + void *context)
> > +{
> > + struct resource *res = context;
> > +
> > + if (acpi_dev_resource_memory(ares, res))
> > + return AE_CTRL_TERMINATE;
>
> -> It looks like this will terminate on the first memory resource found,
> but what if there are more of them?
>
> Or is it guaranteed that there will be only one for the device objects in
> question?
Given that spcr_uart_addr is actually the only Base Address specified by
the SPCR table, I think it is assumed that this kind of devices only
have one memory region.
> If not, then it would better to check res.start == spcr_uart_addr here too
> and only terminate if there's a match.
>
> > +
> > + return AE_OK;
> > +}
> > +
> > +static bool acpi_device_should_be_hidden(acpi_handle handle)
> > +{
> > + acpi_status status;
> > + struct resource res;
> > +
> > + /* Check if it should ignore the UART device */
> > + if (spcr_uart_addr != 0) {
> > + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> > + return false;
> > +
> > + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> > + acpi_get_resource_memory, &res);
> > + if (ACPI_FAILURE(status))
> > + return false;
> > +
> > + if (res.start == spcr_uart_addr) {
> > + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
> > + return true;
> > + }
> > + }
> > +
> > + return false;
> > +}
> > +
> > static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > unsigned long long *sta)
> > {
> > @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > switch (acpi_type) {
> > case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> > case ACPI_TYPE_DEVICE:
> > + if (acpi_device_should_be_hidden(handle))
> > + return -ENODEV;
> > +
> > *type = ACPI_BUS_TYPE_DEVICE;
> > status = acpi_bus_get_status_handle(handle, sta);
> > if (ACPI_FAILURE(status))
> > @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> > return result < 0 ? result : 0;
> > }
> >
> > +static void __init acpi_get_spcr_uart_addr(void)
> > +{
> > + acpi_status status;
> > + struct acpi_table_spcr *spcr_ptr;
> > +
> > + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> > + (struct acpi_table_header **)&spcr_ptr);
> > + if (ACPI_SUCCESS(status))
> > + spcr_uart_addr = spcr_ptr->serial_port.address;
> > + else
> > + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> > +}
> > +
> > int __init acpi_scan_init(void)
> > {
> > int result;
> > + acpi_status status;
> > + struct acpi_table_stao *stao_ptr;
> >
> > acpi_pci_root_init();
> > acpi_pci_link_init();
> > @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
> >
> > acpi_scan_add_handler(&generic_device_handler);
> >
> > + /*
> > + * If there is STAO table, check whether it needs to ignore the UART
> > + * device in SPCR table.
> > + */
> > + status = acpi_get_table(ACPI_SIG_STAO, 0,
> > + (struct acpi_table_header **)&stao_ptr);
> > + if (ACPI_SUCCESS(status)) {
> > + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> > + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> > +
> > + if (stao_ptr->ignore_uart)
> > + acpi_get_spcr_uart_addr();
> > + }
> > +
> > mutex_lock(&acpi_scan_lock);
> > /*
> > * Enumerate devices in the ACPI namespace.
> >
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-25 8:05 ` Shannon Zhao
` (3 preceding siblings ...)
(?)
@ 2016-03-25 17:15 ` Bjorn Helgaas
-1 siblings, 0 replies; 172+ messages in thread
From: Bjorn Helgaas @ 2016-03-25 17:15 UTC (permalink / raw)
To: Shannon Zhao
Cc: devicetree, linux-efi, Rafael J. Wysocki, catalin.marinas,
will.deacon, linux-kernel, xen-devel, open list:ACPI,
stefano.stabellini, david.vrabel, peter.huangpeng, Len Brown,
linux-arm-kernel, shannon.zhao
On Fri, Mar 25, 2016 at 04:05:49PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> CC: linux-acpi@vger.kernel.org (open list:ACPI)
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 5f28cf7..5420cc5 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> DEFINE_MUTEX(acpi_device_lock);
> LIST_HEAD(acpi_wakeup_device_list);
> static DEFINE_MUTEX(acpi_hp_context_lock);
> +static u64 spcr_uart_addr;
>
> struct acpi_dep_data {
> struct list_head node;
> @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> return 0;
> }
>
> +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> + void *context)
> +{
> + struct resource *res = context;
> +
> + if (acpi_dev_resource_memory(ares, res))
> + return AE_CTRL_TERMINATE;
> +
> + return AE_OK;
> +}
> +
> +static bool acpi_device_should_be_hidden(acpi_handle handle)
> +{
> + acpi_status status;
> + struct resource res;
> +
> + /* Check if it should ignore the UART device */
> + if (spcr_uart_addr != 0) {
> + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> + return false;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> + acpi_get_resource_memory, &res);
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + if (res.start == spcr_uart_addr) {
> + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
Can we at least print out the ACPI device path and address here for
debugging purposes? IMHO, kernel messages that contain only static
text are always dubious. There's almost always a useful address, IRQ,
return value, etc., that could be included.
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> unsigned long long *sta)
> {
> @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> switch (acpi_type) {
> case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> case ACPI_TYPE_DEVICE:
> + if (acpi_device_should_be_hidden(handle))
> + return -ENODEV;
> +
> *type = ACPI_BUS_TYPE_DEVICE;
> status = acpi_bus_get_status_handle(handle, sta);
> if (ACPI_FAILURE(status))
> @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> return result < 0 ? result : 0;
> }
>
> +static void __init acpi_get_spcr_uart_addr(void)
> +{
> + acpi_status status;
> + struct acpi_table_spcr *spcr_ptr;
> +
> + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> + (struct acpi_table_header **)&spcr_ptr);
> + if (ACPI_SUCCESS(status))
> + spcr_uart_addr = spcr_ptr->serial_port.address;
> + else
> + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> +}
> +
> int __init acpi_scan_init(void)
> {
> int result;
> + acpi_status status;
> + struct acpi_table_stao *stao_ptr;
>
> acpi_pci_root_init();
> acpi_pci_link_init();
> @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
>
> acpi_scan_add_handler(&generic_device_handler);
>
> + /*
> + * If there is STAO table, check whether it needs to ignore the UART
> + * device in SPCR table.
> + */
> + status = acpi_get_table(ACPI_SIG_STAO, 0,
> + (struct acpi_table_header **)&stao_ptr);
> + if (ACPI_SUCCESS(status)) {
> + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> +
> + if (stao_ptr->ignore_uart)
> + acpi_get_spcr_uart_addr();
> + }
This all seems sort of ad hoc. Are UARTs the only things that can be
listed in STAO? If STAO can contain things other than UARTs, are we
going to see more patches adding special-case code like this?
> mutex_lock(&acpi_scan_lock);
> /*
> * Enumerate devices in the ACPI namespace.
> --
> 2.0.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-25 8:05 ` Shannon Zhao
@ 2016-03-25 17:15 ` Bjorn Helgaas
-1 siblings, 0 replies; 172+ messages in thread
From: Bjorn Helgaas @ 2016-03-25 17:15 UTC (permalink / raw)
To: Shannon Zhao
Cc: linux-arm-kernel, stefano.stabellini, david.vrabel,
catalin.marinas, will.deacon, xen-devel, devicetree, linux-efi,
linux-kernel, shannon.zhao, peter.huangpeng, Rafael J. Wysocki,
Len Brown, open list:ACPI
On Fri, Mar 25, 2016 at 04:05:49PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> CC: linux-acpi@vger.kernel.org (open list:ACPI)
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 5f28cf7..5420cc5 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> DEFINE_MUTEX(acpi_device_lock);
> LIST_HEAD(acpi_wakeup_device_list);
> static DEFINE_MUTEX(acpi_hp_context_lock);
> +static u64 spcr_uart_addr;
>
> struct acpi_dep_data {
> struct list_head node;
> @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> return 0;
> }
>
> +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> + void *context)
> +{
> + struct resource *res = context;
> +
> + if (acpi_dev_resource_memory(ares, res))
> + return AE_CTRL_TERMINATE;
> +
> + return AE_OK;
> +}
> +
> +static bool acpi_device_should_be_hidden(acpi_handle handle)
> +{
> + acpi_status status;
> + struct resource res;
> +
> + /* Check if it should ignore the UART device */
> + if (spcr_uart_addr != 0) {
> + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> + return false;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> + acpi_get_resource_memory, &res);
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + if (res.start == spcr_uart_addr) {
> + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
Can we at least print out the ACPI device path and address here for
debugging purposes? IMHO, kernel messages that contain only static
text are always dubious. There's almost always a useful address, IRQ,
return value, etc., that could be included.
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> unsigned long long *sta)
> {
> @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> switch (acpi_type) {
> case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> case ACPI_TYPE_DEVICE:
> + if (acpi_device_should_be_hidden(handle))
> + return -ENODEV;
> +
> *type = ACPI_BUS_TYPE_DEVICE;
> status = acpi_bus_get_status_handle(handle, sta);
> if (ACPI_FAILURE(status))
> @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> return result < 0 ? result : 0;
> }
>
> +static void __init acpi_get_spcr_uart_addr(void)
> +{
> + acpi_status status;
> + struct acpi_table_spcr *spcr_ptr;
> +
> + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> + (struct acpi_table_header **)&spcr_ptr);
> + if (ACPI_SUCCESS(status))
> + spcr_uart_addr = spcr_ptr->serial_port.address;
> + else
> + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> +}
> +
> int __init acpi_scan_init(void)
> {
> int result;
> + acpi_status status;
> + struct acpi_table_stao *stao_ptr;
>
> acpi_pci_root_init();
> acpi_pci_link_init();
> @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
>
> acpi_scan_add_handler(&generic_device_handler);
>
> + /*
> + * If there is STAO table, check whether it needs to ignore the UART
> + * device in SPCR table.
> + */
> + status = acpi_get_table(ACPI_SIG_STAO, 0,
> + (struct acpi_table_header **)&stao_ptr);
> + if (ACPI_SUCCESS(status)) {
> + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> +
> + if (stao_ptr->ignore_uart)
> + acpi_get_spcr_uart_addr();
> + }
This all seems sort of ad hoc. Are UARTs the only things that can be
listed in STAO? If STAO can contain things other than UARTs, are we
going to see more patches adding special-case code like this?
> mutex_lock(&acpi_scan_lock);
> /*
> * Enumerate devices in the ACPI namespace.
> --
> 2.0.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-25 17:15 ` Bjorn Helgaas
0 siblings, 0 replies; 172+ messages in thread
From: Bjorn Helgaas @ 2016-03-25 17:15 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Mar 25, 2016 at 04:05:49PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> CC: linux-acpi at vger.kernel.org (open list:ACPI)
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 5f28cf7..5420cc5 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> DEFINE_MUTEX(acpi_device_lock);
> LIST_HEAD(acpi_wakeup_device_list);
> static DEFINE_MUTEX(acpi_hp_context_lock);
> +static u64 spcr_uart_addr;
>
> struct acpi_dep_data {
> struct list_head node;
> @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> return 0;
> }
>
> +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> + void *context)
> +{
> + struct resource *res = context;
> +
> + if (acpi_dev_resource_memory(ares, res))
> + return AE_CTRL_TERMINATE;
> +
> + return AE_OK;
> +}
> +
> +static bool acpi_device_should_be_hidden(acpi_handle handle)
> +{
> + acpi_status status;
> + struct resource res;
> +
> + /* Check if it should ignore the UART device */
> + if (spcr_uart_addr != 0) {
> + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> + return false;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> + acpi_get_resource_memory, &res);
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + if (res.start == spcr_uart_addr) {
> + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
Can we at least print out the ACPI device path and address here for
debugging purposes? IMHO, kernel messages that contain only static
text are always dubious. There's almost always a useful address, IRQ,
return value, etc., that could be included.
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> unsigned long long *sta)
> {
> @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> switch (acpi_type) {
> case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> case ACPI_TYPE_DEVICE:
> + if (acpi_device_should_be_hidden(handle))
> + return -ENODEV;
> +
> *type = ACPI_BUS_TYPE_DEVICE;
> status = acpi_bus_get_status_handle(handle, sta);
> if (ACPI_FAILURE(status))
> @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> return result < 0 ? result : 0;
> }
>
> +static void __init acpi_get_spcr_uart_addr(void)
> +{
> + acpi_status status;
> + struct acpi_table_spcr *spcr_ptr;
> +
> + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> + (struct acpi_table_header **)&spcr_ptr);
> + if (ACPI_SUCCESS(status))
> + spcr_uart_addr = spcr_ptr->serial_port.address;
> + else
> + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> +}
> +
> int __init acpi_scan_init(void)
> {
> int result;
> + acpi_status status;
> + struct acpi_table_stao *stao_ptr;
>
> acpi_pci_root_init();
> acpi_pci_link_init();
> @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
>
> acpi_scan_add_handler(&generic_device_handler);
>
> + /*
> + * If there is STAO table, check whether it needs to ignore the UART
> + * device in SPCR table.
> + */
> + status = acpi_get_table(ACPI_SIG_STAO, 0,
> + (struct acpi_table_header **)&stao_ptr);
> + if (ACPI_SUCCESS(status)) {
> + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> +
> + if (stao_ptr->ignore_uart)
> + acpi_get_spcr_uart_addr();
> + }
This all seems sort of ad hoc. Are UARTs the only things that can be
listed in STAO? If STAO can contain things other than UARTs, are we
going to see more patches adding special-case code like this?
> mutex_lock(&acpi_scan_lock);
> /*
> * Enumerate devices in the ACPI namespace.
> --
> 2.0.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-25 17:15 ` Bjorn Helgaas
(?)
@ 2016-03-26 12:44 ` Stefano Stabellini
-1 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-26 12:44 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: devicetree, linux-efi, Rafael J. Wysocki, catalin.marinas,
will.deacon, linux-kernel, xen-devel, open list:ACPI,
stefano.stabellini, david.vrabel, Shannon Zhao, peter.huangpeng,
Len Brown, linux-arm-kernel, shannon.zhao
On Fri, 25 Mar 2016, Bjorn Helgaas wrote:
> On Fri, Mar 25, 2016 at 04:05:49PM +0800, Shannon Zhao wrote:
> > From: Shannon Zhao <shannon.zhao@linaro.org>
> >
> > ACPI 6.0 introduces a new table STAO to list the devices which are used
> > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > UART is used by Xen. So here it hides UART from Dom0.
> >
> > CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> > CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> > CC: linux-acpi@vger.kernel.org (open list:ACPI)
> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> > ---
> > drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 68 insertions(+)
> >
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 5f28cf7..5420cc5 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> > @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> > DEFINE_MUTEX(acpi_device_lock);
> > LIST_HEAD(acpi_wakeup_device_list);
> > static DEFINE_MUTEX(acpi_hp_context_lock);
> > +static u64 spcr_uart_addr;
> >
> > struct acpi_dep_data {
> > struct list_head node;
> > @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> > return 0;
> > }
> >
> > +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> > + void *context)
> > +{
> > + struct resource *res = context;
> > +
> > + if (acpi_dev_resource_memory(ares, res))
> > + return AE_CTRL_TERMINATE;
> > +
> > + return AE_OK;
> > +}
> > +
> > +static bool acpi_device_should_be_hidden(acpi_handle handle)
> > +{
> > + acpi_status status;
> > + struct resource res;
> > +
> > + /* Check if it should ignore the UART device */
> > + if (spcr_uart_addr != 0) {
> > + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> > + return false;
> > +
> > + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> > + acpi_get_resource_memory, &res);
> > + if (ACPI_FAILURE(status))
> > + return false;
> > +
> > + if (res.start == spcr_uart_addr) {
> > + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
>
> Can we at least print out the ACPI device path and address here for
> debugging purposes? IMHO, kernel messages that contain only static
> text are always dubious. There's almost always a useful address, IRQ,
> return value, etc., that could be included.
>
> > + return true;
> > + }
> > + }
> > +
> > + return false;
> > +}
> > +
> > static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > unsigned long long *sta)
> > {
> > @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > switch (acpi_type) {
> > case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> > case ACPI_TYPE_DEVICE:
> > + if (acpi_device_should_be_hidden(handle))
> > + return -ENODEV;
> > +
> > *type = ACPI_BUS_TYPE_DEVICE;
> > status = acpi_bus_get_status_handle(handle, sta);
> > if (ACPI_FAILURE(status))
> > @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> > return result < 0 ? result : 0;
> > }
> >
> > +static void __init acpi_get_spcr_uart_addr(void)
> > +{
> > + acpi_status status;
> > + struct acpi_table_spcr *spcr_ptr;
> > +
> > + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> > + (struct acpi_table_header **)&spcr_ptr);
> > + if (ACPI_SUCCESS(status))
> > + spcr_uart_addr = spcr_ptr->serial_port.address;
> > + else
> > + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> > +}
> > +
> > int __init acpi_scan_init(void)
> > {
> > int result;
> > + acpi_status status;
> > + struct acpi_table_stao *stao_ptr;
> >
> > acpi_pci_root_init();
> > acpi_pci_link_init();
> > @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
> >
> > acpi_scan_add_handler(&generic_device_handler);
> >
> > + /*
> > + * If there is STAO table, check whether it needs to ignore the UART
> > + * device in SPCR table.
> > + */
> > + status = acpi_get_table(ACPI_SIG_STAO, 0,
> > + (struct acpi_table_header **)&stao_ptr);
> > + if (ACPI_SUCCESS(status)) {
> > + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> > + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> > +
> > + if (stao_ptr->ignore_uart)
> > + acpi_get_spcr_uart_addr();
> > + }
>
> This all seems sort of ad hoc. Are UARTs the only things that can be
> listed in STAO? If STAO can contain things other than UARTs, are we
> going to see more patches adding special-case code like this?
The UART (specifically the UART described by the SPCR table) is the only
object which needs special-casing. Everything else is covered by ACPI
namespace paths (which is what the message above is about, given that it
is not supported by this patch).
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-25 17:15 ` Bjorn Helgaas
(?)
@ 2016-03-26 12:44 ` Stefano Stabellini
-1 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-26 12:44 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Shannon Zhao, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, xen-devel-GuqFBffKawuEi8DpZVb4nw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
shannon.zhao-QSEj5FYQhm4dnm+yROfE0A,
peter.huangpeng-hv44wF8Li93QT0dZR+AlfA, Rafael J. Wysocki,
Len Brown, open list:ACPI
On Fri, 25 Mar 2016, Bjorn Helgaas wrote:
> On Fri, Mar 25, 2016 at 04:05:49PM +0800, Shannon Zhao wrote:
> > From: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >
> > ACPI 6.0 introduces a new table STAO to list the devices which are used
> > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > UART is used by Xen. So here it hides UART from Dom0.
> >
> > CC: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> (supporter:ACPI)
> > CC: Len Brown <lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> (supporter:ACPI)
> > CC: linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list:ACPI)
> > Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > ---
> > drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 68 insertions(+)
> >
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 5f28cf7..5420cc5 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> > @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> > DEFINE_MUTEX(acpi_device_lock);
> > LIST_HEAD(acpi_wakeup_device_list);
> > static DEFINE_MUTEX(acpi_hp_context_lock);
> > +static u64 spcr_uart_addr;
> >
> > struct acpi_dep_data {
> > struct list_head node;
> > @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> > return 0;
> > }
> >
> > +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> > + void *context)
> > +{
> > + struct resource *res = context;
> > +
> > + if (acpi_dev_resource_memory(ares, res))
> > + return AE_CTRL_TERMINATE;
> > +
> > + return AE_OK;
> > +}
> > +
> > +static bool acpi_device_should_be_hidden(acpi_handle handle)
> > +{
> > + acpi_status status;
> > + struct resource res;
> > +
> > + /* Check if it should ignore the UART device */
> > + if (spcr_uart_addr != 0) {
> > + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> > + return false;
> > +
> > + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> > + acpi_get_resource_memory, &res);
> > + if (ACPI_FAILURE(status))
> > + return false;
> > +
> > + if (res.start == spcr_uart_addr) {
> > + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
>
> Can we at least print out the ACPI device path and address here for
> debugging purposes? IMHO, kernel messages that contain only static
> text are always dubious. There's almost always a useful address, IRQ,
> return value, etc., that could be included.
>
> > + return true;
> > + }
> > + }
> > +
> > + return false;
> > +}
> > +
> > static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > unsigned long long *sta)
> > {
> > @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > switch (acpi_type) {
> > case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> > case ACPI_TYPE_DEVICE:
> > + if (acpi_device_should_be_hidden(handle))
> > + return -ENODEV;
> > +
> > *type = ACPI_BUS_TYPE_DEVICE;
> > status = acpi_bus_get_status_handle(handle, sta);
> > if (ACPI_FAILURE(status))
> > @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> > return result < 0 ? result : 0;
> > }
> >
> > +static void __init acpi_get_spcr_uart_addr(void)
> > +{
> > + acpi_status status;
> > + struct acpi_table_spcr *spcr_ptr;
> > +
> > + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> > + (struct acpi_table_header **)&spcr_ptr);
> > + if (ACPI_SUCCESS(status))
> > + spcr_uart_addr = spcr_ptr->serial_port.address;
> > + else
> > + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> > +}
> > +
> > int __init acpi_scan_init(void)
> > {
> > int result;
> > + acpi_status status;
> > + struct acpi_table_stao *stao_ptr;
> >
> > acpi_pci_root_init();
> > acpi_pci_link_init();
> > @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
> >
> > acpi_scan_add_handler(&generic_device_handler);
> >
> > + /*
> > + * If there is STAO table, check whether it needs to ignore the UART
> > + * device in SPCR table.
> > + */
> > + status = acpi_get_table(ACPI_SIG_STAO, 0,
> > + (struct acpi_table_header **)&stao_ptr);
> > + if (ACPI_SUCCESS(status)) {
> > + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> > + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> > +
> > + if (stao_ptr->ignore_uart)
> > + acpi_get_spcr_uart_addr();
> > + }
>
> This all seems sort of ad hoc. Are UARTs the only things that can be
> listed in STAO? If STAO can contain things other than UARTs, are we
> going to see more patches adding special-case code like this?
The UART (specifically the UART described by the SPCR table) is the only
object which needs special-casing. Everything else is covered by ACPI
namespace paths (which is what the message above is about, given that it
is not supported by this patch).
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-26 12:44 ` Stefano Stabellini
0 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-26 12:44 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 25 Mar 2016, Bjorn Helgaas wrote:
> On Fri, Mar 25, 2016 at 04:05:49PM +0800, Shannon Zhao wrote:
> > From: Shannon Zhao <shannon.zhao@linaro.org>
> >
> > ACPI 6.0 introduces a new table STAO to list the devices which are used
> > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > UART is used by Xen. So here it hides UART from Dom0.
> >
> > CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> > CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> > CC: linux-acpi at vger.kernel.org (open list:ACPI)
> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> > ---
> > drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 68 insertions(+)
> >
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 5f28cf7..5420cc5 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> > @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> > DEFINE_MUTEX(acpi_device_lock);
> > LIST_HEAD(acpi_wakeup_device_list);
> > static DEFINE_MUTEX(acpi_hp_context_lock);
> > +static u64 spcr_uart_addr;
> >
> > struct acpi_dep_data {
> > struct list_head node;
> > @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> > return 0;
> > }
> >
> > +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> > + void *context)
> > +{
> > + struct resource *res = context;
> > +
> > + if (acpi_dev_resource_memory(ares, res))
> > + return AE_CTRL_TERMINATE;
> > +
> > + return AE_OK;
> > +}
> > +
> > +static bool acpi_device_should_be_hidden(acpi_handle handle)
> > +{
> > + acpi_status status;
> > + struct resource res;
> > +
> > + /* Check if it should ignore the UART device */
> > + if (spcr_uart_addr != 0) {
> > + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> > + return false;
> > +
> > + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> > + acpi_get_resource_memory, &res);
> > + if (ACPI_FAILURE(status))
> > + return false;
> > +
> > + if (res.start == spcr_uart_addr) {
> > + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
>
> Can we at least print out the ACPI device path and address here for
> debugging purposes? IMHO, kernel messages that contain only static
> text are always dubious. There's almost always a useful address, IRQ,
> return value, etc., that could be included.
>
> > + return true;
> > + }
> > + }
> > +
> > + return false;
> > +}
> > +
> > static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > unsigned long long *sta)
> > {
> > @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > switch (acpi_type) {
> > case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> > case ACPI_TYPE_DEVICE:
> > + if (acpi_device_should_be_hidden(handle))
> > + return -ENODEV;
> > +
> > *type = ACPI_BUS_TYPE_DEVICE;
> > status = acpi_bus_get_status_handle(handle, sta);
> > if (ACPI_FAILURE(status))
> > @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> > return result < 0 ? result : 0;
> > }
> >
> > +static void __init acpi_get_spcr_uart_addr(void)
> > +{
> > + acpi_status status;
> > + struct acpi_table_spcr *spcr_ptr;
> > +
> > + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> > + (struct acpi_table_header **)&spcr_ptr);
> > + if (ACPI_SUCCESS(status))
> > + spcr_uart_addr = spcr_ptr->serial_port.address;
> > + else
> > + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> > +}
> > +
> > int __init acpi_scan_init(void)
> > {
> > int result;
> > + acpi_status status;
> > + struct acpi_table_stao *stao_ptr;
> >
> > acpi_pci_root_init();
> > acpi_pci_link_init();
> > @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
> >
> > acpi_scan_add_handler(&generic_device_handler);
> >
> > + /*
> > + * If there is STAO table, check whether it needs to ignore the UART
> > + * device in SPCR table.
> > + */
> > + status = acpi_get_table(ACPI_SIG_STAO, 0,
> > + (struct acpi_table_header **)&stao_ptr);
> > + if (ACPI_SUCCESS(status)) {
> > + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> > + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> > +
> > + if (stao_ptr->ignore_uart)
> > + acpi_get_spcr_uart_addr();
> > + }
>
> This all seems sort of ad hoc. Are UARTs the only things that can be
> listed in STAO? If STAO can contain things other than UARTs, are we
> going to see more patches adding special-case code like this?
The UART (specifically the UART described by the SPCR table) is the only
object which needs special-casing. Everything else is covered by ACPI
namespace paths (which is what the message above is about, given that it
is not supported by this patch).
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-26 12:44 ` Stefano Stabellini
0 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-26 12:44 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Shannon Zhao, linux-arm-kernel, stefano.stabellini, david.vrabel,
catalin.marinas, will.deacon, xen-devel, devicetree, linux-efi,
linux-kernel, shannon.zhao, peter.huangpeng, Rafael J. Wysocki,
Len Brown, open list:ACPI
On Fri, 25 Mar 2016, Bjorn Helgaas wrote:
> On Fri, Mar 25, 2016 at 04:05:49PM +0800, Shannon Zhao wrote:
> > From: Shannon Zhao <shannon.zhao@linaro.org>
> >
> > ACPI 6.0 introduces a new table STAO to list the devices which are used
> > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > UART is used by Xen. So here it hides UART from Dom0.
> >
> > CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
> > CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
> > CC: linux-acpi@vger.kernel.org (open list:ACPI)
> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> > ---
> > drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 68 insertions(+)
> >
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 5f28cf7..5420cc5 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> > @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> > DEFINE_MUTEX(acpi_device_lock);
> > LIST_HEAD(acpi_wakeup_device_list);
> > static DEFINE_MUTEX(acpi_hp_context_lock);
> > +static u64 spcr_uart_addr;
> >
> > struct acpi_dep_data {
> > struct list_head node;
> > @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
> > return 0;
> > }
> >
> > +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> > + void *context)
> > +{
> > + struct resource *res = context;
> > +
> > + if (acpi_dev_resource_memory(ares, res))
> > + return AE_CTRL_TERMINATE;
> > +
> > + return AE_OK;
> > +}
> > +
> > +static bool acpi_device_should_be_hidden(acpi_handle handle)
> > +{
> > + acpi_status status;
> > + struct resource res;
> > +
> > + /* Check if it should ignore the UART device */
> > + if (spcr_uart_addr != 0) {
> > + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> > + return false;
> > +
> > + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> > + acpi_get_resource_memory, &res);
> > + if (ACPI_FAILURE(status))
> > + return false;
> > +
> > + if (res.start == spcr_uart_addr) {
> > + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
>
> Can we at least print out the ACPI device path and address here for
> debugging purposes? IMHO, kernel messages that contain only static
> text are always dubious. There's almost always a useful address, IRQ,
> return value, etc., that could be included.
>
> > + return true;
> > + }
> > + }
> > +
> > + return false;
> > +}
> > +
> > static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > unsigned long long *sta)
> > {
> > @@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > switch (acpi_type) {
> > case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> > case ACPI_TYPE_DEVICE:
> > + if (acpi_device_should_be_hidden(handle))
> > + return -ENODEV;
> > +
> > *type = ACPI_BUS_TYPE_DEVICE;
> > status = acpi_bus_get_status_handle(handle, sta);
> > if (ACPI_FAILURE(status))
> > @@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
> > return result < 0 ? result : 0;
> > }
> >
> > +static void __init acpi_get_spcr_uart_addr(void)
> > +{
> > + acpi_status status;
> > + struct acpi_table_spcr *spcr_ptr;
> > +
> > + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> > + (struct acpi_table_header **)&spcr_ptr);
> > + if (ACPI_SUCCESS(status))
> > + spcr_uart_addr = spcr_ptr->serial_port.address;
> > + else
> > + printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
> > +}
> > +
> > int __init acpi_scan_init(void)
> > {
> > int result;
> > + acpi_status status;
> > + struct acpi_table_stao *stao_ptr;
> >
> > acpi_pci_root_init();
> > acpi_pci_link_init();
> > @@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
> >
> > acpi_scan_add_handler(&generic_device_handler);
> >
> > + /*
> > + * If there is STAO table, check whether it needs to ignore the UART
> > + * device in SPCR table.
> > + */
> > + status = acpi_get_table(ACPI_SIG_STAO, 0,
> > + (struct acpi_table_header **)&stao_ptr);
> > + if (ACPI_SUCCESS(status)) {
> > + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> > + printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
> > +
> > + if (stao_ptr->ignore_uart)
> > + acpi_get_spcr_uart_addr();
> > + }
>
> This all seems sort of ad hoc. Are UARTs the only things that can be
> listed in STAO? If STAO can contain things other than UARTs, are we
> going to see more patches adding special-case code like this?
The UART (specifically the UART described by the SPCR table) is the only
object which needs special-casing. Everything else is covered by ACPI
namespace paths (which is what the message above is about, given that it
is not supported by this patch).
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-25 17:15 ` Bjorn Helgaas
(?)
@ 2016-03-29 8:00 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-29 8:00 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-arm-kernel, stefano.stabellini, david.vrabel,
catalin.marinas, will.deacon, xen-devel, devicetree, linux-efi,
linux-kernel, shannon.zhao, peter.huangpeng, Rafael J. Wysocki,
Len Brown, ACPI
On 2016/3/26 1:15, Bjorn Helgaas wrote:
> On Fri, Mar 25, 2016 at 04:05:49PM +0800, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > ACPI 6.0 introduces a new table STAO to list the devices which are used
>> > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
>> > UART is used by Xen. So here it hides UART from Dom0.
>> >
>> > CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
>> > CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
>> > CC: linux-acpi@vger.kernel.org (open list:ACPI)
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> > 1 file changed, 68 insertions(+)
>> >
>> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> > index 5f28cf7..5420cc5 100644
>> > --- a/drivers/acpi/scan.c
>> > +++ b/drivers/acpi/scan.c
>> > @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
>> > DEFINE_MUTEX(acpi_device_lock);
>> > LIST_HEAD(acpi_wakeup_device_list);
>> > static DEFINE_MUTEX(acpi_hp_context_lock);
>> > +static u64 spcr_uart_addr;
>> >
>> > struct acpi_dep_data {
>> > struct list_head node;
>> > @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
>> > return 0;
>> > }
>> >
>> > +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
>> > + void *context)
>> > +{
>> > + struct resource *res = context;
>> > +
>> > + if (acpi_dev_resource_memory(ares, res))
>> > + return AE_CTRL_TERMINATE;
>> > +
>> > + return AE_OK;
>> > +}
>> > +
>> > +static bool acpi_device_should_be_hidden(acpi_handle handle)
>> > +{
>> > + acpi_status status;
>> > + struct resource res;
>> > +
>> > + /* Check if it should ignore the UART device */
>> > + if (spcr_uart_addr != 0) {
>> > + if (!acpi_has_method(handle, METHOD_NAME__CRS))
>> > + return false;
>> > +
>> > + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
>> > + acpi_get_resource_memory, &res);
>> > + if (ACPI_FAILURE(status))
>> > + return false;
>> > +
>> > + if (res.start == spcr_uart_addr) {
>> > + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
> Can we at least print out the ACPI device path and address here for
> debugging purposes? IMHO, kernel messages that contain only static
> text are always dubious. There's almost always a useful address, IRQ,
> return value, etc., that could be included.
>
Ok, I'll add the device address in the message and update this patch.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-29 8:00 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-29 8:00 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/3/26 1:15, Bjorn Helgaas wrote:
> On Fri, Mar 25, 2016 at 04:05:49PM +0800, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > ACPI 6.0 introduces a new table STAO to list the devices which are used
>> > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
>> > UART is used by Xen. So here it hides UART from Dom0.
>> >
>> > CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
>> > CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
>> > CC: linux-acpi at vger.kernel.org (open list:ACPI)
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> > 1 file changed, 68 insertions(+)
>> >
>> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> > index 5f28cf7..5420cc5 100644
>> > --- a/drivers/acpi/scan.c
>> > +++ b/drivers/acpi/scan.c
>> > @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
>> > DEFINE_MUTEX(acpi_device_lock);
>> > LIST_HEAD(acpi_wakeup_device_list);
>> > static DEFINE_MUTEX(acpi_hp_context_lock);
>> > +static u64 spcr_uart_addr;
>> >
>> > struct acpi_dep_data {
>> > struct list_head node;
>> > @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
>> > return 0;
>> > }
>> >
>> > +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
>> > + void *context)
>> > +{
>> > + struct resource *res = context;
>> > +
>> > + if (acpi_dev_resource_memory(ares, res))
>> > + return AE_CTRL_TERMINATE;
>> > +
>> > + return AE_OK;
>> > +}
>> > +
>> > +static bool acpi_device_should_be_hidden(acpi_handle handle)
>> > +{
>> > + acpi_status status;
>> > + struct resource res;
>> > +
>> > + /* Check if it should ignore the UART device */
>> > + if (spcr_uart_addr != 0) {
>> > + if (!acpi_has_method(handle, METHOD_NAME__CRS))
>> > + return false;
>> > +
>> > + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
>> > + acpi_get_resource_memory, &res);
>> > + if (ACPI_FAILURE(status))
>> > + return false;
>> > +
>> > + if (res.start == spcr_uart_addr) {
>> > + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
> Can we at least print out the ACPI device path and address here for
> debugging purposes? IMHO, kernel messages that contain only static
> text are always dubious. There's almost always a useful address, IRQ,
> return value, etc., that could be included.
>
Ok, I'll add the device address in the message and update this patch.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-29 8:00 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-29 8:00 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-arm-kernel, stefano.stabellini, david.vrabel,
catalin.marinas, will.deacon, xen-devel, devicetree, linux-efi,
linux-kernel, shannon.zhao, peter.huangpeng, Rafael J. Wysocki,
Len Brown, ACPI,
On 2016/3/26 1:15, Bjorn Helgaas wrote:
> On Fri, Mar 25, 2016 at 04:05:49PM +0800, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > ACPI 6.0 introduces a new table STAO to list the devices which are used
>> > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
>> > UART is used by Xen. So here it hides UART from Dom0.
>> >
>> > CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
>> > CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
>> > CC: linux-acpi@vger.kernel.org (open list:ACPI)
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> > 1 file changed, 68 insertions(+)
>> >
>> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> > index 5f28cf7..5420cc5 100644
>> > --- a/drivers/acpi/scan.c
>> > +++ b/drivers/acpi/scan.c
>> > @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
>> > DEFINE_MUTEX(acpi_device_lock);
>> > LIST_HEAD(acpi_wakeup_device_list);
>> > static DEFINE_MUTEX(acpi_hp_context_lock);
>> > +static u64 spcr_uart_addr;
>> >
>> > struct acpi_dep_data {
>> > struct list_head node;
>> > @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
>> > return 0;
>> > }
>> >
>> > +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
>> > + void *context)
>> > +{
>> > + struct resource *res = context;
>> > +
>> > + if (acpi_dev_resource_memory(ares, res))
>> > + return AE_CTRL_TERMINATE;
>> > +
>> > + return AE_OK;
>> > +}
>> > +
>> > +static bool acpi_device_should_be_hidden(acpi_handle handle)
>> > +{
>> > + acpi_status status;
>> > + struct resource res;
>> > +
>> > + /* Check if it should ignore the UART device */
>> > + if (spcr_uart_addr != 0) {
>> > + if (!acpi_has_method(handle, METHOD_NAME__CRS))
>> > + return false;
>> > +
>> > + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
>> > + acpi_get_resource_memory, &res);
>> > + if (ACPI_FAILURE(status))
>> > + return false;
>> > +
>> > + if (res.start == spcr_uart_addr) {
>> > + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
> Can we at least print out the ACPI device path and address here for
> debugging purposes? IMHO, kernel messages that contain only static
> text are always dubious. There's almost always a useful address, IRQ,
> return value, etc., that could be included.
>
Ok, I'll add the device address in the message and update this patch.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-25 17:15 ` Bjorn Helgaas
` (3 preceding siblings ...)
(?)
@ 2016-03-29 8:00 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-29 8:00 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: devicetree, linux-efi, Rafael J. Wysocki, catalin.marinas,
will.deacon, linux-kernel, xen-devel, ACPI, stefano.stabellini,
david.vrabel, peter.huangpeng, Len Brown, linux-arm-kernel,
shannon.zhao
On 2016/3/26 1:15, Bjorn Helgaas wrote:
> On Fri, Mar 25, 2016 at 04:05:49PM +0800, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > ACPI 6.0 introduces a new table STAO to list the devices which are used
>> > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
>> > UART is used by Xen. So here it hides UART from Dom0.
>> >
>> > CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
>> > CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
>> > CC: linux-acpi@vger.kernel.org (open list:ACPI)
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> > 1 file changed, 68 insertions(+)
>> >
>> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> > index 5f28cf7..5420cc5 100644
>> > --- a/drivers/acpi/scan.c
>> > +++ b/drivers/acpi/scan.c
>> > @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
>> > DEFINE_MUTEX(acpi_device_lock);
>> > LIST_HEAD(acpi_wakeup_device_list);
>> > static DEFINE_MUTEX(acpi_hp_context_lock);
>> > +static u64 spcr_uart_addr;
>> >
>> > struct acpi_dep_data {
>> > struct list_head node;
>> > @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
>> > return 0;
>> > }
>> >
>> > +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
>> > + void *context)
>> > +{
>> > + struct resource *res = context;
>> > +
>> > + if (acpi_dev_resource_memory(ares, res))
>> > + return AE_CTRL_TERMINATE;
>> > +
>> > + return AE_OK;
>> > +}
>> > +
>> > +static bool acpi_device_should_be_hidden(acpi_handle handle)
>> > +{
>> > + acpi_status status;
>> > + struct resource res;
>> > +
>> > + /* Check if it should ignore the UART device */
>> > + if (spcr_uart_addr != 0) {
>> > + if (!acpi_has_method(handle, METHOD_NAME__CRS))
>> > + return false;
>> > +
>> > + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
>> > + acpi_get_resource_memory, &res);
>> > + if (ACPI_FAILURE(status))
>> > + return false;
>> > +
>> > + if (res.start == spcr_uart_addr) {
>> > + printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
> Can we at least print out the ACPI device path and address here for
> debugging purposes? IMHO, kernel messages that contain only static
> text are always dubious. There's almost always a useful address, IRQ,
> return value, etc., that could be included.
>
Ok, I'll add the device address in the message and update this patch.
Thanks,
--
Shannon
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread
* [RESEND PATCH v9 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-25 8:05 ` Shannon Zhao
` (5 preceding siblings ...)
(?)
@ 2016-03-29 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-29 8:08 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini
Cc: devicetree, linux-efi, Rafael J. Wysocki, catalin.marinas,
will.deacon, linux-kernel, xen-devel, open list:ACPI,
shannon.zhao, peter.huangpeng, Len Brown
From: Shannon Zhao <shannon.zhao@linaro.org>
ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.
CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
CC: linux-acpi@vger.kernel.org (open list:ACPI)
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
v9: add the UART device address in printed message
---
drivers/acpi/scan.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 69 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..29f26fc 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
DEFINE_MUTEX(acpi_device_lock);
LIST_HEAD(acpi_wakeup_device_list);
static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,42 @@ static int acpi_add_single_object(struct acpi_device **child,
return 0;
}
+static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
+ void *context)
+{
+ struct resource *res = context;
+
+ if (acpi_dev_resource_memory(ares, res))
+ return AE_CTRL_TERMINATE;
+
+ return AE_OK;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+ acpi_status status;
+ struct resource res;
+
+ /* Check if it should ignore the UART device */
+ if (spcr_uart_addr != 0) {
+ if (!acpi_has_method(handle, METHOD_NAME__CRS))
+ return false;
+
+ status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+ acpi_get_resource_memory, &res);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ if (res.start == spcr_uart_addr) {
+ printk(KERN_INFO PREFIX "The UART device @%pa in SPCR table will be hidden\n",
+ &res.start);
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
{
@@ -1466,6 +1503,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+ if (acpi_device_should_be_hidden(handle))
+ return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1916,9 +1956,24 @@ static int acpi_bus_scan_fixed(void)
return result < 0 ? result : 0;
}
+static void __init acpi_get_spcr_uart_addr(void)
+{
+ acpi_status status;
+ struct acpi_table_spcr *spcr_ptr;
+
+ status = acpi_get_table(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **)&spcr_ptr);
+ if (ACPI_SUCCESS(status))
+ spcr_uart_addr = spcr_ptr->serial_port.address;
+ else
+ printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
+}
+
int __init acpi_scan_init(void)
{
int result;
+ acpi_status status;
+ struct acpi_table_stao *stao_ptr;
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1934,6 +1989,20 @@ int __init acpi_scan_init(void)
acpi_scan_add_handler(&generic_device_handler);
+ /*
+ * If there is STAO table, check whether it needs to ignore the UART
+ * device in SPCR table.
+ */
+ status = acpi_get_table(ACPI_SIG_STAO, 0,
+ (struct acpi_table_header **)&stao_ptr);
+ if (ACPI_SUCCESS(status)) {
+ if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+ printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
+
+ if (stao_ptr->ignore_uart)
+ acpi_get_spcr_uart_addr();
+ }
+
mutex_lock(&acpi_scan_lock);
/*
* Enumerate devices in the ACPI namespace.
--
2.0.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread* [RESEND PATCH v9 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-25 8:05 ` Shannon Zhao
(?)
@ 2016-03-29 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-29 8:08 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini
Cc: catalin.marinas, will.deacon, xen-devel, devicetree, linux-efi,
linux-kernel, shannon.zhao, peter.huangpeng, Rafael J. Wysocki,
Len Brown, open list:ACPI
From: Shannon Zhao <shannon.zhao@linaro.org>
ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.
CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
CC: linux-acpi@vger.kernel.org (open list:ACPI)
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
v9: add the UART device address in printed message
---
drivers/acpi/scan.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 69 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..29f26fc 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
DEFINE_MUTEX(acpi_device_lock);
LIST_HEAD(acpi_wakeup_device_list);
static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,42 @@ static int acpi_add_single_object(struct acpi_device **child,
return 0;
}
+static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
+ void *context)
+{
+ struct resource *res = context;
+
+ if (acpi_dev_resource_memory(ares, res))
+ return AE_CTRL_TERMINATE;
+
+ return AE_OK;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+ acpi_status status;
+ struct resource res;
+
+ /* Check if it should ignore the UART device */
+ if (spcr_uart_addr != 0) {
+ if (!acpi_has_method(handle, METHOD_NAME__CRS))
+ return false;
+
+ status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+ acpi_get_resource_memory, &res);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ if (res.start == spcr_uart_addr) {
+ printk(KERN_INFO PREFIX "The UART device @%pa in SPCR table will be hidden\n",
+ &res.start);
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
{
@@ -1466,6 +1503,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+ if (acpi_device_should_be_hidden(handle))
+ return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1916,9 +1956,24 @@ static int acpi_bus_scan_fixed(void)
return result < 0 ? result : 0;
}
+static void __init acpi_get_spcr_uart_addr(void)
+{
+ acpi_status status;
+ struct acpi_table_spcr *spcr_ptr;
+
+ status = acpi_get_table(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **)&spcr_ptr);
+ if (ACPI_SUCCESS(status))
+ spcr_uart_addr = spcr_ptr->serial_port.address;
+ else
+ printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
+}
+
int __init acpi_scan_init(void)
{
int result;
+ acpi_status status;
+ struct acpi_table_stao *stao_ptr;
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1934,6 +1989,20 @@ int __init acpi_scan_init(void)
acpi_scan_add_handler(&generic_device_handler);
+ /*
+ * If there is STAO table, check whether it needs to ignore the UART
+ * device in SPCR table.
+ */
+ status = acpi_get_table(ACPI_SIG_STAO, 0,
+ (struct acpi_table_header **)&stao_ptr);
+ if (ACPI_SUCCESS(status)) {
+ if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+ printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
+
+ if (stao_ptr->ignore_uart)
+ acpi_get_spcr_uart_addr();
+ }
+
mutex_lock(&acpi_scan_lock);
/*
* Enumerate devices in the ACPI namespace.
--
2.0.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [RESEND PATCH v9 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-29 8:08 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-29 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.
CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
CC: linux-acpi at vger.kernel.org (open list:ACPI)
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
v9: add the UART device address in printed message
---
drivers/acpi/scan.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 69 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..29f26fc 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
DEFINE_MUTEX(acpi_device_lock);
LIST_HEAD(acpi_wakeup_device_list);
static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,42 @@ static int acpi_add_single_object(struct acpi_device **child,
return 0;
}
+static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
+ void *context)
+{
+ struct resource *res = context;
+
+ if (acpi_dev_resource_memory(ares, res))
+ return AE_CTRL_TERMINATE;
+
+ return AE_OK;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+ acpi_status status;
+ struct resource res;
+
+ /* Check if it should ignore the UART device */
+ if (spcr_uart_addr != 0) {
+ if (!acpi_has_method(handle, METHOD_NAME__CRS))
+ return false;
+
+ status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+ acpi_get_resource_memory, &res);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ if (res.start == spcr_uart_addr) {
+ printk(KERN_INFO PREFIX "The UART device @%pa in SPCR table will be hidden\n",
+ &res.start);
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
{
@@ -1466,6 +1503,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+ if (acpi_device_should_be_hidden(handle))
+ return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1916,9 +1956,24 @@ static int acpi_bus_scan_fixed(void)
return result < 0 ? result : 0;
}
+static void __init acpi_get_spcr_uart_addr(void)
+{
+ acpi_status status;
+ struct acpi_table_spcr *spcr_ptr;
+
+ status = acpi_get_table(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **)&spcr_ptr);
+ if (ACPI_SUCCESS(status))
+ spcr_uart_addr = spcr_ptr->serial_port.address;
+ else
+ printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
+}
+
int __init acpi_scan_init(void)
{
int result;
+ acpi_status status;
+ struct acpi_table_stao *stao_ptr;
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1934,6 +1989,20 @@ int __init acpi_scan_init(void)
acpi_scan_add_handler(&generic_device_handler);
+ /*
+ * If there is STAO table, check whether it needs to ignore the UART
+ * device in SPCR table.
+ */
+ status = acpi_get_table(ACPI_SIG_STAO, 0,
+ (struct acpi_table_header **)&stao_ptr);
+ if (ACPI_SUCCESS(status)) {
+ if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+ printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
+
+ if (stao_ptr->ignore_uart)
+ acpi_get_spcr_uart_addr();
+ }
+
mutex_lock(&acpi_scan_lock);
/*
* Enumerate devices in the ACPI namespace.
--
2.0.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [RESEND PATCH v9 01/17] Xen: ACPI: Hide UART used by Xen
@ 2016-03-29 8:08 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-29 8:08 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini
Cc: catalin.marinas, will.deacon, xen-devel, devicetree, linux-efi,
linux-kernel, shannon.zhao, peter.huangpeng, Rafael J. Wysocki,
Len Brown, open list:ACPI
From: Shannon Zhao <shannon.zhao@linaro.org>
ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.
CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
CC: linux-acpi@vger.kernel.org (open list:ACPI)
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
v9: add the UART device address in printed message
---
drivers/acpi/scan.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 69 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..29f26fc 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
DEFINE_MUTEX(acpi_device_lock);
LIST_HEAD(acpi_wakeup_device_list);
static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,42 @@ static int acpi_add_single_object(struct acpi_device **child,
return 0;
}
+static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
+ void *context)
+{
+ struct resource *res = context;
+
+ if (acpi_dev_resource_memory(ares, res))
+ return AE_CTRL_TERMINATE;
+
+ return AE_OK;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+ acpi_status status;
+ struct resource res;
+
+ /* Check if it should ignore the UART device */
+ if (spcr_uart_addr != 0) {
+ if (!acpi_has_method(handle, METHOD_NAME__CRS))
+ return false;
+
+ status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+ acpi_get_resource_memory, &res);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ if (res.start == spcr_uart_addr) {
+ printk(KERN_INFO PREFIX "The UART device @%pa in SPCR table will be hidden\n",
+ &res.start);
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
{
@@ -1466,6 +1503,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+ if (acpi_device_should_be_hidden(handle))
+ return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1916,9 +1956,24 @@ static int acpi_bus_scan_fixed(void)
return result < 0 ? result : 0;
}
+static void __init acpi_get_spcr_uart_addr(void)
+{
+ acpi_status status;
+ struct acpi_table_spcr *spcr_ptr;
+
+ status = acpi_get_table(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **)&spcr_ptr);
+ if (ACPI_SUCCESS(status))
+ spcr_uart_addr = spcr_ptr->serial_port.address;
+ else
+ printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
+}
+
int __init acpi_scan_init(void)
{
int result;
+ acpi_status status;
+ struct acpi_table_stao *stao_ptr;
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1934,6 +1989,20 @@ int __init acpi_scan_init(void)
acpi_scan_add_handler(&generic_device_handler);
+ /*
+ * If there is STAO table, check whether it needs to ignore the UART
+ * device in SPCR table.
+ */
+ status = acpi_get_table(ACPI_SIG_STAO, 0,
+ (struct acpi_table_header **)&stao_ptr);
+ if (ACPI_SUCCESS(status)) {
+ if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+ printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
+
+ if (stao_ptr->ignore_uart)
+ acpi_get_spcr_uart_addr();
+ }
+
mutex_lock(&acpi_scan_lock);
/*
* Enumerate devices in the ACPI namespace.
--
2.0.4
^ permalink raw reply related [flat|nested] 172+ messages in thread
* [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-24 14:44 ` Shannon Zhao
` (4 preceding siblings ...)
(?)
@ 2016-03-25 8:05 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-25 8:05 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, Rafael J. Wysocki, catalin.marinas,
will.deacon, linux-kernel, xen-devel, open list:ACPI,
shannon.zhao, peter.huangpeng, Len Brown
From: Shannon Zhao <shannon.zhao@linaro.org>
ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.
CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
CC: linux-acpi@vger.kernel.org (open list:ACPI)
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..5420cc5 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
DEFINE_MUTEX(acpi_device_lock);
LIST_HEAD(acpi_wakeup_device_list);
static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
return 0;
}
+static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
+ void *context)
+{
+ struct resource *res = context;
+
+ if (acpi_dev_resource_memory(ares, res))
+ return AE_CTRL_TERMINATE;
+
+ return AE_OK;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+ acpi_status status;
+ struct resource res;
+
+ /* Check if it should ignore the UART device */
+ if (spcr_uart_addr != 0) {
+ if (!acpi_has_method(handle, METHOD_NAME__CRS))
+ return false;
+
+ status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+ acpi_get_resource_memory, &res);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ if (res.start == spcr_uart_addr) {
+ printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
{
@@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+ if (acpi_device_should_be_hidden(handle))
+ return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
return result < 0 ? result : 0;
}
+static void __init acpi_get_spcr_uart_addr(void)
+{
+ acpi_status status;
+ struct acpi_table_spcr *spcr_ptr;
+
+ status = acpi_get_table(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **)&spcr_ptr);
+ if (ACPI_SUCCESS(status))
+ spcr_uart_addr = spcr_ptr->serial_port.address;
+ else
+ printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
+}
+
int __init acpi_scan_init(void)
{
int result;
+ acpi_status status;
+ struct acpi_table_stao *stao_ptr;
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
acpi_scan_add_handler(&generic_device_handler);
+ /*
+ * If there is STAO table, check whether it needs to ignore the UART
+ * device in SPCR table.
+ */
+ status = acpi_get_table(ACPI_SIG_STAO, 0,
+ (struct acpi_table_header **)&stao_ptr);
+ if (ACPI_SUCCESS(status)) {
+ if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+ printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
+
+ if (stao_ptr->ignore_uart)
+ acpi_get_spcr_uart_addr();
+ }
+
mutex_lock(&acpi_scan_lock);
/*
* Enumerate devices in the ACPI namespace.
--
2.0.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread
* [PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen
2016-03-24 14:44 ` Shannon Zhao
` (2 preceding siblings ...)
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, Rafael J. Wysocki, catalin.marinas,
will.deacon, linux-kernel, peter.huangpeng, open list:ACPI,
julien.grall, shannon.zhao, zhaoshenglong, xen-devel, Len Brown
ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.
CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
CC: linux-acpi@vger.kernel.org (open list:ACPI)
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
drivers/acpi/scan.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..e96a058 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
DEFINE_MUTEX(acpi_device_lock);
LIST_HEAD(acpi_wakeup_device_list);
static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct acpi_device **child,
return 0;
}
+static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
+ void *context)
+{
+ struct resource *res = context;
+
+ if (acpi_dev_resource_memory(ares, res))
+ return AE_CTRL_TERMINATE;
+
+ return AE_OK;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+ acpi_status status;
+ struct resource res;
+
+ /* Check if it should ignore the UART device */
+ if (spcr_uart_addr != 0) {
+ if (!acpi_has_method(handle, METHOD_NAME__CRS))
+ return false;
+
+ status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+ acpi_get_resource_memory, &res);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ if (res.start == spcr_uart_addr) {
+ printk(KERN_INFO PREFIX "The UART device in SPCR table will be hidden\n");
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
{
@@ -1466,6 +1502,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+ if (acpi_device_should_be_hidden(handle))
+ return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1916,9 +1955,24 @@ static int acpi_bus_scan_fixed(void)
return result < 0 ? result : 0;
}
+static void acpi_get_spcr_uart_addr(void)
+{
+ acpi_status status;
+ struct acpi_table_spcr *spcr_ptr;
+
+ status = acpi_get_table(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **)&spcr_ptr);
+ if (ACPI_SUCCESS(status))
+ spcr_uart_addr = spcr_ptr->serial_port.address;
+ else
+ printk(KERN_WARNING PREFIX "STAO table present, but SPCR is missing\n");
+}
+
int __init acpi_scan_init(void)
{
int result;
+ acpi_status status;
+ struct acpi_table_stao *stao_ptr;
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1934,6 +1988,20 @@ int __init acpi_scan_init(void)
acpi_scan_add_handler(&generic_device_handler);
+ /*
+ * If there is STAO table, check whether it needs to ignore the UART
+ * device in SPCR table.
+ */
+ status = acpi_get_table(ACPI_SIG_STAO, 0,
+ (struct acpi_table_header **)&stao_ptr);
+ if (ACPI_SUCCESS(status)) {
+ if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+ printk(KERN_INFO PREFIX "STAO Name List not yet supported.");
+
+ if (stao_ptr->ignore_uart)
+ acpi_get_spcr_uart_addr();
+ }
+
mutex_lock(&acpi_scan_lock);
/*
* Enumerate devices in the ACPI namespace.
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 02/17] xen/grant-table: Move xlated_setup_gnttab_pages to common place
2016-03-24 14:44 ` Shannon Zhao
` (3 preceding siblings ...)
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, shannon.zhao,
zhaoshenglong, xen-devel
Move xlated_setup_gnttab_pages to common place, so it can be reused by
ARM to setup grant table.
Rename it to xen_xlate_map_ballooned_pages.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/x86/xen/grant-table.c | 57 +++++--------------------------------------
drivers/xen/xlate_mmu.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++
include/xen/xen-ops.h | 2 ++
3 files changed, 69 insertions(+), 51 deletions(-)
diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index e079500..de4144c 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -111,63 +111,18 @@ 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);
- 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;
-}
-
+#include <xen/xen-ops.h>
static int __init xen_pvh_gnttab_setup(void)
{
if (!xen_pvh_domain())
return -ENODEV;
- return xlated_setup_gnttab_pages();
+ xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+
+ return xen_xlate_map_ballooned_pages(&xen_auto_xlat_grant_frames.pfn,
+ &xen_auto_xlat_grant_frames.vaddr,
+ xen_auto_xlat_grant_frames.count);
}
/* Call it _before_ __gnttab_init as we need to initialize the
* xen_auto_xlat_grant_frames first. */
diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 5063c5e..9692656 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -29,6 +29,8 @@
*/
#include <linux/kernel.h>
#include <linux/mm.h>
+#include <linux/slab.h>
+#include <linux/vmalloc.h>
#include <asm/xen/hypercall.h>
#include <asm/xen/hypervisor.h>
@@ -37,6 +39,7 @@
#include <xen/page.h>
#include <xen/interface/xen.h>
#include <xen/interface/memory.h>
+#include <xen/balloon.h>
typedef void (*xen_gfn_fn_t)(unsigned long gfn, void *data);
@@ -185,3 +188,61 @@ int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
return 0;
}
EXPORT_SYMBOL_GPL(xen_xlate_unmap_gfn_range);
+
+/**
+ * xen_xlate_map_ballooned_pages - map a new set of ballooned pages
+ * @gfns: returns the array of corresponding GFNs
+ * @virt: returns the virtual address of the mapped region
+ * @nr_grant_frames: number of GFNs
+ * @return 0 on success, error otherwise
+ *
+ * This allocates a set of ballooned pages and maps them into the
+ * kernel's address space.
+ */
+int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
+ unsigned long nr_grant_frames)
+{
+ struct page **pages;
+ xen_pfn_t *pfns;
+ void *vaddr;
+ int rc;
+ unsigned int i;
+
+ 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);
+ 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);
+
+ *gfns = pfns;
+ *virt = vaddr;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(xen_xlate_map_ballooned_pages);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 86abe07..072be1c 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -85,6 +85,8 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
struct page **pages);
int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
int nr, struct page **pages);
+int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
+ unsigned long nr_grant_frames);
bool xen_running_on_version_or_later(unsigned int major, unsigned int minor);
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 02/17] xen/grant-table: Move xlated_setup_gnttab_pages to common place
2016-03-24 14:44 ` Shannon Zhao
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao
Move xlated_setup_gnttab_pages to common place, so it can be reused by
ARM to setup grant table.
Rename it to xen_xlate_map_ballooned_pages.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/x86/xen/grant-table.c | 57 +++++--------------------------------------
drivers/xen/xlate_mmu.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++
include/xen/xen-ops.h | 2 ++
3 files changed, 69 insertions(+), 51 deletions(-)
diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index e079500..de4144c 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -111,63 +111,18 @@ 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);
- 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;
-}
-
+#include <xen/xen-ops.h>
static int __init xen_pvh_gnttab_setup(void)
{
if (!xen_pvh_domain())
return -ENODEV;
- return xlated_setup_gnttab_pages();
+ xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+
+ return xen_xlate_map_ballooned_pages(&xen_auto_xlat_grant_frames.pfn,
+ &xen_auto_xlat_grant_frames.vaddr,
+ xen_auto_xlat_grant_frames.count);
}
/* Call it _before_ __gnttab_init as we need to initialize the
* xen_auto_xlat_grant_frames first. */
diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 5063c5e..9692656 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -29,6 +29,8 @@
*/
#include <linux/kernel.h>
#include <linux/mm.h>
+#include <linux/slab.h>
+#include <linux/vmalloc.h>
#include <asm/xen/hypercall.h>
#include <asm/xen/hypervisor.h>
@@ -37,6 +39,7 @@
#include <xen/page.h>
#include <xen/interface/xen.h>
#include <xen/interface/memory.h>
+#include <xen/balloon.h>
typedef void (*xen_gfn_fn_t)(unsigned long gfn, void *data);
@@ -185,3 +188,61 @@ int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
return 0;
}
EXPORT_SYMBOL_GPL(xen_xlate_unmap_gfn_range);
+
+/**
+ * xen_xlate_map_ballooned_pages - map a new set of ballooned pages
+ * @gfns: returns the array of corresponding GFNs
+ * @virt: returns the virtual address of the mapped region
+ * @nr_grant_frames: number of GFNs
+ * @return 0 on success, error otherwise
+ *
+ * This allocates a set of ballooned pages and maps them into the
+ * kernel's address space.
+ */
+int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
+ unsigned long nr_grant_frames)
+{
+ struct page **pages;
+ xen_pfn_t *pfns;
+ void *vaddr;
+ int rc;
+ unsigned int i;
+
+ 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);
+ 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);
+
+ *gfns = pfns;
+ *virt = vaddr;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(xen_xlate_map_ballooned_pages);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 86abe07..072be1c 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -85,6 +85,8 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
struct page **pages);
int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
int nr, struct page **pages);
+int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
+ unsigned long nr_grant_frames);
bool xen_running_on_version_or_later(unsigned int major, unsigned int minor);
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 02/17] xen/grant-table: Move xlated_setup_gnttab_pages to common place
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
Move xlated_setup_gnttab_pages to common place, so it can be reused by
ARM to setup grant table.
Rename it to xen_xlate_map_ballooned_pages.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/x86/xen/grant-table.c | 57 +++++--------------------------------------
drivers/xen/xlate_mmu.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++
include/xen/xen-ops.h | 2 ++
3 files changed, 69 insertions(+), 51 deletions(-)
diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index e079500..de4144c 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -111,63 +111,18 @@ 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);
- 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;
-}
-
+#include <xen/xen-ops.h>
static int __init xen_pvh_gnttab_setup(void)
{
if (!xen_pvh_domain())
return -ENODEV;
- return xlated_setup_gnttab_pages();
+ xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+
+ return xen_xlate_map_ballooned_pages(&xen_auto_xlat_grant_frames.pfn,
+ &xen_auto_xlat_grant_frames.vaddr,
+ xen_auto_xlat_grant_frames.count);
}
/* Call it _before_ __gnttab_init as we need to initialize the
* xen_auto_xlat_grant_frames first. */
diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 5063c5e..9692656 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -29,6 +29,8 @@
*/
#include <linux/kernel.h>
#include <linux/mm.h>
+#include <linux/slab.h>
+#include <linux/vmalloc.h>
#include <asm/xen/hypercall.h>
#include <asm/xen/hypervisor.h>
@@ -37,6 +39,7 @@
#include <xen/page.h>
#include <xen/interface/xen.h>
#include <xen/interface/memory.h>
+#include <xen/balloon.h>
typedef void (*xen_gfn_fn_t)(unsigned long gfn, void *data);
@@ -185,3 +188,61 @@ int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
return 0;
}
EXPORT_SYMBOL_GPL(xen_xlate_unmap_gfn_range);
+
+/**
+ * xen_xlate_map_ballooned_pages - map a new set of ballooned pages
+ * @gfns: returns the array of corresponding GFNs
+ * @virt: returns the virtual address of the mapped region
+ * @nr_grant_frames: number of GFNs
+ * @return 0 on success, error otherwise
+ *
+ * This allocates a set of ballooned pages and maps them into the
+ * kernel's address space.
+ */
+int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
+ unsigned long nr_grant_frames)
+{
+ struct page **pages;
+ xen_pfn_t *pfns;
+ void *vaddr;
+ int rc;
+ unsigned int i;
+
+ 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);
+ 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);
+
+ *gfns = pfns;
+ *virt = vaddr;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(xen_xlate_map_ballooned_pages);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 86abe07..072be1c 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -85,6 +85,8 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
struct page **pages);
int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
int nr, struct page **pages);
+int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
+ unsigned long nr_grant_frames);
bool xen_running_on_version_or_later(unsigned int major, unsigned int minor);
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 02/17] xen/grant-table: Move xlated_setup_gnttab_pages to common place
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, shannon.zhao,
zhaoshenglong, xen-devel
Move xlated_setup_gnttab_pages to common place, so it can be reused by
ARM to setup grant table.
Rename it to xen_xlate_map_ballooned_pages.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/x86/xen/grant-table.c | 57 +++++--------------------------------------
drivers/xen/xlate_mmu.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++
include/xen/xen-ops.h | 2 ++
3 files changed, 69 insertions(+), 51 deletions(-)
diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index e079500..de4144c 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -111,63 +111,18 @@ 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);
- 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;
-}
-
+#include <xen/xen-ops.h>
static int __init xen_pvh_gnttab_setup(void)
{
if (!xen_pvh_domain())
return -ENODEV;
- return xlated_setup_gnttab_pages();
+ xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+
+ return xen_xlate_map_ballooned_pages(&xen_auto_xlat_grant_frames.pfn,
+ &xen_auto_xlat_grant_frames.vaddr,
+ xen_auto_xlat_grant_frames.count);
}
/* Call it _before_ __gnttab_init as we need to initialize the
* xen_auto_xlat_grant_frames first. */
diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 5063c5e..9692656 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -29,6 +29,8 @@
*/
#include <linux/kernel.h>
#include <linux/mm.h>
+#include <linux/slab.h>
+#include <linux/vmalloc.h>
#include <asm/xen/hypercall.h>
#include <asm/xen/hypervisor.h>
@@ -37,6 +39,7 @@
#include <xen/page.h>
#include <xen/interface/xen.h>
#include <xen/interface/memory.h>
+#include <xen/balloon.h>
typedef void (*xen_gfn_fn_t)(unsigned long gfn, void *data);
@@ -185,3 +188,61 @@ int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
return 0;
}
EXPORT_SYMBOL_GPL(xen_xlate_unmap_gfn_range);
+
+/**
+ * xen_xlate_map_ballooned_pages - map a new set of ballooned pages
+ * @gfns: returns the array of corresponding GFNs
+ * @virt: returns the virtual address of the mapped region
+ * @nr_grant_frames: number of GFNs
+ * @return 0 on success, error otherwise
+ *
+ * This allocates a set of ballooned pages and maps them into the
+ * kernel's address space.
+ */
+int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
+ unsigned long nr_grant_frames)
+{
+ struct page **pages;
+ xen_pfn_t *pfns;
+ void *vaddr;
+ int rc;
+ unsigned int i;
+
+ 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);
+ 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);
+
+ *gfns = pfns;
+ *virt = vaddr;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(xen_xlate_map_ballooned_pages);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 86abe07..072be1c 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -85,6 +85,8 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
struct page **pages);
int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
int nr, struct page **pages);
+int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
+ unsigned long nr_grant_frames);
bool xen_running_on_version_or_later(unsigned int major, unsigned int minor);
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread
* [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
2016-03-24 14:44 ` Shannon Zhao
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao
Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
refer to 4K pages.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 9692656..28f728b 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -207,9 +207,12 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
void *vaddr;
int rc;
unsigned int i;
+ unsigned long nr_pages;
+ xen_pfn_t xen_pfn = 0;
BUG_ON(nr_grant_frames == 0);
- pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
+ nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
+ pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
if (!pages)
return -ENOMEM;
@@ -218,22 +221,25 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
kfree(pages);
return -ENOMEM;
}
- rc = alloc_xenballooned_pages(nr_grant_frames, pages);
+ rc = alloc_xenballooned_pages(nr_pages, pages);
if (rc) {
- pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
- nr_grant_frames, rc);
+ pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
+ nr_pages, rc);
kfree(pages);
kfree(pfns);
return rc;
}
- for (i = 0; i < nr_grant_frames; i++)
- pfns[i] = page_to_pfn(pages[i]);
+ for (i = 0; i < nr_grant_frames; i++) {
+ if ((i % XEN_PFN_PER_PAGE) == 0)
+ xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
+ pfns[i] = pfn_to_gfn(xen_pfn++);
+ }
- vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
+ vaddr = vmap(pages, nr_pages, 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);
+ pr_warn("%s Couldn't map %ld pages rc:%d\n", __func__,
+ nr_pages, rc);
+ free_xenballooned_pages(nr_pages, pages);
kfree(pages);
kfree(pfns);
return -ENOMEM;
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
refer to 4K pages.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 9692656..28f728b 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -207,9 +207,12 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
void *vaddr;
int rc;
unsigned int i;
+ unsigned long nr_pages;
+ xen_pfn_t xen_pfn = 0;
BUG_ON(nr_grant_frames == 0);
- pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
+ nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
+ pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
if (!pages)
return -ENOMEM;
@@ -218,22 +221,25 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
kfree(pages);
return -ENOMEM;
}
- rc = alloc_xenballooned_pages(nr_grant_frames, pages);
+ rc = alloc_xenballooned_pages(nr_pages, pages);
if (rc) {
- pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
- nr_grant_frames, rc);
+ pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
+ nr_pages, rc);
kfree(pages);
kfree(pfns);
return rc;
}
- for (i = 0; i < nr_grant_frames; i++)
- pfns[i] = page_to_pfn(pages[i]);
+ for (i = 0; i < nr_grant_frames; i++) {
+ if ((i % XEN_PFN_PER_PAGE) == 0)
+ xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
+ pfns[i] = pfn_to_gfn(xen_pfn++);
+ }
- vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
+ vaddr = vmap(pages, nr_pages, 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);
+ pr_warn("%s Couldn't map %ld pages rc:%d\n", __func__,
+ nr_pages, rc);
+ free_xenballooned_pages(nr_pages, pages);
kfree(pages);
kfree(pfns);
return -ENOMEM;
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, shannon.zhao,
zhaoshenglong, xen-devel
Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
refer to 4K pages.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 9692656..28f728b 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -207,9 +207,12 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
void *vaddr;
int rc;
unsigned int i;
+ unsigned long nr_pages;
+ xen_pfn_t xen_pfn = 0;
BUG_ON(nr_grant_frames == 0);
- pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
+ nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
+ pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
if (!pages)
return -ENOMEM;
@@ -218,22 +221,25 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
kfree(pages);
return -ENOMEM;
}
- rc = alloc_xenballooned_pages(nr_grant_frames, pages);
+ rc = alloc_xenballooned_pages(nr_pages, pages);
if (rc) {
- pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
- nr_grant_frames, rc);
+ pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
+ nr_pages, rc);
kfree(pages);
kfree(pfns);
return rc;
}
- for (i = 0; i < nr_grant_frames; i++)
- pfns[i] = page_to_pfn(pages[i]);
+ for (i = 0; i < nr_grant_frames; i++) {
+ if ((i % XEN_PFN_PER_PAGE) == 0)
+ xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
+ pfns[i] = pfn_to_gfn(xen_pfn++);
+ }
- vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
+ vaddr = vmap(pages, nr_pages, 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);
+ pr_warn("%s Couldn't map %ld pages rc:%d\n", __func__,
+ nr_pages, rc);
+ free_xenballooned_pages(nr_pages, pages);
kfree(pages);
kfree(pfns);
return -ENOMEM;
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread* Re: [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
@ 2016-03-29 16:28 ` Julien Grall
0 siblings, 0 replies; 172+ messages in thread
From: Julien Grall @ 2016-03-29 16:28 UTC (permalink / raw)
To: Shannon Zhao, linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, peter.huangpeng, xen-devel, zhaoshenglong
Hi Shannon,
On 24/03/16 14:44, Shannon Zhao wrote:
> Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
> Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
> refer to 4K pages.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
> drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
> 1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
> index 9692656..28f728b 100644
> --- a/drivers/xen/xlate_mmu.c
> +++ b/drivers/xen/xlate_mmu.c
> @@ -207,9 +207,12 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
> void *vaddr;
> int rc;
> unsigned int i;
> + unsigned long nr_pages;
> + xen_pfn_t xen_pfn = 0;
>
> BUG_ON(nr_grant_frames == 0);
> - pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
> + nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
> + pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
> if (!pages)
> return -ENOMEM;
>
> @@ -218,22 +221,25 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
> kfree(pages);
> return -ENOMEM;
> }
> - rc = alloc_xenballooned_pages(nr_grant_frames, pages);
> + rc = alloc_xenballooned_pages(nr_pages, pages);
> if (rc) {
> - pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
> - nr_grant_frames, rc);
> + pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
> + nr_pages, rc);
> kfree(pages);
> kfree(pfns);
> return rc;
> }
> - for (i = 0; i < nr_grant_frames; i++)
> - pfns[i] = page_to_pfn(pages[i]);
> + for (i = 0; i < nr_grant_frames; i++) {
> + if ((i % XEN_PFN_PER_PAGE) == 0)
> + xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
> + pfns[i] = pfn_to_gfn(xen_pfn++);
> + }
Would it be possible to re-use xen_for_each_gfn? This will avoid
open-coding the loop to break down the Linux page.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
@ 2016-03-29 16:28 ` Julien Grall
0 siblings, 0 replies; 172+ messages in thread
From: Julien Grall @ 2016-03-29 16:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi Shannon,
On 24/03/16 14:44, Shannon Zhao wrote:
> Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
> Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
> refer to 4K pages.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
> drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
> 1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
> index 9692656..28f728b 100644
> --- a/drivers/xen/xlate_mmu.c
> +++ b/drivers/xen/xlate_mmu.c
> @@ -207,9 +207,12 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
> void *vaddr;
> int rc;
> unsigned int i;
> + unsigned long nr_pages;
> + xen_pfn_t xen_pfn = 0;
>
> BUG_ON(nr_grant_frames == 0);
> - pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
> + nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
> + pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
> if (!pages)
> return -ENOMEM;
>
> @@ -218,22 +221,25 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
> kfree(pages);
> return -ENOMEM;
> }
> - rc = alloc_xenballooned_pages(nr_grant_frames, pages);
> + rc = alloc_xenballooned_pages(nr_pages, pages);
> if (rc) {
> - pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
> - nr_grant_frames, rc);
> + pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
> + nr_pages, rc);
> kfree(pages);
> kfree(pfns);
> return rc;
> }
> - for (i = 0; i < nr_grant_frames; i++)
> - pfns[i] = page_to_pfn(pages[i]);
> + for (i = 0; i < nr_grant_frames; i++) {
> + if ((i % XEN_PFN_PER_PAGE) == 0)
> + xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
> + pfns[i] = pfn_to_gfn(xen_pfn++);
> + }
Would it be possible to re-use xen_for_each_gfn? This will avoid
open-coding the loop to break down the Linux page.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
@ 2016-03-29 16:28 ` Julien Grall
0 siblings, 0 replies; 172+ messages in thread
From: Julien Grall @ 2016-03-29 16:28 UTC (permalink / raw)
To: Shannon Zhao, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
zhaoshenglong-hv44wF8Li93QT0dZR+AlfA
Hi Shannon,
On 24/03/16 14:44, Shannon Zhao wrote:
> Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
> Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
> refer to 4K pages.
>
> Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
> ---
> drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
> 1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
> index 9692656..28f728b 100644
> --- a/drivers/xen/xlate_mmu.c
> +++ b/drivers/xen/xlate_mmu.c
> @@ -207,9 +207,12 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
> void *vaddr;
> int rc;
> unsigned int i;
> + unsigned long nr_pages;
> + xen_pfn_t xen_pfn = 0;
>
> BUG_ON(nr_grant_frames == 0);
> - pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
> + nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
> + pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
> if (!pages)
> return -ENOMEM;
>
> @@ -218,22 +221,25 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
> kfree(pages);
> return -ENOMEM;
> }
> - rc = alloc_xenballooned_pages(nr_grant_frames, pages);
> + rc = alloc_xenballooned_pages(nr_pages, pages);
> if (rc) {
> - pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
> - nr_grant_frames, rc);
> + pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
> + nr_pages, rc);
> kfree(pages);
> kfree(pfns);
> return rc;
> }
> - for (i = 0; i < nr_grant_frames; i++)
> - pfns[i] = page_to_pfn(pages[i]);
> + for (i = 0; i < nr_grant_frames; i++) {
> + if ((i % XEN_PFN_PER_PAGE) == 0)
> + xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
> + pfns[i] = pfn_to_gfn(xen_pfn++);
> + }
Would it be possible to re-use xen_for_each_gfn? This will avoid
open-coding the loop to break down the Linux page.
Regards,
--
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
2016-03-29 16:28 ` Julien Grall
(?)
(?)
@ 2016-03-30 7:38 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-30 7:38 UTC (permalink / raw)
To: Julien Grall, Shannon Zhao, linux-arm-kernel, stefano.stabellini,
david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
peter.huangpeng, linux-kernel, xen-devel
On 2016/3/30 0:28, Julien Grall wrote:
> Hi Shannon,
>
> On 24/03/16 14:44, Shannon Zhao wrote:
>> Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
>> Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
>> refer to 4K pages.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> ---
>> drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
>> 1 file changed, 16 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>> index 9692656..28f728b 100644
>> --- a/drivers/xen/xlate_mmu.c
>> +++ b/drivers/xen/xlate_mmu.c
>> @@ -207,9 +207,12 @@ int __init
>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>> void *vaddr;
>> int rc;
>> unsigned int i;
>> + unsigned long nr_pages;
>> + xen_pfn_t xen_pfn = 0;
>>
>> BUG_ON(nr_grant_frames == 0);
>> - pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
>> + nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
>> + pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
>> if (!pages)
>> return -ENOMEM;
>>
>> @@ -218,22 +221,25 @@ int __init
>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>> kfree(pages);
>> return -ENOMEM;
>> }
>> - rc = alloc_xenballooned_pages(nr_grant_frames, pages);
>> + rc = alloc_xenballooned_pages(nr_pages, pages);
>> if (rc) {
>> - pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
>> - nr_grant_frames, rc);
>> + pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
>> + nr_pages, rc);
>> kfree(pages);
>> kfree(pfns);
>> return rc;
>> }
>> - for (i = 0; i < nr_grant_frames; i++)
>> - pfns[i] = page_to_pfn(pages[i]);
>> + for (i = 0; i < nr_grant_frames; i++) {
>> + if ((i % XEN_PFN_PER_PAGE) == 0)
>> + xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
>> + pfns[i] = pfn_to_gfn(xen_pfn++);
>> + }
>
> Would it be possible to re-use xen_for_each_gfn? This will avoid
> open-coding the loop to break down the Linux page.
I don't think so. Using xen_acpi_guest_init will require factoring
"pfns[i] = pfn_to_gfn(xen_pfn++)" to a function with parameter pfns[i].
How can we pass pfns[i]?
Thanks,
--
Shannon
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
@ 2016-03-30 7:38 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-30 7:38 UTC (permalink / raw)
To: Julien Grall, Shannon Zhao, linux-arm-kernel, stefano.stabellini,
david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, peter.huangpeng, xen-devel
On 2016/3/30 0:28, Julien Grall wrote:
> Hi Shannon,
>
> On 24/03/16 14:44, Shannon Zhao wrote:
>> Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
>> Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
>> refer to 4K pages.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> ---
>> drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
>> 1 file changed, 16 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>> index 9692656..28f728b 100644
>> --- a/drivers/xen/xlate_mmu.c
>> +++ b/drivers/xen/xlate_mmu.c
>> @@ -207,9 +207,12 @@ int __init
>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>> void *vaddr;
>> int rc;
>> unsigned int i;
>> + unsigned long nr_pages;
>> + xen_pfn_t xen_pfn = 0;
>>
>> BUG_ON(nr_grant_frames == 0);
>> - pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
>> + nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
>> + pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
>> if (!pages)
>> return -ENOMEM;
>>
>> @@ -218,22 +221,25 @@ int __init
>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>> kfree(pages);
>> return -ENOMEM;
>> }
>> - rc = alloc_xenballooned_pages(nr_grant_frames, pages);
>> + rc = alloc_xenballooned_pages(nr_pages, pages);
>> if (rc) {
>> - pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
>> - nr_grant_frames, rc);
>> + pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
>> + nr_pages, rc);
>> kfree(pages);
>> kfree(pfns);
>> return rc;
>> }
>> - for (i = 0; i < nr_grant_frames; i++)
>> - pfns[i] = page_to_pfn(pages[i]);
>> + for (i = 0; i < nr_grant_frames; i++) {
>> + if ((i % XEN_PFN_PER_PAGE) == 0)
>> + xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
>> + pfns[i] = pfn_to_gfn(xen_pfn++);
>> + }
>
> Would it be possible to re-use xen_for_each_gfn? This will avoid
> open-coding the loop to break down the Linux page.
I don't think so. Using xen_acpi_guest_init will require factoring
"pfns[i] = pfn_to_gfn(xen_pfn++)" to a function with parameter pfns[i].
How can we pass pfns[i]?
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
@ 2016-03-30 7:38 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-30 7:38 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/3/30 0:28, Julien Grall wrote:
> Hi Shannon,
>
> On 24/03/16 14:44, Shannon Zhao wrote:
>> Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
>> Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
>> refer to 4K pages.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> ---
>> drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
>> 1 file changed, 16 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>> index 9692656..28f728b 100644
>> --- a/drivers/xen/xlate_mmu.c
>> +++ b/drivers/xen/xlate_mmu.c
>> @@ -207,9 +207,12 @@ int __init
>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>> void *vaddr;
>> int rc;
>> unsigned int i;
>> + unsigned long nr_pages;
>> + xen_pfn_t xen_pfn = 0;
>>
>> BUG_ON(nr_grant_frames == 0);
>> - pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
>> + nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
>> + pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
>> if (!pages)
>> return -ENOMEM;
>>
>> @@ -218,22 +221,25 @@ int __init
>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>> kfree(pages);
>> return -ENOMEM;
>> }
>> - rc = alloc_xenballooned_pages(nr_grant_frames, pages);
>> + rc = alloc_xenballooned_pages(nr_pages, pages);
>> if (rc) {
>> - pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
>> - nr_grant_frames, rc);
>> + pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
>> + nr_pages, rc);
>> kfree(pages);
>> kfree(pfns);
>> return rc;
>> }
>> - for (i = 0; i < nr_grant_frames; i++)
>> - pfns[i] = page_to_pfn(pages[i]);
>> + for (i = 0; i < nr_grant_frames; i++) {
>> + if ((i % XEN_PFN_PER_PAGE) == 0)
>> + xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
>> + pfns[i] = pfn_to_gfn(xen_pfn++);
>> + }
>
> Would it be possible to re-use xen_for_each_gfn? This will avoid
> open-coding the loop to break down the Linux page.
I don't think so. Using xen_acpi_guest_init will require factoring
"pfns[i] = pfn_to_gfn(xen_pfn++)" to a function with parameter pfns[i].
How can we pass pfns[i]?
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
@ 2016-03-30 7:38 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-30 7:38 UTC (permalink / raw)
To: Julien Grall, Shannon Zhao,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw
On 2016/3/30 0:28, Julien Grall wrote:
> Hi Shannon,
>
> On 24/03/16 14:44, Shannon Zhao wrote:
>> Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
>> Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
>> refer to 4K pages.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Reviewed-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
>> ---
>> drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
>> 1 file changed, 16 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>> index 9692656..28f728b 100644
>> --- a/drivers/xen/xlate_mmu.c
>> +++ b/drivers/xen/xlate_mmu.c
>> @@ -207,9 +207,12 @@ int __init
>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>> void *vaddr;
>> int rc;
>> unsigned int i;
>> + unsigned long nr_pages;
>> + xen_pfn_t xen_pfn = 0;
>>
>> BUG_ON(nr_grant_frames == 0);
>> - pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
>> + nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
>> + pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
>> if (!pages)
>> return -ENOMEM;
>>
>> @@ -218,22 +221,25 @@ int __init
>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>> kfree(pages);
>> return -ENOMEM;
>> }
>> - rc = alloc_xenballooned_pages(nr_grant_frames, pages);
>> + rc = alloc_xenballooned_pages(nr_pages, pages);
>> if (rc) {
>> - pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
>> - nr_grant_frames, rc);
>> + pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
>> + nr_pages, rc);
>> kfree(pages);
>> kfree(pfns);
>> return rc;
>> }
>> - for (i = 0; i < nr_grant_frames; i++)
>> - pfns[i] = page_to_pfn(pages[i]);
>> + for (i = 0; i < nr_grant_frames; i++) {
>> + if ((i % XEN_PFN_PER_PAGE) == 0)
>> + xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
>> + pfns[i] = pfn_to_gfn(xen_pfn++);
>> + }
>
> Would it be possible to re-use xen_for_each_gfn? This will avoid
> open-coding the loop to break down the Linux page.
I don't think so. Using xen_acpi_guest_init will require factoring
"pfns[i] = pfn_to_gfn(xen_pfn++)" to a function with parameter pfns[i].
How can we pass pfns[i]?
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
2016-03-30 7:38 ` Shannon Zhao
(?)
(?)
@ 2016-03-30 11:22 ` Julien Grall
-1 siblings, 0 replies; 172+ messages in thread
From: Julien Grall @ 2016-03-30 11:22 UTC (permalink / raw)
To: Shannon Zhao, Shannon Zhao, linux-arm-kernel, stefano.stabellini,
david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
peter.huangpeng, linux-kernel, xen-devel
Hi Shannon,
On 30/03/16 08:38, Shannon Zhao wrote:
>
>
> On 2016/3/30 0:28, Julien Grall wrote:
>> On 24/03/16 14:44, Shannon Zhao wrote:
>>> Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
>>> Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
>>> refer to 4K pages.
>>>
>>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> ---
>>> drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
>>> 1 file changed, 16 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>>> index 9692656..28f728b 100644
>>> --- a/drivers/xen/xlate_mmu.c
>>> +++ b/drivers/xen/xlate_mmu.c
>>> @@ -207,9 +207,12 @@ int __init
>>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>>> void *vaddr;
>>> int rc;
>>> unsigned int i;
>>> + unsigned long nr_pages;
>>> + xen_pfn_t xen_pfn = 0;
>>>
>>> BUG_ON(nr_grant_frames == 0);
>>> - pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
>>> + nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
>>> + pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
>>> if (!pages)
>>> return -ENOMEM;
>>>
>>> @@ -218,22 +221,25 @@ int __init
>>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>>> kfree(pages);
>>> return -ENOMEM;
>>> }
>>> - rc = alloc_xenballooned_pages(nr_grant_frames, pages);
>>> + rc = alloc_xenballooned_pages(nr_pages, pages);
>>> if (rc) {
>>> - pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
>>> - nr_grant_frames, rc);
>>> + pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
>>> + nr_pages, rc);
>>> kfree(pages);
>>> kfree(pfns);
>>> return rc;
>>> }
>>> - for (i = 0; i < nr_grant_frames; i++)
>>> - pfns[i] = page_to_pfn(pages[i]);
>>> + for (i = 0; i < nr_grant_frames; i++) {
>>> + if ((i % XEN_PFN_PER_PAGE) == 0)
>>> + xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
>>> + pfns[i] = pfn_to_gfn(xen_pfn++);
>>> + }
>>
>> Would it be possible to re-use xen_for_each_gfn? This will avoid
>> open-coding the loop to break down the Linux page.
> I don't think so. Using xen_acpi_guest_init will require factoring
> "pfns[i] = pfn_to_gfn(xen_pfn++)" to a function with parameter pfns[i].
> How can we pass pfns[i]?
By using the variable data. Something along those lines:
struct map_balloon_pages
{
xen_pfn_t *pfns;
unsigned int idx;
};
static void setup_balloon_gfn(unsigned long gfn, void *data)
{
struct map_balloon_pages *info = data;
data->pfns[data->idx] = gfn;
data->idx++;
}
And then in xen_xlate_map_ballooned_pages
xen_for_each_gfn(pages, nr_grant_frames, setup_balloon_gfn, &data);
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
@ 2016-03-30 11:22 ` Julien Grall
0 siblings, 0 replies; 172+ messages in thread
From: Julien Grall @ 2016-03-30 11:22 UTC (permalink / raw)
To: Shannon Zhao, Shannon Zhao, linux-arm-kernel, stefano.stabellini,
david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, peter.huangpeng, xen-devel
Hi Shannon,
On 30/03/16 08:38, Shannon Zhao wrote:
>
>
> On 2016/3/30 0:28, Julien Grall wrote:
>> On 24/03/16 14:44, Shannon Zhao wrote:
>>> Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
>>> Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
>>> refer to 4K pages.
>>>
>>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> ---
>>> drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
>>> 1 file changed, 16 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>>> index 9692656..28f728b 100644
>>> --- a/drivers/xen/xlate_mmu.c
>>> +++ b/drivers/xen/xlate_mmu.c
>>> @@ -207,9 +207,12 @@ int __init
>>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>>> void *vaddr;
>>> int rc;
>>> unsigned int i;
>>> + unsigned long nr_pages;
>>> + xen_pfn_t xen_pfn = 0;
>>>
>>> BUG_ON(nr_grant_frames == 0);
>>> - pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
>>> + nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
>>> + pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
>>> if (!pages)
>>> return -ENOMEM;
>>>
>>> @@ -218,22 +221,25 @@ int __init
>>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>>> kfree(pages);
>>> return -ENOMEM;
>>> }
>>> - rc = alloc_xenballooned_pages(nr_grant_frames, pages);
>>> + rc = alloc_xenballooned_pages(nr_pages, pages);
>>> if (rc) {
>>> - pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
>>> - nr_grant_frames, rc);
>>> + pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
>>> + nr_pages, rc);
>>> kfree(pages);
>>> kfree(pfns);
>>> return rc;
>>> }
>>> - for (i = 0; i < nr_grant_frames; i++)
>>> - pfns[i] = page_to_pfn(pages[i]);
>>> + for (i = 0; i < nr_grant_frames; i++) {
>>> + if ((i % XEN_PFN_PER_PAGE) == 0)
>>> + xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
>>> + pfns[i] = pfn_to_gfn(xen_pfn++);
>>> + }
>>
>> Would it be possible to re-use xen_for_each_gfn? This will avoid
>> open-coding the loop to break down the Linux page.
> I don't think so. Using xen_acpi_guest_init will require factoring
> "pfns[i] = pfn_to_gfn(xen_pfn++)" to a function with parameter pfns[i].
> How can we pass pfns[i]?
By using the variable data. Something along those lines:
struct map_balloon_pages
{
xen_pfn_t *pfns;
unsigned int idx;
};
static void setup_balloon_gfn(unsigned long gfn, void *data)
{
struct map_balloon_pages *info = data;
data->pfns[data->idx] = gfn;
data->idx++;
}
And then in xen_xlate_map_ballooned_pages
xen_for_each_gfn(pages, nr_grant_frames, setup_balloon_gfn, &data);
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
@ 2016-03-30 11:22 ` Julien Grall
0 siblings, 0 replies; 172+ messages in thread
From: Julien Grall @ 2016-03-30 11:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi Shannon,
On 30/03/16 08:38, Shannon Zhao wrote:
>
>
> On 2016/3/30 0:28, Julien Grall wrote:
>> On 24/03/16 14:44, Shannon Zhao wrote:
>>> Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
>>> Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
>>> refer to 4K pages.
>>>
>>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> ---
>>> drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
>>> 1 file changed, 16 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>>> index 9692656..28f728b 100644
>>> --- a/drivers/xen/xlate_mmu.c
>>> +++ b/drivers/xen/xlate_mmu.c
>>> @@ -207,9 +207,12 @@ int __init
>>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>>> void *vaddr;
>>> int rc;
>>> unsigned int i;
>>> + unsigned long nr_pages;
>>> + xen_pfn_t xen_pfn = 0;
>>>
>>> BUG_ON(nr_grant_frames == 0);
>>> - pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
>>> + nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
>>> + pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
>>> if (!pages)
>>> return -ENOMEM;
>>>
>>> @@ -218,22 +221,25 @@ int __init
>>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>>> kfree(pages);
>>> return -ENOMEM;
>>> }
>>> - rc = alloc_xenballooned_pages(nr_grant_frames, pages);
>>> + rc = alloc_xenballooned_pages(nr_pages, pages);
>>> if (rc) {
>>> - pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
>>> - nr_grant_frames, rc);
>>> + pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
>>> + nr_pages, rc);
>>> kfree(pages);
>>> kfree(pfns);
>>> return rc;
>>> }
>>> - for (i = 0; i < nr_grant_frames; i++)
>>> - pfns[i] = page_to_pfn(pages[i]);
>>> + for (i = 0; i < nr_grant_frames; i++) {
>>> + if ((i % XEN_PFN_PER_PAGE) == 0)
>>> + xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
>>> + pfns[i] = pfn_to_gfn(xen_pfn++);
>>> + }
>>
>> Would it be possible to re-use xen_for_each_gfn? This will avoid
>> open-coding the loop to break down the Linux page.
> I don't think so. Using xen_acpi_guest_init will require factoring
> "pfns[i] = pfn_to_gfn(xen_pfn++)" to a function with parameter pfns[i].
> How can we pass pfns[i]?
By using the variable data. Something along those lines:
struct map_balloon_pages
{
xen_pfn_t *pfns;
unsigned int idx;
};
static void setup_balloon_gfn(unsigned long gfn, void *data)
{
struct map_balloon_pages *info = data;
data->pfns[data->idx] = gfn;
data->idx++;
}
And then in xen_xlate_map_ballooned_pages
xen_for_each_gfn(pages, nr_grant_frames, setup_balloon_gfn, &data);
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
@ 2016-03-30 11:22 ` Julien Grall
0 siblings, 0 replies; 172+ messages in thread
From: Julien Grall @ 2016-03-30 11:22 UTC (permalink / raw)
To: Shannon Zhao, Shannon Zhao,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw
Hi Shannon,
On 30/03/16 08:38, Shannon Zhao wrote:
>
>
> On 2016/3/30 0:28, Julien Grall wrote:
>> On 24/03/16 14:44, Shannon Zhao wrote:
>>> Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
>>> Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
>>> refer to 4K pages.
>>>
>>> Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> Reviewed-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
>>> ---
>>> drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
>>> 1 file changed, 16 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>>> index 9692656..28f728b 100644
>>> --- a/drivers/xen/xlate_mmu.c
>>> +++ b/drivers/xen/xlate_mmu.c
>>> @@ -207,9 +207,12 @@ int __init
>>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>>> void *vaddr;
>>> int rc;
>>> unsigned int i;
>>> + unsigned long nr_pages;
>>> + xen_pfn_t xen_pfn = 0;
>>>
>>> BUG_ON(nr_grant_frames == 0);
>>> - pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
>>> + nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
>>> + pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
>>> if (!pages)
>>> return -ENOMEM;
>>>
>>> @@ -218,22 +221,25 @@ int __init
>>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>>> kfree(pages);
>>> return -ENOMEM;
>>> }
>>> - rc = alloc_xenballooned_pages(nr_grant_frames, pages);
>>> + rc = alloc_xenballooned_pages(nr_pages, pages);
>>> if (rc) {
>>> - pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
>>> - nr_grant_frames, rc);
>>> + pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
>>> + nr_pages, rc);
>>> kfree(pages);
>>> kfree(pfns);
>>> return rc;
>>> }
>>> - for (i = 0; i < nr_grant_frames; i++)
>>> - pfns[i] = page_to_pfn(pages[i]);
>>> + for (i = 0; i < nr_grant_frames; i++) {
>>> + if ((i % XEN_PFN_PER_PAGE) == 0)
>>> + xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
>>> + pfns[i] = pfn_to_gfn(xen_pfn++);
>>> + }
>>
>> Would it be possible to re-use xen_for_each_gfn? This will avoid
>> open-coding the loop to break down the Linux page.
> I don't think so. Using xen_acpi_guest_init will require factoring
> "pfns[i] = pfn_to_gfn(xen_pfn++)" to a function with parameter pfns[i].
> How can we pass pfns[i]?
By using the variable data. Something along those lines:
struct map_balloon_pages
{
xen_pfn_t *pfns;
unsigned int idx;
};
static void setup_balloon_gfn(unsigned long gfn, void *data)
{
struct map_balloon_pages *info = data;
data->pfns[data->idx] = gfn;
data->idx++;
}
And then in xen_xlate_map_ballooned_pages
xen_for_each_gfn(pages, nr_grant_frames, setup_balloon_gfn, &data);
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
2016-03-30 11:22 ` Julien Grall
(?)
(?)
@ 2016-03-30 12:42 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-30 12:42 UTC (permalink / raw)
To: Julien Grall, Shannon Zhao, linux-arm-kernel, stefano.stabellini,
david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
peter.huangpeng, linux-kernel, xen-devel
On 2016年03月30日 19:22, Julien Grall wrote:
> Hi Shannon,
>
> On 30/03/16 08:38, Shannon Zhao wrote:
>>
>>
>> On 2016/3/30 0:28, Julien Grall wrote:
>>> On 24/03/16 14:44, Shannon Zhao wrote:
>>>> Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
>>>> Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
>>>> refer to 4K pages.
>>>>
>>>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>> ---
>>>> drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
>>>> 1 file changed, 16 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>>>> index 9692656..28f728b 100644
>>>> --- a/drivers/xen/xlate_mmu.c
>>>> +++ b/drivers/xen/xlate_mmu.c
>>>> @@ -207,9 +207,12 @@ int __init
>>>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>>>> void *vaddr;
>>>> int rc;
>>>> unsigned int i;
>>>> + unsigned long nr_pages;
>>>> + xen_pfn_t xen_pfn = 0;
>>>>
>>>> BUG_ON(nr_grant_frames == 0);
>>>> - pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
>>>> + nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
>>>> + pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
>>>> if (!pages)
>>>> return -ENOMEM;
>>>>
>>>> @@ -218,22 +221,25 @@ int __init
>>>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>>>> kfree(pages);
>>>> return -ENOMEM;
>>>> }
>>>> - rc = alloc_xenballooned_pages(nr_grant_frames, pages);
>>>> + rc = alloc_xenballooned_pages(nr_pages, pages);
>>>> if (rc) {
>>>> - pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n",
>>>> __func__,
>>>> - nr_grant_frames, rc);
>>>> + pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n",
>>>> __func__,
>>>> + nr_pages, rc);
>>>> kfree(pages);
>>>> kfree(pfns);
>>>> return rc;
>>>> }
>>>> - for (i = 0; i < nr_grant_frames; i++)
>>>> - pfns[i] = page_to_pfn(pages[i]);
>>>> + for (i = 0; i < nr_grant_frames; i++) {
>>>> + if ((i % XEN_PFN_PER_PAGE) == 0)
>>>> + xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
>>>> + pfns[i] = pfn_to_gfn(xen_pfn++);
>>>> + }
>>>
>>> Would it be possible to re-use xen_for_each_gfn? This will avoid
>>> open-coding the loop to break down the Linux page.
>> I don't think so. Using xen_acpi_guest_init will require factoring
>> "pfns[i] = pfn_to_gfn(xen_pfn++)" to a function with parameter pfns[i].
>> How can we pass pfns[i]?
>
> By using the variable data. Something along those lines:
>
> struct map_balloon_pages
> {
> xen_pfn_t *pfns;
> unsigned int idx;
> };
>
> static void setup_balloon_gfn(unsigned long gfn, void *data)
> {
> struct map_balloon_pages *info = data;
>
>
> data->pfns[data->idx] = gfn;
> data->idx++;
> }
>
> And then in xen_xlate_map_ballooned_pages
>
> xen_for_each_gfn(pages, nr_grant_frames, setup_balloon_gfn, &data);
I think this looks like less direct. Anyway I will update this patch as
you said.
Thanks,
--
Shannon
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
2016-03-30 11:22 ` Julien Grall
(?)
@ 2016-03-30 12:42 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-30 12:42 UTC (permalink / raw)
To: Julien Grall, Shannon Zhao, linux-arm-kernel, stefano.stabellini,
david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, peter.huangpeng, xen-devel
On 2016年03月30日 19:22, Julien Grall wrote:
> Hi Shannon,
>
> On 30/03/16 08:38, Shannon Zhao wrote:
>>
>>
>> On 2016/3/30 0:28, Julien Grall wrote:
>>> On 24/03/16 14:44, Shannon Zhao wrote:
>>>> Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
>>>> Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
>>>> refer to 4K pages.
>>>>
>>>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>> ---
>>>> drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
>>>> 1 file changed, 16 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>>>> index 9692656..28f728b 100644
>>>> --- a/drivers/xen/xlate_mmu.c
>>>> +++ b/drivers/xen/xlate_mmu.c
>>>> @@ -207,9 +207,12 @@ int __init
>>>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>>>> void *vaddr;
>>>> int rc;
>>>> unsigned int i;
>>>> + unsigned long nr_pages;
>>>> + xen_pfn_t xen_pfn = 0;
>>>>
>>>> BUG_ON(nr_grant_frames == 0);
>>>> - pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
>>>> + nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
>>>> + pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
>>>> if (!pages)
>>>> return -ENOMEM;
>>>>
>>>> @@ -218,22 +221,25 @@ int __init
>>>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>>>> kfree(pages);
>>>> return -ENOMEM;
>>>> }
>>>> - rc = alloc_xenballooned_pages(nr_grant_frames, pages);
>>>> + rc = alloc_xenballooned_pages(nr_pages, pages);
>>>> if (rc) {
>>>> - pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n",
>>>> __func__,
>>>> - nr_grant_frames, rc);
>>>> + pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n",
>>>> __func__,
>>>> + nr_pages, rc);
>>>> kfree(pages);
>>>> kfree(pfns);
>>>> return rc;
>>>> }
>>>> - for (i = 0; i < nr_grant_frames; i++)
>>>> - pfns[i] = page_to_pfn(pages[i]);
>>>> + for (i = 0; i < nr_grant_frames; i++) {
>>>> + if ((i % XEN_PFN_PER_PAGE) == 0)
>>>> + xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
>>>> + pfns[i] = pfn_to_gfn(xen_pfn++);
>>>> + }
>>>
>>> Would it be possible to re-use xen_for_each_gfn? This will avoid
>>> open-coding the loop to break down the Linux page.
>> I don't think so. Using xen_acpi_guest_init will require factoring
>> "pfns[i] = pfn_to_gfn(xen_pfn++)" to a function with parameter pfns[i].
>> How can we pass pfns[i]?
>
> By using the variable data. Something along those lines:
>
> struct map_balloon_pages
> {
> xen_pfn_t *pfns;
> unsigned int idx;
> };
>
> static void setup_balloon_gfn(unsigned long gfn, void *data)
> {
> struct map_balloon_pages *info = data;
>
>
> data->pfns[data->idx] = gfn;
> data->idx++;
> }
>
> And then in xen_xlate_map_ballooned_pages
>
> xen_for_each_gfn(pages, nr_grant_frames, setup_balloon_gfn, &data);
I think this looks like less direct. Anyway I will update this patch as
you said.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
@ 2016-03-30 12:42 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-30 12:42 UTC (permalink / raw)
To: linux-arm-kernel
On 2016?03?30? 19:22, Julien Grall wrote:
> Hi Shannon,
>
> On 30/03/16 08:38, Shannon Zhao wrote:
>>
>>
>> On 2016/3/30 0:28, Julien Grall wrote:
>>> On 24/03/16 14:44, Shannon Zhao wrote:
>>>> Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
>>>> Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
>>>> refer to 4K pages.
>>>>
>>>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>> ---
>>>> drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
>>>> 1 file changed, 16 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>>>> index 9692656..28f728b 100644
>>>> --- a/drivers/xen/xlate_mmu.c
>>>> +++ b/drivers/xen/xlate_mmu.c
>>>> @@ -207,9 +207,12 @@ int __init
>>>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>>>> void *vaddr;
>>>> int rc;
>>>> unsigned int i;
>>>> + unsigned long nr_pages;
>>>> + xen_pfn_t xen_pfn = 0;
>>>>
>>>> BUG_ON(nr_grant_frames == 0);
>>>> - pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
>>>> + nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
>>>> + pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
>>>> if (!pages)
>>>> return -ENOMEM;
>>>>
>>>> @@ -218,22 +221,25 @@ int __init
>>>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>>>> kfree(pages);
>>>> return -ENOMEM;
>>>> }
>>>> - rc = alloc_xenballooned_pages(nr_grant_frames, pages);
>>>> + rc = alloc_xenballooned_pages(nr_pages, pages);
>>>> if (rc) {
>>>> - pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n",
>>>> __func__,
>>>> - nr_grant_frames, rc);
>>>> + pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n",
>>>> __func__,
>>>> + nr_pages, rc);
>>>> kfree(pages);
>>>> kfree(pfns);
>>>> return rc;
>>>> }
>>>> - for (i = 0; i < nr_grant_frames; i++)
>>>> - pfns[i] = page_to_pfn(pages[i]);
>>>> + for (i = 0; i < nr_grant_frames; i++) {
>>>> + if ((i % XEN_PFN_PER_PAGE) == 0)
>>>> + xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
>>>> + pfns[i] = pfn_to_gfn(xen_pfn++);
>>>> + }
>>>
>>> Would it be possible to re-use xen_for_each_gfn? This will avoid
>>> open-coding the loop to break down the Linux page.
>> I don't think so. Using xen_acpi_guest_init will require factoring
>> "pfns[i] = pfn_to_gfn(xen_pfn++)" to a function with parameter pfns[i].
>> How can we pass pfns[i]?
>
> By using the variable data. Something along those lines:
>
> struct map_balloon_pages
> {
> xen_pfn_t *pfns;
> unsigned int idx;
> };
>
> static void setup_balloon_gfn(unsigned long gfn, void *data)
> {
> struct map_balloon_pages *info = data;
>
>
> data->pfns[data->idx] = gfn;
> data->idx++;
> }
>
> And then in xen_xlate_map_ballooned_pages
>
> xen_for_each_gfn(pages, nr_grant_frames, setup_balloon_gfn, &data);
I think this looks like less direct. Anyway I will update this patch as
you said.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
@ 2016-03-30 12:42 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-30 12:42 UTC (permalink / raw)
To: Julien Grall, Shannon Zhao, linux-arm-kernel, stefano.stabellini,
david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
peter.huangpeng, linux-kernel, xen-devel
On 2016年03月30日 19:22, Julien Grall wrote:
> Hi Shannon,
>
> On 30/03/16 08:38, Shannon Zhao wrote:
>>
>>
>> On 2016/3/30 0:28, Julien Grall wrote:
>>> On 24/03/16 14:44, Shannon Zhao wrote:
>>>> Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
>>>> Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
>>>> refer to 4K pages.
>>>>
>>>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>> ---
>>>> drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
>>>> 1 file changed, 16 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>>>> index 9692656..28f728b 100644
>>>> --- a/drivers/xen/xlate_mmu.c
>>>> +++ b/drivers/xen/xlate_mmu.c
>>>> @@ -207,9 +207,12 @@ int __init
>>>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>>>> void *vaddr;
>>>> int rc;
>>>> unsigned int i;
>>>> + unsigned long nr_pages;
>>>> + xen_pfn_t xen_pfn = 0;
>>>>
>>>> BUG_ON(nr_grant_frames == 0);
>>>> - pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
>>>> + nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
>>>> + pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
>>>> if (!pages)
>>>> return -ENOMEM;
>>>>
>>>> @@ -218,22 +221,25 @@ int __init
>>>> xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
>>>> kfree(pages);
>>>> return -ENOMEM;
>>>> }
>>>> - rc = alloc_xenballooned_pages(nr_grant_frames, pages);
>>>> + rc = alloc_xenballooned_pages(nr_pages, pages);
>>>> if (rc) {
>>>> - pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n",
>>>> __func__,
>>>> - nr_grant_frames, rc);
>>>> + pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n",
>>>> __func__,
>>>> + nr_pages, rc);
>>>> kfree(pages);
>>>> kfree(pfns);
>>>> return rc;
>>>> }
>>>> - for (i = 0; i < nr_grant_frames; i++)
>>>> - pfns[i] = page_to_pfn(pages[i]);
>>>> + for (i = 0; i < nr_grant_frames; i++) {
>>>> + if ((i % XEN_PFN_PER_PAGE) == 0)
>>>> + xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
>>>> + pfns[i] = pfn_to_gfn(xen_pfn++);
>>>> + }
>>>
>>> Would it be possible to re-use xen_for_each_gfn? This will avoid
>>> open-coding the loop to break down the Linux page.
>> I don't think so. Using xen_acpi_guest_init will require factoring
>> "pfns[i] = pfn_to_gfn(xen_pfn++)" to a function with parameter pfns[i].
>> How can we pass pfns[i]?
>
> By using the variable data. Something along those lines:
>
> struct map_balloon_pages
> {
> xen_pfn_t *pfns;
> unsigned int idx;
> };
>
> static void setup_balloon_gfn(unsigned long gfn, void *data)
> {
> struct map_balloon_pages *info = data;
>
>
> data->pfns[data->idx] = gfn;
> data->idx++;
> }
>
> And then in xen_xlate_map_ballooned_pages
>
> xen_for_each_gfn(pages, nr_grant_frames, setup_balloon_gfn, &data);
I think this looks like less direct. Anyway I will update this patch as
you said.
Thanks,
--
Shannon
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v7 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
2016-03-24 14:44 ` Shannon Zhao
` (2 preceding siblings ...)
(?)
@ 2016-03-29 16:28 ` Julien Grall
-1 siblings, 0 replies; 172+ messages in thread
From: Julien Grall @ 2016-03-29 16:28 UTC (permalink / raw)
To: Shannon Zhao, linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
peter.huangpeng, linux-kernel, zhaoshenglong, xen-devel
Hi Shannon,
On 24/03/16 14:44, Shannon Zhao wrote:
> Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
> Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
> refer to 4K pages.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
> drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
> 1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
> index 9692656..28f728b 100644
> --- a/drivers/xen/xlate_mmu.c
> +++ b/drivers/xen/xlate_mmu.c
> @@ -207,9 +207,12 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
> void *vaddr;
> int rc;
> unsigned int i;
> + unsigned long nr_pages;
> + xen_pfn_t xen_pfn = 0;
>
> BUG_ON(nr_grant_frames == 0);
> - pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
> + nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
> + pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
> if (!pages)
> return -ENOMEM;
>
> @@ -218,22 +221,25 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
> kfree(pages);
> return -ENOMEM;
> }
> - rc = alloc_xenballooned_pages(nr_grant_frames, pages);
> + rc = alloc_xenballooned_pages(nr_pages, pages);
> if (rc) {
> - pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
> - nr_grant_frames, rc);
> + pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
> + nr_pages, rc);
> kfree(pages);
> kfree(pfns);
> return rc;
> }
> - for (i = 0; i < nr_grant_frames; i++)
> - pfns[i] = page_to_pfn(pages[i]);
> + for (i = 0; i < nr_grant_frames; i++) {
> + if ((i % XEN_PFN_PER_PAGE) == 0)
> + xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
> + pfns[i] = pfn_to_gfn(xen_pfn++);
> + }
Would it be possible to re-use xen_for_each_gfn? This will avoid
open-coding the loop to break down the Linux page.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread
* [PATCH v7 04/17] arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao
Use xen_xlate_map_ballooned_pages to setup grant table. Then it doesn't
rely on DT or ACPI to pass the start address and size of grant table.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/arm/xen/enlighten.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..d94f726 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -282,18 +282,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");
@@ -328,7 +320,10 @@ static int __init xen_guest_init(void)
if (xen_vcpu_info == NULL)
return -ENOMEM;
- if (gnttab_setup_auto_xlat_frames(grant_frames)) {
+ xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+ if (xen_xlate_map_ballooned_pages(&xen_auto_xlat_grant_frames.pfn,
+ &xen_auto_xlat_grant_frames.vaddr,
+ xen_auto_xlat_grant_frames.count)) {
free_percpu(xen_vcpu_info);
return -ENOMEM;
}
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 04/17] arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
Use xen_xlate_map_ballooned_pages to setup grant table. Then it doesn't
rely on DT or ACPI to pass the start address and size of grant table.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/arm/xen/enlighten.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..d94f726 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -282,18 +282,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");
@@ -328,7 +320,10 @@ static int __init xen_guest_init(void)
if (xen_vcpu_info == NULL)
return -ENOMEM;
- if (gnttab_setup_auto_xlat_frames(grant_frames)) {
+ xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+ if (xen_xlate_map_ballooned_pages(&xen_auto_xlat_grant_frames.pfn,
+ &xen_auto_xlat_grant_frames.vaddr,
+ xen_auto_xlat_grant_frames.count)) {
free_percpu(xen_vcpu_info);
return -ENOMEM;
}
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 04/17] arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, julien.grall-5wv7dgnIgG8,
peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
zhaoshenglong-hv44wF8Li93QT0dZR+AlfA,
shannon.zhao-QSEj5FYQhm4dnm+yROfE0A
Use xen_xlate_map_ballooned_pages to setup grant table. Then it doesn't
rely on DT or ACPI to pass the start address and size of grant table.
Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
---
arch/arm/xen/enlighten.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..d94f726 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -282,18 +282,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");
@@ -328,7 +320,10 @@ static int __init xen_guest_init(void)
if (xen_vcpu_info == NULL)
return -ENOMEM;
- if (gnttab_setup_auto_xlat_frames(grant_frames)) {
+ xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+ if (xen_xlate_map_ballooned_pages(&xen_auto_xlat_grant_frames.pfn,
+ &xen_auto_xlat_grant_frames.vaddr,
+ xen_auto_xlat_grant_frames.count)) {
free_percpu(xen_vcpu_info);
return -ENOMEM;
}
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread
* [PATCH v7 04/17] arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
2016-03-24 14:44 ` Shannon Zhao
` (7 preceding siblings ...)
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, shannon.zhao,
zhaoshenglong, xen-devel
Use xen_xlate_map_ballooned_pages to setup grant table. Then it doesn't
rely on DT or ACPI to pass the start address and size of grant table.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/arm/xen/enlighten.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..d94f726 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -282,18 +282,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");
@@ -328,7 +320,10 @@ static int __init xen_guest_init(void)
if (xen_vcpu_info == NULL)
return -ENOMEM;
- if (gnttab_setup_auto_xlat_frames(grant_frames)) {
+ xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+ if (xen_xlate_map_ballooned_pages(&xen_auto_xlat_grant_frames.pfn,
+ &xen_auto_xlat_grant_frames.vaddr,
+ xen_auto_xlat_grant_frames.count)) {
free_percpu(xen_vcpu_info);
return -ENOMEM;
}
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 05/17] xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao
Add a new type of Xen map space for Dom0 to map device's MMIO region.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
include/xen/interface/memory.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 2ecfe4f..9aa8988 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -160,6 +160,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
* XENMEM_add_to_physmap_range only.
*/
+#define XENMAPSPACE_dev_mmio 5 /* device mmio region */
/*
* Sets the GPFN at which a particular page appears in the specified guest's
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread
* [PATCH v7 05/17] xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
Add a new type of Xen map space for Dom0 to map device's MMIO region.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
include/xen/interface/memory.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 2ecfe4f..9aa8988 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -160,6 +160,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
* XENMEM_add_to_physmap_range only.
*/
+#define XENMAPSPACE_dev_mmio 5 /* device mmio region */
/*
* Sets the GPFN at which a particular page appears in the specified guest's
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread
* [PATCH v7 05/17] xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, julien.grall-5wv7dgnIgG8,
peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
zhaoshenglong-hv44wF8Li93QT0dZR+AlfA,
shannon.zhao-QSEj5FYQhm4dnm+yROfE0A
Add a new type of Xen map space for Dom0 to map device's MMIO region.
Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
include/xen/interface/memory.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 2ecfe4f..9aa8988 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -160,6 +160,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
* XENMEM_add_to_physmap_range only.
*/
+#define XENMAPSPACE_dev_mmio 5 /* device mmio region */
/*
* Sets the GPFN at which a particular page appears in the specified guest's
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 172+ messages in thread
* [PATCH v7 05/17] xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
2016-03-24 14:44 ` Shannon Zhao
` (9 preceding siblings ...)
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, shannon.zhao,
zhaoshenglong, xen-devel
Add a new type of Xen map space for Dom0 to map device's MMIO region.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
include/xen/interface/memory.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 2ecfe4f..9aa8988 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -160,6 +160,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
* XENMEM_add_to_physmap_range only.
*/
+#define XENMAPSPACE_dev_mmio 5 /* device mmio region */
/*
* Sets the GPFN at which a particular page appears in the specified guest's
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 06/17] Xen: ARM: Add support for mapping platform device mmio
2016-03-24 14:44 ` Shannon Zhao
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao
Add a bus_notifier for platform bus device in order to map the device
mmio regions when DOM0 booting with ACPI.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
drivers/xen/Makefile | 1 +
drivers/xen/arm-device.c | 141 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 142 insertions(+)
create mode 100644 drivers/xen/arm-device.c
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 9b7a35c..415f286 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -9,6 +9,7 @@ CFLAGS_features.o := $(nostackp)
CFLAGS_efi.o += -fshort-wchar
+dom0-$(CONFIG_ARM64) += arm-device.o
dom0-$(CONFIG_PCI) += pci.o
dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
new file mode 100644
index 0000000..76e26e5
--- /dev/null
+++ b/drivers/xen/arm-device.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/platform_device.h>
+#include <linux/acpi.h>
+#include <xen/xen.h>
+#include <xen/page.h>
+#include <xen/interface/memory.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+
+static int xen_unmap_device_mmio(struct resource *resource, unsigned int count)
+{
+ unsigned int i, j, nr;
+ int rc = 0;
+ struct resource *r;
+ struct xen_remove_from_physmap xrp;
+
+ for (i = 0; i < count; i++) {
+ r = &resource[i];
+ nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+ if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+ continue;
+
+ for (j = 0; j < nr; j++) {
+ xrp.domid = DOMID_SELF;
+ xrp.gpfn = XEN_PFN_DOWN(r->start) + j;
+ rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap,
+ &xrp);
+ if (rc)
+ return rc;
+ }
+ }
+
+ return rc;
+}
+
+static int xen_map_device_mmio(struct resource *resource, unsigned int count)
+{
+ unsigned int i, j, nr;
+ int rc = 0;
+ struct resource *r;
+ xen_pfn_t *gpfns;
+ xen_ulong_t *idxs;
+ int *errs;
+ struct xen_add_to_physmap_range xatp;
+
+ for (i = 0; i < count; i++) {
+ r = &resource[i];
+ nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+ if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+ continue;
+
+ gpfns = kzalloc(sizeof(xen_pfn_t) * nr, GFP_KERNEL);
+ idxs = kzalloc(sizeof(xen_ulong_t) * nr, GFP_KERNEL);
+ errs = kzalloc(sizeof(int) * nr, GFP_KERNEL);
+ if (!gpfns || !idxs || !errs) {
+ kfree(gpfns);
+ kfree(idxs);
+ kfree(errs);
+ return -ENOMEM;
+ }
+
+ for (j = 0; j < nr; j++) {
+ gpfns[j] = XEN_PFN_DOWN(r->start) + j;
+ idxs[j] = XEN_PFN_DOWN(r->start) + j;
+ }
+
+ 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)
+ 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 (pdev->num_resources == 0 || pdev->resource == NULL)
+ return NOTIFY_OK;
+
+ switch (action) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ r = xen_map_device_mmio(pdev->resource, pdev->num_resources);
+ break;
+ case BUS_NOTIFY_DEL_DEVICE:
+ r = xen_unmap_device_mmio(pdev->resource, pdev->num_resources);
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+ if (r)
+ dev_err(&pdev->dev, "Platform: Failed to %s device %s MMIO!\n",
+ action == BUS_NOTIFY_ADD_DEVICE ? "map" :
+ (action == BUS_NOTIFY_DEL_DEVICE ? "unmap" : "?"),
+ pdev->name);
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block platform_device_nb = {
+ .notifier_call = xen_platform_notifier,
+};
+
+static int __init register_xen_platform_notifier(void)
+{
+ if (!xen_initial_domain() || acpi_disabled)
+ return 0;
+
+ return bus_register_notifier(&platform_bus_type, &platform_device_nb);
+}
+
+arch_initcall(register_xen_platform_notifier);
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 06/17] Xen: ARM: Add support for mapping platform device mmio
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
Add a bus_notifier for platform bus device in order to map the device
mmio regions when DOM0 booting with ACPI.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
drivers/xen/Makefile | 1 +
drivers/xen/arm-device.c | 141 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 142 insertions(+)
create mode 100644 drivers/xen/arm-device.c
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 9b7a35c..415f286 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -9,6 +9,7 @@ CFLAGS_features.o := $(nostackp)
CFLAGS_efi.o += -fshort-wchar
+dom0-$(CONFIG_ARM64) += arm-device.o
dom0-$(CONFIG_PCI) += pci.o
dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
new file mode 100644
index 0000000..76e26e5
--- /dev/null
+++ b/drivers/xen/arm-device.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/platform_device.h>
+#include <linux/acpi.h>
+#include <xen/xen.h>
+#include <xen/page.h>
+#include <xen/interface/memory.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+
+static int xen_unmap_device_mmio(struct resource *resource, unsigned int count)
+{
+ unsigned int i, j, nr;
+ int rc = 0;
+ struct resource *r;
+ struct xen_remove_from_physmap xrp;
+
+ for (i = 0; i < count; i++) {
+ r = &resource[i];
+ nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+ if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+ continue;
+
+ for (j = 0; j < nr; j++) {
+ xrp.domid = DOMID_SELF;
+ xrp.gpfn = XEN_PFN_DOWN(r->start) + j;
+ rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap,
+ &xrp);
+ if (rc)
+ return rc;
+ }
+ }
+
+ return rc;
+}
+
+static int xen_map_device_mmio(struct resource *resource, unsigned int count)
+{
+ unsigned int i, j, nr;
+ int rc = 0;
+ struct resource *r;
+ xen_pfn_t *gpfns;
+ xen_ulong_t *idxs;
+ int *errs;
+ struct xen_add_to_physmap_range xatp;
+
+ for (i = 0; i < count; i++) {
+ r = &resource[i];
+ nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+ if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+ continue;
+
+ gpfns = kzalloc(sizeof(xen_pfn_t) * nr, GFP_KERNEL);
+ idxs = kzalloc(sizeof(xen_ulong_t) * nr, GFP_KERNEL);
+ errs = kzalloc(sizeof(int) * nr, GFP_KERNEL);
+ if (!gpfns || !idxs || !errs) {
+ kfree(gpfns);
+ kfree(idxs);
+ kfree(errs);
+ return -ENOMEM;
+ }
+
+ for (j = 0; j < nr; j++) {
+ gpfns[j] = XEN_PFN_DOWN(r->start) + j;
+ idxs[j] = XEN_PFN_DOWN(r->start) + j;
+ }
+
+ 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)
+ 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 (pdev->num_resources == 0 || pdev->resource == NULL)
+ return NOTIFY_OK;
+
+ switch (action) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ r = xen_map_device_mmio(pdev->resource, pdev->num_resources);
+ break;
+ case BUS_NOTIFY_DEL_DEVICE:
+ r = xen_unmap_device_mmio(pdev->resource, pdev->num_resources);
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+ if (r)
+ dev_err(&pdev->dev, "Platform: Failed to %s device %s MMIO!\n",
+ action == BUS_NOTIFY_ADD_DEVICE ? "map" :
+ (action == BUS_NOTIFY_DEL_DEVICE ? "unmap" : "?"),
+ pdev->name);
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block platform_device_nb = {
+ .notifier_call = xen_platform_notifier,
+};
+
+static int __init register_xen_platform_notifier(void)
+{
+ if (!xen_initial_domain() || acpi_disabled)
+ return 0;
+
+ return bus_register_notifier(&platform_bus_type, &platform_device_nb);
+}
+
+arch_initcall(register_xen_platform_notifier);
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 06/17] Xen: ARM: Add support for mapping platform device mmio
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, shannon.zhao,
zhaoshenglong, xen-devel
Add a bus_notifier for platform bus device in order to map the device
mmio regions when DOM0 booting with ACPI.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
drivers/xen/Makefile | 1 +
drivers/xen/arm-device.c | 141 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 142 insertions(+)
create mode 100644 drivers/xen/arm-device.c
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 9b7a35c..415f286 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -9,6 +9,7 @@ CFLAGS_features.o := $(nostackp)
CFLAGS_efi.o += -fshort-wchar
+dom0-$(CONFIG_ARM64) += arm-device.o
dom0-$(CONFIG_PCI) += pci.o
dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
new file mode 100644
index 0000000..76e26e5
--- /dev/null
+++ b/drivers/xen/arm-device.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/platform_device.h>
+#include <linux/acpi.h>
+#include <xen/xen.h>
+#include <xen/page.h>
+#include <xen/interface/memory.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+
+static int xen_unmap_device_mmio(struct resource *resource, unsigned int count)
+{
+ unsigned int i, j, nr;
+ int rc = 0;
+ struct resource *r;
+ struct xen_remove_from_physmap xrp;
+
+ for (i = 0; i < count; i++) {
+ r = &resource[i];
+ nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+ if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+ continue;
+
+ for (j = 0; j < nr; j++) {
+ xrp.domid = DOMID_SELF;
+ xrp.gpfn = XEN_PFN_DOWN(r->start) + j;
+ rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap,
+ &xrp);
+ if (rc)
+ return rc;
+ }
+ }
+
+ return rc;
+}
+
+static int xen_map_device_mmio(struct resource *resource, unsigned int count)
+{
+ unsigned int i, j, nr;
+ int rc = 0;
+ struct resource *r;
+ xen_pfn_t *gpfns;
+ xen_ulong_t *idxs;
+ int *errs;
+ struct xen_add_to_physmap_range xatp;
+
+ for (i = 0; i < count; i++) {
+ r = &resource[i];
+ nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+ if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+ continue;
+
+ gpfns = kzalloc(sizeof(xen_pfn_t) * nr, GFP_KERNEL);
+ idxs = kzalloc(sizeof(xen_ulong_t) * nr, GFP_KERNEL);
+ errs = kzalloc(sizeof(int) * nr, GFP_KERNEL);
+ if (!gpfns || !idxs || !errs) {
+ kfree(gpfns);
+ kfree(idxs);
+ kfree(errs);
+ return -ENOMEM;
+ }
+
+ for (j = 0; j < nr; j++) {
+ gpfns[j] = XEN_PFN_DOWN(r->start) + j;
+ idxs[j] = XEN_PFN_DOWN(r->start) + j;
+ }
+
+ 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)
+ 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 (pdev->num_resources == 0 || pdev->resource == NULL)
+ return NOTIFY_OK;
+
+ switch (action) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ r = xen_map_device_mmio(pdev->resource, pdev->num_resources);
+ break;
+ case BUS_NOTIFY_DEL_DEVICE:
+ r = xen_unmap_device_mmio(pdev->resource, pdev->num_resources);
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+ if (r)
+ dev_err(&pdev->dev, "Platform: Failed to %s device %s MMIO!\n",
+ action == BUS_NOTIFY_ADD_DEVICE ? "map" :
+ (action == BUS_NOTIFY_DEL_DEVICE ? "unmap" : "?"),
+ pdev->name);
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block platform_device_nb = {
+ .notifier_call = xen_platform_notifier,
+};
+
+static int __init register_xen_platform_notifier(void)
+{
+ if (!xen_initial_domain() || acpi_disabled)
+ return 0;
+
+ return bus_register_notifier(&platform_bus_type, &platform_device_nb);
+}
+
+arch_initcall(register_xen_platform_notifier);
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread
* [PATCH v7 07/17] Xen: ARM: Add support for mapping AMBA device mmio
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao
Add a bus_notifier for AMBA bus device in order to map the device
mmio regions when DOM0 booting with ACPI.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
drivers/xen/arm-device.c | 43 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
index 76e26e5..3854043 100644
--- a/drivers/xen/arm-device.c
+++ b/drivers/xen/arm-device.c
@@ -139,3 +139,46 @@ static int __init register_xen_platform_notifier(void)
}
arch_initcall(register_xen_platform_notifier);
+
+#ifdef CONFIG_ARM_AMBA
+#include <linux/amba/bus.h>
+
+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;
+
+ switch (action) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ r = xen_map_device_mmio(&adev->res, 1);
+ break;
+ case BUS_NOTIFY_DEL_DEVICE:
+ r = xen_unmap_device_mmio(&adev->res, 1);
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+ if (r)
+ dev_err(&adev->dev, "AMBA: Failed to %s device %s MMIO!\n",
+ action == BUS_NOTIFY_ADD_DEVICE ? "map" :
+ (action == BUS_NOTIFY_DEL_DEVICE ? "unmap" : "?"),
+ adev->dev.init_name);
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block amba_device_nb = {
+ .notifier_call = xen_amba_notifier,
+};
+
+static int __init register_xen_amba_notifier(void)
+{
+ if (!xen_initial_domain() || acpi_disabled)
+ return 0;
+
+ return bus_register_notifier(&amba_bustype, &amba_device_nb);
+}
+
+arch_initcall(register_xen_amba_notifier);
+#endif
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 07/17] Xen: ARM: Add support for mapping AMBA device mmio
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
Add a bus_notifier for AMBA bus device in order to map the device
mmio regions when DOM0 booting with ACPI.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
drivers/xen/arm-device.c | 43 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
index 76e26e5..3854043 100644
--- a/drivers/xen/arm-device.c
+++ b/drivers/xen/arm-device.c
@@ -139,3 +139,46 @@ static int __init register_xen_platform_notifier(void)
}
arch_initcall(register_xen_platform_notifier);
+
+#ifdef CONFIG_ARM_AMBA
+#include <linux/amba/bus.h>
+
+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;
+
+ switch (action) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ r = xen_map_device_mmio(&adev->res, 1);
+ break;
+ case BUS_NOTIFY_DEL_DEVICE:
+ r = xen_unmap_device_mmio(&adev->res, 1);
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+ if (r)
+ dev_err(&adev->dev, "AMBA: Failed to %s device %s MMIO!\n",
+ action == BUS_NOTIFY_ADD_DEVICE ? "map" :
+ (action == BUS_NOTIFY_DEL_DEVICE ? "unmap" : "?"),
+ adev->dev.init_name);
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block amba_device_nb = {
+ .notifier_call = xen_amba_notifier,
+};
+
+static int __init register_xen_amba_notifier(void)
+{
+ if (!xen_initial_domain() || acpi_disabled)
+ return 0;
+
+ return bus_register_notifier(&amba_bustype, &amba_device_nb);
+}
+
+arch_initcall(register_xen_amba_notifier);
+#endif
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 07/17] Xen: ARM: Add support for mapping AMBA device mmio
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, julien.grall-5wv7dgnIgG8,
peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
zhaoshenglong-hv44wF8Li93QT0dZR+AlfA,
shannon.zhao-QSEj5FYQhm4dnm+yROfE0A
Add a bus_notifier for AMBA bus device in order to map the device
mmio regions when DOM0 booting with ACPI.
Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
---
drivers/xen/arm-device.c | 43 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
index 76e26e5..3854043 100644
--- a/drivers/xen/arm-device.c
+++ b/drivers/xen/arm-device.c
@@ -139,3 +139,46 @@ static int __init register_xen_platform_notifier(void)
}
arch_initcall(register_xen_platform_notifier);
+
+#ifdef CONFIG_ARM_AMBA
+#include <linux/amba/bus.h>
+
+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;
+
+ switch (action) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ r = xen_map_device_mmio(&adev->res, 1);
+ break;
+ case BUS_NOTIFY_DEL_DEVICE:
+ r = xen_unmap_device_mmio(&adev->res, 1);
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+ if (r)
+ dev_err(&adev->dev, "AMBA: Failed to %s device %s MMIO!\n",
+ action == BUS_NOTIFY_ADD_DEVICE ? "map" :
+ (action == BUS_NOTIFY_DEL_DEVICE ? "unmap" : "?"),
+ adev->dev.init_name);
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block amba_device_nb = {
+ .notifier_call = xen_amba_notifier,
+};
+
+static int __init register_xen_amba_notifier(void)
+{
+ if (!xen_initial_domain() || acpi_disabled)
+ return 0;
+
+ return bus_register_notifier(&amba_bustype, &amba_device_nb);
+}
+
+arch_initcall(register_xen_amba_notifier);
+#endif
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 172+ messages in thread
* [PATCH v7 07/17] Xen: ARM: Add support for mapping AMBA device mmio
2016-03-24 14:44 ` Shannon Zhao
` (12 preceding siblings ...)
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, shannon.zhao,
zhaoshenglong, xen-devel
Add a bus_notifier for AMBA bus device in order to map the device
mmio regions when DOM0 booting with ACPI.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
drivers/xen/arm-device.c | 43 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
index 76e26e5..3854043 100644
--- a/drivers/xen/arm-device.c
+++ b/drivers/xen/arm-device.c
@@ -139,3 +139,46 @@ static int __init register_xen_platform_notifier(void)
}
arch_initcall(register_xen_platform_notifier);
+
+#ifdef CONFIG_ARM_AMBA
+#include <linux/amba/bus.h>
+
+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;
+
+ switch (action) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ r = xen_map_device_mmio(&adev->res, 1);
+ break;
+ case BUS_NOTIFY_DEL_DEVICE:
+ r = xen_unmap_device_mmio(&adev->res, 1);
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+ if (r)
+ dev_err(&adev->dev, "AMBA: Failed to %s device %s MMIO!\n",
+ action == BUS_NOTIFY_ADD_DEVICE ? "map" :
+ (action == BUS_NOTIFY_DEL_DEVICE ? "unmap" : "?"),
+ adev->dev.init_name);
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block amba_device_nb = {
+ .notifier_call = xen_amba_notifier,
+};
+
+static int __init register_xen_amba_notifier(void)
+{
+ if (!xen_initial_domain() || acpi_disabled)
+ return 0;
+
+ return bus_register_notifier(&amba_bustype, &amba_device_nb);
+}
+
+arch_initcall(register_xen_amba_notifier);
+#endif
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 08/17] Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
2016-03-24 14:44 ` Shannon Zhao
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao
Sync the changes of HVM_PARAM_CALLBACK_VIA ABI introduced by
Xen commit <ca5c54b6ff05> (public/hvm: export the HVM_PARAM_CALLBACK_VIA
ABI in the API).
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
include/xen/interface/hvm/params.h | 27 +++++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/include/xen/interface/hvm/params.h b/include/xen/interface/hvm/params.h
index a6c7991..70ad208 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -27,16 +27,31 @@
* Parameter space for HVMOP_{set,get}_param.
*/
+#define HVM_PARAM_CALLBACK_IRQ 0
/*
* How should CPU0 event-channel notifications be delivered?
- * val[63:56] == 0: val[55:0] is a delivery GSI (Global System Interrupt).
- * val[63:56] == 1: val[55:0] is a delivery PCI INTx line, as follows:
- * 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.
+ *
* If val == 0 then CPU0 event-channel notifications are not delivered.
+ * If val != 0, val[63:56] encodes the type, as follows:
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_GSI 0
+/*
+ * val[55:0] is a delivery GSI. GSI 0 cannot be used, as it aliases val == 0,
+ * and disables all notifications.
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_PCI_INTX 1
+/*
+ * val[55:0] is a delivery PCI INTx line:
+ * Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = val[1:0]
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_VECTOR 2
+/*
+ * val[7:0] is a vector number. Check for XENFEAT_hvm_callback_vector to know
+ * if this delivery method is available.
*/
-#define HVM_PARAM_CALLBACK_IRQ 0
#define HVM_PARAM_STORE_PFN 1
#define HVM_PARAM_STORE_EVTCHN 2
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 08/17] Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
Sync the changes of HVM_PARAM_CALLBACK_VIA ABI introduced by
Xen commit <ca5c54b6ff05> (public/hvm: export the HVM_PARAM_CALLBACK_VIA
ABI in the API).
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
include/xen/interface/hvm/params.h | 27 +++++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/include/xen/interface/hvm/params.h b/include/xen/interface/hvm/params.h
index a6c7991..70ad208 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -27,16 +27,31 @@
* Parameter space for HVMOP_{set,get}_param.
*/
+#define HVM_PARAM_CALLBACK_IRQ 0
/*
* How should CPU0 event-channel notifications be delivered?
- * val[63:56] == 0: val[55:0] is a delivery GSI (Global System Interrupt).
- * val[63:56] == 1: val[55:0] is a delivery PCI INTx line, as follows:
- * 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.
+ *
* If val == 0 then CPU0 event-channel notifications are not delivered.
+ * If val != 0, val[63:56] encodes the type, as follows:
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_GSI 0
+/*
+ * val[55:0] is a delivery GSI. GSI 0 cannot be used, as it aliases val == 0,
+ * and disables all notifications.
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_PCI_INTX 1
+/*
+ * val[55:0] is a delivery PCI INTx line:
+ * Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = val[1:0]
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_VECTOR 2
+/*
+ * val[7:0] is a vector number. Check for XENFEAT_hvm_callback_vector to know
+ * if this delivery method is available.
*/
-#define HVM_PARAM_CALLBACK_IRQ 0
#define HVM_PARAM_STORE_PFN 1
#define HVM_PARAM_STORE_EVTCHN 2
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 08/17] Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, shannon.zhao,
zhaoshenglong, xen-devel
Sync the changes of HVM_PARAM_CALLBACK_VIA ABI introduced by
Xen commit <ca5c54b6ff05> (public/hvm: export the HVM_PARAM_CALLBACK_VIA
ABI in the API).
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
include/xen/interface/hvm/params.h | 27 +++++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/include/xen/interface/hvm/params.h b/include/xen/interface/hvm/params.h
index a6c7991..70ad208 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -27,16 +27,31 @@
* Parameter space for HVMOP_{set,get}_param.
*/
+#define HVM_PARAM_CALLBACK_IRQ 0
/*
* How should CPU0 event-channel notifications be delivered?
- * val[63:56] == 0: val[55:0] is a delivery GSI (Global System Interrupt).
- * val[63:56] == 1: val[55:0] is a delivery PCI INTx line, as follows:
- * 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.
+ *
* If val == 0 then CPU0 event-channel notifications are not delivered.
+ * If val != 0, val[63:56] encodes the type, as follows:
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_GSI 0
+/*
+ * val[55:0] is a delivery GSI. GSI 0 cannot be used, as it aliases val == 0,
+ * and disables all notifications.
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_PCI_INTX 1
+/*
+ * val[55:0] is a delivery PCI INTx line:
+ * Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = val[1:0]
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_VECTOR 2
+/*
+ * val[7:0] is a vector number. Check for XENFEAT_hvm_callback_vector to know
+ * if this delivery method is available.
*/
-#define HVM_PARAM_CALLBACK_IRQ 0
#define HVM_PARAM_STORE_PFN 1
#define HVM_PARAM_STORE_EVTCHN 2
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread
* [PATCH v7 09/17] xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
2016-03-24 14:44 ` Shannon Zhao
` (14 preceding siblings ...)
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, shannon.zhao,
zhaoshenglong, xen-devel
This new delivery type which is for ARM shares the same value with
HVM_PARAM_CALLBACK_TYPE_VECTOR which is for x86.
val[15:8] is flag: val[7:0] is a PPI.
To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and
bit 9 stands the interrupt polarity is active low(1) or high(0).
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
include/xen/interface/hvm/params.h | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/include/xen/interface/hvm/params.h b/include/xen/interface/hvm/params.h
index 70ad208..4d61fc5 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -47,11 +47,24 @@
* Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = val[1:0]
*/
+#if defined(__i386__) || defined(__x86_64__)
#define HVM_PARAM_CALLBACK_TYPE_VECTOR 2
/*
* val[7:0] is a vector number. Check for XENFEAT_hvm_callback_vector to know
* if this delivery method is available.
*/
+#elif defined(__arm__) || defined(__aarch64__)
+#define HVM_PARAM_CALLBACK_TYPE_PPI 2
+/*
+ * val[55:16] needs to be zero.
+ * val[15:8] is interrupt flag of the PPI used by event-channel:
+ * bit 8: the PPI is edge(1) or level(0) triggered
+ * bit 9: the PPI is active low(1) or high(0)
+ * val[7:0] is a PPI number used by event-channel.
+ * This is only used by ARM/ARM64 and masking/eoi the interrupt associated to
+ * the notification is handled by the interrupt controller.
+ */
+#endif
#define HVM_PARAM_STORE_PFN 1
#define HVM_PARAM_STORE_EVTCHN 2
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 09/17] xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
2016-03-24 14:44 ` Shannon Zhao
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao
This new delivery type which is for ARM shares the same value with
HVM_PARAM_CALLBACK_TYPE_VECTOR which is for x86.
val[15:8] is flag: val[7:0] is a PPI.
To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and
bit 9 stands the interrupt polarity is active low(1) or high(0).
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
include/xen/interface/hvm/params.h | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/include/xen/interface/hvm/params.h b/include/xen/interface/hvm/params.h
index 70ad208..4d61fc5 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -47,11 +47,24 @@
* Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = val[1:0]
*/
+#if defined(__i386__) || defined(__x86_64__)
#define HVM_PARAM_CALLBACK_TYPE_VECTOR 2
/*
* val[7:0] is a vector number. Check for XENFEAT_hvm_callback_vector to know
* if this delivery method is available.
*/
+#elif defined(__arm__) || defined(__aarch64__)
+#define HVM_PARAM_CALLBACK_TYPE_PPI 2
+/*
+ * val[55:16] needs to be zero.
+ * val[15:8] is interrupt flag of the PPI used by event-channel:
+ * bit 8: the PPI is edge(1) or level(0) triggered
+ * bit 9: the PPI is active low(1) or high(0)
+ * val[7:0] is a PPI number used by event-channel.
+ * This is only used by ARM/ARM64 and masking/eoi the interrupt associated to
+ * the notification is handled by the interrupt controller.
+ */
+#endif
#define HVM_PARAM_STORE_PFN 1
#define HVM_PARAM_STORE_EVTCHN 2
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread
* [PATCH v7 09/17] xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
This new delivery type which is for ARM shares the same value with
HVM_PARAM_CALLBACK_TYPE_VECTOR which is for x86.
val[15:8] is flag: val[7:0] is a PPI.
To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and
bit 9 stands the interrupt polarity is active low(1) or high(0).
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
include/xen/interface/hvm/params.h | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/include/xen/interface/hvm/params.h b/include/xen/interface/hvm/params.h
index 70ad208..4d61fc5 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -47,11 +47,24 @@
* Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = val[1:0]
*/
+#if defined(__i386__) || defined(__x86_64__)
#define HVM_PARAM_CALLBACK_TYPE_VECTOR 2
/*
* val[7:0] is a vector number. Check for XENFEAT_hvm_callback_vector to know
* if this delivery method is available.
*/
+#elif defined(__arm__) || defined(__aarch64__)
+#define HVM_PARAM_CALLBACK_TYPE_PPI 2
+/*
+ * val[55:16] needs to be zero.
+ * val[15:8] is interrupt flag of the PPI used by event-channel:
+ * bit 8: the PPI is edge(1) or level(0) triggered
+ * bit 9: the PPI is active low(1) or high(0)
+ * val[7:0] is a PPI number used by event-channel.
+ * This is only used by ARM/ARM64 and masking/eoi the interrupt associated to
+ * the notification is handled by the interrupt controller.
+ */
+#endif
#define HVM_PARAM_STORE_PFN 1
#define HVM_PARAM_STORE_EVTCHN 2
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread
* [PATCH v7 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
2016-03-24 14:44 ` Shannon Zhao
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao
When booting with ACPI, it could get the event-channel irq through
HVM_PARAM_CALLBACK_IRQ.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/arm/xen/enlighten.c | 36 +++++++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index d94f726..680aae0 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -30,6 +30,7 @@
#include <linux/time64.h>
#include <linux/timekeeping.h>
#include <linux/timekeeper_internal.h>
+#include <linux/acpi.h>
#include <linux/mm.h>
@@ -278,6 +279,35 @@ void __init xen_early_init(void)
add_preferred_console("hvc", 0, NULL);
}
+static void __init xen_acpi_guest_init(void)
+{
+#ifdef CONFIG_ACPI
+ struct xen_hvm_param a;
+ int interrupt, trigger, polarity;
+
+ a.domid = DOMID_SELF;
+ a.index = HVM_PARAM_CALLBACK_IRQ;
+ xen_events_irq = 0;
+
+ if (!HYPERVISOR_hvm_op(HVMOP_get_param, &a)) {
+ if ((a.value >> 56) == HVM_PARAM_CALLBACK_TYPE_PPI) {
+ interrupt = a.value & 0xff;
+ trigger = ((a.value >> 8) & 0x1) ? ACPI_EDGE_SENSITIVE
+ : ACPI_LEVEL_SENSITIVE;
+ polarity = ((a.value >> 8) & 0x2) ? ACPI_ACTIVE_LOW
+ : ACPI_ACTIVE_HIGH;
+ xen_events_irq = acpi_register_gsi(NULL, interrupt,
+ trigger, polarity);
+ }
+ }
+#endif
+}
+
+static void __init xen_dt_guest_init(void)
+{
+ xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+}
+
static int __init xen_guest_init(void)
{
struct xen_add_to_physmap xatp;
@@ -286,7 +316,11 @@ static int __init xen_guest_init(void)
if (!xen_domain())
return 0;
- xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+ if (!acpi_disabled)
+ xen_acpi_guest_init();
+ else
+ xen_dt_guest_init();
+
if (!xen_events_irq) {
pr_err("Xen event channel interrupt not found\n");
return -ENODEV;
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
When booting with ACPI, it could get the event-channel irq through
HVM_PARAM_CALLBACK_IRQ.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/arm/xen/enlighten.c | 36 +++++++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index d94f726..680aae0 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -30,6 +30,7 @@
#include <linux/time64.h>
#include <linux/timekeeping.h>
#include <linux/timekeeper_internal.h>
+#include <linux/acpi.h>
#include <linux/mm.h>
@@ -278,6 +279,35 @@ void __init xen_early_init(void)
add_preferred_console("hvc", 0, NULL);
}
+static void __init xen_acpi_guest_init(void)
+{
+#ifdef CONFIG_ACPI
+ struct xen_hvm_param a;
+ int interrupt, trigger, polarity;
+
+ a.domid = DOMID_SELF;
+ a.index = HVM_PARAM_CALLBACK_IRQ;
+ xen_events_irq = 0;
+
+ if (!HYPERVISOR_hvm_op(HVMOP_get_param, &a)) {
+ if ((a.value >> 56) == HVM_PARAM_CALLBACK_TYPE_PPI) {
+ interrupt = a.value & 0xff;
+ trigger = ((a.value >> 8) & 0x1) ? ACPI_EDGE_SENSITIVE
+ : ACPI_LEVEL_SENSITIVE;
+ polarity = ((a.value >> 8) & 0x2) ? ACPI_ACTIVE_LOW
+ : ACPI_ACTIVE_HIGH;
+ xen_events_irq = acpi_register_gsi(NULL, interrupt,
+ trigger, polarity);
+ }
+ }
+#endif
+}
+
+static void __init xen_dt_guest_init(void)
+{
+ xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+}
+
static int __init xen_guest_init(void)
{
struct xen_add_to_physmap xatp;
@@ -286,7 +316,11 @@ static int __init xen_guest_init(void)
if (!xen_domain())
return 0;
- xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+ if (!acpi_disabled)
+ xen_acpi_guest_init();
+ else
+ xen_dt_guest_init();
+
if (!xen_events_irq) {
pr_err("Xen event channel interrupt not found\n");
return -ENODEV;
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, shannon.zhao,
zhaoshenglong, xen-devel
When booting with ACPI, it could get the event-channel irq through
HVM_PARAM_CALLBACK_IRQ.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/arm/xen/enlighten.c | 36 +++++++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index d94f726..680aae0 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -30,6 +30,7 @@
#include <linux/time64.h>
#include <linux/timekeeping.h>
#include <linux/timekeeper_internal.h>
+#include <linux/acpi.h>
#include <linux/mm.h>
@@ -278,6 +279,35 @@ void __init xen_early_init(void)
add_preferred_console("hvc", 0, NULL);
}
+static void __init xen_acpi_guest_init(void)
+{
+#ifdef CONFIG_ACPI
+ struct xen_hvm_param a;
+ int interrupt, trigger, polarity;
+
+ a.domid = DOMID_SELF;
+ a.index = HVM_PARAM_CALLBACK_IRQ;
+ xen_events_irq = 0;
+
+ if (!HYPERVISOR_hvm_op(HVMOP_get_param, &a)) {
+ if ((a.value >> 56) == HVM_PARAM_CALLBACK_TYPE_PPI) {
+ interrupt = a.value & 0xff;
+ trigger = ((a.value >> 8) & 0x1) ? ACPI_EDGE_SENSITIVE
+ : ACPI_LEVEL_SENSITIVE;
+ polarity = ((a.value >> 8) & 0x2) ? ACPI_ACTIVE_LOW
+ : ACPI_ACTIVE_HIGH;
+ xen_events_irq = acpi_register_gsi(NULL, interrupt,
+ trigger, polarity);
+ }
+ }
+#endif
+}
+
+static void __init xen_dt_guest_init(void)
+{
+ xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+}
+
static int __init xen_guest_init(void)
{
struct xen_add_to_physmap xatp;
@@ -286,7 +316,11 @@ static int __init xen_guest_init(void)
if (!xen_domain())
return 0;
- xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+ if (!acpi_disabled)
+ xen_acpi_guest_init();
+ else
+ xen_dt_guest_init();
+
if (!xen_events_irq) {
pr_err("Xen event channel interrupt not found\n");
return -ENODEV;
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread* Re: [PATCH v7 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
@ 2016-03-29 16:35 ` Julien Grall
0 siblings, 0 replies; 172+ messages in thread
From: Julien Grall @ 2016-03-29 16:35 UTC (permalink / raw)
To: Shannon Zhao, linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, peter.huangpeng, xen-devel, zhaoshenglong
Hi Shannon,
On 24/03/16 14:44, Shannon Zhao wrote:
> When booting with ACPI, it could get the event-channel irq through
The kernel will always get the event-channel IRQ through
HVM_PARAM_CALLBACK_IRQ.
So I would say: ", the kernel will get the event-channel..."
> HVM_PARAM_CALLBACK_IRQ.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
> arch/arm/xen/enlighten.c | 36 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index d94f726..680aae0 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -30,6 +30,7 @@
> #include <linux/time64.h>
> #include <linux/timekeeping.h>
> #include <linux/timekeeper_internal.h>
> +#include <linux/acpi.h>
>
> #include <linux/mm.h>
>
> @@ -278,6 +279,35 @@ void __init xen_early_init(void)
> add_preferred_console("hvc", 0, NULL);
> }
>
> +static void __init xen_acpi_guest_init(void)
> +{
> +#ifdef CONFIG_ACPI
> + struct xen_hvm_param a;
> + int interrupt, trigger, polarity;
> +
> + a.domid = DOMID_SELF;
> + a.index = HVM_PARAM_CALLBACK_IRQ;
> + xen_events_irq = 0;
> +
> + if (!HYPERVISOR_hvm_op(HVMOP_get_param, &a)) {
> + if ((a.value >> 56) == HVM_PARAM_CALLBACK_TYPE_PPI) {
> + interrupt = a.value & 0xff;
> + trigger = ((a.value >> 8) & 0x1) ? ACPI_EDGE_SENSITIVE
> + : ACPI_LEVEL_SENSITIVE;
> + polarity = ((a.value >> 8) & 0x2) ? ACPI_ACTIVE_LOW
> + : ACPI_ACTIVE_HIGH;
> + xen_events_irq = acpi_register_gsi(NULL, interrupt,
> + trigger, polarity);
> + }
> + }
Can you invert the condition to remove one layer of indentation?
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
@ 2016-03-29 16:35 ` Julien Grall
0 siblings, 0 replies; 172+ messages in thread
From: Julien Grall @ 2016-03-29 16:35 UTC (permalink / raw)
To: linux-arm-kernel
Hi Shannon,
On 24/03/16 14:44, Shannon Zhao wrote:
> When booting with ACPI, it could get the event-channel irq through
The kernel will always get the event-channel IRQ through
HVM_PARAM_CALLBACK_IRQ.
So I would say: ", the kernel will get the event-channel..."
> HVM_PARAM_CALLBACK_IRQ.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
> arch/arm/xen/enlighten.c | 36 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index d94f726..680aae0 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -30,6 +30,7 @@
> #include <linux/time64.h>
> #include <linux/timekeeping.h>
> #include <linux/timekeeper_internal.h>
> +#include <linux/acpi.h>
>
> #include <linux/mm.h>
>
> @@ -278,6 +279,35 @@ void __init xen_early_init(void)
> add_preferred_console("hvc", 0, NULL);
> }
>
> +static void __init xen_acpi_guest_init(void)
> +{
> +#ifdef CONFIG_ACPI
> + struct xen_hvm_param a;
> + int interrupt, trigger, polarity;
> +
> + a.domid = DOMID_SELF;
> + a.index = HVM_PARAM_CALLBACK_IRQ;
> + xen_events_irq = 0;
> +
> + if (!HYPERVISOR_hvm_op(HVMOP_get_param, &a)) {
> + if ((a.value >> 56) == HVM_PARAM_CALLBACK_TYPE_PPI) {
> + interrupt = a.value & 0xff;
> + trigger = ((a.value >> 8) & 0x1) ? ACPI_EDGE_SENSITIVE
> + : ACPI_LEVEL_SENSITIVE;
> + polarity = ((a.value >> 8) & 0x2) ? ACPI_ACTIVE_LOW
> + : ACPI_ACTIVE_HIGH;
> + xen_events_irq = acpi_register_gsi(NULL, interrupt,
> + trigger, polarity);
> + }
> + }
Can you invert the condition to remove one layer of indentation?
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
@ 2016-03-29 16:35 ` Julien Grall
0 siblings, 0 replies; 172+ messages in thread
From: Julien Grall @ 2016-03-29 16:35 UTC (permalink / raw)
To: Shannon Zhao, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
zhaoshenglong-hv44wF8Li93QT0dZR+AlfA
Hi Shannon,
On 24/03/16 14:44, Shannon Zhao wrote:
> When booting with ACPI, it could get the event-channel irq through
The kernel will always get the event-channel IRQ through
HVM_PARAM_CALLBACK_IRQ.
So I would say: ", the kernel will get the event-channel..."
> HVM_PARAM_CALLBACK_IRQ.
>
> Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
> ---
> arch/arm/xen/enlighten.c | 36 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index d94f726..680aae0 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -30,6 +30,7 @@
> #include <linux/time64.h>
> #include <linux/timekeeping.h>
> #include <linux/timekeeper_internal.h>
> +#include <linux/acpi.h>
>
> #include <linux/mm.h>
>
> @@ -278,6 +279,35 @@ void __init xen_early_init(void)
> add_preferred_console("hvc", 0, NULL);
> }
>
> +static void __init xen_acpi_guest_init(void)
> +{
> +#ifdef CONFIG_ACPI
> + struct xen_hvm_param a;
> + int interrupt, trigger, polarity;
> +
> + a.domid = DOMID_SELF;
> + a.index = HVM_PARAM_CALLBACK_IRQ;
> + xen_events_irq = 0;
> +
> + if (!HYPERVISOR_hvm_op(HVMOP_get_param, &a)) {
> + if ((a.value >> 56) == HVM_PARAM_CALLBACK_TYPE_PPI) {
> + interrupt = a.value & 0xff;
> + trigger = ((a.value >> 8) & 0x1) ? ACPI_EDGE_SENSITIVE
> + : ACPI_LEVEL_SENSITIVE;
> + polarity = ((a.value >> 8) & 0x2) ? ACPI_ACTIVE_LOW
> + : ACPI_ACTIVE_HIGH;
> + xen_events_irq = acpi_register_gsi(NULL, interrupt,
> + trigger, polarity);
> + }
> + }
Can you invert the condition to remove one layer of indentation?
Regards,
--
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
2016-03-29 16:35 ` Julien Grall
(?)
(?)
@ 2016-03-30 7:34 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-30 7:34 UTC (permalink / raw)
To: Julien Grall, Shannon Zhao, linux-arm-kernel, stefano.stabellini,
david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
peter.huangpeng, linux-kernel, xen-devel
On 2016/3/30 0:35, Julien Grall wrote:
> Hi Shannon,
>
> On 24/03/16 14:44, Shannon Zhao wrote:
>> When booting with ACPI, it could get the event-channel irq through
>
> The kernel will always get the event-channel IRQ through
> HVM_PARAM_CALLBACK_IRQ.
>
> So I would say: ", the kernel will get the event-channel..."
>
>> HVM_PARAM_CALLBACK_IRQ.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> ---
>> arch/arm/xen/enlighten.c | 36 +++++++++++++++++++++++++++++++++++-
>> 1 file changed, 35 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> index d94f726..680aae0 100644
>> --- a/arch/arm/xen/enlighten.c
>> +++ b/arch/arm/xen/enlighten.c
>> @@ -30,6 +30,7 @@
>> #include <linux/time64.h>
>> #include <linux/timekeeping.h>
>> #include <linux/timekeeper_internal.h>
>> +#include <linux/acpi.h>
>>
>> #include <linux/mm.h>
>>
>> @@ -278,6 +279,35 @@ void __init xen_early_init(void)
>> add_preferred_console("hvc", 0, NULL);
>> }
>>
>> +static void __init xen_acpi_guest_init(void)
>> +{
>> +#ifdef CONFIG_ACPI
>> + struct xen_hvm_param a;
>> + int interrupt, trigger, polarity;
>> +
>> + a.domid = DOMID_SELF;
>> + a.index = HVM_PARAM_CALLBACK_IRQ;
>> + xen_events_irq = 0;
>> +
>> + if (!HYPERVISOR_hvm_op(HVMOP_get_param, &a)) {
>> + if ((a.value >> 56) == HVM_PARAM_CALLBACK_TYPE_PPI) {
>> + interrupt = a.value & 0xff;
>> + trigger = ((a.value >> 8) & 0x1) ? ACPI_EDGE_SENSITIVE
>> + : ACPI_LEVEL_SENSITIVE;
>> + polarity = ((a.value >> 8) & 0x2) ? ACPI_ACTIVE_LOW
>> + : ACPI_ACTIVE_HIGH;
>> + xen_events_irq = acpi_register_gsi(NULL, interrupt,
>> + trigger, polarity);
>> + }
>> + }
>
> Can you invert the condition to remove one layer of indentation?
Sure, will update.
Thanks,
--
Shannon
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
@ 2016-03-30 7:34 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-30 7:34 UTC (permalink / raw)
To: Julien Grall, Shannon Zhao, linux-arm-kernel, stefano.stabellini,
david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, peter.huangpeng, xen-devel
On 2016/3/30 0:35, Julien Grall wrote:
> Hi Shannon,
>
> On 24/03/16 14:44, Shannon Zhao wrote:
>> When booting with ACPI, it could get the event-channel irq through
>
> The kernel will always get the event-channel IRQ through
> HVM_PARAM_CALLBACK_IRQ.
>
> So I would say: ", the kernel will get the event-channel..."
>
>> HVM_PARAM_CALLBACK_IRQ.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> ---
>> arch/arm/xen/enlighten.c | 36 +++++++++++++++++++++++++++++++++++-
>> 1 file changed, 35 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> index d94f726..680aae0 100644
>> --- a/arch/arm/xen/enlighten.c
>> +++ b/arch/arm/xen/enlighten.c
>> @@ -30,6 +30,7 @@
>> #include <linux/time64.h>
>> #include <linux/timekeeping.h>
>> #include <linux/timekeeper_internal.h>
>> +#include <linux/acpi.h>
>>
>> #include <linux/mm.h>
>>
>> @@ -278,6 +279,35 @@ void __init xen_early_init(void)
>> add_preferred_console("hvc", 0, NULL);
>> }
>>
>> +static void __init xen_acpi_guest_init(void)
>> +{
>> +#ifdef CONFIG_ACPI
>> + struct xen_hvm_param a;
>> + int interrupt, trigger, polarity;
>> +
>> + a.domid = DOMID_SELF;
>> + a.index = HVM_PARAM_CALLBACK_IRQ;
>> + xen_events_irq = 0;
>> +
>> + if (!HYPERVISOR_hvm_op(HVMOP_get_param, &a)) {
>> + if ((a.value >> 56) == HVM_PARAM_CALLBACK_TYPE_PPI) {
>> + interrupt = a.value & 0xff;
>> + trigger = ((a.value >> 8) & 0x1) ? ACPI_EDGE_SENSITIVE
>> + : ACPI_LEVEL_SENSITIVE;
>> + polarity = ((a.value >> 8) & 0x2) ? ACPI_ACTIVE_LOW
>> + : ACPI_ACTIVE_HIGH;
>> + xen_events_irq = acpi_register_gsi(NULL, interrupt,
>> + trigger, polarity);
>> + }
>> + }
>
> Can you invert the condition to remove one layer of indentation?
Sure, will update.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
@ 2016-03-30 7:34 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-30 7:34 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/3/30 0:35, Julien Grall wrote:
> Hi Shannon,
>
> On 24/03/16 14:44, Shannon Zhao wrote:
>> When booting with ACPI, it could get the event-channel irq through
>
> The kernel will always get the event-channel IRQ through
> HVM_PARAM_CALLBACK_IRQ.
>
> So I would say: ", the kernel will get the event-channel..."
>
>> HVM_PARAM_CALLBACK_IRQ.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> ---
>> arch/arm/xen/enlighten.c | 36 +++++++++++++++++++++++++++++++++++-
>> 1 file changed, 35 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> index d94f726..680aae0 100644
>> --- a/arch/arm/xen/enlighten.c
>> +++ b/arch/arm/xen/enlighten.c
>> @@ -30,6 +30,7 @@
>> #include <linux/time64.h>
>> #include <linux/timekeeping.h>
>> #include <linux/timekeeper_internal.h>
>> +#include <linux/acpi.h>
>>
>> #include <linux/mm.h>
>>
>> @@ -278,6 +279,35 @@ void __init xen_early_init(void)
>> add_preferred_console("hvc", 0, NULL);
>> }
>>
>> +static void __init xen_acpi_guest_init(void)
>> +{
>> +#ifdef CONFIG_ACPI
>> + struct xen_hvm_param a;
>> + int interrupt, trigger, polarity;
>> +
>> + a.domid = DOMID_SELF;
>> + a.index = HVM_PARAM_CALLBACK_IRQ;
>> + xen_events_irq = 0;
>> +
>> + if (!HYPERVISOR_hvm_op(HVMOP_get_param, &a)) {
>> + if ((a.value >> 56) == HVM_PARAM_CALLBACK_TYPE_PPI) {
>> + interrupt = a.value & 0xff;
>> + trigger = ((a.value >> 8) & 0x1) ? ACPI_EDGE_SENSITIVE
>> + : ACPI_LEVEL_SENSITIVE;
>> + polarity = ((a.value >> 8) & 0x2) ? ACPI_ACTIVE_LOW
>> + : ACPI_ACTIVE_HIGH;
>> + xen_events_irq = acpi_register_gsi(NULL, interrupt,
>> + trigger, polarity);
>> + }
>> + }
>
> Can you invert the condition to remove one layer of indentation?
Sure, will update.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
@ 2016-03-30 7:34 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-30 7:34 UTC (permalink / raw)
To: Julien Grall, Shannon Zhao,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw
On 2016/3/30 0:35, Julien Grall wrote:
> Hi Shannon,
>
> On 24/03/16 14:44, Shannon Zhao wrote:
>> When booting with ACPI, it could get the event-channel irq through
>
> The kernel will always get the event-channel IRQ through
> HVM_PARAM_CALLBACK_IRQ.
>
> So I would say: ", the kernel will get the event-channel..."
>
>> HVM_PARAM_CALLBACK_IRQ.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Reviewed-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
>> ---
>> arch/arm/xen/enlighten.c | 36 +++++++++++++++++++++++++++++++++++-
>> 1 file changed, 35 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> index d94f726..680aae0 100644
>> --- a/arch/arm/xen/enlighten.c
>> +++ b/arch/arm/xen/enlighten.c
>> @@ -30,6 +30,7 @@
>> #include <linux/time64.h>
>> #include <linux/timekeeping.h>
>> #include <linux/timekeeper_internal.h>
>> +#include <linux/acpi.h>
>>
>> #include <linux/mm.h>
>>
>> @@ -278,6 +279,35 @@ void __init xen_early_init(void)
>> add_preferred_console("hvc", 0, NULL);
>> }
>>
>> +static void __init xen_acpi_guest_init(void)
>> +{
>> +#ifdef CONFIG_ACPI
>> + struct xen_hvm_param a;
>> + int interrupt, trigger, polarity;
>> +
>> + a.domid = DOMID_SELF;
>> + a.index = HVM_PARAM_CALLBACK_IRQ;
>> + xen_events_irq = 0;
>> +
>> + if (!HYPERVISOR_hvm_op(HVMOP_get_param, &a)) {
>> + if ((a.value >> 56) == HVM_PARAM_CALLBACK_TYPE_PPI) {
>> + interrupt = a.value & 0xff;
>> + trigger = ((a.value >> 8) & 0x1) ? ACPI_EDGE_SENSITIVE
>> + : ACPI_LEVEL_SENSITIVE;
>> + polarity = ((a.value >> 8) & 0x2) ? ACPI_ACTIVE_LOW
>> + : ACPI_ACTIVE_HIGH;
>> + xen_events_irq = acpi_register_gsi(NULL, interrupt,
>> + trigger, polarity);
>> + }
>> + }
>
> Can you invert the condition to remove one layer of indentation?
Sure, will update.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v7 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
2016-03-24 14:44 ` Shannon Zhao
` (2 preceding siblings ...)
(?)
@ 2016-03-29 16:35 ` Julien Grall
-1 siblings, 0 replies; 172+ messages in thread
From: Julien Grall @ 2016-03-29 16:35 UTC (permalink / raw)
To: Shannon Zhao, linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
peter.huangpeng, linux-kernel, zhaoshenglong, xen-devel
Hi Shannon,
On 24/03/16 14:44, Shannon Zhao wrote:
> When booting with ACPI, it could get the event-channel irq through
The kernel will always get the event-channel IRQ through
HVM_PARAM_CALLBACK_IRQ.
So I would say: ", the kernel will get the event-channel..."
> HVM_PARAM_CALLBACK_IRQ.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
> arch/arm/xen/enlighten.c | 36 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index d94f726..680aae0 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -30,6 +30,7 @@
> #include <linux/time64.h>
> #include <linux/timekeeping.h>
> #include <linux/timekeeper_internal.h>
> +#include <linux/acpi.h>
>
> #include <linux/mm.h>
>
> @@ -278,6 +279,35 @@ void __init xen_early_init(void)
> add_preferred_console("hvc", 0, NULL);
> }
>
> +static void __init xen_acpi_guest_init(void)
> +{
> +#ifdef CONFIG_ACPI
> + struct xen_hvm_param a;
> + int interrupt, trigger, polarity;
> +
> + a.domid = DOMID_SELF;
> + a.index = HVM_PARAM_CALLBACK_IRQ;
> + xen_events_irq = 0;
> +
> + if (!HYPERVISOR_hvm_op(HVMOP_get_param, &a)) {
> + if ((a.value >> 56) == HVM_PARAM_CALLBACK_TYPE_PPI) {
> + interrupt = a.value & 0xff;
> + trigger = ((a.value >> 8) & 0x1) ? ACPI_EDGE_SENSITIVE
> + : ACPI_LEVEL_SENSITIVE;
> + polarity = ((a.value >> 8) & 0x2) ? ACPI_ACTIVE_LOW
> + : ACPI_ACTIVE_HIGH;
> + xen_events_irq = acpi_register_gsi(NULL, interrupt,
> + trigger, polarity);
> + }
> + }
Can you invert the condition to remove one layer of indentation?
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread
* [PATCH v7 11/17] ARM: XEN: Move xen_early_init() before efi_init()
2016-03-24 14:44 ` Shannon Zhao
` (17 preceding siblings ...)
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, shannon.zhao,
zhaoshenglong, xen-devel
Move xen_early_init() before efi_init(), then when calling efi_init()
could initialize Xen specific UEFI.
Check if it runs on Xen hypervisor through the flat dts.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/arm/xen/enlighten.c | 56 ++++++++++++++++++++++++++++++++++-------------
arch/arm64/kernel/setup.c | 2 +-
2 files changed, 42 insertions(+), 16 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 680aae0..c43617f 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -20,6 +20,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>
@@ -53,8 +54,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,
@@ -238,6 +237,33 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
return IRQ_HANDLED;
}
+static __initdata struct {
+ const char *compat;
+ const char *prefix;
+ const char *version;
+ bool found;
+} hyper_node = {"xen,xen", "xen,xen-", NULL, false};
+
+static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ const void *s = NULL;
+ int len;
+
+ if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+ return 0;
+
+ if (of_flat_dt_is_compatible(node, hyper_node.compat))
+ hyper_node.found = true;
+
+ s = of_get_flat_dt_prop(node, "compatible", &len);
+ if (strlen(hyper_node.prefix) + 3 < len &&
+ !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
+ hyper_node.version = s + strlen(hyper_node.prefix);
+
+ return 0;
+}
+
/*
* see Documentation/devicetree/bindings/arm/xen.txt for the
* documentation of the Xen Device Tree format.
@@ -245,26 +271,18 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
#define GRANT_TABLE_PHYSADDR 0
void __init xen_early_init(void)
{
- int len;
- const char *s = NULL;
- const char *version = NULL;
- const char *xen_prefix = "xen,xen-";
-
- xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
- if (!xen_node) {
+ of_scan_flat_dt(fdt_find_hyper_node, NULL);
+ if (!hyper_node.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 (hyper_node.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", hyper_node.version);
xen_domain_type = XEN_HVM_DOMAIN;
@@ -305,6 +323,14 @@ static void __init xen_acpi_guest_init(void)
static void __init xen_dt_guest_init(void)
{
+ struct device_node *xen_node;
+
+ xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
+ if (!xen_node) {
+ pr_err("Xen support was detected before, but it has disappeared\n");
+ return;
+ }
+
xen_events_irq = irq_of_parse_and_map(xen_node, 0);
}
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 450987d..6cf5051 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
*/
local_async_enable();
+ xen_early_init();
efi_init();
arm64_memblock_init();
@@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
} else {
psci_acpi_init();
}
- xen_early_init();
cpu_read_bootcpu_ops();
smp_init_cpus();
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 11/17] ARM: XEN: Move xen_early_init() before efi_init()
2016-03-24 14:44 ` Shannon Zhao
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao
Move xen_early_init() before efi_init(), then when calling efi_init()
could initialize Xen specific UEFI.
Check if it runs on Xen hypervisor through the flat dts.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/arm/xen/enlighten.c | 56 ++++++++++++++++++++++++++++++++++-------------
arch/arm64/kernel/setup.c | 2 +-
2 files changed, 42 insertions(+), 16 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 680aae0..c43617f 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -20,6 +20,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>
@@ -53,8 +54,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,
@@ -238,6 +237,33 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
return IRQ_HANDLED;
}
+static __initdata struct {
+ const char *compat;
+ const char *prefix;
+ const char *version;
+ bool found;
+} hyper_node = {"xen,xen", "xen,xen-", NULL, false};
+
+static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ const void *s = NULL;
+ int len;
+
+ if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+ return 0;
+
+ if (of_flat_dt_is_compatible(node, hyper_node.compat))
+ hyper_node.found = true;
+
+ s = of_get_flat_dt_prop(node, "compatible", &len);
+ if (strlen(hyper_node.prefix) + 3 < len &&
+ !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
+ hyper_node.version = s + strlen(hyper_node.prefix);
+
+ return 0;
+}
+
/*
* see Documentation/devicetree/bindings/arm/xen.txt for the
* documentation of the Xen Device Tree format.
@@ -245,26 +271,18 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
#define GRANT_TABLE_PHYSADDR 0
void __init xen_early_init(void)
{
- int len;
- const char *s = NULL;
- const char *version = NULL;
- const char *xen_prefix = "xen,xen-";
-
- xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
- if (!xen_node) {
+ of_scan_flat_dt(fdt_find_hyper_node, NULL);
+ if (!hyper_node.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 (hyper_node.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", hyper_node.version);
xen_domain_type = XEN_HVM_DOMAIN;
@@ -305,6 +323,14 @@ static void __init xen_acpi_guest_init(void)
static void __init xen_dt_guest_init(void)
{
+ struct device_node *xen_node;
+
+ xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
+ if (!xen_node) {
+ pr_err("Xen support was detected before, but it has disappeared\n");
+ return;
+ }
+
xen_events_irq = irq_of_parse_and_map(xen_node, 0);
}
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 450987d..6cf5051 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
*/
local_async_enable();
+ xen_early_init();
efi_init();
arm64_memblock_init();
@@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
} else {
psci_acpi_init();
}
- xen_early_init();
cpu_read_bootcpu_ops();
smp_init_cpus();
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 11/17] ARM: XEN: Move xen_early_init() before efi_init()
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
Move xen_early_init() before efi_init(), then when calling efi_init()
could initialize Xen specific UEFI.
Check if it runs on Xen hypervisor through the flat dts.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/arm/xen/enlighten.c | 56 ++++++++++++++++++++++++++++++++++-------------
arch/arm64/kernel/setup.c | 2 +-
2 files changed, 42 insertions(+), 16 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 680aae0..c43617f 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -20,6 +20,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>
@@ -53,8 +54,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,
@@ -238,6 +237,33 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
return IRQ_HANDLED;
}
+static __initdata struct {
+ const char *compat;
+ const char *prefix;
+ const char *version;
+ bool found;
+} hyper_node = {"xen,xen", "xen,xen-", NULL, false};
+
+static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ const void *s = NULL;
+ int len;
+
+ if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+ return 0;
+
+ if (of_flat_dt_is_compatible(node, hyper_node.compat))
+ hyper_node.found = true;
+
+ s = of_get_flat_dt_prop(node, "compatible", &len);
+ if (strlen(hyper_node.prefix) + 3 < len &&
+ !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
+ hyper_node.version = s + strlen(hyper_node.prefix);
+
+ return 0;
+}
+
/*
* see Documentation/devicetree/bindings/arm/xen.txt for the
* documentation of the Xen Device Tree format.
@@ -245,26 +271,18 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
#define GRANT_TABLE_PHYSADDR 0
void __init xen_early_init(void)
{
- int len;
- const char *s = NULL;
- const char *version = NULL;
- const char *xen_prefix = "xen,xen-";
-
- xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
- if (!xen_node) {
+ of_scan_flat_dt(fdt_find_hyper_node, NULL);
+ if (!hyper_node.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 (hyper_node.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", hyper_node.version);
xen_domain_type = XEN_HVM_DOMAIN;
@@ -305,6 +323,14 @@ static void __init xen_acpi_guest_init(void)
static void __init xen_dt_guest_init(void)
{
+ struct device_node *xen_node;
+
+ xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
+ if (!xen_node) {
+ pr_err("Xen support was detected before, but it has disappeared\n");
+ return;
+ }
+
xen_events_irq = irq_of_parse_and_map(xen_node, 0);
}
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 450987d..6cf5051 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
*/
local_async_enable();
+ xen_early_init();
efi_init();
arm64_memblock_init();
@@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
} else {
psci_acpi_init();
}
- xen_early_init();
cpu_read_bootcpu_ops();
smp_init_cpus();
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* Re: [PATCH v7 11/17] ARM: XEN: Move xen_early_init() before efi_init()
2016-03-24 14:44 ` Shannon Zhao
(?)
@ 2016-03-26 12:54 ` Stefano Stabellini
-1 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-26 12:54 UTC (permalink / raw)
To: catalin.marinas, will.deacon
Cc: devicetree, linux-efi, linux-kernel, peter.huangpeng,
julien.grall, stefano.stabellini, david.vrabel, zhaoshenglong,
xen-devel, linux-arm-kernel, shannon.zhao
Will, Catalin,
are you OK with this patch?
Thanks,
Stefano
On Thu, 24 Mar 2016, Shannon Zhao wrote:
> Move xen_early_init() before efi_init(), then when calling efi_init()
> could initialize Xen specific UEFI.
>
> Check if it runs on Xen hypervisor through the flat dts.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
> arch/arm/xen/enlighten.c | 56 ++++++++++++++++++++++++++++++++++-------------
> arch/arm64/kernel/setup.c | 2 +-
> 2 files changed, 42 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 680aae0..c43617f 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -20,6 +20,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>
> @@ -53,8 +54,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,
> @@ -238,6 +237,33 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
> return IRQ_HANDLED;
> }
>
> +static __initdata struct {
> + const char *compat;
> + const char *prefix;
> + const char *version;
> + bool found;
> +} hyper_node = {"xen,xen", "xen,xen-", NULL, false};
> +
> +static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
> + int depth, void *data)
> +{
> + const void *s = NULL;
> + int len;
> +
> + if (depth != 1 || strcmp(uname, "hypervisor") != 0)
> + return 0;
> +
> + if (of_flat_dt_is_compatible(node, hyper_node.compat))
> + hyper_node.found = true;
> +
> + s = of_get_flat_dt_prop(node, "compatible", &len);
> + if (strlen(hyper_node.prefix) + 3 < len &&
> + !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
> + hyper_node.version = s + strlen(hyper_node.prefix);
> +
> + return 0;
> +}
> +
> /*
> * see Documentation/devicetree/bindings/arm/xen.txt for the
> * documentation of the Xen Device Tree format.
> @@ -245,26 +271,18 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
> #define GRANT_TABLE_PHYSADDR 0
> void __init xen_early_init(void)
> {
> - int len;
> - const char *s = NULL;
> - const char *version = NULL;
> - const char *xen_prefix = "xen,xen-";
> -
> - xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
> - if (!xen_node) {
> + of_scan_flat_dt(fdt_find_hyper_node, NULL);
> + if (!hyper_node.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 (hyper_node.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", hyper_node.version);
>
> xen_domain_type = XEN_HVM_DOMAIN;
>
> @@ -305,6 +323,14 @@ static void __init xen_acpi_guest_init(void)
>
> static void __init xen_dt_guest_init(void)
> {
> + struct device_node *xen_node;
> +
> + xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
> + if (!xen_node) {
> + pr_err("Xen support was detected before, but it has disappeared\n");
> + return;
> + }
> +
> xen_events_irq = irq_of_parse_and_map(xen_node, 0);
> }
>
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 450987d..6cf5051 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
> */
> local_async_enable();
>
> + xen_early_init();
> efi_init();
> arm64_memblock_init();
>
> @@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
> } else {
> psci_acpi_init();
> }
> - xen_early_init();
>
> cpu_read_bootcpu_ops();
> smp_init_cpus();
> --
> 2.1.4
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 11/17] ARM: XEN: Move xen_early_init() before efi_init()
@ 2016-03-26 12:54 ` Stefano Stabellini
0 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-26 12:54 UTC (permalink / raw)
To: catalin.marinas, will.deacon
Cc: linux-arm-kernel, stefano.stabellini, david.vrabel, devicetree,
linux-efi, linux-kernel, julien.grall, peter.huangpeng,
xen-devel, zhaoshenglong, shannon.zhao
Will, Catalin,
are you OK with this patch?
Thanks,
Stefano
On Thu, 24 Mar 2016, Shannon Zhao wrote:
> Move xen_early_init() before efi_init(), then when calling efi_init()
> could initialize Xen specific UEFI.
>
> Check if it runs on Xen hypervisor through the flat dts.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
> arch/arm/xen/enlighten.c | 56 ++++++++++++++++++++++++++++++++++-------------
> arch/arm64/kernel/setup.c | 2 +-
> 2 files changed, 42 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 680aae0..c43617f 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -20,6 +20,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>
> @@ -53,8 +54,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,
> @@ -238,6 +237,33 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
> return IRQ_HANDLED;
> }
>
> +static __initdata struct {
> + const char *compat;
> + const char *prefix;
> + const char *version;
> + bool found;
> +} hyper_node = {"xen,xen", "xen,xen-", NULL, false};
> +
> +static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
> + int depth, void *data)
> +{
> + const void *s = NULL;
> + int len;
> +
> + if (depth != 1 || strcmp(uname, "hypervisor") != 0)
> + return 0;
> +
> + if (of_flat_dt_is_compatible(node, hyper_node.compat))
> + hyper_node.found = true;
> +
> + s = of_get_flat_dt_prop(node, "compatible", &len);
> + if (strlen(hyper_node.prefix) + 3 < len &&
> + !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
> + hyper_node.version = s + strlen(hyper_node.prefix);
> +
> + return 0;
> +}
> +
> /*
> * see Documentation/devicetree/bindings/arm/xen.txt for the
> * documentation of the Xen Device Tree format.
> @@ -245,26 +271,18 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
> #define GRANT_TABLE_PHYSADDR 0
> void __init xen_early_init(void)
> {
> - int len;
> - const char *s = NULL;
> - const char *version = NULL;
> - const char *xen_prefix = "xen,xen-";
> -
> - xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
> - if (!xen_node) {
> + of_scan_flat_dt(fdt_find_hyper_node, NULL);
> + if (!hyper_node.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 (hyper_node.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", hyper_node.version);
>
> xen_domain_type = XEN_HVM_DOMAIN;
>
> @@ -305,6 +323,14 @@ static void __init xen_acpi_guest_init(void)
>
> static void __init xen_dt_guest_init(void)
> {
> + struct device_node *xen_node;
> +
> + xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
> + if (!xen_node) {
> + pr_err("Xen support was detected before, but it has disappeared\n");
> + return;
> + }
> +
> xen_events_irq = irq_of_parse_and_map(xen_node, 0);
> }
>
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 450987d..6cf5051 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
> */
> local_async_enable();
>
> + xen_early_init();
> efi_init();
> arm64_memblock_init();
>
> @@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
> } else {
> psci_acpi_init();
> }
> - xen_early_init();
>
> cpu_read_bootcpu_ops();
> smp_init_cpus();
> --
> 2.1.4
>
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 11/17] ARM: XEN: Move xen_early_init() before efi_init()
@ 2016-03-26 12:54 ` Stefano Stabellini
0 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-26 12:54 UTC (permalink / raw)
To: linux-arm-kernel
Will, Catalin,
are you OK with this patch?
Thanks,
Stefano
On Thu, 24 Mar 2016, Shannon Zhao wrote:
> Move xen_early_init() before efi_init(), then when calling efi_init()
> could initialize Xen specific UEFI.
>
> Check if it runs on Xen hypervisor through the flat dts.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
> arch/arm/xen/enlighten.c | 56 ++++++++++++++++++++++++++++++++++-------------
> arch/arm64/kernel/setup.c | 2 +-
> 2 files changed, 42 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 680aae0..c43617f 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -20,6 +20,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>
> @@ -53,8 +54,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,
> @@ -238,6 +237,33 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
> return IRQ_HANDLED;
> }
>
> +static __initdata struct {
> + const char *compat;
> + const char *prefix;
> + const char *version;
> + bool found;
> +} hyper_node = {"xen,xen", "xen,xen-", NULL, false};
> +
> +static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
> + int depth, void *data)
> +{
> + const void *s = NULL;
> + int len;
> +
> + if (depth != 1 || strcmp(uname, "hypervisor") != 0)
> + return 0;
> +
> + if (of_flat_dt_is_compatible(node, hyper_node.compat))
> + hyper_node.found = true;
> +
> + s = of_get_flat_dt_prop(node, "compatible", &len);
> + if (strlen(hyper_node.prefix) + 3 < len &&
> + !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
> + hyper_node.version = s + strlen(hyper_node.prefix);
> +
> + return 0;
> +}
> +
> /*
> * see Documentation/devicetree/bindings/arm/xen.txt for the
> * documentation of the Xen Device Tree format.
> @@ -245,26 +271,18 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
> #define GRANT_TABLE_PHYSADDR 0
> void __init xen_early_init(void)
> {
> - int len;
> - const char *s = NULL;
> - const char *version = NULL;
> - const char *xen_prefix = "xen,xen-";
> -
> - xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
> - if (!xen_node) {
> + of_scan_flat_dt(fdt_find_hyper_node, NULL);
> + if (!hyper_node.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 (hyper_node.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", hyper_node.version);
>
> xen_domain_type = XEN_HVM_DOMAIN;
>
> @@ -305,6 +323,14 @@ static void __init xen_acpi_guest_init(void)
>
> static void __init xen_dt_guest_init(void)
> {
> + struct device_node *xen_node;
> +
> + xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
> + if (!xen_node) {
> + pr_err("Xen support was detected before, but it has disappeared\n");
> + return;
> + }
> +
> xen_events_irq = irq_of_parse_and_map(xen_node, 0);
> }
>
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 450987d..6cf5051 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
> */
> local_async_enable();
>
> + xen_early_init();
> efi_init();
> arm64_memblock_init();
>
> @@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
> } else {
> psci_acpi_init();
> }
> - xen_early_init();
>
> cpu_read_bootcpu_ops();
> smp_init_cpus();
> --
> 2.1.4
>
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 11/17] ARM: XEN: Move xen_early_init() before efi_init()
@ 2016-03-26 12:54 ` Stefano Stabellini
0 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-26 12:54 UTC (permalink / raw)
To: catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, julien.grall-5wv7dgnIgG8,
peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
zhaoshenglong-hv44wF8Li93QT0dZR+AlfA,
shannon.zhao-QSEj5FYQhm4dnm+yROfE0A
Will, Catalin,
are you OK with this patch?
Thanks,
Stefano
On Thu, 24 Mar 2016, Shannon Zhao wrote:
> Move xen_early_init() before efi_init(), then when calling efi_init()
> could initialize Xen specific UEFI.
>
> Check if it runs on Xen hypervisor through the flat dts.
>
> Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
> ---
> arch/arm/xen/enlighten.c | 56 ++++++++++++++++++++++++++++++++++-------------
> arch/arm64/kernel/setup.c | 2 +-
> 2 files changed, 42 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 680aae0..c43617f 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -20,6 +20,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>
> @@ -53,8 +54,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,
> @@ -238,6 +237,33 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
> return IRQ_HANDLED;
> }
>
> +static __initdata struct {
> + const char *compat;
> + const char *prefix;
> + const char *version;
> + bool found;
> +} hyper_node = {"xen,xen", "xen,xen-", NULL, false};
> +
> +static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
> + int depth, void *data)
> +{
> + const void *s = NULL;
> + int len;
> +
> + if (depth != 1 || strcmp(uname, "hypervisor") != 0)
> + return 0;
> +
> + if (of_flat_dt_is_compatible(node, hyper_node.compat))
> + hyper_node.found = true;
> +
> + s = of_get_flat_dt_prop(node, "compatible", &len);
> + if (strlen(hyper_node.prefix) + 3 < len &&
> + !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
> + hyper_node.version = s + strlen(hyper_node.prefix);
> +
> + return 0;
> +}
> +
> /*
> * see Documentation/devicetree/bindings/arm/xen.txt for the
> * documentation of the Xen Device Tree format.
> @@ -245,26 +271,18 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
> #define GRANT_TABLE_PHYSADDR 0
> void __init xen_early_init(void)
> {
> - int len;
> - const char *s = NULL;
> - const char *version = NULL;
> - const char *xen_prefix = "xen,xen-";
> -
> - xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
> - if (!xen_node) {
> + of_scan_flat_dt(fdt_find_hyper_node, NULL);
> + if (!hyper_node.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 (hyper_node.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", hyper_node.version);
>
> xen_domain_type = XEN_HVM_DOMAIN;
>
> @@ -305,6 +323,14 @@ static void __init xen_acpi_guest_init(void)
>
> static void __init xen_dt_guest_init(void)
> {
> + struct device_node *xen_node;
> +
> + xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
> + if (!xen_node) {
> + pr_err("Xen support was detected before, but it has disappeared\n");
> + return;
> + }
> +
> xen_events_irq = irq_of_parse_and_map(xen_node, 0);
> }
>
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 450987d..6cf5051 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
> */
> local_async_enable();
>
> + xen_early_init();
> efi_init();
> arm64_memblock_init();
>
> @@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
> } else {
> psci_acpi_init();
> }
> - xen_early_init();
>
> cpu_read_bootcpu_ops();
> smp_init_cpus();
> --
> 2.1.4
>
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 11/17] ARM: XEN: Move xen_early_init() before efi_init()
2016-03-26 12:54 ` Stefano Stabellini
(?)
(?)
@ 2016-03-29 16:07 ` Will Deacon
-1 siblings, 0 replies; 172+ messages in thread
From: Will Deacon @ 2016-03-29 16:07 UTC (permalink / raw)
To: Stefano Stabellini
Cc: devicetree, linux-efi, catalin.marinas, linux-kernel,
peter.huangpeng, julien.grall, stefano.stabellini, david.vrabel,
zhaoshenglong, xen-devel, linux-arm-kernel, shannon.zhao
On Sat, Mar 26, 2016 at 12:54:09PM +0000, Stefano Stabellini wrote:
> are you OK with this patch?
Nothing against it, but the only arm64 bit is:
> > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > index 450987d..6cf5051 100644
> > --- a/arch/arm64/kernel/setup.c
> > +++ b/arch/arm64/kernel/setup.c
> > @@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
> > */
> > local_async_enable();
> >
> > + xen_early_init();
> > efi_init();
> > arm64_memblock_init();
> >
> > @@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
> > } else {
> > psci_acpi_init();
> > }
> > - xen_early_init();
so it's difficult to care too much ;) I do hope that there won't be a
need to split up efi_init() in future because some of it has to happen
before xen_early_init, but that doesn't sound likely at the moment.
Will
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 11/17] ARM: XEN: Move xen_early_init() before efi_init()
2016-03-26 12:54 ` Stefano Stabellini
@ 2016-03-29 16:07 ` Will Deacon
-1 siblings, 0 replies; 172+ messages in thread
From: Will Deacon @ 2016-03-29 16:07 UTC (permalink / raw)
To: Stefano Stabellini
Cc: catalin.marinas, linux-arm-kernel, stefano.stabellini,
david.vrabel, devicetree, linux-efi, linux-kernel, julien.grall,
peter.huangpeng, xen-devel, zhaoshenglong, shannon.zhao
On Sat, Mar 26, 2016 at 12:54:09PM +0000, Stefano Stabellini wrote:
> are you OK with this patch?
Nothing against it, but the only arm64 bit is:
> > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > index 450987d..6cf5051 100644
> > --- a/arch/arm64/kernel/setup.c
> > +++ b/arch/arm64/kernel/setup.c
> > @@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
> > */
> > local_async_enable();
> >
> > + xen_early_init();
> > efi_init();
> > arm64_memblock_init();
> >
> > @@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
> > } else {
> > psci_acpi_init();
> > }
> > - xen_early_init();
so it's difficult to care too much ;) I do hope that there won't be a
need to split up efi_init() in future because some of it has to happen
before xen_early_init, but that doesn't sound likely at the moment.
Will
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 11/17] ARM: XEN: Move xen_early_init() before efi_init()
@ 2016-03-29 16:07 ` Will Deacon
0 siblings, 0 replies; 172+ messages in thread
From: Will Deacon @ 2016-03-29 16:07 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Mar 26, 2016 at 12:54:09PM +0000, Stefano Stabellini wrote:
> are you OK with this patch?
Nothing against it, but the only arm64 bit is:
> > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > index 450987d..6cf5051 100644
> > --- a/arch/arm64/kernel/setup.c
> > +++ b/arch/arm64/kernel/setup.c
> > @@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
> > */
> > local_async_enable();
> >
> > + xen_early_init();
> > efi_init();
> > arm64_memblock_init();
> >
> > @@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
> > } else {
> > psci_acpi_init();
> > }
> > - xen_early_init();
so it's difficult to care too much ;) I do hope that there won't be a
need to split up efi_init() in future because some of it has to happen
before xen_early_init, but that doesn't sound likely at the moment.
Will
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 11/17] ARM: XEN: Move xen_early_init() before efi_init()
2016-03-29 16:07 ` Will Deacon
(?)
@ 2016-03-31 11:12 ` Stefano Stabellini
-1 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-31 11:12 UTC (permalink / raw)
To: Will Deacon
Cc: devicetree, linux-efi, Stefano Stabellini, catalin.marinas,
peter.huangpeng, linux-kernel, julien.grall, stefano.stabellini,
david.vrabel, zhaoshenglong, xen-devel, linux-arm-kernel,
shannon.zhao
On Tue, 29 Mar 2016, Will Deacon wrote:
> On Sat, Mar 26, 2016 at 12:54:09PM +0000, Stefano Stabellini wrote:
> > are you OK with this patch?
>
> Nothing against it, but the only arm64 bit is:
>
> > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > > index 450987d..6cf5051 100644
> > > --- a/arch/arm64/kernel/setup.c
> > > +++ b/arch/arm64/kernel/setup.c
> > > @@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
> > > */
> > > local_async_enable();
> > >
> > > + xen_early_init();
> > > efi_init();
> > > arm64_memblock_init();
> > >
> > > @@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
> > > } else {
> > > psci_acpi_init();
> > > }
> > > - xen_early_init();
>
> so it's difficult to care too much ;)
Understood :-)
> I do hope that there won't be a
> need to split up efi_init() in future because some of it has to happen
> before xen_early_init, but that doesn't sound likely at the moment.
Right.
The series is almost fully acked, if you are OK with it, as soon as the
last couple of remaining comments are resolved, I'll queue it up in the
xentip tree for 4.7 (now it is too late for 4.6).
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [Xen-devel] [PATCH v7 11/17] ARM: XEN: Move xen_early_init() before efi_init()
2016-03-29 16:07 ` Will Deacon
(?)
@ 2016-03-31 11:12 ` Stefano Stabellini
-1 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-31 11:12 UTC (permalink / raw)
To: Will Deacon
Cc: Stefano Stabellini, devicetree, linux-efi, catalin.marinas,
linux-kernel, peter.huangpeng, julien.grall, stefano.stabellini,
david.vrabel, zhaoshenglong, xen-devel, linux-arm-kernel,
shannon.zhao
On Tue, 29 Mar 2016, Will Deacon wrote:
> On Sat, Mar 26, 2016 at 12:54:09PM +0000, Stefano Stabellini wrote:
> > are you OK with this patch?
>
> Nothing against it, but the only arm64 bit is:
>
> > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > > index 450987d..6cf5051 100644
> > > --- a/arch/arm64/kernel/setup.c
> > > +++ b/arch/arm64/kernel/setup.c
> > > @@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
> > > */
> > > local_async_enable();
> > >
> > > + xen_early_init();
> > > efi_init();
> > > arm64_memblock_init();
> > >
> > > @@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
> > > } else {
> > > psci_acpi_init();
> > > }
> > > - xen_early_init();
>
> so it's difficult to care too much ;)
Understood :-)
> I do hope that there won't be a
> need to split up efi_init() in future because some of it has to happen
> before xen_early_init, but that doesn't sound likely at the moment.
Right.
The series is almost fully acked, if you are OK with it, as soon as the
last couple of remaining comments are resolved, I'll queue it up in the
xentip tree for 4.7 (now it is too late for 4.6).
^ permalink raw reply [flat|nested] 172+ messages in thread* [Xen-devel] [PATCH v7 11/17] ARM: XEN: Move xen_early_init() before efi_init()
@ 2016-03-31 11:12 ` Stefano Stabellini
0 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-31 11:12 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 29 Mar 2016, Will Deacon wrote:
> On Sat, Mar 26, 2016 at 12:54:09PM +0000, Stefano Stabellini wrote:
> > are you OK with this patch?
>
> Nothing against it, but the only arm64 bit is:
>
> > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > > index 450987d..6cf5051 100644
> > > --- a/arch/arm64/kernel/setup.c
> > > +++ b/arch/arm64/kernel/setup.c
> > > @@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
> > > */
> > > local_async_enable();
> > >
> > > + xen_early_init();
> > > efi_init();
> > > arm64_memblock_init();
> > >
> > > @@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
> > > } else {
> > > psci_acpi_init();
> > > }
> > > - xen_early_init();
>
> so it's difficult to care too much ;)
Understood :-)
> I do hope that there won't be a
> need to split up efi_init() in future because some of it has to happen
> before xen_early_init, but that doesn't sound likely at the moment.
Right.
The series is almost fully acked, if you are OK with it, as soon as the
last couple of remaining comments are resolved, I'll queue it up in the
xentip tree for 4.7 (now it is too late for 4.6).
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [Xen-devel] [PATCH v7 11/17] ARM: XEN: Move xen_early_init() before efi_init()
@ 2016-03-31 11:12 ` Stefano Stabellini
0 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-31 11:12 UTC (permalink / raw)
To: Will Deacon
Cc: Stefano Stabellini, devicetree, linux-efi, catalin.marinas,
linux-kernel, peter.huangpeng, julien.grall, stefano.stabellini,
david.vrabel, zhaoshenglong, xen-devel, linux-arm-kernel,
shannon.zhao
On Tue, 29 Mar 2016, Will Deacon wrote:
> On Sat, Mar 26, 2016 at 12:54:09PM +0000, Stefano Stabellini wrote:
> > are you OK with this patch?
>
> Nothing against it, but the only arm64 bit is:
>
> > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > > index 450987d..6cf5051 100644
> > > --- a/arch/arm64/kernel/setup.c
> > > +++ b/arch/arm64/kernel/setup.c
> > > @@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
> > > */
> > > local_async_enable();
> > >
> > > + xen_early_init();
> > > efi_init();
> > > arm64_memblock_init();
> > >
> > > @@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
> > > } else {
> > > psci_acpi_init();
> > > }
> > > - xen_early_init();
>
> so it's difficult to care too much ;)
Understood :-)
> I do hope that there won't be a
> need to split up efi_init() in future because some of it has to happen
> before xen_early_init, but that doesn't sound likely at the moment.
Right.
The series is almost fully acked, if you are OK with it, as soon as the
last couple of remaining comments are resolved, I'll queue it up in the
xentip tree for 4.7 (now it is too late for 4.6).
^ permalink raw reply [flat|nested] 172+ messages in thread
* [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao
When it's a Xen domain0 booting with ACPI, it will supply a /chosen and
a /hypervisor node in DT. So check if it needs to enable ACPI.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2..4e92be0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -67,10 +67,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 /hypervisor node when running on Xen.
*/
- if (depth == 1 && (strcmp(uname, "chosen") != 0))
- return 1;
+ if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
+ if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
+ return 1;
+ }
+
return 0;
}
@@ -184,7 +187,8 @@ 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)
+ * - the device tree is not empty (it has more than just a /chosen node,
+ * and a /hypervisor node when running on Xen)
* and ACPI has not been force enabled (acpi=force)
*/
if (param_acpi_off ||
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
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 <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2..4e92be0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -67,10 +67,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 /hypervisor node when running on Xen.
*/
- if (depth == 1 && (strcmp(uname, "chosen") != 0))
- return 1;
+ if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
+ if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
+ return 1;
+ }
+
return 0;
}
@@ -184,7 +187,8 @@ 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)
+ * - the device tree is not empty (it has more than just a /chosen node,
+ * and a /hypervisor node when running on Xen)
* and ACPI has not been force enabled (acpi=force)
*/
if (param_acpi_off ||
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, julien.grall-5wv7dgnIgG8,
peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
zhaoshenglong-hv44wF8Li93QT0dZR+AlfA,
shannon.zhao-QSEj5FYQhm4dnm+yROfE0A
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 <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
Acked-by: Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
arch/arm64/kernel/acpi.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2..4e92be0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -67,10 +67,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 /hypervisor node when running on Xen.
*/
- if (depth == 1 && (strcmp(uname, "chosen") != 0))
- return 1;
+ if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
+ if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
+ return 1;
+ }
+
return 0;
}
@@ -184,7 +187,8 @@ 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)
+ * - the device tree is not empty (it has more than just a /chosen node,
+ * and a /hypervisor node when running on Xen)
* and ACPI has not been force enabled (acpi=force)
*/
if (param_acpi_off ||
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-26 12:56 ` Stefano Stabellini
0 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-26 12:56 UTC (permalink / raw)
To: Shannon Zhao
Cc: linux-arm-kernel, stefano.stabellini, david.vrabel, devicetree,
linux-efi, linux-kernel, catalin.marinas, will.deacon,
julien.grall, peter.huangpeng, xen-devel, zhaoshenglong
Will, Catalin,
are you OK with this change?
The series is almost ready to go in, I would like to tie up the loose ends.
Thanks,
Stefano
On Thu, 24 Mar 2016, Shannon Zhao wrote:
> 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 <shannon.zhao@linaro.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/arm64/kernel/acpi.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index d1ce8e2..4e92be0 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -67,10 +67,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 /hypervisor node when running on Xen.
> */
> - if (depth == 1 && (strcmp(uname, "chosen") != 0))
> - return 1;
> + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> + return 1;
> + }
> +
> return 0;
> }
>
> @@ -184,7 +187,8 @@ 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)
> + * - the device tree is not empty (it has more than just a /chosen node,
> + * and a /hypervisor node when running on Xen)
> * and ACPI has not been force enabled (acpi=force)
> */
> if (param_acpi_off ||
> --
> 2.1.4
>
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-26 12:56 ` Stefano Stabellini
0 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-26 12:56 UTC (permalink / raw)
To: linux-arm-kernel
Will, Catalin,
are you OK with this change?
The series is almost ready to go in, I would like to tie up the loose ends.
Thanks,
Stefano
On Thu, 24 Mar 2016, Shannon Zhao wrote:
> 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 <shannon.zhao@linaro.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/arm64/kernel/acpi.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index d1ce8e2..4e92be0 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -67,10 +67,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 /hypervisor node when running on Xen.
> */
> - if (depth == 1 && (strcmp(uname, "chosen") != 0))
> - return 1;
> + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> + return 1;
> + }
> +
> return 0;
> }
>
> @@ -184,7 +187,8 @@ 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)
> + * - the device tree is not empty (it has more than just a /chosen node,
> + * and a /hypervisor node when running on Xen)
> * and ACPI has not been force enabled (acpi=force)
> */
> if (param_acpi_off ||
> --
> 2.1.4
>
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-26 12:56 ` Stefano Stabellini
0 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-26 12:56 UTC (permalink / raw)
To: Shannon Zhao
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, julien.grall-5wv7dgnIgG8,
peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
zhaoshenglong-hv44wF8Li93QT0dZR+AlfA
Will, Catalin,
are you OK with this change?
The series is almost ready to go in, I would like to tie up the loose ends.
Thanks,
Stefano
On Thu, 24 Mar 2016, Shannon Zhao wrote:
> 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 <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
> Acked-by: Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> arch/arm64/kernel/acpi.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index d1ce8e2..4e92be0 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -67,10 +67,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 /hypervisor node when running on Xen.
> */
> - if (depth == 1 && (strcmp(uname, "chosen") != 0))
> - return 1;
> + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> + return 1;
> + }
> +
> return 0;
> }
>
> @@ -184,7 +187,8 @@ 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)
> + * - the device tree is not empty (it has more than just a /chosen node,
> + * and a /hypervisor node when running on Xen)
> * and ACPI has not been force enabled (acpi=force)
> */
> if (param_acpi_off ||
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
2016-03-24 14:44 ` Shannon Zhao
` (2 preceding siblings ...)
(?)
@ 2016-03-26 12:56 ` Stefano Stabellini
-1 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-26 12:56 UTC (permalink / raw)
To: Shannon Zhao
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, stefano.stabellini,
david.vrabel, zhaoshenglong, xen-devel, linux-arm-kernel
Will, Catalin,
are you OK with this change?
The series is almost ready to go in, I would like to tie up the loose ends.
Thanks,
Stefano
On Thu, 24 Mar 2016, Shannon Zhao wrote:
> 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 <shannon.zhao@linaro.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/arm64/kernel/acpi.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index d1ce8e2..4e92be0 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -67,10 +67,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 /hypervisor node when running on Xen.
> */
> - if (depth == 1 && (strcmp(uname, "chosen") != 0))
> - return 1;
> + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> + return 1;
> + }
> +
> return 0;
> }
>
> @@ -184,7 +187,8 @@ 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)
> + * - the device tree is not empty (it has more than just a /chosen node,
> + * and a /hypervisor node when running on Xen)
> * and ACPI has not been force enabled (acpi=force)
> */
> if (param_acpi_off ||
> --
> 2.1.4
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
2016-03-24 14:44 ` Shannon Zhao
@ 2016-03-29 16:18 ` Will Deacon
-1 siblings, 0 replies; 172+ messages in thread
From: Will Deacon @ 2016-03-29 16:18 UTC (permalink / raw)
To: Shannon Zhao
Cc: linux-arm-kernel, stefano.stabellini, david.vrabel, devicetree,
linux-efi, linux-kernel, catalin.marinas, julien.grall,
peter.huangpeng, xen-devel, zhaoshenglong, mark.rutland
On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
> 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 <shannon.zhao@linaro.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/arm64/kernel/acpi.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index d1ce8e2..4e92be0 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -67,10 +67,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 /hypervisor node when running on Xen.
> */
> - if (depth == 1 && (strcmp(uname, "chosen") != 0))
> - return 1;
> + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> + return 1;
> + }
Hmm, but xen_initial_domain() is false when xen isn't being used at all,
so it feels to me like this is a bit too far-reaching and is basically
claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
"xen,hypervisor" or something?
Mark, got any thoughts on this?
Will
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-29 16:18 ` Will Deacon
0 siblings, 0 replies; 172+ messages in thread
From: Will Deacon @ 2016-03-29 16:18 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
> 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 <shannon.zhao@linaro.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/arm64/kernel/acpi.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index d1ce8e2..4e92be0 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -67,10 +67,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 /hypervisor node when running on Xen.
> */
> - if (depth == 1 && (strcmp(uname, "chosen") != 0))
> - return 1;
> + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> + return 1;
> + }
Hmm, but xen_initial_domain() is false when xen isn't being used at all,
so it feels to me like this is a bit too far-reaching and is basically
claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
"xen,hypervisor" or something?
Mark, got any thoughts on this?
Will
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
2016-03-29 16:18 ` Will Deacon
(?)
@ 2016-03-29 16:31 ` Mark Rutland
-1 siblings, 0 replies; 172+ messages in thread
From: Mark Rutland @ 2016-03-29 16:31 UTC (permalink / raw)
To: Will Deacon
Cc: devicetree, linux-efi, catalin.marinas, linux-kernel,
peter.huangpeng, julien.grall, stefano.stabellini, Shannon Zhao,
zhaoshenglong, xen-devel, linux-arm-kernel, david.vrabel
On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
> On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
> > 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 <shannon.zhao@linaro.org>
> > Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> > ---
> > arch/arm64/kernel/acpi.c | 12 ++++++++----
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > index d1ce8e2..4e92be0 100644
> > --- a/arch/arm64/kernel/acpi.c
> > +++ b/arch/arm64/kernel/acpi.c
> > @@ -67,10 +67,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 /hypervisor node when running on Xen.
> > */
> > - if (depth == 1 && (strcmp(uname, "chosen") != 0))
> > - return 1;
> > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> > + return 1;
> > + }
>
> Hmm, but xen_initial_domain() is false when xen isn't being used at all,
> so it feels to me like this is a bit too far-reaching and is basically
> claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
> "xen,hypervisor" or something?
>
> Mark, got any thoughts on this?
The node has a compatible string, "xen,xen" per [1], which would tell us
absolutely that xen is present. I'd be happy checking for that
explicitly.
In patch 11 fdt_find_hyper_node checks the compatible string. We could
factor that out into a helper like is_xen_node(node) and use it here
too.
If in future we want to do the same for other hypervisors we can add
explicit checks for their compatible strings and/or wrap that in a more
generic helper to cater for any hypervisor-specific details.
Thanks,
Mark.
[1] Documentation/devicetree/bindings/arm/xen.txt
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-29 16:31 ` Mark Rutland
0 siblings, 0 replies; 172+ messages in thread
From: Mark Rutland @ 2016-03-29 16:31 UTC (permalink / raw)
To: Will Deacon
Cc: Shannon Zhao, linux-arm-kernel, stefano.stabellini, david.vrabel,
devicetree, linux-efi, linux-kernel, catalin.marinas,
julien.grall, peter.huangpeng, xen-devel, zhaoshenglong
On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
> On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
> > 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 <shannon.zhao@linaro.org>
> > Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> > ---
> > arch/arm64/kernel/acpi.c | 12 ++++++++----
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > index d1ce8e2..4e92be0 100644
> > --- a/arch/arm64/kernel/acpi.c
> > +++ b/arch/arm64/kernel/acpi.c
> > @@ -67,10 +67,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 /hypervisor node when running on Xen.
> > */
> > - if (depth == 1 && (strcmp(uname, "chosen") != 0))
> > - return 1;
> > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> > + return 1;
> > + }
>
> Hmm, but xen_initial_domain() is false when xen isn't being used at all,
> so it feels to me like this is a bit too far-reaching and is basically
> claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
> "xen,hypervisor" or something?
>
> Mark, got any thoughts on this?
The node has a compatible string, "xen,xen" per [1], which would tell us
absolutely that xen is present. I'd be happy checking for that
explicitly.
In patch 11 fdt_find_hyper_node checks the compatible string. We could
factor that out into a helper like is_xen_node(node) and use it here
too.
If in future we want to do the same for other hypervisors we can add
explicit checks for their compatible strings and/or wrap that in a more
generic helper to cater for any hypervisor-specific details.
Thanks,
Mark.
[1] Documentation/devicetree/bindings/arm/xen.txt
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-29 16:31 ` Mark Rutland
0 siblings, 0 replies; 172+ messages in thread
From: Mark Rutland @ 2016-03-29 16:31 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
> On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
> > 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 <shannon.zhao@linaro.org>
> > Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> > ---
> > arch/arm64/kernel/acpi.c | 12 ++++++++----
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > index d1ce8e2..4e92be0 100644
> > --- a/arch/arm64/kernel/acpi.c
> > +++ b/arch/arm64/kernel/acpi.c
> > @@ -67,10 +67,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 /hypervisor node when running on Xen.
> > */
> > - if (depth == 1 && (strcmp(uname, "chosen") != 0))
> > - return 1;
> > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> > + return 1;
> > + }
>
> Hmm, but xen_initial_domain() is false when xen isn't being used at all,
> so it feels to me like this is a bit too far-reaching and is basically
> claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
> "xen,hypervisor" or something?
>
> Mark, got any thoughts on this?
The node has a compatible string, "xen,xen" per [1], which would tell us
absolutely that xen is present. I'd be happy checking for that
explicitly.
In patch 11 fdt_find_hyper_node checks the compatible string. We could
factor that out into a helper like is_xen_node(node) and use it here
too.
If in future we want to do the same for other hypervisors we can add
explicit checks for their compatible strings and/or wrap that in a more
generic helper to cater for any hypervisor-specific details.
Thanks,
Mark.
[1] Documentation/devicetree/bindings/arm/xen.txt
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-29 16:31 ` Mark Rutland
0 siblings, 0 replies; 172+ messages in thread
From: Mark Rutland @ 2016-03-29 16:31 UTC (permalink / raw)
To: Will Deacon
Cc: Shannon Zhao, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
julien.grall-5wv7dgnIgG8, peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
zhaoshenglong-hv44wF8Li93QT0dZR+AlfA
On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
> On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
> > 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 <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Reviewed-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
> > Acked-by: Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > ---
> > arch/arm64/kernel/acpi.c | 12 ++++++++----
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > index d1ce8e2..4e92be0 100644
> > --- a/arch/arm64/kernel/acpi.c
> > +++ b/arch/arm64/kernel/acpi.c
> > @@ -67,10 +67,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 /hypervisor node when running on Xen.
> > */
> > - if (depth == 1 && (strcmp(uname, "chosen") != 0))
> > - return 1;
> > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> > + return 1;
> > + }
>
> Hmm, but xen_initial_domain() is false when xen isn't being used at all,
> so it feels to me like this is a bit too far-reaching and is basically
> claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
> "xen,hypervisor" or something?
>
> Mark, got any thoughts on this?
The node has a compatible string, "xen,xen" per [1], which would tell us
absolutely that xen is present. I'd be happy checking for that
explicitly.
In patch 11 fdt_find_hyper_node checks the compatible string. We could
factor that out into a helper like is_xen_node(node) and use it here
too.
If in future we want to do the same for other hypervisors we can add
explicit checks for their compatible strings and/or wrap that in a more
generic helper to cater for any hypervisor-specific details.
Thanks,
Mark.
[1] Documentation/devicetree/bindings/arm/xen.txt
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
2016-03-29 16:31 ` Mark Rutland
(?)
@ 2016-03-30 7:19 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-30 7:19 UTC (permalink / raw)
To: Mark Rutland, Will Deacon
Cc: Shannon Zhao, linux-arm-kernel, stefano.stabellini, david.vrabel,
devicetree, linux-efi, linux-kernel, catalin.marinas,
julien.grall, peter.huangpeng, xen-devel
Hi Will, Mark,
On 2016/3/30 0:31, Mark Rutland wrote:
> On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
>> > On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
>>> > > 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 <shannon.zhao@linaro.org>
>>> > > Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> > > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> > > ---
>>> > > arch/arm64/kernel/acpi.c | 12 ++++++++----
>>> > > 1 file changed, 8 insertions(+), 4 deletions(-)
>>> > >
>>> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>>> > > index d1ce8e2..4e92be0 100644
>>> > > --- a/arch/arm64/kernel/acpi.c
>>> > > +++ b/arch/arm64/kernel/acpi.c
>>> > > @@ -67,10 +67,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 /hypervisor node when running on Xen.
>>> > > */
>>> > > - if (depth == 1 && (strcmp(uname, "chosen") != 0))
>>> > > - return 1;
>>> > > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
>>> > > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
>>> > > + return 1;
>>> > > + }
>> >
>> > Hmm, but xen_initial_domain() is false when xen isn't being used at all,
>> > so it feels to me like this is a bit too far-reaching and is basically
>> > claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
>> > "xen,hypervisor" or something?
>> >
>> > Mark, got any thoughts on this?
> The node has a compatible string, "xen,xen" per [1], which would tell us
> absolutely that xen is present. I'd be happy checking for that
> explicitly.
>
I think actually the xen_initial_domain is the result of the
fdt_find_hyper_node. If the compatible string "xen,xen" doesn't exist,
the xen_initial_domain() will return false and whatever the current node
is the above check will return 1 since the device tree is not empty.
> In patch 11 fdt_find_hyper_node checks the compatible string. We could
> factor that out into a helper like is_xen_node(node) and use it here
> too.
>
I don't think so because we already check the compatible string before
and we could get the result simply via xen_initial_domain().
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-30 7:19 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-30 7:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi Will, Mark,
On 2016/3/30 0:31, Mark Rutland wrote:
> On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
>> > On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
>>> > > 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 <shannon.zhao@linaro.org>
>>> > > Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> > > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> > > ---
>>> > > arch/arm64/kernel/acpi.c | 12 ++++++++----
>>> > > 1 file changed, 8 insertions(+), 4 deletions(-)
>>> > >
>>> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>>> > > index d1ce8e2..4e92be0 100644
>>> > > --- a/arch/arm64/kernel/acpi.c
>>> > > +++ b/arch/arm64/kernel/acpi.c
>>> > > @@ -67,10 +67,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 /hypervisor node when running on Xen.
>>> > > */
>>> > > - if (depth == 1 && (strcmp(uname, "chosen") != 0))
>>> > > - return 1;
>>> > > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
>>> > > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
>>> > > + return 1;
>>> > > + }
>> >
>> > Hmm, but xen_initial_domain() is false when xen isn't being used at all,
>> > so it feels to me like this is a bit too far-reaching and is basically
>> > claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
>> > "xen,hypervisor" or something?
>> >
>> > Mark, got any thoughts on this?
> The node has a compatible string, "xen,xen" per [1], which would tell us
> absolutely that xen is present. I'd be happy checking for that
> explicitly.
>
I think actually the xen_initial_domain is the result of the
fdt_find_hyper_node. If the compatible string "xen,xen" doesn't exist,
the xen_initial_domain() will return false and whatever the current node
is the above check will return 1 since the device tree is not empty.
> In patch 11 fdt_find_hyper_node checks the compatible string. We could
> factor that out into a helper like is_xen_node(node) and use it here
> too.
>
I don't think so because we already check the compatible string before
and we could get the result simply via xen_initial_domain().
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-30 7:19 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-30 7:19 UTC (permalink / raw)
To: Mark Rutland, Will Deacon
Cc: Shannon Zhao, linux-arm-kernel, stefano.stabellini, david.vrabel,
devicetree, linux-efi, linux-kernel, catalin.marinas,
julien.grall, peter.huangpeng, xen-devel
Hi Will, Mark,
On 2016/3/30 0:31, Mark Rutland wrote:
> On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
>> > On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
>>> > > 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 <shannon.zhao@linaro.org>
>>> > > Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> > > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> > > ---
>>> > > arch/arm64/kernel/acpi.c | 12 ++++++++----
>>> > > 1 file changed, 8 insertions(+), 4 deletions(-)
>>> > >
>>> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>>> > > index d1ce8e2..4e92be0 100644
>>> > > --- a/arch/arm64/kernel/acpi.c
>>> > > +++ b/arch/arm64/kernel/acpi.c
>>> > > @@ -67,10 +67,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 /hypervisor node when running on Xen.
>>> > > */
>>> > > - if (depth == 1 && (strcmp(uname, "chosen") != 0))
>>> > > - return 1;
>>> > > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
>>> > > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
>>> > > + return 1;
>>> > > + }
>> >
>> > Hmm, but xen_initial_domain() is false when xen isn't being used at all,
>> > so it feels to me like this is a bit too far-reaching and is basically
>> > claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
>> > "xen,hypervisor" or something?
>> >
>> > Mark, got any thoughts on this?
> The node has a compatible string, "xen,xen" per [1], which would tell us
> absolutely that xen is present. I'd be happy checking for that
> explicitly.
>
I think actually the xen_initial_domain is the result of the
fdt_find_hyper_node. If the compatible string "xen,xen" doesn't exist,
the xen_initial_domain() will return false and whatever the current node
is the above check will return 1 since the device tree is not empty.
> In patch 11 fdt_find_hyper_node checks the compatible string. We could
> factor that out into a helper like is_xen_node(node) and use it here
> too.
>
I don't think so because we already check the compatible string before
and we could get the result simply via xen_initial_domain().
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
2016-03-30 7:19 ` Shannon Zhao
(?)
(?)
@ 2016-03-31 11:04 ` Stefano Stabellini
-1 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-31 11:04 UTC (permalink / raw)
To: Shannon Zhao
Cc: Mark Rutland, devicetree, linux-efi, catalin.marinas,
Will Deacon, linux-kernel, peter.huangpeng, julien.grall,
stefano.stabellini, Shannon Zhao, xen-devel, linux-arm-kernel,
david.vrabel
On Wed, 30 Mar 2016, Shannon Zhao wrote:
> Hi Will, Mark,
>
> On 2016/3/30 0:31, Mark Rutland wrote:
> > On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
> >> > On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
> >>> > > 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 <shannon.zhao@linaro.org>
> >>> > > Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>> > > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> >>> > > ---
> >>> > > arch/arm64/kernel/acpi.c | 12 ++++++++----
> >>> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> >>> > >
> >>> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> >>> > > index d1ce8e2..4e92be0 100644
> >>> > > --- a/arch/arm64/kernel/acpi.c
> >>> > > +++ b/arch/arm64/kernel/acpi.c
> >>> > > @@ -67,10 +67,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 /hypervisor node when running on Xen.
> >>> > > */
> >>> > > - if (depth == 1 && (strcmp(uname, "chosen") != 0))
> >>> > > - return 1;
> >>> > > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> >>> > > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> >>> > > + return 1;
> >>> > > + }
> >> >
> >> > Hmm, but xen_initial_domain() is false when xen isn't being used at all,
> >> > so it feels to me like this is a bit too far-reaching and is basically
> >> > claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
> >> > "xen,hypervisor" or something?
> >> >
> >> > Mark, got any thoughts on this?
> > The node has a compatible string, "xen,xen" per [1], which would tell us
> > absolutely that xen is present. I'd be happy checking for that
> > explicitly.
> >
> I think actually the xen_initial_domain is the result of the
> fdt_find_hyper_node. If the compatible string "xen,xen" doesn't exist,
> the xen_initial_domain() will return false and whatever the current node
> is the above check will return 1 since the device tree is not empty.
Right.
xen_initial_domain implies both "xen,xen" and XENFEAT_dom0 (which is a
feature retrieved by making a XENVER_get_features hypercall, see
drivers/xen/features.c:xen_setup_features).
So the following check:
+ if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
+ return 1;
means that even if it's xen_initial_domain(), return error unless the
node found is "hypervisor". In other words, even if
xen_initial_domain(), no other nodes are allowed except /chosen and
/hypervisor.
This doesn't look far reaching to me, but yes, we could check explicitly
for the node to be compatible "xen,xen", in addition to be named
"hypervisor", even though the check is already done elsewhere
(arch/arm/xen/enlighten.c).
But I would keep it as it is.
> > In patch 11 fdt_find_hyper_node checks the compatible string. We could
> > factor that out into a helper like is_xen_node(node) and use it here
> > too.
> >
> I don't think so because we already check the compatible string before
> and we could get the result simply via xen_initial_domain().
We could add a comment saying xen_initial_domain() implies "xen,xen" or
something.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-31 11:04 ` Stefano Stabellini
0 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-31 11:04 UTC (permalink / raw)
To: Shannon Zhao
Cc: Mark Rutland, Will Deacon, Shannon Zhao, linux-arm-kernel,
stefano.stabellini, david.vrabel, devicetree, linux-efi,
linux-kernel, catalin.marinas, julien.grall, peter.huangpeng,
xen-devel
On Wed, 30 Mar 2016, Shannon Zhao wrote:
> Hi Will, Mark,
>
> On 2016/3/30 0:31, Mark Rutland wrote:
> > On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
> >> > On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
> >>> > > 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 <shannon.zhao@linaro.org>
> >>> > > Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>> > > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> >>> > > ---
> >>> > > arch/arm64/kernel/acpi.c | 12 ++++++++----
> >>> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> >>> > >
> >>> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> >>> > > index d1ce8e2..4e92be0 100644
> >>> > > --- a/arch/arm64/kernel/acpi.c
> >>> > > +++ b/arch/arm64/kernel/acpi.c
> >>> > > @@ -67,10 +67,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 /hypervisor node when running on Xen.
> >>> > > */
> >>> > > - if (depth == 1 && (strcmp(uname, "chosen") != 0))
> >>> > > - return 1;
> >>> > > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> >>> > > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> >>> > > + return 1;
> >>> > > + }
> >> >
> >> > Hmm, but xen_initial_domain() is false when xen isn't being used at all,
> >> > so it feels to me like this is a bit too far-reaching and is basically
> >> > claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
> >> > "xen,hypervisor" or something?
> >> >
> >> > Mark, got any thoughts on this?
> > The node has a compatible string, "xen,xen" per [1], which would tell us
> > absolutely that xen is present. I'd be happy checking for that
> > explicitly.
> >
> I think actually the xen_initial_domain is the result of the
> fdt_find_hyper_node. If the compatible string "xen,xen" doesn't exist,
> the xen_initial_domain() will return false and whatever the current node
> is the above check will return 1 since the device tree is not empty.
Right.
xen_initial_domain implies both "xen,xen" and XENFEAT_dom0 (which is a
feature retrieved by making a XENVER_get_features hypercall, see
drivers/xen/features.c:xen_setup_features).
So the following check:
+ if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
+ return 1;
means that even if it's xen_initial_domain(), return error unless the
node found is "hypervisor". In other words, even if
xen_initial_domain(), no other nodes are allowed except /chosen and
/hypervisor.
This doesn't look far reaching to me, but yes, we could check explicitly
for the node to be compatible "xen,xen", in addition to be named
"hypervisor", even though the check is already done elsewhere
(arch/arm/xen/enlighten.c).
But I would keep it as it is.
> > In patch 11 fdt_find_hyper_node checks the compatible string. We could
> > factor that out into a helper like is_xen_node(node) and use it here
> > too.
> >
> I don't think so because we already check the compatible string before
> and we could get the result simply via xen_initial_domain().
We could add a comment saying xen_initial_domain() implies "xen,xen" or
something.
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-31 11:04 ` Stefano Stabellini
0 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-31 11:04 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 30 Mar 2016, Shannon Zhao wrote:
> Hi Will, Mark,
>
> On 2016/3/30 0:31, Mark Rutland wrote:
> > On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
> >> > On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
> >>> > > 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 <shannon.zhao@linaro.org>
> >>> > > Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>> > > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> >>> > > ---
> >>> > > arch/arm64/kernel/acpi.c | 12 ++++++++----
> >>> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> >>> > >
> >>> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> >>> > > index d1ce8e2..4e92be0 100644
> >>> > > --- a/arch/arm64/kernel/acpi.c
> >>> > > +++ b/arch/arm64/kernel/acpi.c
> >>> > > @@ -67,10 +67,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 /hypervisor node when running on Xen.
> >>> > > */
> >>> > > - if (depth == 1 && (strcmp(uname, "chosen") != 0))
> >>> > > - return 1;
> >>> > > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> >>> > > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> >>> > > + return 1;
> >>> > > + }
> >> >
> >> > Hmm, but xen_initial_domain() is false when xen isn't being used at all,
> >> > so it feels to me like this is a bit too far-reaching and is basically
> >> > claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
> >> > "xen,hypervisor" or something?
> >> >
> >> > Mark, got any thoughts on this?
> > The node has a compatible string, "xen,xen" per [1], which would tell us
> > absolutely that xen is present. I'd be happy checking for that
> > explicitly.
> >
> I think actually the xen_initial_domain is the result of the
> fdt_find_hyper_node. If the compatible string "xen,xen" doesn't exist,
> the xen_initial_domain() will return false and whatever the current node
> is the above check will return 1 since the device tree is not empty.
Right.
xen_initial_domain implies both "xen,xen" and XENFEAT_dom0 (which is a
feature retrieved by making a XENVER_get_features hypercall, see
drivers/xen/features.c:xen_setup_features).
So the following check:
+ if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
+ return 1;
means that even if it's xen_initial_domain(), return error unless the
node found is "hypervisor". In other words, even if
xen_initial_domain(), no other nodes are allowed except /chosen and
/hypervisor.
This doesn't look far reaching to me, but yes, we could check explicitly
for the node to be compatible "xen,xen", in addition to be named
"hypervisor", even though the check is already done elsewhere
(arch/arm/xen/enlighten.c).
But I would keep it as it is.
> > In patch 11 fdt_find_hyper_node checks the compatible string. We could
> > factor that out into a helper like is_xen_node(node) and use it here
> > too.
> >
> I don't think so because we already check the compatible string before
> and we could get the result simply via xen_initial_domain().
We could add a comment saying xen_initial_domain() implies "xen,xen" or
something.
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-31 11:04 ` Stefano Stabellini
0 siblings, 0 replies; 172+ messages in thread
From: Stefano Stabellini @ 2016-03-31 11:04 UTC (permalink / raw)
To: Shannon Zhao
Cc: Mark Rutland, Will Deacon, Shannon Zhao,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
julien.grall-5wv7dgnIgG8, peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw
On Wed, 30 Mar 2016, Shannon Zhao wrote:
> Hi Will, Mark,
>
> On 2016/3/30 0:31, Mark Rutland wrote:
> > On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
> >> > On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
> >>> > > 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 <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >>> > > Reviewed-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
> >>> > > Acked-by: Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >>> > > ---
> >>> > > arch/arm64/kernel/acpi.c | 12 ++++++++----
> >>> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> >>> > >
> >>> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> >>> > > index d1ce8e2..4e92be0 100644
> >>> > > --- a/arch/arm64/kernel/acpi.c
> >>> > > +++ b/arch/arm64/kernel/acpi.c
> >>> > > @@ -67,10 +67,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 /hypervisor node when running on Xen.
> >>> > > */
> >>> > > - if (depth == 1 && (strcmp(uname, "chosen") != 0))
> >>> > > - return 1;
> >>> > > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> >>> > > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> >>> > > + return 1;
> >>> > > + }
> >> >
> >> > Hmm, but xen_initial_domain() is false when xen isn't being used at all,
> >> > so it feels to me like this is a bit too far-reaching and is basically
> >> > claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
> >> > "xen,hypervisor" or something?
> >> >
> >> > Mark, got any thoughts on this?
> > The node has a compatible string, "xen,xen" per [1], which would tell us
> > absolutely that xen is present. I'd be happy checking for that
> > explicitly.
> >
> I think actually the xen_initial_domain is the result of the
> fdt_find_hyper_node. If the compatible string "xen,xen" doesn't exist,
> the xen_initial_domain() will return false and whatever the current node
> is the above check will return 1 since the device tree is not empty.
Right.
xen_initial_domain implies both "xen,xen" and XENFEAT_dom0 (which is a
feature retrieved by making a XENVER_get_features hypercall, see
drivers/xen/features.c:xen_setup_features).
So the following check:
+ if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
+ return 1;
means that even if it's xen_initial_domain(), return error unless the
node found is "hypervisor". In other words, even if
xen_initial_domain(), no other nodes are allowed except /chosen and
/hypervisor.
This doesn't look far reaching to me, but yes, we could check explicitly
for the node to be compatible "xen,xen", in addition to be named
"hypervisor", even though the check is already done elsewhere
(arch/arm/xen/enlighten.c).
But I would keep it as it is.
> > In patch 11 fdt_find_hyper_node checks the compatible string. We could
> > factor that out into a helper like is_xen_node(node) and use it here
> > too.
> >
> I don't think so because we already check the compatible string before
> and we could get the result simply via xen_initial_domain().
We could add a comment saying xen_initial_domain() implies "xen,xen" or
something.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-31 11:44 ` Ard Biesheuvel
0 siblings, 0 replies; 172+ messages in thread
From: Ard Biesheuvel @ 2016-03-31 11:44 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Shannon Zhao, Mark Rutland, devicetree, linux-efi,
Catalin Marinas, Will Deacon, linux-kernel, Huangpeng (Peter),
julien.grall, Stefano Stabellini, Shannon Zhao, xen-devel,
linux-arm-kernel, David Vrabel
On 31 March 2016 at 13:04, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 30 Mar 2016, Shannon Zhao wrote:
>> Hi Will, Mark,
>>
>> On 2016/3/30 0:31, Mark Rutland wrote:
>> > On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
>> >> > On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
>> >>> > > 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 <shannon.zhao@linaro.org>
>> >>> > > Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> >>> > > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
>> >>> > > ---
>> >>> > > arch/arm64/kernel/acpi.c | 12 ++++++++----
>> >>> > > 1 file changed, 8 insertions(+), 4 deletions(-)
>> >>> > >
>> >>> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> >>> > > index d1ce8e2..4e92be0 100644
>> >>> > > --- a/arch/arm64/kernel/acpi.c
>> >>> > > +++ b/arch/arm64/kernel/acpi.c
>> >>> > > @@ -67,10 +67,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 /hypervisor node when running on Xen.
>> >>> > > */
>> >>> > > - if (depth == 1 && (strcmp(uname, "chosen") != 0))
>> >>> > > - return 1;
>> >>> > > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
>> >>> > > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
>> >>> > > + return 1;
>> >>> > > + }
>> >> >
>> >> > Hmm, but xen_initial_domain() is false when xen isn't being used at all,
>> >> > so it feels to me like this is a bit too far-reaching and is basically
>> >> > claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
>> >> > "xen,hypervisor" or something?
>> >> >
>> >> > Mark, got any thoughts on this?
>> > The node has a compatible string, "xen,xen" per [1], which would tell us
>> > absolutely that xen is present. I'd be happy checking for that
>> > explicitly.
>> >
>> I think actually the xen_initial_domain is the result of the
>> fdt_find_hyper_node. If the compatible string "xen,xen" doesn't exist,
>> the xen_initial_domain() will return false and whatever the current node
>> is the above check will return 1 since the device tree is not empty.
>
> Right.
>
> xen_initial_domain implies both "xen,xen" and XENFEAT_dom0 (which is a
> feature retrieved by making a XENVER_get_features hypercall, see
> drivers/xen/features.c:xen_setup_features).
>
> So the following check:
>
> + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> + return 1;
>
> means that even if it's xen_initial_domain(), return error unless the
> node found is "hypervisor". In other words, even if
> xen_initial_domain(), no other nodes are allowed except /chosen and
> /hypervisor.
>
> This doesn't look far reaching to me, but yes, we could check explicitly
> for the node to be compatible "xen,xen", in addition to be named
> "hypervisor", even though the check is already done elsewhere
> (arch/arm/xen/enlighten.c).
>
> But I would keep it as it is.
>
The heuristic is there to decide whether some DTB image contains a
complete description of the platform, or only some data handed over by
the bootloader. Arguably, a DT containing both /chosen and /hypervisor
but nothing else can still not describe an actual platform, and
whether we execute under Xen or not is completely irrelevant.
So this should be sufficient imo
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2f98b9..d6d61e2e4d49 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -67,9 +67,10 @@ 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 the /hypervisor node.
*/
- if (depth == 1 && (strcmp(uname, "chosen") != 0))
+ if (depth == 1 && strcmp(uname, "chosen") != 0 &&
+ strcmp(uname, "hypervisor") != 0)
return 1;
return 0;
}
>> > In patch 11 fdt_find_hyper_node checks the compatible string. We could
>> > factor that out into a helper like is_xen_node(node) and use it here
>> > too.
>> >
>> I don't think so because we already check the compatible string before
>> and we could get the result simply via xen_initial_domain().
>
> We could add a comment saying xen_initial_domain() implies "xen,xen" or
> something.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-31 11:44 ` Ard Biesheuvel
0 siblings, 0 replies; 172+ messages in thread
From: Ard Biesheuvel @ 2016-03-31 11:44 UTC (permalink / raw)
To: linux-arm-kernel
On 31 March 2016 at 13:04, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 30 Mar 2016, Shannon Zhao wrote:
>> Hi Will, Mark,
>>
>> On 2016/3/30 0:31, Mark Rutland wrote:
>> > On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
>> >> > On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
>> >>> > > 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 <shannon.zhao@linaro.org>
>> >>> > > Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> >>> > > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
>> >>> > > ---
>> >>> > > arch/arm64/kernel/acpi.c | 12 ++++++++----
>> >>> > > 1 file changed, 8 insertions(+), 4 deletions(-)
>> >>> > >
>> >>> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> >>> > > index d1ce8e2..4e92be0 100644
>> >>> > > --- a/arch/arm64/kernel/acpi.c
>> >>> > > +++ b/arch/arm64/kernel/acpi.c
>> >>> > > @@ -67,10 +67,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 /hypervisor node when running on Xen.
>> >>> > > */
>> >>> > > - if (depth == 1 && (strcmp(uname, "chosen") != 0))
>> >>> > > - return 1;
>> >>> > > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
>> >>> > > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
>> >>> > > + return 1;
>> >>> > > + }
>> >> >
>> >> > Hmm, but xen_initial_domain() is false when xen isn't being used at all,
>> >> > so it feels to me like this is a bit too far-reaching and is basically
>> >> > claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
>> >> > "xen,hypervisor" or something?
>> >> >
>> >> > Mark, got any thoughts on this?
>> > The node has a compatible string, "xen,xen" per [1], which would tell us
>> > absolutely that xen is present. I'd be happy checking for that
>> > explicitly.
>> >
>> I think actually the xen_initial_domain is the result of the
>> fdt_find_hyper_node. If the compatible string "xen,xen" doesn't exist,
>> the xen_initial_domain() will return false and whatever the current node
>> is the above check will return 1 since the device tree is not empty.
>
> Right.
>
> xen_initial_domain implies both "xen,xen" and XENFEAT_dom0 (which is a
> feature retrieved by making a XENVER_get_features hypercall, see
> drivers/xen/features.c:xen_setup_features).
>
> So the following check:
>
> + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> + return 1;
>
> means that even if it's xen_initial_domain(), return error unless the
> node found is "hypervisor". In other words, even if
> xen_initial_domain(), no other nodes are allowed except /chosen and
> /hypervisor.
>
> This doesn't look far reaching to me, but yes, we could check explicitly
> for the node to be compatible "xen,xen", in addition to be named
> "hypervisor", even though the check is already done elsewhere
> (arch/arm/xen/enlighten.c).
>
> But I would keep it as it is.
>
The heuristic is there to decide whether some DTB image contains a
complete description of the platform, or only some data handed over by
the bootloader. Arguably, a DT containing both /chosen and /hypervisor
but nothing else can still not describe an actual platform, and
whether we execute under Xen or not is completely irrelevant.
So this should be sufficient imo
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2f98b9..d6d61e2e4d49 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -67,9 +67,10 @@ 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 the /hypervisor node.
*/
- if (depth == 1 && (strcmp(uname, "chosen") != 0))
+ if (depth == 1 && strcmp(uname, "chosen") != 0 &&
+ strcmp(uname, "hypervisor") != 0)
return 1;
return 0;
}
>> > In patch 11 fdt_find_hyper_node checks the compatible string. We could
>> > factor that out into a helper like is_xen_node(node) and use it here
>> > too.
>> >
>> I don't think so because we already check the compatible string before
>> and we could get the result simply via xen_initial_domain().
>
> We could add a comment saying xen_initial_domain() implies "xen,xen" or
> something.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 172+ messages in thread* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-31 11:44 ` Ard Biesheuvel
0 siblings, 0 replies; 172+ messages in thread
From: Ard Biesheuvel @ 2016-03-31 11:44 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Shannon Zhao, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, Catalin Marinas, Will Deacon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Huangpeng (Peter),
julien.grall-5wv7dgnIgG8, Stefano Stabellini, Shannon Zhao,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Vrabel
On 31 March 2016 at 13:04, Stefano Stabellini
<stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org> wrote:
> On Wed, 30 Mar 2016, Shannon Zhao wrote:
>> Hi Will, Mark,
>>
>> On 2016/3/30 0:31, Mark Rutland wrote:
>> > On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
>> >> > On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
>> >>> > > 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 <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> >>> > > Reviewed-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
>> >>> > > Acked-by: Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> >>> > > ---
>> >>> > > arch/arm64/kernel/acpi.c | 12 ++++++++----
>> >>> > > 1 file changed, 8 insertions(+), 4 deletions(-)
>> >>> > >
>> >>> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> >>> > > index d1ce8e2..4e92be0 100644
>> >>> > > --- a/arch/arm64/kernel/acpi.c
>> >>> > > +++ b/arch/arm64/kernel/acpi.c
>> >>> > > @@ -67,10 +67,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 /hypervisor node when running on Xen.
>> >>> > > */
>> >>> > > - if (depth == 1 && (strcmp(uname, "chosen") != 0))
>> >>> > > - return 1;
>> >>> > > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
>> >>> > > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
>> >>> > > + return 1;
>> >>> > > + }
>> >> >
>> >> > Hmm, but xen_initial_domain() is false when xen isn't being used at all,
>> >> > so it feels to me like this is a bit too far-reaching and is basically
>> >> > claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
>> >> > "xen,hypervisor" or something?
>> >> >
>> >> > Mark, got any thoughts on this?
>> > The node has a compatible string, "xen,xen" per [1], which would tell us
>> > absolutely that xen is present. I'd be happy checking for that
>> > explicitly.
>> >
>> I think actually the xen_initial_domain is the result of the
>> fdt_find_hyper_node. If the compatible string "xen,xen" doesn't exist,
>> the xen_initial_domain() will return false and whatever the current node
>> is the above check will return 1 since the device tree is not empty.
>
> Right.
>
> xen_initial_domain implies both "xen,xen" and XENFEAT_dom0 (which is a
> feature retrieved by making a XENVER_get_features hypercall, see
> drivers/xen/features.c:xen_setup_features).
>
> So the following check:
>
> + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> + return 1;
>
> means that even if it's xen_initial_domain(), return error unless the
> node found is "hypervisor". In other words, even if
> xen_initial_domain(), no other nodes are allowed except /chosen and
> /hypervisor.
>
> This doesn't look far reaching to me, but yes, we could check explicitly
> for the node to be compatible "xen,xen", in addition to be named
> "hypervisor", even though the check is already done elsewhere
> (arch/arm/xen/enlighten.c).
>
> But I would keep it as it is.
>
The heuristic is there to decide whether some DTB image contains a
complete description of the platform, or only some data handed over by
the bootloader. Arguably, a DT containing both /chosen and /hypervisor
but nothing else can still not describe an actual platform, and
whether we execute under Xen or not is completely irrelevant.
So this should be sufficient imo
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2f98b9..d6d61e2e4d49 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -67,9 +67,10 @@ 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 the /hypervisor node.
*/
- if (depth == 1 && (strcmp(uname, "chosen") != 0))
+ if (depth == 1 && strcmp(uname, "chosen") != 0 &&
+ strcmp(uname, "hypervisor") != 0)
return 1;
return 0;
}
>> > In patch 11 fdt_find_hyper_node checks the compatible string. We could
>> > factor that out into a helper like is_xen_node(node) and use it here
>> > too.
>> >
>> I don't think so because we already check the compatible string before
>> and we could get the result simply via xen_initial_domain().
>
> We could add a comment saying xen_initial_domain() implies "xen,xen" or
> something.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 172+ messages in thread* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-31 12:42 ` Mark Rutland
0 siblings, 0 replies; 172+ messages in thread
From: Mark Rutland @ 2016-03-31 12:42 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Stefano Stabellini, Shannon Zhao, devicetree, linux-efi,
Catalin Marinas, Will Deacon, linux-kernel, Huangpeng (Peter),
julien.grall, Stefano Stabellini, Shannon Zhao, xen-devel,
linux-arm-kernel, David Vrabel
On Thu, Mar 31, 2016 at 01:44:08PM +0200, Ard Biesheuvel wrote:
> The heuristic is there to decide whether some DTB image contains a
> complete description of the platform, or only some data handed over by
> the bootloader. Arguably, a DT containing both /chosen and /hypervisor
> but nothing else can still not describe an actual platform, and
> whether we execute under Xen or not is completely irrelevant.
I disagree somewhat.
In general, a /hypervisor node may not be a Xen node, and could
potentially imply some platform description. As /hypervisor is a generic
name up for grabs by any hypervisor, we simply cannot make assumptions
about it.
As /chosen is a special reserved path that implies a particular binding
and has no compatible string, so checking its path alone is correct.
While we do check that the /hypervisor node is "xen,xen" compatible
elsewhere, the canonical mechanism of checking for a Xen node (as
opposed to any hypervisor's node) is to check the compatible string.
If we are going to handle nodes for other hypervisors while treating the
DTB as empty, we need code and discussion regarding said hypervisor.
Hence, for checking for a Xen /hypervisor node, I would prefer we
checked the compatible string rather than the path.
An is_xen_node() helper (which could also check that the path is
"/hypervisor") would avoid having redundant, subtly distinct ways of
checking, and would explicitly document precisely what we are checking
for.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 172+ messages in thread
* [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-31 12:42 ` Mark Rutland
0 siblings, 0 replies; 172+ messages in thread
From: Mark Rutland @ 2016-03-31 12:42 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 31, 2016 at 01:44:08PM +0200, Ard Biesheuvel wrote:
> The heuristic is there to decide whether some DTB image contains a
> complete description of the platform, or only some data handed over by
> the bootloader. Arguably, a DT containing both /chosen and /hypervisor
> but nothing else can still not describe an actual platform, and
> whether we execute under Xen or not is completely irrelevant.
I disagree somewhat.
In general, a /hypervisor node may not be a Xen node, and could
potentially imply some platform description. As /hypervisor is a generic
name up for grabs by any hypervisor, we simply cannot make assumptions
about it.
As /chosen is a special reserved path that implies a particular binding
and has no compatible string, so checking its path alone is correct.
While we do check that the /hypervisor node is "xen,xen" compatible
elsewhere, the canonical mechanism of checking for a Xen node (as
opposed to any hypervisor's node) is to check the compatible string.
If we are going to handle nodes for other hypervisors while treating the
DTB as empty, we need code and discussion regarding said hypervisor.
Hence, for checking for a Xen /hypervisor node, I would prefer we
checked the compatible string rather than the path.
An is_xen_node() helper (which could also check that the path is
"/hypervisor") would avoid having redundant, subtly distinct ways of
checking, and would explicitly document precisely what we are checking
for.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-03-31 12:42 ` Mark Rutland
0 siblings, 0 replies; 172+ messages in thread
From: Mark Rutland @ 2016-03-31 12:42 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Stefano Stabellini, Shannon Zhao,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, Catalin Marinas, Will Deacon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Huangpeng (Peter),
julien.grall-5wv7dgnIgG8, Stefano Stabellini, Shannon Zhao,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Vrabel
On Thu, Mar 31, 2016 at 01:44:08PM +0200, Ard Biesheuvel wrote:
> The heuristic is there to decide whether some DTB image contains a
> complete description of the platform, or only some data handed over by
> the bootloader. Arguably, a DT containing both /chosen and /hypervisor
> but nothing else can still not describe an actual platform, and
> whether we execute under Xen or not is completely irrelevant.
I disagree somewhat.
In general, a /hypervisor node may not be a Xen node, and could
potentially imply some platform description. As /hypervisor is a generic
name up for grabs by any hypervisor, we simply cannot make assumptions
about it.
As /chosen is a special reserved path that implies a particular binding
and has no compatible string, so checking its path alone is correct.
While we do check that the /hypervisor node is "xen,xen" compatible
elsewhere, the canonical mechanism of checking for a Xen node (as
opposed to any hypervisor's node) is to check the compatible string.
If we are going to handle nodes for other hypervisors while treating the
DTB as empty, we need code and discussion regarding said hypervisor.
Hence, for checking for a Xen /hypervisor node, I would prefer we
checked the compatible string rather than the path.
An is_xen_node() helper (which could also check that the path is
"/hypervisor") would avoid having redundant, subtly distinct ways of
checking, and would explicitly document precisely what we are checking
for.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
2016-03-31 12:42 ` Mark Rutland
(?)
@ 2016-04-01 9:25 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-04-01 9:25 UTC (permalink / raw)
To: Mark Rutland, Ard Biesheuvel
Cc: Stefano Stabellini, devicetree, linux-efi, Catalin Marinas,
Will Deacon, linux-kernel, Huangpeng (Peter),
julien.grall, Stefano Stabellini, Shannon Zhao, xen-devel,
linux-arm-kernel, David Vrabel
On 2016/3/31 20:42, Mark Rutland wrote:
> On Thu, Mar 31, 2016 at 01:44:08PM +0200, Ard Biesheuvel wrote:
>> > The heuristic is there to decide whether some DTB image contains a
>> > complete description of the platform, or only some data handed over by
>> > the bootloader. Arguably, a DT containing both /chosen and /hypervisor
>> > but nothing else can still not describe an actual platform, and
>> > whether we execute under Xen or not is completely irrelevant.
> I disagree somewhat.
>
> In general, a /hypervisor node may not be a Xen node, and could
> potentially imply some platform description. As /hypervisor is a generic
> name up for grabs by any hypervisor, we simply cannot make assumptions
> about it.
>
> As /chosen is a special reserved path that implies a particular binding
> and has no compatible string, so checking its path alone is correct.
>
> While we do check that the /hypervisor node is "xen,xen" compatible
> elsewhere, the canonical mechanism of checking for a Xen node (as
> opposed to any hypervisor's node) is to check the compatible string.
>
> If we are going to handle nodes for other hypervisors while treating the
> DTB as empty, we need code and discussion regarding said hypervisor.
>
> Hence, for checking for a Xen /hypervisor node, I would prefer we
> checked the compatible string rather than the path.
>
> An is_xen_node() helper (which could also check that the path is
> "/hypervisor") would avoid having redundant, subtly distinct ways of
> checking, and would explicitly document precisely what we are checking
> for.
So if we use is_xen_node(), do we need to call xen_initial_domain()
again? I still think here is_xen_node() and xen_initial_domain() have
same meaning. Why do we need that?
If it really needs is_xen_node(), I will not factor
fdt_find_hyper_node() in patch 11 since it uses flat DT while here it's
going to use unflatten DT.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread
* [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-04-01 9:25 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-04-01 9:25 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/3/31 20:42, Mark Rutland wrote:
> On Thu, Mar 31, 2016 at 01:44:08PM +0200, Ard Biesheuvel wrote:
>> > The heuristic is there to decide whether some DTB image contains a
>> > complete description of the platform, or only some data handed over by
>> > the bootloader. Arguably, a DT containing both /chosen and /hypervisor
>> > but nothing else can still not describe an actual platform, and
>> > whether we execute under Xen or not is completely irrelevant.
> I disagree somewhat.
>
> In general, a /hypervisor node may not be a Xen node, and could
> potentially imply some platform description. As /hypervisor is a generic
> name up for grabs by any hypervisor, we simply cannot make assumptions
> about it.
>
> As /chosen is a special reserved path that implies a particular binding
> and has no compatible string, so checking its path alone is correct.
>
> While we do check that the /hypervisor node is "xen,xen" compatible
> elsewhere, the canonical mechanism of checking for a Xen node (as
> opposed to any hypervisor's node) is to check the compatible string.
>
> If we are going to handle nodes for other hypervisors while treating the
> DTB as empty, we need code and discussion regarding said hypervisor.
>
> Hence, for checking for a Xen /hypervisor node, I would prefer we
> checked the compatible string rather than the path.
>
> An is_xen_node() helper (which could also check that the path is
> "/hypervisor") would avoid having redundant, subtly distinct ways of
> checking, and would explicitly document precisely what we are checking
> for.
So if we use is_xen_node(), do we need to call xen_initial_domain()
again? I still think here is_xen_node() and xen_initial_domain() have
same meaning. Why do we need that?
If it really needs is_xen_node(), I will not factor
fdt_find_hyper_node() in patch 11 since it uses flat DT while here it's
going to use unflatten DT.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-04-01 9:25 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-04-01 9:25 UTC (permalink / raw)
To: Mark Rutland, Ard Biesheuvel
Cc: Stefano Stabellini, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, Catalin Marinas, Will Deacon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Huangpeng (Peter),
julien.grall-5wv7dgnIgG8, Stefano Stabellini, Shannon Zhao,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Vrabel
On 2016/3/31 20:42, Mark Rutland wrote:
> On Thu, Mar 31, 2016 at 01:44:08PM +0200, Ard Biesheuvel wrote:
>> > The heuristic is there to decide whether some DTB image contains a
>> > complete description of the platform, or only some data handed over by
>> > the bootloader. Arguably, a DT containing both /chosen and /hypervisor
>> > but nothing else can still not describe an actual platform, and
>> > whether we execute under Xen or not is completely irrelevant.
> I disagree somewhat.
>
> In general, a /hypervisor node may not be a Xen node, and could
> potentially imply some platform description. As /hypervisor is a generic
> name up for grabs by any hypervisor, we simply cannot make assumptions
> about it.
>
> As /chosen is a special reserved path that implies a particular binding
> and has no compatible string, so checking its path alone is correct.
>
> While we do check that the /hypervisor node is "xen,xen" compatible
> elsewhere, the canonical mechanism of checking for a Xen node (as
> opposed to any hypervisor's node) is to check the compatible string.
>
> If we are going to handle nodes for other hypervisors while treating the
> DTB as empty, we need code and discussion regarding said hypervisor.
>
> Hence, for checking for a Xen /hypervisor node, I would prefer we
> checked the compatible string rather than the path.
>
> An is_xen_node() helper (which could also check that the path is
> "/hypervisor") would avoid having redundant, subtly distinct ways of
> checking, and would explicitly document precisely what we are checking
> for.
So if we use is_xen_node(), do we need to call xen_initial_domain()
again? I still think here is_xen_node() and xen_initial_domain() have
same meaning. Why do we need that?
If it really needs is_xen_node(), I will not factor
fdt_find_hyper_node() in patch 11 since it uses flat DT while here it's
going to use unflatten DT.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-04-01 9:32 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-04-01 9:32 UTC (permalink / raw)
To: Mark Rutland, Ard Biesheuvel
Cc: Stefano Stabellini, devicetree, linux-efi, Catalin Marinas,
Will Deacon, linux-kernel, Huangpeng (Peter),
julien.grall, Stefano Stabellini, Shannon Zhao, xen-devel,
linux-arm-kernel, David Vrabel
On 2016/4/1 17:25, Shannon Zhao wrote:
> If it really needs is_xen_node(), I will not factor
> fdt_find_hyper_node() in patch 11 since it uses flat DT while here it's
> going to use unflatten DT.
Sorry, I'm wrong. They both use flat DT. But it's no need to factor
fdt_find_hyper_node() since is_xen_node is very simple like below I think.
of_flat_dt_is_compatible(node, "xen,xen");
And maybe it cloud directly use above check in dt_scan_depth1_nodes.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread
* [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-04-01 9:32 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-04-01 9:32 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/4/1 17:25, Shannon Zhao wrote:
> If it really needs is_xen_node(), I will not factor
> fdt_find_hyper_node() in patch 11 since it uses flat DT while here it's
> going to use unflatten DT.
Sorry, I'm wrong. They both use flat DT. But it's no need to factor
fdt_find_hyper_node() since is_xen_node is very simple like below I think.
of_flat_dt_is_compatible(node, "xen,xen");
And maybe it cloud directly use above check in dt_scan_depth1_nodes.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
@ 2016-04-01 9:32 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-04-01 9:32 UTC (permalink / raw)
To: Mark Rutland, Ard Biesheuvel
Cc: Stefano Stabellini, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, Catalin Marinas, Will Deacon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Huangpeng (Peter),
julien.grall-5wv7dgnIgG8, Stefano Stabellini, Shannon Zhao,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Vrabel
On 2016/4/1 17:25, Shannon Zhao wrote:
> If it really needs is_xen_node(), I will not factor
> fdt_find_hyper_node() in patch 11 since it uses flat DT while here it's
> going to use unflatten DT.
Sorry, I'm wrong. They both use flat DT. But it's no need to factor
fdt_find_hyper_node() since is_xen_node is very simple like below I think.
of_flat_dt_is_compatible(node, "xen,xen");
And maybe it cloud directly use above check in dt_scan_depth1_nodes.
Thanks,
--
Shannon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
2016-04-01 9:25 ` Shannon Zhao
` (2 preceding siblings ...)
(?)
@ 2016-04-01 9:32 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-04-01 9:32 UTC (permalink / raw)
To: Mark Rutland, Ard Biesheuvel
Cc: devicetree, linux-efi, Stefano Stabellini, Catalin Marinas,
Will Deacon, linux-kernel, Huangpeng (Peter),
julien.grall, Stefano Stabellini, Shannon Zhao, xen-devel,
linux-arm-kernel, David Vrabel
On 2016/4/1 17:25, Shannon Zhao wrote:
> If it really needs is_xen_node(), I will not factor
> fdt_find_hyper_node() in patch 11 since it uses flat DT while here it's
> going to use unflatten DT.
Sorry, I'm wrong. They both use flat DT. But it's no need to factor
fdt_find_hyper_node() since is_xen_node is very simple like below I think.
of_flat_dt_is_compatible(node, "xen,xen");
And maybe it cloud directly use above check in dt_scan_depth1_nodes.
Thanks,
--
Shannon
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
2016-03-31 12:42 ` Mark Rutland
` (2 preceding siblings ...)
(?)
@ 2016-04-01 9:25 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-04-01 9:25 UTC (permalink / raw)
To: Mark Rutland, Ard Biesheuvel
Cc: devicetree, linux-efi, Stefano Stabellini, Catalin Marinas,
Will Deacon, linux-kernel, Huangpeng (Peter),
julien.grall, Stefano Stabellini, Shannon Zhao, xen-devel,
linux-arm-kernel, David Vrabel
On 2016/3/31 20:42, Mark Rutland wrote:
> On Thu, Mar 31, 2016 at 01:44:08PM +0200, Ard Biesheuvel wrote:
>> > The heuristic is there to decide whether some DTB image contains a
>> > complete description of the platform, or only some data handed over by
>> > the bootloader. Arguably, a DT containing both /chosen and /hypervisor
>> > but nothing else can still not describe an actual platform, and
>> > whether we execute under Xen or not is completely irrelevant.
> I disagree somewhat.
>
> In general, a /hypervisor node may not be a Xen node, and could
> potentially imply some platform description. As /hypervisor is a generic
> name up for grabs by any hypervisor, we simply cannot make assumptions
> about it.
>
> As /chosen is a special reserved path that implies a particular binding
> and has no compatible string, so checking its path alone is correct.
>
> While we do check that the /hypervisor node is "xen,xen" compatible
> elsewhere, the canonical mechanism of checking for a Xen node (as
> opposed to any hypervisor's node) is to check the compatible string.
>
> If we are going to handle nodes for other hypervisors while treating the
> DTB as empty, we need code and discussion regarding said hypervisor.
>
> Hence, for checking for a Xen /hypervisor node, I would prefer we
> checked the compatible string rather than the path.
>
> An is_xen_node() helper (which could also check that the path is
> "/hypervisor") would avoid having redundant, subtly distinct ways of
> checking, and would explicitly document precisely what we are checking
> for.
So if we use is_xen_node(), do we need to call xen_initial_domain()
again? I still think here is_xen_node() and xen_initial_domain() have
same meaning. Why do we need that?
If it really needs is_xen_node(), I will not factor
fdt_find_hyper_node() in patch 11 since it uses flat DT while here it's
going to use unflatten DT.
Thanks,
--
Shannon
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
2016-03-31 11:44 ` Ard Biesheuvel
` (2 preceding siblings ...)
(?)
@ 2016-03-31 12:42 ` Mark Rutland
-1 siblings, 0 replies; 172+ messages in thread
From: Mark Rutland @ 2016-03-31 12:42 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: devicetree, linux-efi, Stefano Stabellini, Catalin Marinas,
Will Deacon, linux-kernel, Huangpeng (Peter),
julien.grall, Stefano Stabellini, Shannon Zhao, Shannon Zhao,
xen-devel, linux-arm-kernel, David Vrabel
On Thu, Mar 31, 2016 at 01:44:08PM +0200, Ard Biesheuvel wrote:
> The heuristic is there to decide whether some DTB image contains a
> complete description of the platform, or only some data handed over by
> the bootloader. Arguably, a DT containing both /chosen and /hypervisor
> but nothing else can still not describe an actual platform, and
> whether we execute under Xen or not is completely irrelevant.
I disagree somewhat.
In general, a /hypervisor node may not be a Xen node, and could
potentially imply some platform description. As /hypervisor is a generic
name up for grabs by any hypervisor, we simply cannot make assumptions
about it.
As /chosen is a special reserved path that implies a particular binding
and has no compatible string, so checking its path alone is correct.
While we do check that the /hypervisor node is "xen,xen" compatible
elsewhere, the canonical mechanism of checking for a Xen node (as
opposed to any hypervisor's node) is to check the compatible string.
If we are going to handle nodes for other hypervisors while treating the
DTB as empty, we need code and discussion regarding said hypervisor.
Hence, for checking for a Xen /hypervisor node, I would prefer we
checked the compatible string rather than the path.
An is_xen_node() helper (which could also check that the path is
"/hypervisor") would avoid having redundant, subtly distinct ways of
checking, and would explicitly document precisely what we are checking
for.
Thanks,
Mark.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
2016-03-31 11:04 ` Stefano Stabellini
` (2 preceding siblings ...)
(?)
@ 2016-03-31 11:44 ` Ard Biesheuvel
-1 siblings, 0 replies; 172+ messages in thread
From: Ard Biesheuvel @ 2016-03-31 11:44 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Mark Rutland, devicetree, linux-efi, Catalin Marinas,
Will Deacon, linux-kernel, Huangpeng (Peter),
julien.grall, Stefano Stabellini, Shannon Zhao, Shannon Zhao,
xen-devel, linux-arm-kernel, David Vrabel
On 31 March 2016 at 13:04, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 30 Mar 2016, Shannon Zhao wrote:
>> Hi Will, Mark,
>>
>> On 2016/3/30 0:31, Mark Rutland wrote:
>> > On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
>> >> > On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
>> >>> > > 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 <shannon.zhao@linaro.org>
>> >>> > > Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> >>> > > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
>> >>> > > ---
>> >>> > > arch/arm64/kernel/acpi.c | 12 ++++++++----
>> >>> > > 1 file changed, 8 insertions(+), 4 deletions(-)
>> >>> > >
>> >>> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> >>> > > index d1ce8e2..4e92be0 100644
>> >>> > > --- a/arch/arm64/kernel/acpi.c
>> >>> > > +++ b/arch/arm64/kernel/acpi.c
>> >>> > > @@ -67,10 +67,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 /hypervisor node when running on Xen.
>> >>> > > */
>> >>> > > - if (depth == 1 && (strcmp(uname, "chosen") != 0))
>> >>> > > - return 1;
>> >>> > > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
>> >>> > > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
>> >>> > > + return 1;
>> >>> > > + }
>> >> >
>> >> > Hmm, but xen_initial_domain() is false when xen isn't being used at all,
>> >> > so it feels to me like this is a bit too far-reaching and is basically
>> >> > claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
>> >> > "xen,hypervisor" or something?
>> >> >
>> >> > Mark, got any thoughts on this?
>> > The node has a compatible string, "xen,xen" per [1], which would tell us
>> > absolutely that xen is present. I'd be happy checking for that
>> > explicitly.
>> >
>> I think actually the xen_initial_domain is the result of the
>> fdt_find_hyper_node. If the compatible string "xen,xen" doesn't exist,
>> the xen_initial_domain() will return false and whatever the current node
>> is the above check will return 1 since the device tree is not empty.
>
> Right.
>
> xen_initial_domain implies both "xen,xen" and XENFEAT_dom0 (which is a
> feature retrieved by making a XENVER_get_features hypercall, see
> drivers/xen/features.c:xen_setup_features).
>
> So the following check:
>
> + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> + return 1;
>
> means that even if it's xen_initial_domain(), return error unless the
> node found is "hypervisor". In other words, even if
> xen_initial_domain(), no other nodes are allowed except /chosen and
> /hypervisor.
>
> This doesn't look far reaching to me, but yes, we could check explicitly
> for the node to be compatible "xen,xen", in addition to be named
> "hypervisor", even though the check is already done elsewhere
> (arch/arm/xen/enlighten.c).
>
> But I would keep it as it is.
>
The heuristic is there to decide whether some DTB image contains a
complete description of the platform, or only some data handed over by
the bootloader. Arguably, a DT containing both /chosen and /hypervisor
but nothing else can still not describe an actual platform, and
whether we execute under Xen or not is completely irrelevant.
So this should be sufficient imo
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2f98b9..d6d61e2e4d49 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -67,9 +67,10 @@ 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 the /hypervisor node.
*/
- if (depth == 1 && (strcmp(uname, "chosen") != 0))
+ if (depth == 1 && strcmp(uname, "chosen") != 0 &&
+ strcmp(uname, "hypervisor") != 0)
return 1;
return 0;
}
>> > In patch 11 fdt_find_hyper_node checks the compatible string. We could
>> > factor that out into a helper like is_xen_node(node) and use it here
>> > too.
>> >
>> I don't think so because we already check the compatible string before
>> and we could get the result simply via xen_initial_domain().
>
> We could add a comment saying xen_initial_domain() implies "xen,xen" or
> something.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread
* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
2016-03-29 16:31 ` Mark Rutland
` (2 preceding siblings ...)
(?)
@ 2016-03-30 7:19 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-30 7:19 UTC (permalink / raw)
To: Mark Rutland, Will Deacon
Cc: devicetree, linux-efi, catalin.marinas, linux-kernel,
peter.huangpeng, julien.grall, stefano.stabellini, Shannon Zhao,
xen-devel, linux-arm-kernel, david.vrabel
Hi Will, Mark,
On 2016/3/30 0:31, Mark Rutland wrote:
> On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
>> > On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
>>> > > 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 <shannon.zhao@linaro.org>
>>> > > Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> > > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> > > ---
>>> > > arch/arm64/kernel/acpi.c | 12 ++++++++----
>>> > > 1 file changed, 8 insertions(+), 4 deletions(-)
>>> > >
>>> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>>> > > index d1ce8e2..4e92be0 100644
>>> > > --- a/arch/arm64/kernel/acpi.c
>>> > > +++ b/arch/arm64/kernel/acpi.c
>>> > > @@ -67,10 +67,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 /hypervisor node when running on Xen.
>>> > > */
>>> > > - if (depth == 1 && (strcmp(uname, "chosen") != 0))
>>> > > - return 1;
>>> > > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
>>> > > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
>>> > > + return 1;
>>> > > + }
>> >
>> > Hmm, but xen_initial_domain() is false when xen isn't being used at all,
>> > so it feels to me like this is a bit too far-reaching and is basically
>> > claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
>> > "xen,hypervisor" or something?
>> >
>> > Mark, got any thoughts on this?
> The node has a compatible string, "xen,xen" per [1], which would tell us
> absolutely that xen is present. I'd be happy checking for that
> explicitly.
>
I think actually the xen_initial_domain is the result of the
fdt_find_hyper_node. If the compatible string "xen,xen" doesn't exist,
the xen_initial_domain() will return false and whatever the current node
is the above check will return 1 since the device tree is not empty.
> In patch 11 fdt_find_hyper_node checks the compatible string. We could
> factor that out into a helper like is_xen_node(node) and use it here
> too.
>
I don't think so because we already check the compatible string before
and we could get the result simply via xen_initial_domain().
Thanks,
--
Shannon
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
2016-03-24 14:44 ` Shannon Zhao
` (4 preceding siblings ...)
(?)
@ 2016-03-29 16:18 ` Will Deacon
-1 siblings, 0 replies; 172+ messages in thread
From: Will Deacon @ 2016-03-29 16:18 UTC (permalink / raw)
To: Shannon Zhao
Cc: mark.rutland, devicetree, linux-efi, catalin.marinas,
linux-kernel, peter.huangpeng, julien.grall, stefano.stabellini,
david.vrabel, zhaoshenglong, xen-devel, linux-arm-kernel
On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
> 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 <shannon.zhao@linaro.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/arm64/kernel/acpi.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index d1ce8e2..4e92be0 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -67,10 +67,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 /hypervisor node when running on Xen.
> */
> - if (depth == 1 && (strcmp(uname, "chosen") != 0))
> - return 1;
> + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> + return 1;
> + }
Hmm, but xen_initial_domain() is false when xen isn't being used at all,
so it feels to me like this is a bit too far-reaching and is basically
claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
"xen,hypervisor" or something?
Mark, got any thoughts on this?
Will
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread
* [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
2016-03-24 14:44 ` Shannon Zhao
` (20 preceding siblings ...)
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, shannon.zhao,
zhaoshenglong, xen-devel
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 <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2..4e92be0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -67,10 +67,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 /hypervisor node when running on Xen.
*/
- if (depth == 1 && (strcmp(uname, "chosen") != 0))
- return 1;
+ if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
+ if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
+ return 1;
+ }
+
return 0;
}
@@ -184,7 +187,8 @@ 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)
+ * - the device tree is not empty (it has more than just a /chosen node,
+ * and a /hypervisor node when running on Xen)
* and ACPI has not been force enabled (acpi=force)
*/
if (param_acpi_off ||
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms
2016-03-24 14:44 ` Shannon Zhao
` (21 preceding siblings ...)
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, Rob Herring, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, shannon.zhao,
zhaoshenglong, xen-devel
Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
scan this to get the UEFI information.
CC: Rob Herring <robh@kernel.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
Documentation/devicetree/bindings/arm/xen.txt | 33 +++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
index 0f7b9c2..6f83f76 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -15,6 +15,26 @@ 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 populates the FDT "uefi" node
+under /hypervisor with following parameters:
+
+________________________________________________________________________________
+Name | Size | Description
+================================================================================
+xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
+ | | Table.
+--------------------------------------------------------------------------------
+xen,uefi-mmap-start | 64-bit | Guest 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 +42,17 @@ 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>;
+ };
};
+
+The format and meaning of the "xen,uefi-*" parameters are similar to those in
+Documentation/arm/uefi.txt, which are provided by the regular UEFI stub. However
+they differ because they are provided by the Xen hypervisor, together with a set
+of UEFI runtime services implemented via hypercalls, see
+http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao, Rob Herring
Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
scan this to get the UEFI information.
CC: Rob Herring <robh@kernel.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
Documentation/devicetree/bindings/arm/xen.txt | 33 +++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
index 0f7b9c2..6f83f76 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -15,6 +15,26 @@ 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 populates the FDT "uefi" node
+under /hypervisor with following parameters:
+
+________________________________________________________________________________
+Name | Size | Description
+================================================================================
+xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
+ | | Table.
+--------------------------------------------------------------------------------
+xen,uefi-mmap-start | 64-bit | Guest 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 +42,17 @@ 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>;
+ };
};
+
+The format and meaning of the "xen,uefi-*" parameters are similar to those in
+Documentation/arm/uefi.txt, which are provided by the regular UEFI stub. However
+they differ because they are provided by the Xen hypervisor, together with a set
+of UEFI runtime services implemented via hypercalls, see
+http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
scan this to get the UEFI information.
CC: Rob Herring <robh@kernel.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
Documentation/devicetree/bindings/arm/xen.txt | 33 +++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
index 0f7b9c2..6f83f76 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -15,6 +15,26 @@ 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 populates the FDT "uefi" node
+under /hypervisor with following parameters:
+
+________________________________________________________________________________
+Name | Size | Description
+================================================================================
+xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
+ | | Table.
+--------------------------------------------------------------------------------
+xen,uefi-mmap-start | 64-bit | Guest 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 +42,17 @@ 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>;
+ };
};
+
+The format and meaning of the "xen,uefi-*" parameters are similar to those in
+Documentation/arm/uefi.txt, which are provided by the regular UEFI stub. However
+they differ because they are provided by the Xen hypervisor, together with a set
+of UEFI runtime services implemented via hypercalls, see
+http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, julien.grall-5wv7dgnIgG8,
peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
zhaoshenglong-hv44wF8Li93QT0dZR+AlfA,
shannon.zhao-QSEj5FYQhm4dnm+yROfE0A, Rob Herring
Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
scan this to get the UEFI information.
CC: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
---
Documentation/devicetree/bindings/arm/xen.txt | 33 +++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
index 0f7b9c2..6f83f76 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -15,6 +15,26 @@ 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 populates the FDT "uefi" node
+under /hypervisor with following parameters:
+
+________________________________________________________________________________
+Name | Size | Description
+================================================================================
+xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
+ | | Table.
+--------------------------------------------------------------------------------
+xen,uefi-mmap-start | 64-bit | Guest 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 +42,17 @@ 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>;
+ };
};
+
+The format and meaning of the "xen,uefi-*" parameters are similar to those in
+Documentation/arm/uefi.txt, which are provided by the regular UEFI stub. However
+they differ because they are provided by the Xen hypervisor, together with a set
+of UEFI runtime services implemented via hypercalls, see
+http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* Re: [PATCH v7 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms
2016-03-24 14:44 ` Shannon Zhao
(?)
(?)
@ 2016-03-29 17:21 ` Julien Grall
-1 siblings, 0 replies; 172+ messages in thread
From: Julien Grall @ 2016-03-29 17:21 UTC (permalink / raw)
To: Shannon Zhao, linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, Rob Herring, catalin.marinas, will.deacon,
peter.huangpeng, linux-kernel, zhaoshenglong, xen-devel
Hi Shannon,
On 24/03/16 14:44, Shannon Zhao wrote:
> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
> scan this to get the UEFI information.
>
> CC: Rob Herring <robh@kernel.org>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
> Documentation/devicetree/bindings/arm/xen.txt | 33 +++++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> index 0f7b9c2..6f83f76 100644
> --- a/Documentation/devicetree/bindings/arm/xen.txt
> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> @@ -15,6 +15,26 @@ the following properties:
> - interrupts: the interrupt used by Xen to inject event notifications.
> A GIC node is also required.
You need to update the recent of the document based on the changes you
made in the Xen one. See [1].
> +To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
> +under /hypervisor with following parameters:
> +
> +________________________________________________________________________________
> +Name | Size | Description
> +================================================================================
> +xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
> + | | Table.
> +--------------------------------------------------------------------------------
> +xen,uefi-mmap-start | 64-bit | Guest 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 +42,17 @@ 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>;
> + };
> };
> +
> +The format and meaning of the "xen,uefi-*" parameters are similar to those in
> +Documentation/arm/uefi.txt, which are provided by the regular UEFI stub. However
> +they differ because they are provided by the Xen hypervisor, together with a set
> +of UEFI runtime services implemented via hypercalls, see
> +http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
>
Regards,
[1]
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03413.html
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms
@ 2016-03-29 17:21 ` Julien Grall
0 siblings, 0 replies; 172+ messages in thread
From: Julien Grall @ 2016-03-29 17:21 UTC (permalink / raw)
To: Shannon Zhao, linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, peter.huangpeng, xen-devel, zhaoshenglong,
Rob Herring
Hi Shannon,
On 24/03/16 14:44, Shannon Zhao wrote:
> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
> scan this to get the UEFI information.
>
> CC: Rob Herring <robh@kernel.org>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
> Documentation/devicetree/bindings/arm/xen.txt | 33 +++++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> index 0f7b9c2..6f83f76 100644
> --- a/Documentation/devicetree/bindings/arm/xen.txt
> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> @@ -15,6 +15,26 @@ the following properties:
> - interrupts: the interrupt used by Xen to inject event notifications.
> A GIC node is also required.
You need to update the recent of the document based on the changes you
made in the Xen one. See [1].
> +To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
> +under /hypervisor with following parameters:
> +
> +________________________________________________________________________________
> +Name | Size | Description
> +================================================================================
> +xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
> + | | Table.
> +--------------------------------------------------------------------------------
> +xen,uefi-mmap-start | 64-bit | Guest 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 +42,17 @@ 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>;
> + };
> };
> +
> +The format and meaning of the "xen,uefi-*" parameters are similar to those in
> +Documentation/arm/uefi.txt, which are provided by the regular UEFI stub. However
> +they differ because they are provided by the Xen hypervisor, together with a set
> +of UEFI runtime services implemented via hypercalls, see
> +http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
>
Regards,
[1]
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03413.html
--
Julien Grall
^ permalink raw reply [flat|nested] 172+ messages in thread* [PATCH v7 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms
@ 2016-03-29 17:21 ` Julien Grall
0 siblings, 0 replies; 172+ messages in thread
From: Julien Grall @ 2016-03-29 17:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Shannon,
On 24/03/16 14:44, Shannon Zhao wrote:
> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
> scan this to get the UEFI information.
>
> CC: Rob Herring <robh@kernel.org>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
> Documentation/devicetree/bindings/arm/xen.txt | 33 +++++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> index 0f7b9c2..6f83f76 100644
> --- a/Documentation/devicetree/bindings/arm/xen.txt
> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> @@ -15,6 +15,26 @@ the following properties:
> - interrupts: the interrupt used by Xen to inject event notifications.
> A GIC node is also required.
You need to update the recent of the document based on the changes you
made in the Xen one. See [1].
> +To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
> +under /hypervisor with following parameters:
> +
> +________________________________________________________________________________
> +Name | Size | Description
> +================================================================================
> +xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
> + | | Table.
> +--------------------------------------------------------------------------------
> +xen,uefi-mmap-start | 64-bit | Guest 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 +42,17 @@ 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>;
> + };
> };
> +
> +The format and meaning of the "xen,uefi-*" parameters are similar to those in
> +Documentation/arm/uefi.txt, which are provided by the regular UEFI stub. However
> +they differ because they are provided by the Xen hypervisor, together with a set
> +of UEFI runtime services implemented via hypercalls, see
> +http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
>
Regards,
[1]
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03413.html
--
Julien Grall
^ permalink raw reply [flat|nested] 172+ messages in thread* Re: [PATCH v7 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms
@ 2016-03-29 17:21 ` Julien Grall
0 siblings, 0 replies; 172+ messages in thread
From: Julien Grall @ 2016-03-29 17:21 UTC (permalink / raw)
To: Shannon Zhao, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
zhaoshenglong-hv44wF8Li93QT0dZR+AlfA, Rob Herring
Hi Shannon,
On 24/03/16 14:44, Shannon Zhao wrote:
> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
> scan this to get the UEFI information.
>
> CC: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/arm/xen.txt | 33 +++++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> index 0f7b9c2..6f83f76 100644
> --- a/Documentation/devicetree/bindings/arm/xen.txt
> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> @@ -15,6 +15,26 @@ the following properties:
> - interrupts: the interrupt used by Xen to inject event notifications.
> A GIC node is also required.
You need to update the recent of the document based on the changes you
made in the Xen one. See [1].
> +To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
> +under /hypervisor with following parameters:
> +
> +________________________________________________________________________________
> +Name | Size | Description
> +================================================================================
> +xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
> + | | Table.
> +--------------------------------------------------------------------------------
> +xen,uefi-mmap-start | 64-bit | Guest 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 +42,17 @@ 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>;
> + };
> };
> +
> +The format and meaning of the "xen,uefi-*" parameters are similar to those in
> +Documentation/arm/uefi.txt, which are provided by the regular UEFI stub. However
> +they differ because they are provided by the Xen hypervisor, together with a set
> +of UEFI runtime services implemented via hypercalls, see
> +http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
>
Regards,
[1]
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03413.html
--
Julien Grall
^ permalink raw reply [flat|nested] 172+ messages in thread
* [PATCH v7 14/17] XEN: EFI: Move x86 specific codes to architecture directory
2016-03-24 14:44 ` Shannon Zhao
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao
Move x86 specific codes to architecture directory and export those EFI
runtime service functions. This will be useful for initializing runtime
service on ARM later.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/x86/xen/efi.c | 112 ++++++++++++++++++++++++++++++++
drivers/xen/efi.c | 174 ++++++++++----------------------------------------
include/xen/xen-ops.h | 30 ++++++---
3 files changed, 168 insertions(+), 148 deletions(-)
diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index be14cc3..86527f1 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -20,10 +20,122 @@
#include <linux/init.h>
#include <linux/string.h>
+#include <xen/xen.h>
#include <xen/xen-ops.h>
+#include <xen/interface/platform.h>
#include <asm/page.h>
#include <asm/setup.h>
+#include <asm/xen/hypercall.h>
+
+static efi_char16_t vendor[100] __initdata;
+
+static efi_system_table_t efi_systab_xen __initdata = {
+ .hdr = {
+ .signature = EFI_SYSTEM_TABLE_SIGNATURE,
+ .revision = 0, /* Initialized later. */
+ .headersize = 0, /* Ignored by Linux Kernel. */
+ .crc32 = 0, /* Ignored by Linux Kernel. */
+ .reserved = 0
+ },
+ .fw_vendor = EFI_INVALID_TABLE_ADDR, /* Initialized later. */
+ .fw_revision = 0, /* Initialized later. */
+ .con_in_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .con_in = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .con_out_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .con_out = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .stderr_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .stderr = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .runtime = (efi_runtime_services_t *)EFI_INVALID_TABLE_ADDR,
+ /* Not used under Xen. */
+ .boottime = (efi_boot_services_t *)EFI_INVALID_TABLE_ADDR,
+ /* Not used under Xen. */
+ .nr_tables = 0, /* Initialized later. */
+ .tables = EFI_INVALID_TABLE_ADDR /* Initialized later. */
+};
+
+static const struct efi efi_xen __initconst = {
+ .systab = NULL, /* Initialized later. */
+ .runtime_version = 0, /* Initialized later. */
+ .mps = EFI_INVALID_TABLE_ADDR,
+ .acpi = EFI_INVALID_TABLE_ADDR,
+ .acpi20 = EFI_INVALID_TABLE_ADDR,
+ .smbios = EFI_INVALID_TABLE_ADDR,
+ .smbios3 = EFI_INVALID_TABLE_ADDR,
+ .sal_systab = EFI_INVALID_TABLE_ADDR,
+ .boot_info = EFI_INVALID_TABLE_ADDR,
+ .hcdp = EFI_INVALID_TABLE_ADDR,
+ .uga = EFI_INVALID_TABLE_ADDR,
+ .uv_systab = EFI_INVALID_TABLE_ADDR,
+ .fw_vendor = EFI_INVALID_TABLE_ADDR,
+ .runtime = EFI_INVALID_TABLE_ADDR,
+ .config_table = EFI_INVALID_TABLE_ADDR,
+ .get_time = xen_efi_get_time,
+ .set_time = xen_efi_set_time,
+ .get_wakeup_time = xen_efi_get_wakeup_time,
+ .set_wakeup_time = xen_efi_set_wakeup_time,
+ .get_variable = xen_efi_get_variable,
+ .get_next_variable = xen_efi_get_next_variable,
+ .set_variable = xen_efi_set_variable,
+ .query_variable_info = xen_efi_query_variable_info,
+ .update_capsule = xen_efi_update_capsule,
+ .query_capsule_caps = xen_efi_query_capsule_caps,
+ .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
+ .reset_system = NULL, /* Functionality provided by Xen. */
+ .set_virtual_address_map = NULL, /* Not used under Xen. */
+ .memmap = NULL, /* Not used under Xen. */
+ .flags = 0 /* Initialized later. */
+};
+
+static efi_system_table_t __init *xen_efi_probe(void)
+{
+ struct xen_platform_op op = {
+ .cmd = XENPF_firmware_info,
+ .u.firmware_info = {
+ .type = XEN_FW_EFI_INFO,
+ .index = XEN_FW_EFI_CONFIG_TABLE
+ }
+ };
+ union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+ if (!xen_initial_domain() || HYPERVISOR_platform_op(&op) < 0)
+ return NULL;
+
+ /* Here we know that Xen runs on EFI platform. */
+
+ efi = efi_xen;
+
+ efi_systab_xen.tables = info->cfg.addr;
+ efi_systab_xen.nr_tables = info->cfg.nent;
+
+ op.cmd = XENPF_firmware_info;
+ op.u.firmware_info.type = XEN_FW_EFI_INFO;
+ op.u.firmware_info.index = XEN_FW_EFI_VENDOR;
+ info->vendor.bufsz = sizeof(vendor);
+ set_xen_guest_handle(info->vendor.name, vendor);
+
+ if (HYPERVISOR_platform_op(&op) == 0) {
+ efi_systab_xen.fw_vendor = __pa_symbol(vendor);
+ efi_systab_xen.fw_revision = info->vendor.revision;
+ } else
+ efi_systab_xen.fw_vendor = __pa_symbol(L"UNKNOWN");
+
+ op.cmd = XENPF_firmware_info;
+ op.u.firmware_info.type = XEN_FW_EFI_INFO;
+ op.u.firmware_info.index = XEN_FW_EFI_VERSION;
+
+ if (HYPERVISOR_platform_op(&op) == 0)
+ efi_systab_xen.hdr.revision = info->version;
+
+ op.cmd = XENPF_firmware_info;
+ op.u.firmware_info.type = XEN_FW_EFI_INFO;
+ op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION;
+
+ if (HYPERVISOR_platform_op(&op) == 0)
+ efi.runtime_version = info->version;
+
+ return &efi_systab_xen;
+}
void __init xen_efi_init(void)
{
diff --git a/drivers/xen/efi.c b/drivers/xen/efi.c
index be7e56a..22f71ff 100644
--- a/drivers/xen/efi.c
+++ b/drivers/xen/efi.c
@@ -38,7 +38,7 @@
#define efi_data(op) (op.u.efi_runtime_call)
-static efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
+efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
{
struct xen_platform_op op = INIT_EFI_OP(get_time);
@@ -59,8 +59,9 @@ static efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_get_time);
-static efi_status_t xen_efi_set_time(efi_time_t *tm)
+efi_status_t xen_efi_set_time(efi_time_t *tm)
{
struct xen_platform_op op = INIT_EFI_OP(set_time);
@@ -72,10 +73,10 @@ static efi_status_t xen_efi_set_time(efi_time_t *tm)
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_set_time);
-static efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled,
- efi_bool_t *pending,
- efi_time_t *tm)
+efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, efi_bool_t *pending,
+ efi_time_t *tm)
{
struct xen_platform_op op = INIT_EFI_OP(get_wakeup_time);
@@ -95,8 +96,9 @@ static efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_get_wakeup_time);
-static efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
+efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
{
struct xen_platform_op op = INIT_EFI_OP(set_wakeup_time);
@@ -113,12 +115,11 @@ static efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_set_wakeup_time);
-static efi_status_t xen_efi_get_variable(efi_char16_t *name,
- efi_guid_t *vendor,
- u32 *attr,
- unsigned long *data_size,
- void *data)
+efi_status_t xen_efi_get_variable(efi_char16_t *name, efi_guid_t *vendor,
+ u32 *attr, unsigned long *data_size,
+ void *data)
{
struct xen_platform_op op = INIT_EFI_OP(get_variable);
@@ -138,10 +139,11 @@ static efi_status_t xen_efi_get_variable(efi_char16_t *name,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_get_variable);
-static efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
- efi_char16_t *name,
- efi_guid_t *vendor)
+efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
+ efi_char16_t *name,
+ efi_guid_t *vendor)
{
struct xen_platform_op op = INIT_EFI_OP(get_next_variable_name);
@@ -161,12 +163,11 @@ static efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_get_next_variable);
-static efi_status_t xen_efi_set_variable(efi_char16_t *name,
- efi_guid_t *vendor,
- u32 attr,
- unsigned long data_size,
- void *data)
+efi_status_t xen_efi_set_variable(efi_char16_t *name, efi_guid_t *vendor,
+ u32 attr, unsigned long data_size,
+ void *data)
{
struct xen_platform_op op = INIT_EFI_OP(set_variable);
@@ -183,11 +184,11 @@ static efi_status_t xen_efi_set_variable(efi_char16_t *name,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_set_variable);
-static efi_status_t xen_efi_query_variable_info(u32 attr,
- u64 *storage_space,
- u64 *remaining_space,
- u64 *max_variable_size)
+efi_status_t xen_efi_query_variable_info(u32 attr, u64 *storage_space,
+ u64 *remaining_space,
+ u64 *max_variable_size)
{
struct xen_platform_op op = INIT_EFI_OP(query_variable_info);
@@ -205,8 +206,9 @@ static efi_status_t xen_efi_query_variable_info(u32 attr,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_query_variable_info);
-static efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
+efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
{
struct xen_platform_op op = INIT_EFI_OP(get_next_high_monotonic_count);
@@ -217,10 +219,10 @@ static efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_get_next_high_mono_count);
-static efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
- unsigned long count,
- unsigned long sg_list)
+efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
+ unsigned long count, unsigned long sg_list)
{
struct xen_platform_op op = INIT_EFI_OP(update_capsule);
@@ -237,11 +239,11 @@ static efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_update_capsule);
-static efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
- unsigned long count,
- u64 *max_size,
- int *reset_type)
+efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
+ unsigned long count, u64 *max_size,
+ int *reset_type)
{
struct xen_platform_op op = INIT_EFI_OP(query_capsule_capabilities);
@@ -260,112 +262,4 @@ static efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
return efi_data(op).status;
}
-
-static efi_char16_t vendor[100] __initdata;
-
-static efi_system_table_t efi_systab_xen __initdata = {
- .hdr = {
- .signature = EFI_SYSTEM_TABLE_SIGNATURE,
- .revision = 0, /* Initialized later. */
- .headersize = 0, /* Ignored by Linux Kernel. */
- .crc32 = 0, /* Ignored by Linux Kernel. */
- .reserved = 0
- },
- .fw_vendor = EFI_INVALID_TABLE_ADDR, /* Initialized later. */
- .fw_revision = 0, /* Initialized later. */
- .con_in_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .con_in = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .con_out_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .con_out = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .stderr_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .stderr = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .runtime = (efi_runtime_services_t *)EFI_INVALID_TABLE_ADDR,
- /* Not used under Xen. */
- .boottime = (efi_boot_services_t *)EFI_INVALID_TABLE_ADDR,
- /* Not used under Xen. */
- .nr_tables = 0, /* Initialized later. */
- .tables = EFI_INVALID_TABLE_ADDR /* Initialized later. */
-};
-
-static const struct efi efi_xen __initconst = {
- .systab = NULL, /* Initialized later. */
- .runtime_version = 0, /* Initialized later. */
- .mps = EFI_INVALID_TABLE_ADDR,
- .acpi = EFI_INVALID_TABLE_ADDR,
- .acpi20 = EFI_INVALID_TABLE_ADDR,
- .smbios = EFI_INVALID_TABLE_ADDR,
- .smbios3 = EFI_INVALID_TABLE_ADDR,
- .sal_systab = EFI_INVALID_TABLE_ADDR,
- .boot_info = EFI_INVALID_TABLE_ADDR,
- .hcdp = EFI_INVALID_TABLE_ADDR,
- .uga = EFI_INVALID_TABLE_ADDR,
- .uv_systab = EFI_INVALID_TABLE_ADDR,
- .fw_vendor = EFI_INVALID_TABLE_ADDR,
- .runtime = EFI_INVALID_TABLE_ADDR,
- .config_table = EFI_INVALID_TABLE_ADDR,
- .get_time = xen_efi_get_time,
- .set_time = xen_efi_set_time,
- .get_wakeup_time = xen_efi_get_wakeup_time,
- .set_wakeup_time = xen_efi_set_wakeup_time,
- .get_variable = xen_efi_get_variable,
- .get_next_variable = xen_efi_get_next_variable,
- .set_variable = xen_efi_set_variable,
- .query_variable_info = xen_efi_query_variable_info,
- .update_capsule = xen_efi_update_capsule,
- .query_capsule_caps = xen_efi_query_capsule_caps,
- .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
- .reset_system = NULL, /* Functionality provided by Xen. */
- .set_virtual_address_map = NULL, /* Not used under Xen. */
- .memmap = NULL, /* Not used under Xen. */
- .flags = 0 /* Initialized later. */
-};
-
-efi_system_table_t __init *xen_efi_probe(void)
-{
- struct xen_platform_op op = {
- .cmd = XENPF_firmware_info,
- .u.firmware_info = {
- .type = XEN_FW_EFI_INFO,
- .index = XEN_FW_EFI_CONFIG_TABLE
- }
- };
- union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
-
- if (!xen_initial_domain() || HYPERVISOR_platform_op(&op) < 0)
- return NULL;
-
- /* Here we know that Xen runs on EFI platform. */
-
- efi = efi_xen;
-
- efi_systab_xen.tables = info->cfg.addr;
- efi_systab_xen.nr_tables = info->cfg.nent;
-
- op.cmd = XENPF_firmware_info;
- op.u.firmware_info.type = XEN_FW_EFI_INFO;
- op.u.firmware_info.index = XEN_FW_EFI_VENDOR;
- info->vendor.bufsz = sizeof(vendor);
- set_xen_guest_handle(info->vendor.name, vendor);
-
- if (HYPERVISOR_platform_op(&op) == 0) {
- efi_systab_xen.fw_vendor = __pa_symbol(vendor);
- efi_systab_xen.fw_revision = info->vendor.revision;
- } else
- efi_systab_xen.fw_vendor = __pa_symbol(L"UNKNOWN");
-
- op.cmd = XENPF_firmware_info;
- op.u.firmware_info.type = XEN_FW_EFI_INFO;
- op.u.firmware_info.index = XEN_FW_EFI_VERSION;
-
- if (HYPERVISOR_platform_op(&op) == 0)
- efi_systab_xen.hdr.revision = info->version;
-
- op.cmd = XENPF_firmware_info;
- op.u.firmware_info.type = XEN_FW_EFI_INFO;
- op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION;
-
- if (HYPERVISOR_platform_op(&op) == 0)
- efi.runtime_version = info->version;
-
- return &efi_systab_xen;
-}
+EXPORT_SYMBOL_GPL(xen_efi_query_capsule_caps);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 072be1c..3491582 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -90,14 +90,28 @@ int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
bool xen_running_on_version_or_later(unsigned int major, unsigned int minor);
-#ifdef CONFIG_XEN_EFI
-extern efi_system_table_t *xen_efi_probe(void);
-#else
-static inline efi_system_table_t __init *xen_efi_probe(void)
-{
- return NULL;
-}
-#endif
+efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc);
+efi_status_t xen_efi_set_time(efi_time_t *tm);
+efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, efi_bool_t *pending,
+ efi_time_t *tm);
+efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm);
+efi_status_t xen_efi_get_variable(efi_char16_t *name, efi_guid_t *vendor,
+ u32 *attr, unsigned long *data_size,
+ void *data);
+efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
+ efi_char16_t *name, efi_guid_t *vendor);
+efi_status_t xen_efi_set_variable(efi_char16_t *name, efi_guid_t *vendor,
+ u32 attr, unsigned long data_size,
+ void *data);
+efi_status_t xen_efi_query_variable_info(u32 attr, u64 *storage_space,
+ u64 *remaining_space,
+ u64 *max_variable_size);
+efi_status_t xen_efi_get_next_high_mono_count(u32 *count);
+efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
+ unsigned long count, unsigned long sg_list);
+efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
+ unsigned long count, u64 *max_size,
+ int *reset_type);
#ifdef CONFIG_PREEMPT
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 14/17] XEN: EFI: Move x86 specific codes to architecture directory
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
Move x86 specific codes to architecture directory and export those EFI
runtime service functions. This will be useful for initializing runtime
service on ARM later.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/x86/xen/efi.c | 112 ++++++++++++++++++++++++++++++++
drivers/xen/efi.c | 174 ++++++++++----------------------------------------
include/xen/xen-ops.h | 30 ++++++---
3 files changed, 168 insertions(+), 148 deletions(-)
diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index be14cc3..86527f1 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -20,10 +20,122 @@
#include <linux/init.h>
#include <linux/string.h>
+#include <xen/xen.h>
#include <xen/xen-ops.h>
+#include <xen/interface/platform.h>
#include <asm/page.h>
#include <asm/setup.h>
+#include <asm/xen/hypercall.h>
+
+static efi_char16_t vendor[100] __initdata;
+
+static efi_system_table_t efi_systab_xen __initdata = {
+ .hdr = {
+ .signature = EFI_SYSTEM_TABLE_SIGNATURE,
+ .revision = 0, /* Initialized later. */
+ .headersize = 0, /* Ignored by Linux Kernel. */
+ .crc32 = 0, /* Ignored by Linux Kernel. */
+ .reserved = 0
+ },
+ .fw_vendor = EFI_INVALID_TABLE_ADDR, /* Initialized later. */
+ .fw_revision = 0, /* Initialized later. */
+ .con_in_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .con_in = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .con_out_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .con_out = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .stderr_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .stderr = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .runtime = (efi_runtime_services_t *)EFI_INVALID_TABLE_ADDR,
+ /* Not used under Xen. */
+ .boottime = (efi_boot_services_t *)EFI_INVALID_TABLE_ADDR,
+ /* Not used under Xen. */
+ .nr_tables = 0, /* Initialized later. */
+ .tables = EFI_INVALID_TABLE_ADDR /* Initialized later. */
+};
+
+static const struct efi efi_xen __initconst = {
+ .systab = NULL, /* Initialized later. */
+ .runtime_version = 0, /* Initialized later. */
+ .mps = EFI_INVALID_TABLE_ADDR,
+ .acpi = EFI_INVALID_TABLE_ADDR,
+ .acpi20 = EFI_INVALID_TABLE_ADDR,
+ .smbios = EFI_INVALID_TABLE_ADDR,
+ .smbios3 = EFI_INVALID_TABLE_ADDR,
+ .sal_systab = EFI_INVALID_TABLE_ADDR,
+ .boot_info = EFI_INVALID_TABLE_ADDR,
+ .hcdp = EFI_INVALID_TABLE_ADDR,
+ .uga = EFI_INVALID_TABLE_ADDR,
+ .uv_systab = EFI_INVALID_TABLE_ADDR,
+ .fw_vendor = EFI_INVALID_TABLE_ADDR,
+ .runtime = EFI_INVALID_TABLE_ADDR,
+ .config_table = EFI_INVALID_TABLE_ADDR,
+ .get_time = xen_efi_get_time,
+ .set_time = xen_efi_set_time,
+ .get_wakeup_time = xen_efi_get_wakeup_time,
+ .set_wakeup_time = xen_efi_set_wakeup_time,
+ .get_variable = xen_efi_get_variable,
+ .get_next_variable = xen_efi_get_next_variable,
+ .set_variable = xen_efi_set_variable,
+ .query_variable_info = xen_efi_query_variable_info,
+ .update_capsule = xen_efi_update_capsule,
+ .query_capsule_caps = xen_efi_query_capsule_caps,
+ .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
+ .reset_system = NULL, /* Functionality provided by Xen. */
+ .set_virtual_address_map = NULL, /* Not used under Xen. */
+ .memmap = NULL, /* Not used under Xen. */
+ .flags = 0 /* Initialized later. */
+};
+
+static efi_system_table_t __init *xen_efi_probe(void)
+{
+ struct xen_platform_op op = {
+ .cmd = XENPF_firmware_info,
+ .u.firmware_info = {
+ .type = XEN_FW_EFI_INFO,
+ .index = XEN_FW_EFI_CONFIG_TABLE
+ }
+ };
+ union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+ if (!xen_initial_domain() || HYPERVISOR_platform_op(&op) < 0)
+ return NULL;
+
+ /* Here we know that Xen runs on EFI platform. */
+
+ efi = efi_xen;
+
+ efi_systab_xen.tables = info->cfg.addr;
+ efi_systab_xen.nr_tables = info->cfg.nent;
+
+ op.cmd = XENPF_firmware_info;
+ op.u.firmware_info.type = XEN_FW_EFI_INFO;
+ op.u.firmware_info.index = XEN_FW_EFI_VENDOR;
+ info->vendor.bufsz = sizeof(vendor);
+ set_xen_guest_handle(info->vendor.name, vendor);
+
+ if (HYPERVISOR_platform_op(&op) == 0) {
+ efi_systab_xen.fw_vendor = __pa_symbol(vendor);
+ efi_systab_xen.fw_revision = info->vendor.revision;
+ } else
+ efi_systab_xen.fw_vendor = __pa_symbol(L"UNKNOWN");
+
+ op.cmd = XENPF_firmware_info;
+ op.u.firmware_info.type = XEN_FW_EFI_INFO;
+ op.u.firmware_info.index = XEN_FW_EFI_VERSION;
+
+ if (HYPERVISOR_platform_op(&op) == 0)
+ efi_systab_xen.hdr.revision = info->version;
+
+ op.cmd = XENPF_firmware_info;
+ op.u.firmware_info.type = XEN_FW_EFI_INFO;
+ op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION;
+
+ if (HYPERVISOR_platform_op(&op) == 0)
+ efi.runtime_version = info->version;
+
+ return &efi_systab_xen;
+}
void __init xen_efi_init(void)
{
diff --git a/drivers/xen/efi.c b/drivers/xen/efi.c
index be7e56a..22f71ff 100644
--- a/drivers/xen/efi.c
+++ b/drivers/xen/efi.c
@@ -38,7 +38,7 @@
#define efi_data(op) (op.u.efi_runtime_call)
-static efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
+efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
{
struct xen_platform_op op = INIT_EFI_OP(get_time);
@@ -59,8 +59,9 @@ static efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_get_time);
-static efi_status_t xen_efi_set_time(efi_time_t *tm)
+efi_status_t xen_efi_set_time(efi_time_t *tm)
{
struct xen_platform_op op = INIT_EFI_OP(set_time);
@@ -72,10 +73,10 @@ static efi_status_t xen_efi_set_time(efi_time_t *tm)
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_set_time);
-static efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled,
- efi_bool_t *pending,
- efi_time_t *tm)
+efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, efi_bool_t *pending,
+ efi_time_t *tm)
{
struct xen_platform_op op = INIT_EFI_OP(get_wakeup_time);
@@ -95,8 +96,9 @@ static efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_get_wakeup_time);
-static efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
+efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
{
struct xen_platform_op op = INIT_EFI_OP(set_wakeup_time);
@@ -113,12 +115,11 @@ static efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_set_wakeup_time);
-static efi_status_t xen_efi_get_variable(efi_char16_t *name,
- efi_guid_t *vendor,
- u32 *attr,
- unsigned long *data_size,
- void *data)
+efi_status_t xen_efi_get_variable(efi_char16_t *name, efi_guid_t *vendor,
+ u32 *attr, unsigned long *data_size,
+ void *data)
{
struct xen_platform_op op = INIT_EFI_OP(get_variable);
@@ -138,10 +139,11 @@ static efi_status_t xen_efi_get_variable(efi_char16_t *name,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_get_variable);
-static efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
- efi_char16_t *name,
- efi_guid_t *vendor)
+efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
+ efi_char16_t *name,
+ efi_guid_t *vendor)
{
struct xen_platform_op op = INIT_EFI_OP(get_next_variable_name);
@@ -161,12 +163,11 @@ static efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_get_next_variable);
-static efi_status_t xen_efi_set_variable(efi_char16_t *name,
- efi_guid_t *vendor,
- u32 attr,
- unsigned long data_size,
- void *data)
+efi_status_t xen_efi_set_variable(efi_char16_t *name, efi_guid_t *vendor,
+ u32 attr, unsigned long data_size,
+ void *data)
{
struct xen_platform_op op = INIT_EFI_OP(set_variable);
@@ -183,11 +184,11 @@ static efi_status_t xen_efi_set_variable(efi_char16_t *name,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_set_variable);
-static efi_status_t xen_efi_query_variable_info(u32 attr,
- u64 *storage_space,
- u64 *remaining_space,
- u64 *max_variable_size)
+efi_status_t xen_efi_query_variable_info(u32 attr, u64 *storage_space,
+ u64 *remaining_space,
+ u64 *max_variable_size)
{
struct xen_platform_op op = INIT_EFI_OP(query_variable_info);
@@ -205,8 +206,9 @@ static efi_status_t xen_efi_query_variable_info(u32 attr,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_query_variable_info);
-static efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
+efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
{
struct xen_platform_op op = INIT_EFI_OP(get_next_high_monotonic_count);
@@ -217,10 +219,10 @@ static efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_get_next_high_mono_count);
-static efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
- unsigned long count,
- unsigned long sg_list)
+efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
+ unsigned long count, unsigned long sg_list)
{
struct xen_platform_op op = INIT_EFI_OP(update_capsule);
@@ -237,11 +239,11 @@ static efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_update_capsule);
-static efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
- unsigned long count,
- u64 *max_size,
- int *reset_type)
+efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
+ unsigned long count, u64 *max_size,
+ int *reset_type)
{
struct xen_platform_op op = INIT_EFI_OP(query_capsule_capabilities);
@@ -260,112 +262,4 @@ static efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
return efi_data(op).status;
}
-
-static efi_char16_t vendor[100] __initdata;
-
-static efi_system_table_t efi_systab_xen __initdata = {
- .hdr = {
- .signature = EFI_SYSTEM_TABLE_SIGNATURE,
- .revision = 0, /* Initialized later. */
- .headersize = 0, /* Ignored by Linux Kernel. */
- .crc32 = 0, /* Ignored by Linux Kernel. */
- .reserved = 0
- },
- .fw_vendor = EFI_INVALID_TABLE_ADDR, /* Initialized later. */
- .fw_revision = 0, /* Initialized later. */
- .con_in_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .con_in = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .con_out_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .con_out = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .stderr_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .stderr = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .runtime = (efi_runtime_services_t *)EFI_INVALID_TABLE_ADDR,
- /* Not used under Xen. */
- .boottime = (efi_boot_services_t *)EFI_INVALID_TABLE_ADDR,
- /* Not used under Xen. */
- .nr_tables = 0, /* Initialized later. */
- .tables = EFI_INVALID_TABLE_ADDR /* Initialized later. */
-};
-
-static const struct efi efi_xen __initconst = {
- .systab = NULL, /* Initialized later. */
- .runtime_version = 0, /* Initialized later. */
- .mps = EFI_INVALID_TABLE_ADDR,
- .acpi = EFI_INVALID_TABLE_ADDR,
- .acpi20 = EFI_INVALID_TABLE_ADDR,
- .smbios = EFI_INVALID_TABLE_ADDR,
- .smbios3 = EFI_INVALID_TABLE_ADDR,
- .sal_systab = EFI_INVALID_TABLE_ADDR,
- .boot_info = EFI_INVALID_TABLE_ADDR,
- .hcdp = EFI_INVALID_TABLE_ADDR,
- .uga = EFI_INVALID_TABLE_ADDR,
- .uv_systab = EFI_INVALID_TABLE_ADDR,
- .fw_vendor = EFI_INVALID_TABLE_ADDR,
- .runtime = EFI_INVALID_TABLE_ADDR,
- .config_table = EFI_INVALID_TABLE_ADDR,
- .get_time = xen_efi_get_time,
- .set_time = xen_efi_set_time,
- .get_wakeup_time = xen_efi_get_wakeup_time,
- .set_wakeup_time = xen_efi_set_wakeup_time,
- .get_variable = xen_efi_get_variable,
- .get_next_variable = xen_efi_get_next_variable,
- .set_variable = xen_efi_set_variable,
- .query_variable_info = xen_efi_query_variable_info,
- .update_capsule = xen_efi_update_capsule,
- .query_capsule_caps = xen_efi_query_capsule_caps,
- .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
- .reset_system = NULL, /* Functionality provided by Xen. */
- .set_virtual_address_map = NULL, /* Not used under Xen. */
- .memmap = NULL, /* Not used under Xen. */
- .flags = 0 /* Initialized later. */
-};
-
-efi_system_table_t __init *xen_efi_probe(void)
-{
- struct xen_platform_op op = {
- .cmd = XENPF_firmware_info,
- .u.firmware_info = {
- .type = XEN_FW_EFI_INFO,
- .index = XEN_FW_EFI_CONFIG_TABLE
- }
- };
- union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
-
- if (!xen_initial_domain() || HYPERVISOR_platform_op(&op) < 0)
- return NULL;
-
- /* Here we know that Xen runs on EFI platform. */
-
- efi = efi_xen;
-
- efi_systab_xen.tables = info->cfg.addr;
- efi_systab_xen.nr_tables = info->cfg.nent;
-
- op.cmd = XENPF_firmware_info;
- op.u.firmware_info.type = XEN_FW_EFI_INFO;
- op.u.firmware_info.index = XEN_FW_EFI_VENDOR;
- info->vendor.bufsz = sizeof(vendor);
- set_xen_guest_handle(info->vendor.name, vendor);
-
- if (HYPERVISOR_platform_op(&op) == 0) {
- efi_systab_xen.fw_vendor = __pa_symbol(vendor);
- efi_systab_xen.fw_revision = info->vendor.revision;
- } else
- efi_systab_xen.fw_vendor = __pa_symbol(L"UNKNOWN");
-
- op.cmd = XENPF_firmware_info;
- op.u.firmware_info.type = XEN_FW_EFI_INFO;
- op.u.firmware_info.index = XEN_FW_EFI_VERSION;
-
- if (HYPERVISOR_platform_op(&op) == 0)
- efi_systab_xen.hdr.revision = info->version;
-
- op.cmd = XENPF_firmware_info;
- op.u.firmware_info.type = XEN_FW_EFI_INFO;
- op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION;
-
- if (HYPERVISOR_platform_op(&op) == 0)
- efi.runtime_version = info->version;
-
- return &efi_systab_xen;
-}
+EXPORT_SYMBOL_GPL(xen_efi_query_capsule_caps);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 072be1c..3491582 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -90,14 +90,28 @@ int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
bool xen_running_on_version_or_later(unsigned int major, unsigned int minor);
-#ifdef CONFIG_XEN_EFI
-extern efi_system_table_t *xen_efi_probe(void);
-#else
-static inline efi_system_table_t __init *xen_efi_probe(void)
-{
- return NULL;
-}
-#endif
+efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc);
+efi_status_t xen_efi_set_time(efi_time_t *tm);
+efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, efi_bool_t *pending,
+ efi_time_t *tm);
+efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm);
+efi_status_t xen_efi_get_variable(efi_char16_t *name, efi_guid_t *vendor,
+ u32 *attr, unsigned long *data_size,
+ void *data);
+efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
+ efi_char16_t *name, efi_guid_t *vendor);
+efi_status_t xen_efi_set_variable(efi_char16_t *name, efi_guid_t *vendor,
+ u32 attr, unsigned long data_size,
+ void *data);
+efi_status_t xen_efi_query_variable_info(u32 attr, u64 *storage_space,
+ u64 *remaining_space,
+ u64 *max_variable_size);
+efi_status_t xen_efi_get_next_high_mono_count(u32 *count);
+efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
+ unsigned long count, unsigned long sg_list);
+efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
+ unsigned long count, u64 *max_size,
+ int *reset_type);
#ifdef CONFIG_PREEMPT
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread
* [PATCH v7 14/17] XEN: EFI: Move x86 specific codes to architecture directory
2016-03-24 14:44 ` Shannon Zhao
` (24 preceding siblings ...)
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, shannon.zhao,
zhaoshenglong, xen-devel
Move x86 specific codes to architecture directory and export those EFI
runtime service functions. This will be useful for initializing runtime
service on ARM later.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/x86/xen/efi.c | 112 ++++++++++++++++++++++++++++++++
drivers/xen/efi.c | 174 ++++++++++----------------------------------------
include/xen/xen-ops.h | 30 ++++++---
3 files changed, 168 insertions(+), 148 deletions(-)
diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index be14cc3..86527f1 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -20,10 +20,122 @@
#include <linux/init.h>
#include <linux/string.h>
+#include <xen/xen.h>
#include <xen/xen-ops.h>
+#include <xen/interface/platform.h>
#include <asm/page.h>
#include <asm/setup.h>
+#include <asm/xen/hypercall.h>
+
+static efi_char16_t vendor[100] __initdata;
+
+static efi_system_table_t efi_systab_xen __initdata = {
+ .hdr = {
+ .signature = EFI_SYSTEM_TABLE_SIGNATURE,
+ .revision = 0, /* Initialized later. */
+ .headersize = 0, /* Ignored by Linux Kernel. */
+ .crc32 = 0, /* Ignored by Linux Kernel. */
+ .reserved = 0
+ },
+ .fw_vendor = EFI_INVALID_TABLE_ADDR, /* Initialized later. */
+ .fw_revision = 0, /* Initialized later. */
+ .con_in_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .con_in = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .con_out_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .con_out = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .stderr_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .stderr = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .runtime = (efi_runtime_services_t *)EFI_INVALID_TABLE_ADDR,
+ /* Not used under Xen. */
+ .boottime = (efi_boot_services_t *)EFI_INVALID_TABLE_ADDR,
+ /* Not used under Xen. */
+ .nr_tables = 0, /* Initialized later. */
+ .tables = EFI_INVALID_TABLE_ADDR /* Initialized later. */
+};
+
+static const struct efi efi_xen __initconst = {
+ .systab = NULL, /* Initialized later. */
+ .runtime_version = 0, /* Initialized later. */
+ .mps = EFI_INVALID_TABLE_ADDR,
+ .acpi = EFI_INVALID_TABLE_ADDR,
+ .acpi20 = EFI_INVALID_TABLE_ADDR,
+ .smbios = EFI_INVALID_TABLE_ADDR,
+ .smbios3 = EFI_INVALID_TABLE_ADDR,
+ .sal_systab = EFI_INVALID_TABLE_ADDR,
+ .boot_info = EFI_INVALID_TABLE_ADDR,
+ .hcdp = EFI_INVALID_TABLE_ADDR,
+ .uga = EFI_INVALID_TABLE_ADDR,
+ .uv_systab = EFI_INVALID_TABLE_ADDR,
+ .fw_vendor = EFI_INVALID_TABLE_ADDR,
+ .runtime = EFI_INVALID_TABLE_ADDR,
+ .config_table = EFI_INVALID_TABLE_ADDR,
+ .get_time = xen_efi_get_time,
+ .set_time = xen_efi_set_time,
+ .get_wakeup_time = xen_efi_get_wakeup_time,
+ .set_wakeup_time = xen_efi_set_wakeup_time,
+ .get_variable = xen_efi_get_variable,
+ .get_next_variable = xen_efi_get_next_variable,
+ .set_variable = xen_efi_set_variable,
+ .query_variable_info = xen_efi_query_variable_info,
+ .update_capsule = xen_efi_update_capsule,
+ .query_capsule_caps = xen_efi_query_capsule_caps,
+ .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
+ .reset_system = NULL, /* Functionality provided by Xen. */
+ .set_virtual_address_map = NULL, /* Not used under Xen. */
+ .memmap = NULL, /* Not used under Xen. */
+ .flags = 0 /* Initialized later. */
+};
+
+static efi_system_table_t __init *xen_efi_probe(void)
+{
+ struct xen_platform_op op = {
+ .cmd = XENPF_firmware_info,
+ .u.firmware_info = {
+ .type = XEN_FW_EFI_INFO,
+ .index = XEN_FW_EFI_CONFIG_TABLE
+ }
+ };
+ union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+ if (!xen_initial_domain() || HYPERVISOR_platform_op(&op) < 0)
+ return NULL;
+
+ /* Here we know that Xen runs on EFI platform. */
+
+ efi = efi_xen;
+
+ efi_systab_xen.tables = info->cfg.addr;
+ efi_systab_xen.nr_tables = info->cfg.nent;
+
+ op.cmd = XENPF_firmware_info;
+ op.u.firmware_info.type = XEN_FW_EFI_INFO;
+ op.u.firmware_info.index = XEN_FW_EFI_VENDOR;
+ info->vendor.bufsz = sizeof(vendor);
+ set_xen_guest_handle(info->vendor.name, vendor);
+
+ if (HYPERVISOR_platform_op(&op) == 0) {
+ efi_systab_xen.fw_vendor = __pa_symbol(vendor);
+ efi_systab_xen.fw_revision = info->vendor.revision;
+ } else
+ efi_systab_xen.fw_vendor = __pa_symbol(L"UNKNOWN");
+
+ op.cmd = XENPF_firmware_info;
+ op.u.firmware_info.type = XEN_FW_EFI_INFO;
+ op.u.firmware_info.index = XEN_FW_EFI_VERSION;
+
+ if (HYPERVISOR_platform_op(&op) == 0)
+ efi_systab_xen.hdr.revision = info->version;
+
+ op.cmd = XENPF_firmware_info;
+ op.u.firmware_info.type = XEN_FW_EFI_INFO;
+ op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION;
+
+ if (HYPERVISOR_platform_op(&op) == 0)
+ efi.runtime_version = info->version;
+
+ return &efi_systab_xen;
+}
void __init xen_efi_init(void)
{
diff --git a/drivers/xen/efi.c b/drivers/xen/efi.c
index be7e56a..22f71ff 100644
--- a/drivers/xen/efi.c
+++ b/drivers/xen/efi.c
@@ -38,7 +38,7 @@
#define efi_data(op) (op.u.efi_runtime_call)
-static efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
+efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
{
struct xen_platform_op op = INIT_EFI_OP(get_time);
@@ -59,8 +59,9 @@ static efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_get_time);
-static efi_status_t xen_efi_set_time(efi_time_t *tm)
+efi_status_t xen_efi_set_time(efi_time_t *tm)
{
struct xen_platform_op op = INIT_EFI_OP(set_time);
@@ -72,10 +73,10 @@ static efi_status_t xen_efi_set_time(efi_time_t *tm)
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_set_time);
-static efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled,
- efi_bool_t *pending,
- efi_time_t *tm)
+efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, efi_bool_t *pending,
+ efi_time_t *tm)
{
struct xen_platform_op op = INIT_EFI_OP(get_wakeup_time);
@@ -95,8 +96,9 @@ static efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_get_wakeup_time);
-static efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
+efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
{
struct xen_platform_op op = INIT_EFI_OP(set_wakeup_time);
@@ -113,12 +115,11 @@ static efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_set_wakeup_time);
-static efi_status_t xen_efi_get_variable(efi_char16_t *name,
- efi_guid_t *vendor,
- u32 *attr,
- unsigned long *data_size,
- void *data)
+efi_status_t xen_efi_get_variable(efi_char16_t *name, efi_guid_t *vendor,
+ u32 *attr, unsigned long *data_size,
+ void *data)
{
struct xen_platform_op op = INIT_EFI_OP(get_variable);
@@ -138,10 +139,11 @@ static efi_status_t xen_efi_get_variable(efi_char16_t *name,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_get_variable);
-static efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
- efi_char16_t *name,
- efi_guid_t *vendor)
+efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
+ efi_char16_t *name,
+ efi_guid_t *vendor)
{
struct xen_platform_op op = INIT_EFI_OP(get_next_variable_name);
@@ -161,12 +163,11 @@ static efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_get_next_variable);
-static efi_status_t xen_efi_set_variable(efi_char16_t *name,
- efi_guid_t *vendor,
- u32 attr,
- unsigned long data_size,
- void *data)
+efi_status_t xen_efi_set_variable(efi_char16_t *name, efi_guid_t *vendor,
+ u32 attr, unsigned long data_size,
+ void *data)
{
struct xen_platform_op op = INIT_EFI_OP(set_variable);
@@ -183,11 +184,11 @@ static efi_status_t xen_efi_set_variable(efi_char16_t *name,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_set_variable);
-static efi_status_t xen_efi_query_variable_info(u32 attr,
- u64 *storage_space,
- u64 *remaining_space,
- u64 *max_variable_size)
+efi_status_t xen_efi_query_variable_info(u32 attr, u64 *storage_space,
+ u64 *remaining_space,
+ u64 *max_variable_size)
{
struct xen_platform_op op = INIT_EFI_OP(query_variable_info);
@@ -205,8 +206,9 @@ static efi_status_t xen_efi_query_variable_info(u32 attr,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_query_variable_info);
-static efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
+efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
{
struct xen_platform_op op = INIT_EFI_OP(get_next_high_monotonic_count);
@@ -217,10 +219,10 @@ static efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_get_next_high_mono_count);
-static efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
- unsigned long count,
- unsigned long sg_list)
+efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
+ unsigned long count, unsigned long sg_list)
{
struct xen_platform_op op = INIT_EFI_OP(update_capsule);
@@ -237,11 +239,11 @@ static efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
return efi_data(op).status;
}
+EXPORT_SYMBOL_GPL(xen_efi_update_capsule);
-static efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
- unsigned long count,
- u64 *max_size,
- int *reset_type)
+efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
+ unsigned long count, u64 *max_size,
+ int *reset_type)
{
struct xen_platform_op op = INIT_EFI_OP(query_capsule_capabilities);
@@ -260,112 +262,4 @@ static efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
return efi_data(op).status;
}
-
-static efi_char16_t vendor[100] __initdata;
-
-static efi_system_table_t efi_systab_xen __initdata = {
- .hdr = {
- .signature = EFI_SYSTEM_TABLE_SIGNATURE,
- .revision = 0, /* Initialized later. */
- .headersize = 0, /* Ignored by Linux Kernel. */
- .crc32 = 0, /* Ignored by Linux Kernel. */
- .reserved = 0
- },
- .fw_vendor = EFI_INVALID_TABLE_ADDR, /* Initialized later. */
- .fw_revision = 0, /* Initialized later. */
- .con_in_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .con_in = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .con_out_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .con_out = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .stderr_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .stderr = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
- .runtime = (efi_runtime_services_t *)EFI_INVALID_TABLE_ADDR,
- /* Not used under Xen. */
- .boottime = (efi_boot_services_t *)EFI_INVALID_TABLE_ADDR,
- /* Not used under Xen. */
- .nr_tables = 0, /* Initialized later. */
- .tables = EFI_INVALID_TABLE_ADDR /* Initialized later. */
-};
-
-static const struct efi efi_xen __initconst = {
- .systab = NULL, /* Initialized later. */
- .runtime_version = 0, /* Initialized later. */
- .mps = EFI_INVALID_TABLE_ADDR,
- .acpi = EFI_INVALID_TABLE_ADDR,
- .acpi20 = EFI_INVALID_TABLE_ADDR,
- .smbios = EFI_INVALID_TABLE_ADDR,
- .smbios3 = EFI_INVALID_TABLE_ADDR,
- .sal_systab = EFI_INVALID_TABLE_ADDR,
- .boot_info = EFI_INVALID_TABLE_ADDR,
- .hcdp = EFI_INVALID_TABLE_ADDR,
- .uga = EFI_INVALID_TABLE_ADDR,
- .uv_systab = EFI_INVALID_TABLE_ADDR,
- .fw_vendor = EFI_INVALID_TABLE_ADDR,
- .runtime = EFI_INVALID_TABLE_ADDR,
- .config_table = EFI_INVALID_TABLE_ADDR,
- .get_time = xen_efi_get_time,
- .set_time = xen_efi_set_time,
- .get_wakeup_time = xen_efi_get_wakeup_time,
- .set_wakeup_time = xen_efi_set_wakeup_time,
- .get_variable = xen_efi_get_variable,
- .get_next_variable = xen_efi_get_next_variable,
- .set_variable = xen_efi_set_variable,
- .query_variable_info = xen_efi_query_variable_info,
- .update_capsule = xen_efi_update_capsule,
- .query_capsule_caps = xen_efi_query_capsule_caps,
- .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
- .reset_system = NULL, /* Functionality provided by Xen. */
- .set_virtual_address_map = NULL, /* Not used under Xen. */
- .memmap = NULL, /* Not used under Xen. */
- .flags = 0 /* Initialized later. */
-};
-
-efi_system_table_t __init *xen_efi_probe(void)
-{
- struct xen_platform_op op = {
- .cmd = XENPF_firmware_info,
- .u.firmware_info = {
- .type = XEN_FW_EFI_INFO,
- .index = XEN_FW_EFI_CONFIG_TABLE
- }
- };
- union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
-
- if (!xen_initial_domain() || HYPERVISOR_platform_op(&op) < 0)
- return NULL;
-
- /* Here we know that Xen runs on EFI platform. */
-
- efi = efi_xen;
-
- efi_systab_xen.tables = info->cfg.addr;
- efi_systab_xen.nr_tables = info->cfg.nent;
-
- op.cmd = XENPF_firmware_info;
- op.u.firmware_info.type = XEN_FW_EFI_INFO;
- op.u.firmware_info.index = XEN_FW_EFI_VENDOR;
- info->vendor.bufsz = sizeof(vendor);
- set_xen_guest_handle(info->vendor.name, vendor);
-
- if (HYPERVISOR_platform_op(&op) == 0) {
- efi_systab_xen.fw_vendor = __pa_symbol(vendor);
- efi_systab_xen.fw_revision = info->vendor.revision;
- } else
- efi_systab_xen.fw_vendor = __pa_symbol(L"UNKNOWN");
-
- op.cmd = XENPF_firmware_info;
- op.u.firmware_info.type = XEN_FW_EFI_INFO;
- op.u.firmware_info.index = XEN_FW_EFI_VERSION;
-
- if (HYPERVISOR_platform_op(&op) == 0)
- efi_systab_xen.hdr.revision = info->version;
-
- op.cmd = XENPF_firmware_info;
- op.u.firmware_info.type = XEN_FW_EFI_INFO;
- op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION;
-
- if (HYPERVISOR_platform_op(&op) == 0)
- efi.runtime_version = info->version;
-
- return &efi_systab_xen;
-}
+EXPORT_SYMBOL_GPL(xen_efi_query_capsule_caps);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 072be1c..3491582 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -90,14 +90,28 @@ int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
bool xen_running_on_version_or_later(unsigned int major, unsigned int minor);
-#ifdef CONFIG_XEN_EFI
-extern efi_system_table_t *xen_efi_probe(void);
-#else
-static inline efi_system_table_t __init *xen_efi_probe(void)
-{
- return NULL;
-}
-#endif
+efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc);
+efi_status_t xen_efi_set_time(efi_time_t *tm);
+efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, efi_bool_t *pending,
+ efi_time_t *tm);
+efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm);
+efi_status_t xen_efi_get_variable(efi_char16_t *name, efi_guid_t *vendor,
+ u32 *attr, unsigned long *data_size,
+ void *data);
+efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
+ efi_char16_t *name, efi_guid_t *vendor);
+efi_status_t xen_efi_set_variable(efi_char16_t *name, efi_guid_t *vendor,
+ u32 attr, unsigned long data_size,
+ void *data);
+efi_status_t xen_efi_query_variable_info(u32 attr, u64 *storage_space,
+ u64 *remaining_space,
+ u64 *max_variable_size);
+efi_status_t xen_efi_get_next_high_mono_count(u32 *count);
+efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
+ unsigned long count, unsigned long sg_list);
+efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
+ unsigned long count, u64 *max_size,
+ int *reset_type);
#ifdef CONFIG_PREEMPT
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 15/17] ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services
2016-03-24 14:44 ` Shannon Zhao
` (25 preceding siblings ...)
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, shannon.zhao,
zhaoshenglong, xen-devel
When running on Xen hypervisor, runtime services are supported through
hypercall. Add a Xen specific function to initialize runtime services.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/arm/include/asm/xen/xen-ops.h | 6 ++++++
arch/arm/xen/Makefile | 1 +
arch/arm/xen/efi.c | 40 ++++++++++++++++++++++++++++++++++++
arch/arm64/include/asm/xen/xen-ops.h | 6 ++++++
arch/arm64/xen/Makefile | 1 +
drivers/xen/Kconfig | 2 +-
6 files changed, 55 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/asm/xen/xen-ops.h
create mode 100644 arch/arm/xen/efi.c
create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
diff --git a/arch/arm/include/asm/xen/xen-ops.h b/arch/arm/include/asm/xen/xen-ops.h
new file mode 100644
index 0000000..ec154e7
--- /dev/null
+++ b/arch/arm/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 1296952..2279521 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1,2 @@
obj-y := enlighten.o hypercall.o grant-table.o p2m.o mm.o
+obj-$(CONFIG_XEN_EFI) += efi.o
diff --git a/arch/arm/xen/efi.c b/arch/arm/xen/efi.c
new file mode 100644
index 0000000..16db419
--- /dev/null
+++ b/arch/arm/xen/efi.c
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/efi.h>
+#include <xen/xen-ops.h>
+#include <asm/xen/xen-ops.h>
+
+/* Set XEN EFI runtime services function pointers. Other fields of struct efi,
+ * e.g. efi.systab, will be set like normal EFI.
+ */
+void __init 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;
+ efi.reset_system = NULL; /* Functionality provided by Xen. */
+}
+EXPORT_SYMBOL_GPL(xen_efi_runtime_setup);
diff --git a/arch/arm64/include/asm/xen/xen-ops.h b/arch/arm64/include/asm/xen/xen-ops.h
new file mode 100644
index 0000000..ec154e7
--- /dev/null
+++ b/arch/arm64/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm64/xen/Makefile b/arch/arm64/xen/Makefile
index 74a8d87..8ff8aa9 100644
--- a/arch/arm64/xen/Makefile
+++ b/arch/arm64/xen/Makefile
@@ -1,2 +1,3 @@
xen-arm-y += $(addprefix ../../arm/xen/, enlighten.o grant-table.o p2m.o mm.o)
obj-y := xen-arm.o hypercall.o
+obj-$(CONFIG_XEN_EFI) += $(addprefix ../../arm/xen/, efi.o)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 979a831..f15bb3b 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -275,7 +275,7 @@ config XEN_HAVE_PVMMU
config XEN_EFI
def_bool y
- depends on X86_64 && EFI
+ depends on (ARM || ARM64 || X86_64) && EFI
config XEN_AUTO_XLATE
def_bool y
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 15/17] ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao
When running on Xen hypervisor, runtime services are supported through
hypercall. Add a Xen specific function to initialize runtime services.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/arm/include/asm/xen/xen-ops.h | 6 ++++++
arch/arm/xen/Makefile | 1 +
arch/arm/xen/efi.c | 40 ++++++++++++++++++++++++++++++++++++
arch/arm64/include/asm/xen/xen-ops.h | 6 ++++++
arch/arm64/xen/Makefile | 1 +
drivers/xen/Kconfig | 2 +-
6 files changed, 55 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/asm/xen/xen-ops.h
create mode 100644 arch/arm/xen/efi.c
create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
diff --git a/arch/arm/include/asm/xen/xen-ops.h b/arch/arm/include/asm/xen/xen-ops.h
new file mode 100644
index 0000000..ec154e7
--- /dev/null
+++ b/arch/arm/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 1296952..2279521 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1,2 @@
obj-y := enlighten.o hypercall.o grant-table.o p2m.o mm.o
+obj-$(CONFIG_XEN_EFI) += efi.o
diff --git a/arch/arm/xen/efi.c b/arch/arm/xen/efi.c
new file mode 100644
index 0000000..16db419
--- /dev/null
+++ b/arch/arm/xen/efi.c
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/efi.h>
+#include <xen/xen-ops.h>
+#include <asm/xen/xen-ops.h>
+
+/* Set XEN EFI runtime services function pointers. Other fields of struct efi,
+ * e.g. efi.systab, will be set like normal EFI.
+ */
+void __init 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;
+ efi.reset_system = NULL; /* Functionality provided by Xen. */
+}
+EXPORT_SYMBOL_GPL(xen_efi_runtime_setup);
diff --git a/arch/arm64/include/asm/xen/xen-ops.h b/arch/arm64/include/asm/xen/xen-ops.h
new file mode 100644
index 0000000..ec154e7
--- /dev/null
+++ b/arch/arm64/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm64/xen/Makefile b/arch/arm64/xen/Makefile
index 74a8d87..8ff8aa9 100644
--- a/arch/arm64/xen/Makefile
+++ b/arch/arm64/xen/Makefile
@@ -1,2 +1,3 @@
xen-arm-y += $(addprefix ../../arm/xen/, enlighten.o grant-table.o p2m.o mm.o)
obj-y := xen-arm.o hypercall.o
+obj-$(CONFIG_XEN_EFI) += $(addprefix ../../arm/xen/, efi.o)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 979a831..f15bb3b 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -275,7 +275,7 @@ config XEN_HAVE_PVMMU
config XEN_EFI
def_bool y
- depends on X86_64 && EFI
+ depends on (ARM || ARM64 || X86_64) && EFI
config XEN_AUTO_XLATE
def_bool y
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 15/17] ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
When running on Xen hypervisor, runtime services are supported through
hypercall. Add a Xen specific function to initialize runtime services.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/arm/include/asm/xen/xen-ops.h | 6 ++++++
arch/arm/xen/Makefile | 1 +
arch/arm/xen/efi.c | 40 ++++++++++++++++++++++++++++++++++++
arch/arm64/include/asm/xen/xen-ops.h | 6 ++++++
arch/arm64/xen/Makefile | 1 +
drivers/xen/Kconfig | 2 +-
6 files changed, 55 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/asm/xen/xen-ops.h
create mode 100644 arch/arm/xen/efi.c
create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
diff --git a/arch/arm/include/asm/xen/xen-ops.h b/arch/arm/include/asm/xen/xen-ops.h
new file mode 100644
index 0000000..ec154e7
--- /dev/null
+++ b/arch/arm/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 1296952..2279521 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1,2 @@
obj-y := enlighten.o hypercall.o grant-table.o p2m.o mm.o
+obj-$(CONFIG_XEN_EFI) += efi.o
diff --git a/arch/arm/xen/efi.c b/arch/arm/xen/efi.c
new file mode 100644
index 0000000..16db419
--- /dev/null
+++ b/arch/arm/xen/efi.c
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/efi.h>
+#include <xen/xen-ops.h>
+#include <asm/xen/xen-ops.h>
+
+/* Set XEN EFI runtime services function pointers. Other fields of struct efi,
+ * e.g. efi.systab, will be set like normal EFI.
+ */
+void __init 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;
+ efi.reset_system = NULL; /* Functionality provided by Xen. */
+}
+EXPORT_SYMBOL_GPL(xen_efi_runtime_setup);
diff --git a/arch/arm64/include/asm/xen/xen-ops.h b/arch/arm64/include/asm/xen/xen-ops.h
new file mode 100644
index 0000000..ec154e7
--- /dev/null
+++ b/arch/arm64/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm64/xen/Makefile b/arch/arm64/xen/Makefile
index 74a8d87..8ff8aa9 100644
--- a/arch/arm64/xen/Makefile
+++ b/arch/arm64/xen/Makefile
@@ -1,2 +1,3 @@
xen-arm-y += $(addprefix ../../arm/xen/, enlighten.o grant-table.o p2m.o mm.o)
obj-y := xen-arm.o hypercall.o
+obj-$(CONFIG_XEN_EFI) += $(addprefix ../../arm/xen/, efi.o)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 979a831..f15bb3b 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -275,7 +275,7 @@ config XEN_HAVE_PVMMU
config XEN_EFI
def_bool y
- depends on X86_64 && EFI
+ depends on (ARM || ARM64 || X86_64) && EFI
config XEN_AUTO_XLATE
def_bool y
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 15/17] ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, julien.grall-5wv7dgnIgG8,
peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
zhaoshenglong-hv44wF8Li93QT0dZR+AlfA,
shannon.zhao-QSEj5FYQhm4dnm+yROfE0A
When running on Xen hypervisor, runtime services are supported through
hypercall. Add a Xen specific function to initialize runtime services.
Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
---
arch/arm/include/asm/xen/xen-ops.h | 6 ++++++
arch/arm/xen/Makefile | 1 +
arch/arm/xen/efi.c | 40 ++++++++++++++++++++++++++++++++++++
arch/arm64/include/asm/xen/xen-ops.h | 6 ++++++
arch/arm64/xen/Makefile | 1 +
drivers/xen/Kconfig | 2 +-
6 files changed, 55 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/asm/xen/xen-ops.h
create mode 100644 arch/arm/xen/efi.c
create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
diff --git a/arch/arm/include/asm/xen/xen-ops.h b/arch/arm/include/asm/xen/xen-ops.h
new file mode 100644
index 0000000..ec154e7
--- /dev/null
+++ b/arch/arm/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 1296952..2279521 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1,2 @@
obj-y := enlighten.o hypercall.o grant-table.o p2m.o mm.o
+obj-$(CONFIG_XEN_EFI) += efi.o
diff --git a/arch/arm/xen/efi.c b/arch/arm/xen/efi.c
new file mode 100644
index 0000000..16db419
--- /dev/null
+++ b/arch/arm/xen/efi.c
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/efi.h>
+#include <xen/xen-ops.h>
+#include <asm/xen/xen-ops.h>
+
+/* Set XEN EFI runtime services function pointers. Other fields of struct efi,
+ * e.g. efi.systab, will be set like normal EFI.
+ */
+void __init 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;
+ efi.reset_system = NULL; /* Functionality provided by Xen. */
+}
+EXPORT_SYMBOL_GPL(xen_efi_runtime_setup);
diff --git a/arch/arm64/include/asm/xen/xen-ops.h b/arch/arm64/include/asm/xen/xen-ops.h
new file mode 100644
index 0000000..ec154e7
--- /dev/null
+++ b/arch/arm64/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm64/xen/Makefile b/arch/arm64/xen/Makefile
index 74a8d87..8ff8aa9 100644
--- a/arch/arm64/xen/Makefile
+++ b/arch/arm64/xen/Makefile
@@ -1,2 +1,3 @@
xen-arm-y += $(addprefix ../../arm/xen/, enlighten.o grant-table.o p2m.o mm.o)
obj-y := xen-arm.o hypercall.o
+obj-$(CONFIG_XEN_EFI) += $(addprefix ../../arm/xen/, efi.o)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 979a831..f15bb3b 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -275,7 +275,7 @@ config XEN_HAVE_PVMMU
config XEN_EFI
def_bool y
- depends on X86_64 && EFI
+ depends on (ARM || ARM64 || X86_64) && EFI
config XEN_AUTO_XLATE
def_bool y
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 172+ messages in thread
* [PATCH v7 16/17] FDT: Add a helper to get the subnode by given name
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao, Rob Herring
Sometimes it needs to check if there is a subnode of given node in FDT
by given name. Introduce this helper to get the subnode if it exists.
CC: Rob Herring <robh@kernel.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Rob Herring <robh@kernel.org>
---
drivers/of/fdt.c | 13 +++++++++++++
include/linux/of_fdt.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79d..09001db 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -645,6 +645,19 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,
}
/**
+ * of_get_flat_dt_subnode_by_name - get the subnode by given name
+ *
+ * @node: the parent node
+ * @uname: the name of subnode
+ * @return offset of the subnode, or -FDT_ERR_NOTFOUND if there is none
+ */
+
+int of_get_flat_dt_subnode_by_name(unsigned long node, const char *uname)
+{
+ return fdt_subnode_offset(initial_boot_params, node, uname);
+}
+
+/**
* of_get_flat_dt_root - find the root node in the flat blob
*/
unsigned long __init of_get_flat_dt_root(void)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df9ef38..fc28162 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -52,6 +52,8 @@ extern char __dtb_end[];
extern int of_scan_flat_dt(int (*it)(unsigned long node, const char *uname,
int depth, void *data),
void *data);
+extern int of_get_flat_dt_subnode_by_name(unsigned long node,
+ const char *uname);
extern const void *of_get_flat_dt_prop(unsigned long node, const char *name,
int *size);
extern int of_flat_dt_is_compatible(unsigned long node, const char *name);
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 16/17] FDT: Add a helper to get the subnode by given name
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
Sometimes it needs to check if there is a subnode of given node in FDT
by given name. Introduce this helper to get the subnode if it exists.
CC: Rob Herring <robh@kernel.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Rob Herring <robh@kernel.org>
---
drivers/of/fdt.c | 13 +++++++++++++
include/linux/of_fdt.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79d..09001db 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -645,6 +645,19 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,
}
/**
+ * of_get_flat_dt_subnode_by_name - get the subnode by given name
+ *
+ * @node: the parent node
+ * @uname: the name of subnode
+ * @return offset of the subnode, or -FDT_ERR_NOTFOUND if there is none
+ */
+
+int of_get_flat_dt_subnode_by_name(unsigned long node, const char *uname)
+{
+ return fdt_subnode_offset(initial_boot_params, node, uname);
+}
+
+/**
* of_get_flat_dt_root - find the root node in the flat blob
*/
unsigned long __init of_get_flat_dt_root(void)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df9ef38..fc28162 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -52,6 +52,8 @@ extern char __dtb_end[];
extern int of_scan_flat_dt(int (*it)(unsigned long node, const char *uname,
int depth, void *data),
void *data);
+extern int of_get_flat_dt_subnode_by_name(unsigned long node,
+ const char *uname);
extern const void *of_get_flat_dt_prop(unsigned long node, const char *name,
int *size);
extern int of_flat_dt_is_compatible(unsigned long node, const char *name);
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 16/17] FDT: Add a helper to get the subnode by given name
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, julien.grall-5wv7dgnIgG8,
peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
zhaoshenglong-hv44wF8Li93QT0dZR+AlfA,
shannon.zhao-QSEj5FYQhm4dnm+yROfE0A, Rob Herring
Sometimes it needs to check if there is a subnode of given node in FDT
by given name. Introduce this helper to get the subnode if it exists.
CC: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
drivers/of/fdt.c | 13 +++++++++++++
include/linux/of_fdt.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79d..09001db 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -645,6 +645,19 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,
}
/**
+ * of_get_flat_dt_subnode_by_name - get the subnode by given name
+ *
+ * @node: the parent node
+ * @uname: the name of subnode
+ * @return offset of the subnode, or -FDT_ERR_NOTFOUND if there is none
+ */
+
+int of_get_flat_dt_subnode_by_name(unsigned long node, const char *uname)
+{
+ return fdt_subnode_offset(initial_boot_params, node, uname);
+}
+
+/**
* of_get_flat_dt_root - find the root node in the flat blob
*/
unsigned long __init of_get_flat_dt_root(void)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df9ef38..fc28162 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -52,6 +52,8 @@ extern char __dtb_end[];
extern int of_scan_flat_dt(int (*it)(unsigned long node, const char *uname,
int depth, void *data),
void *data);
+extern int of_get_flat_dt_subnode_by_name(unsigned long node,
+ const char *uname);
extern const void *of_get_flat_dt_prop(unsigned long node, const char *name,
int *size);
extern int of_flat_dt_is_compatible(unsigned long node, const char *name);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 172+ messages in thread
* [PATCH v7 16/17] FDT: Add a helper to get the subnode by given name
2016-03-24 14:44 ` Shannon Zhao
` (28 preceding siblings ...)
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, Rob Herring, catalin.marinas, will.deacon,
linux-kernel, peter.huangpeng, julien.grall, shannon.zhao,
zhaoshenglong, xen-devel
Sometimes it needs to check if there is a subnode of given node in FDT
by given name. Introduce this helper to get the subnode if it exists.
CC: Rob Herring <robh@kernel.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Rob Herring <robh@kernel.org>
---
drivers/of/fdt.c | 13 +++++++++++++
include/linux/of_fdt.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79d..09001db 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -645,6 +645,19 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,
}
/**
+ * of_get_flat_dt_subnode_by_name - get the subnode by given name
+ *
+ * @node: the parent node
+ * @uname: the name of subnode
+ * @return offset of the subnode, or -FDT_ERR_NOTFOUND if there is none
+ */
+
+int of_get_flat_dt_subnode_by_name(unsigned long node, const char *uname)
+{
+ return fdt_subnode_offset(initial_boot_params, node, uname);
+}
+
+/**
* of_get_flat_dt_root - find the root node in the flat blob
*/
unsigned long __init of_get_flat_dt_root(void)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df9ef38..fc28162 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -52,6 +52,8 @@ extern char __dtb_end[];
extern int of_scan_flat_dt(int (*it)(unsigned long node, const char *uname,
int depth, void *data),
void *data);
+extern int of_get_flat_dt_subnode_by_name(unsigned long node,
+ const char *uname);
extern const void *of_get_flat_dt_prop(unsigned long node, const char *name,
int *size);
extern int of_flat_dt_is_compatible(unsigned long node, const char *name);
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 17/17] Xen: EFI: Parse DT parameters for Xen specific UEFI
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, linux-kernel, catalin.marinas,
will.deacon, julien.grall, peter.huangpeng, xen-devel,
zhaoshenglong, shannon.zhao, Matt Fleming
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.
If Xen supports EFI, initialize runtime services.
CC: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/arm/xen/enlighten.c | 6 +++++
drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
drivers/firmware/efi/efi.c | 45 ++++++++++++++++++++++++++++++++------
3 files changed, 56 insertions(+), 12 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c43617f..9d52342b 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -261,6 +261,12 @@ static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
!strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
hyper_node.version = s + strlen(hyper_node.prefix);
+ if (IS_ENABLED(CONFIG_XEN_EFI)) {
+ /* Check if Xen supports EFI */
+ if (of_get_flat_dt_subnode_by_name(node, "uefi") > 0)
+ set_bit(EFI_PARAVIRT, &efi.flags);
+ }
+
return 0;
}
diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 6ae21e4..ac609b9 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -27,6 +27,7 @@
#include <asm/mmu.h>
#include <asm/pgalloc.h>
#include <asm/pgtable.h>
+#include <asm/xen/xen-ops.h>
extern u64 efi_system_table;
@@ -107,13 +108,19 @@ static int __init arm_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 -ENOMEM;
+ if (IS_ENABLED(CONFIG_XEN_EFI) && efi_enabled(EFI_PARAVIRT)) {
+ /* Set up runtime services function pointers for Xen Dom0 */
+ xen_efi_runtime_setup();
+ } else {
+ if (!efi_virtmap_init()) {
+ pr_err("No UEFI virtual mapping was installed -- runtime services will not be available\n");
+ return -ENOMEM;
+ }
+
+ /* Set up runtime services function pointers */
+ efi_native_runtime_setup();
}
- /* Set up runtime services function pointers */
- efi_native_runtime_setup();
set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
efi.runtime_version = efi.systab->hdr.revision;
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37da..1328cb7 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -500,12 +500,14 @@ device_initcall(efi_load_efivars);
FIELD_SIZEOF(struct efi_fdt_params, field) \
}
-static __initdata struct {
+struct params {
const char name[32];
const char propname[32];
int offset;
int size;
-} dt_params[] = {
+};
+
+static struct params fdt_params[] __initdata = {
UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
@@ -513,24 +515,45 @@ static __initdata struct {
UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
};
+static struct params xen_fdt_params[] __initdata = {
+ 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 found;
void *params;
+ struct params *dt_params;
+ int size;
};
static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
int depth, void *data)
{
struct param_info *info = data;
+ struct params *dt_params = info->dt_params;
const void *prop;
void *dest;
u64 val;
- int i, len;
+ int i, len, offset;
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
+ if (efi_enabled(EFI_PARAVIRT)) {
+ if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+ return 0;
- for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+ offset = of_get_flat_dt_subnode_by_name(node, "uefi");
+ if (offset < 0)
+ return 0;
+ node = offset;
+ } else {
+ if (depth != 1 || strcmp(uname, "chosen") != 0)
+ return 0;
+ }
+
+ for (i = 0; i < info->size; i++) {
prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
if (!prop)
return 0;
@@ -561,12 +584,20 @@ int __init efi_get_fdt_params(struct efi_fdt_params *params)
info.found = 0;
info.params = params;
+ if (efi_enabled(EFI_PARAVIRT)) {
+ info.dt_params = xen_fdt_params;
+ info.size = ARRAY_SIZE(xen_fdt_params);
+ } else {
+ info.dt_params = fdt_params;
+ info.size = ARRAY_SIZE(fdt_params);
+ }
+
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);
+ info.dt_params[info.found].name);
return ret;
}
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 17/17] Xen: EFI: Parse DT parameters for Xen specific UEFI
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
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.
If Xen supports EFI, initialize runtime services.
CC: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/arm/xen/enlighten.c | 6 +++++
drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
drivers/firmware/efi/efi.c | 45 ++++++++++++++++++++++++++++++++------
3 files changed, 56 insertions(+), 12 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c43617f..9d52342b 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -261,6 +261,12 @@ static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
!strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
hyper_node.version = s + strlen(hyper_node.prefix);
+ if (IS_ENABLED(CONFIG_XEN_EFI)) {
+ /* Check if Xen supports EFI */
+ if (of_get_flat_dt_subnode_by_name(node, "uefi") > 0)
+ set_bit(EFI_PARAVIRT, &efi.flags);
+ }
+
return 0;
}
diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 6ae21e4..ac609b9 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -27,6 +27,7 @@
#include <asm/mmu.h>
#include <asm/pgalloc.h>
#include <asm/pgtable.h>
+#include <asm/xen/xen-ops.h>
extern u64 efi_system_table;
@@ -107,13 +108,19 @@ static int __init arm_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 -ENOMEM;
+ if (IS_ENABLED(CONFIG_XEN_EFI) && efi_enabled(EFI_PARAVIRT)) {
+ /* Set up runtime services function pointers for Xen Dom0 */
+ xen_efi_runtime_setup();
+ } else {
+ if (!efi_virtmap_init()) {
+ pr_err("No UEFI virtual mapping was installed -- runtime services will not be available\n");
+ return -ENOMEM;
+ }
+
+ /* Set up runtime services function pointers */
+ efi_native_runtime_setup();
}
- /* Set up runtime services function pointers */
- efi_native_runtime_setup();
set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
efi.runtime_version = efi.systab->hdr.revision;
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37da..1328cb7 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -500,12 +500,14 @@ device_initcall(efi_load_efivars);
FIELD_SIZEOF(struct efi_fdt_params, field) \
}
-static __initdata struct {
+struct params {
const char name[32];
const char propname[32];
int offset;
int size;
-} dt_params[] = {
+};
+
+static struct params fdt_params[] __initdata = {
UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
@@ -513,24 +515,45 @@ static __initdata struct {
UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
};
+static struct params xen_fdt_params[] __initdata = {
+ 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 found;
void *params;
+ struct params *dt_params;
+ int size;
};
static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
int depth, void *data)
{
struct param_info *info = data;
+ struct params *dt_params = info->dt_params;
const void *prop;
void *dest;
u64 val;
- int i, len;
+ int i, len, offset;
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
+ if (efi_enabled(EFI_PARAVIRT)) {
+ if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+ return 0;
- for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+ offset = of_get_flat_dt_subnode_by_name(node, "uefi");
+ if (offset < 0)
+ return 0;
+ node = offset;
+ } else {
+ if (depth != 1 || strcmp(uname, "chosen") != 0)
+ return 0;
+ }
+
+ for (i = 0; i < info->size; i++) {
prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
if (!prop)
return 0;
@@ -561,12 +584,20 @@ int __init efi_get_fdt_params(struct efi_fdt_params *params)
info.found = 0;
info.params = params;
+ if (efi_enabled(EFI_PARAVIRT)) {
+ info.dt_params = xen_fdt_params;
+ info.size = ARRAY_SIZE(xen_fdt_params);
+ } else {
+ info.dt_params = fdt_params;
+ info.size = ARRAY_SIZE(fdt_params);
+ }
+
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);
+ info.dt_params[info.found].name);
return ret;
}
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread* [PATCH v7 17/17] Xen: EFI: Parse DT parameters for Xen specific UEFI
@ 2016-03-24 14:44 ` Shannon Zhao
0 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefano.stabellini-Sxgqhf6Nn4DQT0dZR+AlfA,
david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, julien.grall-5wv7dgnIgG8,
peter.huangpeng-hv44wF8Li93QT0dZR+AlfA,
xen-devel-GuqFBffKawuEi8DpZVb4nw,
zhaoshenglong-hv44wF8Li93QT0dZR+AlfA,
shannon.zhao-QSEj5FYQhm4dnm+yROfE0A, Matt Fleming
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.
If Xen supports EFI, initialize runtime services.
CC: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
Signed-off-by: Shannon Zhao <shannon.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Reviewed-by: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
---
arch/arm/xen/enlighten.c | 6 +++++
drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
drivers/firmware/efi/efi.c | 45 ++++++++++++++++++++++++++++++++------
3 files changed, 56 insertions(+), 12 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c43617f..9d52342b 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -261,6 +261,12 @@ static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
!strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
hyper_node.version = s + strlen(hyper_node.prefix);
+ if (IS_ENABLED(CONFIG_XEN_EFI)) {
+ /* Check if Xen supports EFI */
+ if (of_get_flat_dt_subnode_by_name(node, "uefi") > 0)
+ set_bit(EFI_PARAVIRT, &efi.flags);
+ }
+
return 0;
}
diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 6ae21e4..ac609b9 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -27,6 +27,7 @@
#include <asm/mmu.h>
#include <asm/pgalloc.h>
#include <asm/pgtable.h>
+#include <asm/xen/xen-ops.h>
extern u64 efi_system_table;
@@ -107,13 +108,19 @@ static int __init arm_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 -ENOMEM;
+ if (IS_ENABLED(CONFIG_XEN_EFI) && efi_enabled(EFI_PARAVIRT)) {
+ /* Set up runtime services function pointers for Xen Dom0 */
+ xen_efi_runtime_setup();
+ } else {
+ if (!efi_virtmap_init()) {
+ pr_err("No UEFI virtual mapping was installed -- runtime services will not be available\n");
+ return -ENOMEM;
+ }
+
+ /* Set up runtime services function pointers */
+ efi_native_runtime_setup();
}
- /* Set up runtime services function pointers */
- efi_native_runtime_setup();
set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
efi.runtime_version = efi.systab->hdr.revision;
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37da..1328cb7 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -500,12 +500,14 @@ device_initcall(efi_load_efivars);
FIELD_SIZEOF(struct efi_fdt_params, field) \
}
-static __initdata struct {
+struct params {
const char name[32];
const char propname[32];
int offset;
int size;
-} dt_params[] = {
+};
+
+static struct params fdt_params[] __initdata = {
UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
@@ -513,24 +515,45 @@ static __initdata struct {
UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
};
+static struct params xen_fdt_params[] __initdata = {
+ 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 found;
void *params;
+ struct params *dt_params;
+ int size;
};
static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
int depth, void *data)
{
struct param_info *info = data;
+ struct params *dt_params = info->dt_params;
const void *prop;
void *dest;
u64 val;
- int i, len;
+ int i, len, offset;
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
+ if (efi_enabled(EFI_PARAVIRT)) {
+ if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+ return 0;
- for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+ offset = of_get_flat_dt_subnode_by_name(node, "uefi");
+ if (offset < 0)
+ return 0;
+ node = offset;
+ } else {
+ if (depth != 1 || strcmp(uname, "chosen") != 0)
+ return 0;
+ }
+
+ for (i = 0; i < info->size; i++) {
prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
if (!prop)
return 0;
@@ -561,12 +584,20 @@ int __init efi_get_fdt_params(struct efi_fdt_params *params)
info.found = 0;
info.params = params;
+ if (efi_enabled(EFI_PARAVIRT)) {
+ info.dt_params = xen_fdt_params;
+ info.size = ARRAY_SIZE(xen_fdt_params);
+ } else {
+ info.dt_params = fdt_params;
+ info.size = ARRAY_SIZE(fdt_params);
+ }
+
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);
+ info.dt_params[info.found].name);
return ret;
}
--
2.1.4
^ permalink raw reply related [flat|nested] 172+ messages in thread
* [PATCH v7 17/17] Xen: EFI: Parse DT parameters for Xen specific UEFI
2016-03-24 14:44 ` Shannon Zhao
` (30 preceding siblings ...)
(?)
@ 2016-03-24 14:44 ` Shannon Zhao
-1 siblings, 0 replies; 172+ messages in thread
From: Shannon Zhao @ 2016-03-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel, stefano.stabellini, david.vrabel
Cc: devicetree, linux-efi, Matt Fleming, catalin.marinas,
will.deacon, linux-kernel, peter.huangpeng, julien.grall,
shannon.zhao, zhaoshenglong, xen-devel
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.
If Xen supports EFI, initialize runtime services.
CC: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/arm/xen/enlighten.c | 6 +++++
drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
drivers/firmware/efi/efi.c | 45 ++++++++++++++++++++++++++++++++------
3 files changed, 56 insertions(+), 12 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c43617f..9d52342b 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -261,6 +261,12 @@ static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
!strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
hyper_node.version = s + strlen(hyper_node.prefix);
+ if (IS_ENABLED(CONFIG_XEN_EFI)) {
+ /* Check if Xen supports EFI */
+ if (of_get_flat_dt_subnode_by_name(node, "uefi") > 0)
+ set_bit(EFI_PARAVIRT, &efi.flags);
+ }
+
return 0;
}
diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 6ae21e4..ac609b9 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -27,6 +27,7 @@
#include <asm/mmu.h>
#include <asm/pgalloc.h>
#include <asm/pgtable.h>
+#include <asm/xen/xen-ops.h>
extern u64 efi_system_table;
@@ -107,13 +108,19 @@ static int __init arm_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 -ENOMEM;
+ if (IS_ENABLED(CONFIG_XEN_EFI) && efi_enabled(EFI_PARAVIRT)) {
+ /* Set up runtime services function pointers for Xen Dom0 */
+ xen_efi_runtime_setup();
+ } else {
+ if (!efi_virtmap_init()) {
+ pr_err("No UEFI virtual mapping was installed -- runtime services will not be available\n");
+ return -ENOMEM;
+ }
+
+ /* Set up runtime services function pointers */
+ efi_native_runtime_setup();
}
- /* Set up runtime services function pointers */
- efi_native_runtime_setup();
set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
efi.runtime_version = efi.systab->hdr.revision;
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37da..1328cb7 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -500,12 +500,14 @@ device_initcall(efi_load_efivars);
FIELD_SIZEOF(struct efi_fdt_params, field) \
}
-static __initdata struct {
+struct params {
const char name[32];
const char propname[32];
int offset;
int size;
-} dt_params[] = {
+};
+
+static struct params fdt_params[] __initdata = {
UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
@@ -513,24 +515,45 @@ static __initdata struct {
UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
};
+static struct params xen_fdt_params[] __initdata = {
+ 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 found;
void *params;
+ struct params *dt_params;
+ int size;
};
static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
int depth, void *data)
{
struct param_info *info = data;
+ struct params *dt_params = info->dt_params;
const void *prop;
void *dest;
u64 val;
- int i, len;
+ int i, len, offset;
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
+ if (efi_enabled(EFI_PARAVIRT)) {
+ if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+ return 0;
- for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+ offset = of_get_flat_dt_subnode_by_name(node, "uefi");
+ if (offset < 0)
+ return 0;
+ node = offset;
+ } else {
+ if (depth != 1 || strcmp(uname, "chosen") != 0)
+ return 0;
+ }
+
+ for (i = 0; i < info->size; i++) {
prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
if (!prop)
return 0;
@@ -561,12 +584,20 @@ int __init efi_get_fdt_params(struct efi_fdt_params *params)
info.found = 0;
info.params = params;
+ if (efi_enabled(EFI_PARAVIRT)) {
+ info.dt_params = xen_fdt_params;
+ info.size = ARRAY_SIZE(xen_fdt_params);
+ } else {
+ info.dt_params = fdt_params;
+ info.size = ARRAY_SIZE(fdt_params);
+ }
+
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);
+ info.dt_params[info.found].name);
return ret;
}
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 172+ messages in thread