[Xen-devel] [PATCH] xen/input: do not advertise multi-touch pressure support

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Some user-space applications expect multi-touch pressure
on contact to be reported if it is advertised in device
properties. Otherwise, such applications may treat reports
not as actual touches, but hovering. Currently this is
only advertised, but not reported.
Fix this by not advertising that ABS_MT_PRESSURE is supported.

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Andrii Chepurnyi 
---
 drivers/input/misc/xen-kbdfront.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 6bf56bb5f8d9..d91f3b1c5375 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -326,8 +326,6 @@ static int xenkbd_probe(struct xenbus_device *dev,
 0, width, 0, 0);
input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
 0, height, 0, 0);
-   input_set_abs_params(mtouch, ABS_MT_PRESSURE,
-0, 255, 0, 0);
 
ret = input_mt_init_slots(mtouch, num_cont, INPUT_MT_DIRECT);
if (ret) {
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86: xen: remove the use of VLAIS

[Juergen Gross]

On 24/12/17 19:02, Nick Desaulniers wrote:
> Variable Length Arrays In Structs (VLAIS) is not supported by Clang, and
> frowned upon by others.
> 
> https://lkml.org/lkml/2013/9/23/500
> 
> Here, the VLAIS was used because the size of the bitmap returned from
> xen_mc_entry() depended on possibly (based on kernel configuration)
> runtime sized data. Rather than declaring args as a VLAIS then calling
> sizeof on *args, we can define the variable length array (mask) to be a
> pointer, and calculate the appropriate sizeof args manually. Further, we
> can get rid of the #ifdef's and rely on num_possible_cpus() (thanks to a
> helpful checkpatch warning from an earlier version of this patch).

Using a pointer for mask seems to be wrong, as it is never initialized.

Why don't you just use:

DECLARE_BITMAP(mask, NR_CPUS);

and drop the #ifdef, while keeping the manual length calculation?


Juergen

> 
> Signed-off-by: Nick Desaulniers 
> ---
>  arch/x86/xen/mmu_pv.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
> index 4d62c07..966976c 100644
> --- a/arch/x86/xen/mmu_pv.c
> +++ b/arch/x86/xen/mmu_pv.c
> @@ -1325,20 +1325,18 @@ static void xen_flush_tlb_others(const struct cpumask 
> *cpus,
>  {
>   struct {
>   struct mmuext_op op;
> -#ifdef CONFIG_SMP
> - DECLARE_BITMAP(mask, num_processors);
> -#else
> - DECLARE_BITMAP(mask, NR_CPUS);
> -#endif
> + unsigned long *mask;
>   } *args;
>   struct multicall_space mcs;
> + const size_t mc_entry_size = sizeof(args->op) +
> + sizeof(*args->mask) * BITS_TO_LONGS(num_possible_cpus());
>  
>   trace_xen_mmu_flush_tlb_others(cpus, info->mm, info->start, info->end);
>  
>   if (cpumask_empty(cpus))
>   return; /* nothing to do */
>  
> - mcs = xen_mc_entry(sizeof(*args));
> + mcs = xen_mc_entry(mc_entry_size);
>   args = mcs.args;
>   args->op.arg2.vcpumask = to_cpumask(args->mask);
>  
> 


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH -next] xen/pvcalls: use GFP_ATOMIC under spin lock

[Juergen Gross]

On 28/12/17 04:46, Wei Yongjun wrote:
> A spin lock is taken here so we should use GFP_ATOMIC.
> 
> Fixes: 9774c6cca266 ("xen/pvcalls: implement accept command")
> Signed-off-by: Wei Yongjun 

Reviewed-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] 4.8.3 preparations

[Jan Beulich]

>>> On 21.12.17 at 20:42,  wrote:
> With Christoph any myself reporting the same kernel crash when using 4.14.x 
> kernels and Xen 4.8.2 is there any chance to look at this bug before 4.8.3 is 
> released? 

As Christoph has already pointed out - unless you have indication
of your issue (a) being a hypervisor issue and (b) already addressed
in master, I don't understand the request: For stable releases we
only consider backports.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC 00/11] acpi: arm: IORT Support for Xen

[manish . jaggi]

From: Manish Jaggi 

This patch aims to add the support of IORT in Xen. Below is the list
of major components which this patchset provides.
a. Add support for parsing the IORT 
b. Provides API to populate/query requesterid - streamID mappings and
   reuqesterid - deviceid mappings
c. The requesterid - deviceid mappings is used to create the IORT for
   hardware domain (which hides smmu nodes from IORT)
d. iort.c fwnode.h fwspec code is imported from linux and modified.
e. Few kernel helper routines are also imported from linux.

This patchset compiles with [1]  [RFC v4 0/8] SMMUv3 driver.

[1] https://lists.xen.org/archives/html/xen-devel/2017-12/msg01294.html

Manish Jaggi (11):
  acpi: arm: Public API for populating and query based on requesterid
  acpi: arm: API to query estimated size of hardware domain's IORT
  acpi: arm: Code to generate Hardware Domains IORT
  acpi: arm: Import iort.c and acpi_iort.h
  acpi: arm: Import fwnode.h from linux
  acpi: arm: fwnode xen spacific changes
  Add kernel helper functions
  Add ACPI_IORT config
  acpi: arm: Xen IORT Changes
  acpi: arm: IORT parsing functions to prepare requesterId maps
  Add to_pci_dev macro

 xen/arch/arm/Kconfig|   5 +
 xen/arch/arm/domain_build.c |  40 ++-
 xen/arch/arm/setup.c|   2 +
 xen/drivers/acpi/Kconfig|   3 +
 xen/drivers/acpi/Makefile   |   1 +
 xen/drivers/acpi/arm/Makefile   |   3 +
 xen/drivers/acpi/arm/gen-iort.c | 352 +
 xen/drivers/acpi/arm/iort.c | 569 
 xen/drivers/acpi/arm/ridmap.c   | 124 +
 xen/drivers/passthrough/iommu.c |  75 ++
 xen/include/acpi/acpi_iort.h|  57 
 xen/include/acpi/gen-iort.h |   7 +
 xen/include/acpi/ridmap.h   |  77 ++
 xen/include/asm-arm/acpi.h  |   1 +
 xen/include/asm-arm/device.h|  11 +-
 xen/include/xen/fwnode.h| 125 +
 xen/include/xen/iommu.h |  22 ++
 xen/include/xen/kernel.h|  10 +
 xen/include/xen/pci.h   |   3 +
 19 files changed, 1484 insertions(+), 3 deletions(-)
 create mode 100644 xen/drivers/acpi/arm/Makefile
 create mode 100644 xen/drivers/acpi/arm/gen-iort.c
 create mode 100644 xen/drivers/acpi/arm/iort.c
 create mode 100644 xen/drivers/acpi/arm/ridmap.c
 create mode 100644 xen/include/acpi/acpi_iort.h
 create mode 100644 xen/include/acpi/gen-iort.h
 create mode 100644 xen/include/acpi/ridmap.h
 create mode 100644 xen/include/xen/fwnode.h

-- 
2.14.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC 03/11] acpi: arm: Code to generate Hardware Domains IORT

[manish . jaggi]

From: Manish Jaggi 

Singed-off-by: Manish Jaggi 
---
 xen/arch/arm/domain_build.c |  28 +
 xen/drivers/acpi/arm/gen-iort.c | 253 +++-
 xen/include/acpi/gen-iort.h |   1 +
 xen/include/asm-arm/acpi.h  |   1 +
 4 files changed, 282 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f5d5e3d271..9831943147 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1654,6 +1654,8 @@ static int acpi_create_xsdt(struct domain *d, struct 
membank tbl_add[])
ACPI_SIG_FADT, tbl_add[TBL_FADT].start);
 acpi_xsdt_modify_entry(xsdt->table_offset_entry, entry_count,
ACPI_SIG_MADT, tbl_add[TBL_MADT].start);
+acpi_xsdt_modify_entry(xsdt->table_offset_entry, entry_count,
+   ACPI_SIG_IORT, tbl_add[TBL_IORT].start);
 xsdt->table_offset_entry[entry_count] = tbl_add[TBL_STAO].start;
 
 xsdt->header.length = table_size;
@@ -1704,6 +1706,28 @@ static int acpi_create_stao(struct domain *d, struct 
membank tbl_add[])
 return 0;
 }
 
+static int acpi_create_iort(struct domain *d, struct membank tbl_add[])
+{
+struct acpi_table_iort *hwdom_table;
+unsigned int size = 0;
+
+tbl_add[TBL_IORT].start = d->arch.efi_acpi_gpa
+  + acpi_get_table_offset(tbl_add, TBL_IORT);
+hwdom_table = d->arch.efi_acpi_table
+  + acpi_get_table_offset(tbl_add, TBL_IORT);
+
+if ( prepare_iort(hwdom_table, &size) )
+{
+printk("Failed to write IORT table\n");
+return -EINVAL;
+}
+printk("%s %d %d \r\n", __func__, __LINE__, size);
+
+tbl_add[TBL_IORT].size = size;
+printk("%s %d %d \r\n", __func__, __LINE__, size);
+return 0;
+}
+
 static int acpi_create_madt(struct domain *d, struct membank tbl_add[])
 {
 struct acpi_table_header *table = NULL;
@@ -1899,6 +1923,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+rc = acpi_create_iort(d, tbl_add);
+if ( rc != 0 )
+return rc;
+
 rc = acpi_create_xsdt(d, tbl_add);
 if ( rc != 0 )
 return rc;
diff --git a/xen/drivers/acpi/arm/gen-iort.c b/xen/drivers/acpi/arm/gen-iort.c
index 3fc32959c6..f368000753 100644
--- a/xen/drivers/acpi/arm/gen-iort.c
+++ b/xen/drivers/acpi/arm/gen-iort.c
@@ -21,6 +21,257 @@
 #include 
 #include 
 
+/*
+ * Structure of Hardware domain's IORT
+ * ---
+ *
+ * Below is the structure of the IORT which this code generates.
+ *
+ * [IORT Header]
+ * [ITS Group 1 ]
+ * [ITS Group N ]
+ * [PCIRC Node 1]
+ * [PCIRC IDMAP entry 1]
+ * [PCIRC IDMAP entry N]
+ * [PCIRC Node N]
+ *
+ * requesterId- deviceId mapping list poplated by parsing IORT is used
+ * to create nodes and idmaps.
+ * We have one small problem, how to resolve the its grooup node offset from
+ * the firmware iort to the ones in hardware domains IORT.
+ *
+ * Since the ITS group node pointer stored with the rid-devid map is used
+ * to populate the ITS Group nodes in the hardware domains' IORT.
+ * We create another map to save the offset of the ITS group node written
+ * in the hardware domain IORT with the ITS node pointer in the firmware IORT.
+ *
+ * This offset is later used when writing pcirc idmaps output_reference.
+ */
+struct its_node_offset_map
+{
+struct acpi_iort_node *its_node;
+unsigned int offset;
+struct list_head entry;
+};
+struct list_head its_map_list;
+
+int set_its_node_offset(struct acpi_iort_node *its_node, unsigned int offset)
+{
+struct its_node_offset_map *its_map;
+list_for_each_entry(its_map, &its_map_list, entry)
+{
+if ( its_map->its_node == its_node )
+return 0;
+}
+
+its_map = xzalloc(struct its_node_offset_map);
+if ( !its_map )
+return -ENOMEM;
+
+its_map->its_node = its_node;
+its_map->offset = offset;
+list_add_tail(&its_map->entry, &its_map_list);
+
+return 0;
+}
+/*
+ * This method would be used in write_pcirc_nodes when writing idmaps
+ */
+unsigned int get_its_node_offset(struct acpi_iort_node *its_node)
+{
+struct its_node_offset_map *its_map;
+list_for_each_entry(its_map, &its_map_list, entry)
+{
+if ( its_map->its_node == its_node )
+return its_map->offset;
+}
+
+return 0;
+}
+
+void free_its_node_offset_list(void)
+{
+
+struct its_node_offset_map *its_map;
+list_for_each_entry(its_map, &its_map_list, entry)
+xfree(its_map);
+
+list_del(&its_map_list);
+}
+
+void write_its_group(u8 *iort, unsigned int *offset, unsigned int *num_nodes)
+{
+struct rid_deviceid_map *rmap;
+unsigned int of = *offset;
+int n=0;
+INIT_LIST_HEAD(&its_map_list);
+/*
+ * rid_deviceid_map_list is iterated to get unique its group nodes
+ * Each unique ITS group node is written in 

[Xen-devel] [RFC 01/11] acpi: arm: Public API for populating and query based on requesterid

[manish . jaggi]

From: Manish Jaggi 

 Public API to populate and query map between requester id and
 streamId/DeviceID. IORT is parsed one time (outside this patch)
 and two lists are created one for mapping between reuesterId and streamid
 and another between requesterID and deviceID.

 These lists eliminate the need to reparse IORT for querying streamid
 or deviceid using requesterid.

 Signed-off-by: Manish Jaggi 
---
 xen/drivers/acpi/Makefile |   1 +
 xen/drivers/acpi/arm/Makefile |   1 +
 xen/drivers/acpi/arm/ridmap.c | 124 ++
 xen/include/acpi/ridmap.h |  77 ++
 4 files changed, 203 insertions(+)

diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index 444b11d583..80a074e007 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -1,6 +1,7 @@
 subdir-y += tables
 subdir-y += utilities
 subdir-$(CONFIG_X86) += apei
+subdir-$(CONFIG_ARM) += arm
 
 obj-bin-y += tables.init.o
 obj-$(CONFIG_NUMA) += numa.o
diff --git a/xen/drivers/acpi/arm/Makefile b/xen/drivers/acpi/arm/Makefile
new file mode 100644
index 00..046fad5e3d
--- /dev/null
+++ b/xen/drivers/acpi/arm/Makefile
@@ -0,0 +1 @@
+obj-y = ridmap.o
diff --git a/xen/drivers/acpi/arm/ridmap.c b/xen/drivers/acpi/arm/ridmap.c
new file mode 100644
index 00..2c3a8876ea
--- /dev/null
+++ b/xen/drivers/acpi/arm/ridmap.c
@@ -0,0 +1,124 @@
+/*
+ * xen/drivers/acpi/arm/ridmap.c
+ *
+ * Public API to populate and query map between requester id and
+ * streamId/DeviceID
+ *
+ * Manish Jaggi 
+ * Copyright (c) 2018 Linaro.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct list_head rid_streamid_map_list;
+struct list_head rid_deviceid_map_list;
+
+void init_ridmaps(void)
+{
+INIT_LIST_HEAD(&rid_deviceid_map_list);
+INIT_LIST_HEAD(&rid_streamid_map_list);
+}
+
+int add_rid_streamid_map(struct acpi_iort_node *pcirc_node,
+ struct acpi_iort_node *smmu_node,
+ u32 input_base, u32 output_base, u32 id_count)
+{
+struct rid_streamid_map *rid_map;
+rid_map = xzalloc(struct rid_streamid_map);
+
+if (!rid_map)
+return -ENOMEM;
+
+rid_map->idmap.input_base = input_base;
+rid_map->idmap.output_base = output_base;
+rid_map->idmap.id_count = id_count;
+rid_map->pcirc_node = pcirc_node;
+rid_map->smmu_node = smmu_node;
+
+list_add_tail(&rid_map->entry, &rid_streamid_map_list);
+return 0;
+}
+
+int add_rid_deviceid_map(struct acpi_iort_node *pcirc_node,
+ struct acpi_iort_node *its_node,
+ u32 input_base, u32 output_base, u32 id_count)
+{
+struct rid_deviceid_map *rid_map;
+rid_map = xzalloc(struct rid_deviceid_map);
+
+if (!rid_map)
+return -ENOMEM;
+
+rid_map->idmap.input_base = input_base;
+rid_map->idmap.output_base = output_base;
+rid_map->idmap.id_count = id_count;
+rid_map->pcirc_node = pcirc_node;
+rid_map->its_node = its_node;
+
+list_add_tail(&rid_map->entry, &rid_deviceid_map_list);
+return 0;
+}
+
+void query_streamid(struct acpi_iort_node *pcirc_node, u16 rid, u32 *streamid,
+struct acpi_iort_node **smmu_node)
+{
+struct rid_streamid_map *rmap;
+
+list_for_each_entry(rmap, &rid_streamid_map_list, entry)
+{
+if (rmap->pcirc_node == pcirc_node)
+{
+if ( (rid >= rmap->idmap.input_base) &&
+ (rid < rmap->idmap.input_base + rmap->idmap.id_count) )
+{
+*streamid = rid - rmap->idmap.input_base +
+rmap->idmap.output_base;
+*smmu_node = rmap->smmu_node;
+break;
+}
+}
+}
+
+}
+
+void query_deviceid(struct acpi_iort_node *pcirc_node, u16 rid, u32 *deviceid)
+{
+struct rid_deviceid_map *rmap;
+
+list_for_each_entry(rmap, &rid_deviceid_map_list, entry)
+{
+if (rmap->pcirc_node == pcirc_node)
+{
+if ( (rid >= rmap->idmap.input_base) &&
+ (rid < rmap->idmap.input_base + rmap->idmap.id_count) )
+{
+*deviceid = rid - rmap->idmap.input_base +
+rmap->idmap.output_base;
+break;
+}
+}
+}
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xe

[Xen-devel] [RFC 02/11] acpi: arm: API to query estimated size of hardware domain's IORT

[manish . jaggi]

From: Manish Jaggi 

 Code to query estimated IORT size for hardware domain.
 IORT for hardware domain is generated using the requesterId and deviceId map.

 Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/domain_build.c |  12 -
 xen/drivers/acpi/arm/Makefile   |   1 +
 xen/drivers/acpi/arm/gen-iort.c | 101 
 xen/include/acpi/gen-iort.h |   6 +++
 4 files changed, 119 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c74f4dd69d..f5d5e3d271 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1799,7 +1800,7 @@ static int acpi_create_fadt(struct domain *d, struct 
membank tbl_add[])
 
 static int estimate_acpi_efi_size(struct domain *d, struct kernel_info *kinfo)
 {
-size_t efi_size, acpi_size, madt_size;
+size_t efi_size, acpi_size, madt_size, iort_size;
 u64 addr;
 struct acpi_table_rsdp *rsdp_tbl;
 struct acpi_table_header *table;
@@ -1840,6 +1841,15 @@ static int estimate_acpi_efi_size(struct domain *d, 
struct kernel_info *kinfo)
 acpi_os_unmap_memory(table, sizeof(struct acpi_table_header));
 
 acpi_size += ROUNDUP(sizeof(struct acpi_table_rsdp), 8);
+
+if( estimate_iort_size(&iort_size) )
+{
+printk("Unable to get hwdom iort size\n");
+return -EINVAL;
+}
+
+acpi_size += ROUNDUP(iort_size, 8);
+
 d->arch.efi_acpi_len = PAGE_ALIGN(ROUNDUP(efi_size, 8)
   + ROUNDUP(acpi_size, 8));
 
diff --git a/xen/drivers/acpi/arm/Makefile b/xen/drivers/acpi/arm/Makefile
index 046fad5e3d..13f1a9159f 100644
--- a/xen/drivers/acpi/arm/Makefile
+++ b/xen/drivers/acpi/arm/Makefile
@@ -1 +1,2 @@
 obj-y = ridmap.o
+obj-y += gen-iort.o
diff --git a/xen/drivers/acpi/arm/gen-iort.c b/xen/drivers/acpi/arm/gen-iort.c
new file mode 100644
index 00..3fc32959c6
--- /dev/null
+++ b/xen/drivers/acpi/arm/gen-iort.c
@@ -0,0 +1,101 @@
+/*
+ * xen/drivers/acpi/arm/gen-iort.c
+ *
+ * Code to generate IORT for hardware domain using the requesterId
+ * and deviceId map.
+ *
+ * Manish Jaggi 
+ * Copyright (c) 2018 Linaro.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+
+/*
+ * Size of hardware domains iort is calulcated based on the number of
+ * mappings in the requesterId - deviceId mapping list.
+ */
+int estimate_iort_size(size_t *iort_size)
+{
+int count = 0;
+int pcirc_count = 0;
+int itsg_count = 0;
+uint64_t *pcirc_array;
+uint64_t *itsg_array;
+struct rid_deviceid_map *rmap;
+
+list_for_each_entry(rmap, &rid_deviceid_map_list, entry)
+count++;
+
+pcirc_array = xzalloc_bytes(sizeof(uint64_t)*count);
+if ( !pcirc_array )
+return -ENOMEM;
+
+itsg_array = xzalloc_bytes(sizeof(uint64_t)*count);
+if ( !itsg_array )
+return -ENOMEM;
+
+list_for_each_entry(rmap, &rid_deviceid_map_list, entry)
+{
+int i = 0;
+
+for (i=0; i <= pcirc_count; i++)
+{
+if ( pcirc_array[i] == (uint64_t)rmap->pcirc_node )
+break;
+if ( i == pcirc_count )
+{
+pcirc_array[i] = (uint64_t)rmap->pcirc_node;
+pcirc_count++;
+break;
+}
+}
+
+for ( i=0; i <= itsg_count; i++ )
+{
+if ( itsg_array[i] == (uint64_t) rmap->its_node )
+break;
+if ( i == itsg_count )
+{
+itsg_array[i] = (uint64_t)rmap->its_node;
+itsg_count++;
+break;
+}
+}
+}
+
+/* Size of IORT
+ * = Size of IORT Table Header + Size of PCIRC Header Nodes +
+ *   Size of PCIRC nodes + Size of ITS Header nodes + Size of ITS Nodes
+ *   + Size of Idmap nodes
+ */
+*iort_size = sizeof(struct acpi_table_iort) +
+ pcirc_count*( (sizeof(struct acpi_iort_node) -1) +
+   sizeof(struct acpi_iort_root_complex) ) +
+ itsg_count*( (sizeof(struct acpi_iort_node) -1) +
+   sizeof(struct acpi_iort_its_group) ) +
+ count*( sizeof(struct acpi_iort_id_mapping) );
+
+xfree(itsg_array);
+xfree(pcirc_array);
+
+return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode

[Xen-devel] [RFC 09/11] Xen IORT Changes

[manish . jaggi]

From: Manish Jaggi 

This patch adds xen specific changes to iort.c

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/setup.c  |2 +
 xen/drivers/acpi/arm/Makefile |1 +
 xen/drivers/acpi/arm/iort.c   | 1040 +++--
 xen/include/acpi/acpi_iort.h  |6 +-
 4 files changed, 71 insertions(+), 978 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 16a3b1be8e..7ada48920f 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -800,6 +801,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 tasklet_subsys_init();
 
+acpi_iort_init();
 
 xsm_dt_init();
 
diff --git a/xen/drivers/acpi/arm/Makefile b/xen/drivers/acpi/arm/Makefile
index 13f1a9159f..5d16161016 100644
--- a/xen/drivers/acpi/arm/Makefile
+++ b/xen/drivers/acpi/arm/Makefile
@@ -1,2 +1,3 @@
 obj-y = ridmap.o
 obj-y += gen-iort.o
+obj-y += iort.o
diff --git a/xen/drivers/acpi/arm/iort.c b/xen/drivers/acpi/arm/iort.c
index de56394dd1..a47ee2df4c 100644
--- a/xen/drivers/acpi/arm/iort.c
+++ b/xen/drivers/acpi/arm/iort.c
@@ -14,17 +14,20 @@
  * This file implements early detection/parsing of I/O mapping
  * reported to OS through firmware via I/O Remapping Table (IORT)
  * IORT document number: ARM DEN 0049A
+ *
+ * Imported from Linux 4.14.0
+ * Xen Modifications : Manish Jaggi 
  */
 
 #define pr_fmt(fmt)"ACPI: IORT: " fmt
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #define IORT_TYPE_MASK(type)   (1 << (type))
 #define IORT_MSI_TYPE  (1 << ACPI_IORT_NODE_ITS_GROUP)
@@ -36,6 +39,22 @@
 #define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX0x2
 #endif
 
+/* Redefine WARN macros */
+#undef WARN
+#undef WARN_ON
+#define WARN(condition, format...) ({  \
+   int __ret_warn_on = !!(condition);  \
+   if (unlikely(__ret_warn_on))\
+   printk(format); \
+   unlikely(__ret_warn_on);\
+})
+#define WARN_TAINT(cond, taint, format...) WARN(cond, format)
+#define WARN_ON(cond)  (!!cond)
+
+
+#define MAX_ERRNO  4095
+#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned 
long)-MAX_ERRNO)
+
 struct iort_its_msi_chip {
struct list_headlist;
struct fwnode_handle*fw_node;
@@ -49,7 +68,7 @@ struct iort_fwnode {
 };
 static LIST_HEAD(iort_fwnode_list);
 static DEFINE_SPINLOCK(iort_fwnode_lock);
-
+const struct fwnode_operations acpi_static_fwnode_ops;
 /**
  * iort_set_fwnode() - Create iort_fwnode and use it to register
  *iommu data in the iort_fwnode_list
@@ -73,7 +92,6 @@ static inline int iort_set_fwnode(struct acpi_iort_node 
*iort_node,
INIT_LIST_HEAD(&np->list);
np->iort_node = iort_node;
np->fwnode = fwnode;
-
spin_lock(&iort_fwnode_lock);
list_add_tail(&np->list, &iort_fwnode_list);
spin_unlock(&iort_fwnode_lock);
@@ -93,7 +111,6 @@ struct fwnode_handle *iort_get_fwnode(struct acpi_iort_node 
*node)
 {
struct iort_fwnode *curr;
struct fwnode_handle *fwnode = NULL;
-
spin_lock(&iort_fwnode_lock);
list_for_each_entry(curr, &iort_fwnode_list, list) {
if (curr->iort_node == node) {
@@ -132,79 +149,6 @@ typedef acpi_status (*iort_find_node_callback)
 /* Root pointer to the mapped IORT table */
 static struct acpi_table_header *iort_table;
 
-static LIST_HEAD(iort_msi_chip_list);
-static DEFINE_SPINLOCK(iort_msi_chip_lock);
-
-/**
- * iort_register_domain_token() - register domain token and related ITS ID
- * to the list from where we can get it back later on.
- * @trans_id: ITS ID.
- * @fw_node: Domain token.
- *
- * Returns: 0 on success, -ENOMEM if no memory when allocating list element
- */
-int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
-{
-   struct iort_its_msi_chip *its_msi_chip;
-
-   its_msi_chip = kzalloc(sizeof(*its_msi_chip), GFP_KERNEL);
-   if (!its_msi_chip)
-   return -ENOMEM;
-
-   its_msi_chip->fw_node = fw_node;
-   its_msi_chip->translation_id = trans_id;
-
-   spin_lock(&iort_msi_chip_lock);
-   list_add(&its_msi_chip->list, &iort_msi_chip_list);
-   spin_unlock(&iort_msi_chip_lock);
-
-   return 0;
-}
-
-/**
- * iort_deregister_domain_token() - Deregister domain token based on ITS ID
- * @trans_id: ITS ID.
- *
- * Returns: none.
- */
-void iort_deregister_domain_token(int trans_id)
-{
-   struct iort_its_msi_chip *its_msi_chip, *t;
-
-   spin_lock(&iort_msi_chip_lock);
-   list_for_each_entry_safe(its_msi_chip, t, &iort_msi_chip_list, list) {
-   if (it

[Xen-devel] [RFC 06/11] fwnode xen spacific changes

[manish . jaggi]

From: Manish Jaggi 

Merge few more changes from linux kernel code (v4.14) into iommu.c
Modify code specifc to xen.

Signed-off-by: Manish Jaggi 
---
 xen/drivers/passthrough/iommu.c | 75 +
 xen/include/asm-arm/device.h| 11 --
 xen/include/xen/iommu.h | 22 
 3 files changed, 106 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 1aecf7cf34..408f44106d 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -507,6 +508,80 @@ static void iommu_dump_p2m_table(unsigned char key)
 }
 }
 
+/**
+ * fwnode_handle_put - Drop reference to a device node
+ * @fwnode: Pointer to the device node to drop the reference to.
+ *
+ * This has to be used when terminating device_for_each_child_node() iteration
+ * with break or return to prevent stale device node references from being left
+ * behind.
+ */
+void fwnode_handle_put(struct fwnode_handle *fwnode)
+{
+fwnode_call_void_op(fwnode, put);
+}
+
+const struct iommu_ops *iommu_ops_from_fwnode(struct fwnode_handle *fwnode)
+{
+   return iommu_get_ops();
+}
+
+int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
+ const struct iommu_ops *ops)
+{
+   struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+   if (fwspec)
+   return ops == fwspec->ops ? 0 : -EINVAL;
+
+   fwspec = kzalloc(sizeof(*fwspec), GFP_KERNEL);
+   if (!fwspec)
+   return -ENOMEM;
+#if 0
+   of_node_get(to_of_node(iommu_fwnode));
+#endif
+   fwspec->iommu_fwnode = iommu_fwnode;
+   fwspec->ops = ops;
+   dev->iommu_fwspec = fwspec;
+   return 0;
+}
+
+void iommu_fwspec_free(struct device *dev)
+{
+   struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+   if (fwspec) {
+   fwnode_handle_put(fwspec->iommu_fwnode);
+   kfree(fwspec);
+   dev->iommu_fwspec = NULL;
+   }
+}
+
+int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
+{
+  struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+size_t size;
+int i;
+
+if (!fwspec)
+return -EINVAL;
+
+size = offsetof(struct iommu_fwspec, ids[fwspec->num_ids + num_ids]);
+if (size > sizeof(*fwspec)) {
+//TBD: fwspec = krealloc(dev->iommu_fwspec, size, GFP_KERNEL);
+if (!fwspec)
+return -ENOMEM;
+
+dev->iommu_fwspec = fwspec;
+}
+
+for (i = 0; i < num_ids; i++)
+fwspec->ids[fwspec->num_ids + i] = ids[i];
+
+fwspec->num_ids += num_ids;
+return 0;
+
+}
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 6734ae8efd..f78482ca0c 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -6,6 +6,8 @@
 enum device_type
 {
 DEV_DT,
+DEV_ACPI,
+DEV_PCI,
 };
 
 struct dev_archdata {
@@ -18,8 +20,13 @@ struct device
 enum device_type type;
 #ifdef CONFIG_HAS_DEVICE_TREE
 struct dt_device_node *of_node; /* Used by drivers imported from Linux */
+#endif
+#ifdef CONFIG_ACPI
+void *acpi_node;
 #endif
 struct dev_archdata archdata;
+struct fwnode_handle *fwnode; /* firmware device node */
+struct iommu_fwspec *iommu_fwspec;
 };
 
 typedef struct device device_t;
@@ -27,8 +34,8 @@ typedef struct device device_t;
 #include 
 
 /* TODO: Correctly implement dev_is_pci when PCI is supported on ARM */
-#define dev_is_pci(dev) ((void)(dev), 0)
-#define dev_is_dt(dev)  ((dev->type == DEV_DT)
+#define dev_is_pci(dev) (dev->type == DEV_PCI)
+#define dev_is_dt(dev)  (dev->type == DEV_DT)
 
 enum device_class
 {
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 33c8b221dc..56b169bae9 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -208,4 +208,26 @@ DECLARE_PER_CPU(bool_t, iommu_dont_flush_iotlb);
 extern struct spinlock iommu_pt_cleanup_lock;
 extern struct page_list_head iommu_pt_cleanup_list;
 
+/**
+ * struct iommu_fwspec - per-device IOMMU instance data
+ * @ops: ops for this device's IOMMU
+ * @iommu_fwnode: firmware handle for this device's IOMMU
+ * @iommu_priv: IOMMU driver private data for this device
+ * @num_ids: number of associated device IDs
+ * @ids: IDs which this device may present to the IOMMU
+ */
+struct iommu_fwspec {
+const struct iommu_ops  *ops;
+struct fwnode_handle*iommu_fwnode;
+void*iommu_priv;
+unsigned intnum_ids;
+u32 ids[1];
+};
+
+int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
+  const struct iommu_ops *ops);
+void iommu_fwspec_free(struct device *dev);
+int iommu_fwspec_add_i

[Xen-devel] [RFC 07/11] Add kernel helper functions

[manish . jaggi]

From: Manish Jaggi 

Add kalloc kfree functions from linux kernel.

Signed-off-by: Manish Jaggi 
---
 xen/include/xen/kernel.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h
index 548b64da9f..78517f6caa 100644
--- a/xen/include/xen/kernel.h
+++ b/xen/include/xen/kernel.h
@@ -7,6 +7,16 @@
 
 #include 
 
+/* Xen: Define compatibility functions */
+#define FW_BUG "[Firmware Bug]: "
+#define pr_err(fmt, ...) printk(XENLOG_ERR fmt, ## __VA_ARGS__)
+#define pr_warn(fmt, ...) printk(XENLOG_WARNING fmt, ## __VA_ARGS__)
+
+/* Alias to Xen allocation helpers */
+#define kfree xfree
+#define kmalloc(size, flags)_xmalloc(size, sizeof(void *))
+#define kzalloc(size, flags)_xzalloc(size, sizeof(void *))
+
 /*
  * min()/max() macros that also do
  * strict type-checking.. See the
-- 
2.14.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC 11/11] Add to_pci_dev macro

[manish . jaggi]

From: Manish Jaggi 

This patch adds to_pci_dev macro

Signed-off-by: Manish Jaggi 
---
 xen/include/xen/pci.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 43f21251a5..4c7ff4dd10 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -92,8 +92,11 @@ struct pci_dev {
 #define PT_FAULT_THRESHOLD 10
 } fault;
 u64 vf_rlen[6];
+struct device dev;
 };
 
+#define to_pci_dev(p) container_of(p, struct pci_dev, dev)
+#define pci_domain_nr(dev) dev->seg
 #define for_each_pdev(domain, pdev) \
 list_for_each_entry(pdev, &(domain->arch.pdev_list), domain_list)
 
-- 
2.14.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC 08/11] Add ACPI_IORT config

[manish . jaggi]

From: Manish Jaggi 

Add ACPI_IORT config

Singed-off-by: Manish Jaggi 
---
 xen/arch/arm/Kconfig | 5 +
 xen/drivers/acpi/Kconfig | 3 +++
 2 files changed, 8 insertions(+)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index f58019d6ed..d4767d6ea3 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -42,6 +42,11 @@ config ACPI
  Advanced Configuration and Power Interface (ACPI) support for Xen is
  an alternative to device tree on ARM64.
 
+config ACPI_IORT
+   bool
+   prompt "ACPI IORT Support" if EXPERT = "y"
+   depends on ACPI
+
 config HAS_GICV3
bool
 
diff --git a/xen/drivers/acpi/Kconfig b/xen/drivers/acpi/Kconfig
index b64d3731fb..15ae98140c 100644
--- a/xen/drivers/acpi/Kconfig
+++ b/xen/drivers/acpi/Kconfig
@@ -5,5 +5,8 @@ config ACPI
 config ACPI_LEGACY_TABLES_LOOKUP
bool
 
+config ACPI_IORT
+   bool
+
 config NUMA
bool
-- 
2.14.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC 10/11] IORT parsing functions to prepare requesterId maps

[manish . jaggi]

From: Manish Jaggi 

This patch adds functions to parse the IORT and use the requesterID public API
to update the maps.

Signed-off-by: Manish jaggi 
---
 xen/drivers/acpi/arm/iort.c | 200 
 1 file changed, 200 insertions(+)

diff --git a/xen/drivers/acpi/arm/iort.c b/xen/drivers/acpi/arm/iort.c
index a47ee2df4c..00a9f18046 100644
--- a/xen/drivers/acpi/arm/iort.c
+++ b/xen/drivers/acpi/arm/iort.c
@@ -353,6 +353,205 @@ static inline struct fwnode_handle 
*acpi_alloc_fwnode_static(void)
return fwnode;
 }
 
+static inline bool __must_check IS_ERR_OR_NULL(__force const void *ptr)
+{
+   return unlikely(!ptr) || IS_ERR_VALUE((unsigned long)ptr);
+}
+
+static inline bool is_acpi_static_node(const struct fwnode_handle *fwnode)
+{
+   return !IS_ERR_OR_NULL(fwnode) &&
+   fwnode->ops == &acpi_static_fwnode_ops;
+}
+
+static inline void acpi_free_fwnode_static(struct fwnode_handle *fwnode)
+{
+   if (WARN_ON(!is_acpi_static_node(fwnode)))
+   return;
+
+   kfree(fwnode);
+}
+int fixup_rid_deviceid_map(struct acpi_iort_node *inode,
+   struct acpi_iort_id_mapping *pci_idmap,
+   struct acpi_iort_node *smmu_node)
+{
+
+   unsigned int p_input_base, p_output_base, p_id_count;
+   unsigned int s_input_base, s_output_base, s_id_count;
+   unsigned int delta, i;
+   int ret = 0;
+   struct acpi_iort_id_mapping *smmu_idmap = NULL;
+   struct acpi_iort_node *its_node;
+   struct acpi_table_iort *iort;
+
+   iort = (struct acpi_table_iort*) iort_table;
+
+   p_input_base = pci_idmap->input_base;
+   p_output_base = pci_idmap->output_base;
+   p_id_count = pci_idmap->id_count;
+
+   smmu_idmap = (struct acpi_iort_id_mapping*) ((u8*) smmu_node +
+ smmu_node->mapping_offset);
+
+   for (i = 0; i < smmu_node->mapping_count; i++, smmu_idmap++) {
+   s_input_base = smmu_idmap->input_base;
+   s_output_base = smmu_idmap->output_base;
+   s_id_count = smmu_idmap->id_count;
+   its_node = ACPI_ADD_PTR(struct acpi_iort_node, iort,
+   smmu_idmap->output_reference);
+
+   if (s_input_base <= p_output_base) {
+   int count;
+   if (s_input_base + s_id_count < p_output_base)
+   continue;
+
+   delta = p_output_base - s_input_base;
+   count = s_input_base + s_id_count <= p_output_base +
+   p_id_count ? s_id_count - delta : p_id_count;
+
+   ret = add_rid_deviceid_map (inode, its_node,
+   p_input_base,
+   s_output_base + delta,
+   count);
+   if (ret)
+   return ret;
+   } else {
+   int count;
+   if (p_output_base + p_id_count < s_input_base)
+   continue;
+
+   delta = s_input_base - p_output_base;
+   count = s_input_base + s_id_count < p_output_base +
+   p_id_count ? s_id_count : p_id_count - delta;
+
+   ret = add_rid_deviceid_map (inode, its_node,
+   p_input_base + delta,
+   s_output_base, count);
+
+   if (ret)
+   return ret;
+   }
+   }
+
+   return ret;
+}
+
+void parse_pcirc_node(struct acpi_iort_node *iort_node)
+{
+   int j , ret;
+   struct acpi_iort_id_mapping *idmap;
+   struct acpi_iort_node *onode;
+   struct acpi_table_iort *iort;
+
+   iort = (struct acpi_table_iort*) iort_table;
+   idmap = ACPI_ADD_PTR(struct acpi_iort_id_mapping, iort_node,
+iort_node->mapping_offset);
+
+   /* iterate over idmap */
+   for ( j = 0; j < iort_node->mapping_count; j++ ) {
+
+   struct acpi_iort_node *its_node;
+   struct acpi_iort_node *smmu_node;
+   onode = ACPI_ADD_PTR(struct acpi_iort_node, iort,
+idmap->output_reference);
+
+   switch (onode->type) {
+   case ACPI_IORT_NODE_ITS_GROUP:
+
+   its_node = ACPI_ADD_PTR(struct acpi_iort_node, 
iort,
+   
idmap->output_reference);
+
+   ret = add_rid_deviceid_map(iort_node, its_node,
+  idmap->input_base,
+  idmap->output_base,
+ 

[Xen-devel] [RFC 04/11] Import iort.c and acpi_iort.h

[manish . jaggi]

From: Manish Jaggi 

Import iort.c and acpi_iort.h from linux kernel tag v4.14

Signed-off-by: Manish Jaggi 
---
 xen/drivers/acpi/arm/iort.c  | 1279 ++
 xen/include/acpi/acpi_iort.h |   57 ++
 2 files changed, 1336 insertions(+)

diff --git a/xen/drivers/acpi/arm/iort.c b/xen/drivers/acpi/arm/iort.c
new file mode 100644
index 00..de56394dd1
--- /dev/null
+++ b/xen/drivers/acpi/arm/iort.c
@@ -0,0 +1,1279 @@
+/*
+ * Copyright (C) 2016, Semihalf
+ * Author: Tomasz Nowicki 
+ *
+ * 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.
+ *
+ * This file implements early detection/parsing of I/O mapping
+ * reported to OS through firmware via I/O Remapping Table (IORT)
+ * IORT document number: ARM DEN 0049A
+ */
+
+#define pr_fmt(fmt)"ACPI: IORT: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IORT_TYPE_MASK(type)   (1 << (type))
+#define IORT_MSI_TYPE  (1 << ACPI_IORT_NODE_ITS_GROUP)
+#define IORT_IOMMU_TYPE((1 << ACPI_IORT_NODE_SMMU) |   \
+   (1 << ACPI_IORT_NODE_SMMU_V3))
+
+/* Until ACPICA headers cover IORT rev. C */
+#ifndef ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
+#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX0x2
+#endif
+
+struct iort_its_msi_chip {
+   struct list_headlist;
+   struct fwnode_handle*fw_node;
+   u32 translation_id;
+};
+
+struct iort_fwnode {
+   struct list_head list;
+   struct acpi_iort_node *iort_node;
+   struct fwnode_handle *fwnode;
+};
+static LIST_HEAD(iort_fwnode_list);
+static DEFINE_SPINLOCK(iort_fwnode_lock);
+
+/**
+ * iort_set_fwnode() - Create iort_fwnode and use it to register
+ *iommu data in the iort_fwnode_list
+ *
+ * @node: IORT table node associated with the IOMMU
+ * @fwnode: fwnode associated with the IORT node
+ *
+ * Returns: 0 on success
+ *  <0 on failure
+ */
+static inline int iort_set_fwnode(struct acpi_iort_node *iort_node,
+ struct fwnode_handle *fwnode)
+{
+   struct iort_fwnode *np;
+
+   np = kzalloc(sizeof(struct iort_fwnode), GFP_ATOMIC);
+
+   if (WARN_ON(!np))
+   return -ENOMEM;
+
+   INIT_LIST_HEAD(&np->list);
+   np->iort_node = iort_node;
+   np->fwnode = fwnode;
+
+   spin_lock(&iort_fwnode_lock);
+   list_add_tail(&np->list, &iort_fwnode_list);
+   spin_unlock(&iort_fwnode_lock);
+
+   return 0;
+}
+
+/**
+ * iort_get_fwnode() - Retrieve fwnode associated with an IORT node
+ *
+ * @node: IORT table node to be looked-up
+ *
+ * Returns: fwnode_handle pointer on success, NULL on failure
+ */
+static inline
+struct fwnode_handle *iort_get_fwnode(struct acpi_iort_node *node)
+{
+   struct iort_fwnode *curr;
+   struct fwnode_handle *fwnode = NULL;
+
+   spin_lock(&iort_fwnode_lock);
+   list_for_each_entry(curr, &iort_fwnode_list, list) {
+   if (curr->iort_node == node) {
+   fwnode = curr->fwnode;
+   break;
+   }
+   }
+   spin_unlock(&iort_fwnode_lock);
+
+   return fwnode;
+}
+
+/**
+ * iort_delete_fwnode() - Delete fwnode associated with an IORT node
+ *
+ * @node: IORT table node associated with fwnode to delete
+ */
+static inline void iort_delete_fwnode(struct acpi_iort_node *node)
+{
+   struct iort_fwnode *curr, *tmp;
+
+   spin_lock(&iort_fwnode_lock);
+   list_for_each_entry_safe(curr, tmp, &iort_fwnode_list, list) {
+   if (curr->iort_node == node) {
+   list_del(&curr->list);
+   kfree(curr);
+   break;
+   }
+   }
+   spin_unlock(&iort_fwnode_lock);
+}
+
+typedef acpi_status (*iort_find_node_callback)
+   (struct acpi_iort_node *node, void *context);
+
+/* Root pointer to the mapped IORT table */
+static struct acpi_table_header *iort_table;
+
+static LIST_HEAD(iort_msi_chip_list);
+static DEFINE_SPINLOCK(iort_msi_chip_lock);
+
+/**
+ * iort_register_domain_token() - register domain token and related ITS ID
+ * to the list from where we can get it back later on.
+ * @trans_id: ITS ID.
+ * @fw_node: Domain token.
+ *
+ * Returns: 0 on success, -ENOMEM if no memory when allocating list element
+ */
+int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
+{
+   struct iort_its_msi_chip *its_msi_chip;
+
+   its_msi_chip = kzalloc(sizeof(*its_msi_chip), GFP_KERNEL);
+   if (!its_msi_chip)
+

[Xen-devel] [RFC 05/11] Import fwnode.h from linux

[manish . jaggi]

From: Manish Jaggi 

Import fwnode.h from linux kernel tag v4.14

Signed-off-by: Manish Jaggi 
---
 xen/include/xen/fwnode.h | 125 +++
 1 file changed, 125 insertions(+)

diff --git a/xen/include/xen/fwnode.h b/xen/include/xen/fwnode.h
new file mode 100644
index 00..af186a9dc6
--- /dev/null
+++ b/xen/include/xen/fwnode.h
@@ -0,0 +1,125 @@
+/*
+ * fwnode.h - Firmware device node object handle type definition.
+ *
+ * Copyright (C) 2015, Intel Corporation
+ * Author: Rafael J. Wysocki 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _LINUX_FWNODE_H_
+#define _LINUX_FWNODE_H_
+
+#include 
+
+struct fwnode_operations;
+
+struct fwnode_handle {
+   struct fwnode_handle *secondary;
+   const struct fwnode_operations *ops;
+};
+
+/**
+ * struct fwnode_endpoint - Fwnode graph endpoint
+ * @port: Port number
+ * @id: Endpoint id
+ * @local_fwnode: reference to the related fwnode
+ */
+struct fwnode_endpoint {
+   unsigned int port;
+   unsigned int id;
+   const struct fwnode_handle *local_fwnode;
+};
+
+#define NR_FWNODE_REFERENCE_ARGS   8
+
+/**
+ * struct fwnode_reference_args - Fwnode reference with additional arguments
+ * @fwnode:- A reference to the base fwnode
+ * @nargs: Number of elements in @args array
+ * @args: Integer arguments on the fwnode
+ */
+struct fwnode_reference_args {
+   struct fwnode_handle *fwnode;
+   unsigned int nargs;
+   unsigned int args[NR_FWNODE_REFERENCE_ARGS];
+};
+
+/**
+ * struct fwnode_operations - Operations for fwnode interface
+ * @get: Get a reference to an fwnode.
+ * @put: Put a reference to an fwnode.
+ * @property_present: Return true if a property is present.
+ * @property_read_integer_array: Read an array of integer properties. Return
+ *  zero on success, a negative error code
+ *  otherwise.
+ * @property_read_string_array: Read an array of string properties. Return zero
+ * on success, a negative error code otherwise.
+ * @get_parent: Return the parent of an fwnode.
+ * @get_next_child_node: Return the next child node in an iteration.
+ * @get_named_child_node: Return a child node with a given name.
+ * @get_reference_args: Return a reference pointed to by a property, with args
+ * @graph_get_next_endpoint: Return an endpoint node in an iteration.
+ * @graph_get_remote_endpoint: Return the remote endpoint node of a local
+ *endpoint node.
+ * @graph_get_port_parent: Return the parent node of a port node.
+ * @graph_parse_endpoint: Parse endpoint for port and endpoint id.
+ */
+struct fwnode_operations {
+   void (*get)(struct fwnode_handle *fwnode);
+   void (*put)(struct fwnode_handle *fwnode);
+   bool (*device_is_available)(const struct fwnode_handle *fwnode);
+   bool (*property_present)(const struct fwnode_handle *fwnode,
+const char *propname);
+   int (*property_read_int_array)(const struct fwnode_handle *fwnode,
+  const char *propname,
+  unsigned int elem_size, void *val,
+  size_t nval);
+   int
+   (*property_read_string_array)(const struct fwnode_handle *fwnode_handle,
+ const char *propname, const char **val,
+ size_t nval);
+   struct fwnode_handle *(*get_parent)(const struct fwnode_handle *fwnode);
+   struct fwnode_handle *
+   (*get_next_child_node)(const struct fwnode_handle *fwnode,
+  struct fwnode_handle *child);
+   struct fwnode_handle *
+   (*get_named_child_node)(const struct fwnode_handle *fwnode,
+   const char *name);
+   int (*get_reference_args)(const struct fwnode_handle *fwnode,
+ const char *prop, const char *nargs_prop,
+ unsigned int nargs, unsigned int index,
+ struct fwnode_reference_args *args);
+   struct fwnode_handle *
+   (*graph_get_next_endpoint)(const struct fwnode_handle *fwnode,
+  struct fwnode_handle *prev);
+   struct fwnode_handle *
+   (*graph_get_remote_endpoint)(const struct fwnode_handle *fwnode);
+   struct fwnode_handle *
+   (*graph_get_port_parent)(struct fwnode_handle *fwnode);
+   int (*graph_parse_endpoint)(const struct fwnode_handle *fwnode,
+   struct fwnode_endpoint *endpoint);
+};
+
+#define fwnode_has_op(fwnode, op)  \
+   ((fwnode) && (fwnode)->ops && (fwnode)->ops->op)
+#define fwnode_call_int_op(fwnode, op, .

Re: [Xen-devel] [PATCH v2] x86: implement cpu_possible_map

[Jan Beulich]

>>> On 28.12.17 at 18:25,  wrote:
> On x86 cpu_possible_map is not defined, so trying to use
> num_possible_cpus will generate link time errors.

I think this makes sense only in connection with a patch actually
requiring the symbol. The variable isn't there on x86 (anymore
iirc) for the very reason that the last user has long gone.

> @@ -1474,11 +1475,14 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  {
>  max_cpus = 0;
>  set_nr_cpu_ids(1);
> +__cpumask_set_cpu(0, &cpu_possible_map);
>  }
>  else
>  {
>  set_nr_cpu_ids(max_cpus);
>  max_cpus = nr_cpu_ids;
> +for ( i = 0; i < nr_cpu_ids; i++ )
> +__cpumask_set_cpu(i, &cpu_possible_map);
>  }

Considering this - why can't you use nr_cpu_ids instead of
num_possible_cpus?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Problem creating x86_64 PVH mini-os domain

[Bruno Alvisio]

On Sun, Dec 31, 2017 at 5:12 PM, Andrew Cooper 
wrote:

> On 31/12/2017 15:19, Bruno Alvisio wrote:
>
> Hi all,
>
>
>
> I was trying to create mini-os PVH instances both x86_32 and x86_64. I
> have no issue with x86_32 but when trying to ‘xl create’ x86_64 type I get
> the following error:
>
>
> 
>
> xc: error: panic: xc_dom_hvmloader.c:113: xc_dom_parse_hvm_kernel: ELF
> image is not 32bit: Invalid kernel
>
>
> The domain loader only ever accepts elf32 images, because the starting
> state is 32bit flat mode.
>
> This is how XTF deals with the problem:
>
> http://xenbits.xen.org/gitweb/?p=xtf.git;a=blob;f=build/gen.mk;h=
> 8d7a6bf89725fedc8343d2e4d3c8e2c93c16811f;hb=HEAD#l47
>
> There is a lot of template meta-programming in there, but basically after
> doing the final link, do a further objcopy to convert the image to
> elf32-x86-64 (if available), or elf32-i386.  The former is only available
> if you have an x32 toolchain, and allows the binary to load properly and
> disassemble correctly.
>

Thank you. Doing:

$objcopy  -O elf32-x86-64 

 worked perfectly!

>
>  Happy New Year!
>
>
> Happy new year.
>
> ~Andrew
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] x86/hvm: Add MSR old value

[Jan Beulich]

>>> On 22.12.17 at 10:09,  wrote:
> On 12/05/2017 11:07 AM, Jan Beulich wrote:
> On 04.12.17 at 16:45,  wrote:
  On Fri, Oct 13, 2017 at 03:50:57PM +0300, Alexandru Isaila wrote:
> This patch adds the old value param and the onchangeonly option
> to the VM_EVENT_REASON_MOV_TO_MSR event.
>
> The param was added to the vm_event_mov_to_msr struct and to the
> hvm_monitor_msr function. Finally I've changed the bool_t param
> to a bool for the hvm_msr_write_intercept function.
>
> Signed-off-by: Alexandru Isaila 
> Acked-by: Tamas K Lengyel 
>
> ---
> Changes since V1:
>   - Removed Stray blanks inside the inner parentheses
>   - Added space after the if statement
>   - Added * 8 to the set/clear/test_bit statements
>   - Removed the blank line after monitored_msr.
> ---
>  tools/libxc/include/xenctrl.h |  2 +-
>  tools/libxc/xc_monitor.c  |  3 ++-

 Acked-by: Wei Liu 
>>>
>>> Ping - AFAICT this patch has all the required acks?
>> 
>> Sure, and it is not being forgotten. But the tree is not fully open
>> yet, so it is subject to the judgment of committers whether any
>> patch (or series) is suitable of committing at this point. I did think
>> about committing this patch yesterday, but decided against
>> doing so. Please be a little more patient - even once the tree is
>> fully open, a few working days should be allowed for everyone
>> to deal with backlog, before sending pings.
> 
> Sorry for the previous early ping. Just to check: is there action
> required on our part for this patch post-4.10 (rebasing, etc.)?

I think when I had last looked I did get the (wrong) impression
that there was a missing ack. I'll try to remember to commit this
with the next batch.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen release cycle revisited

[Lars Kurth]

Hi Juergen:

thank you for raising this. As far as I can tell, the switch to the 6-monthly 
release model has had some consequences, some of which were predicted, others 
were not. So, I think we should probably review the decision. 

Key concerns raised:
• Too much work in actively maintaining 4 branches (6 security branches)
• Impact on users (too many releases)
• I think we are definitely incurring higher overheads than with longer cycles
• It is not clear to me whether one of the key benefits – aka vendors getting 
patches into tree more easily – has in fact materialized
• Better release predictability has materialized

Maybe the right approach would be to kick off some kind of survey to gather 
input from different stake-holders and maybe plan 4.11 for June. If there is a 
consensus for a change to say a year cadence, we probably wouldn’t execute this 
until 4.12 anyway. 

Maybe make some minor adjustments for the 4.11 cycle based on this thread, if 
it makes sense to do so.

Regards
Lars

On 14/12/2017, 07:56, "Juergen Gross"  wrote:

Hi all,

with 4.10 more or less finished it is time to plan for the next release
4.11. Since 4.7 we are using a 6 month release cycle [1] targeting to
release in June and December.

While this worked reasonably well for 4.7, 4.8 and 4.9 we had some
difficulties with 4.10: bad luck with security patch timing shifted the
4.10 release more towards mid of December. Doing thorough testing of the
latest security patches and trying to release at least 10 days before
Christmas seemed to be almost mutually exclusive goals.

So what do we learn from this experience?

1. Should we think about other planned release dates (e.g. May and
   November - would that collide with any holiday season)?

2. Shouldn't we have tried to include the latest security patches in
   4.10, resulting in the need for 4.10.1 at once?

3. Should we let the release slip for almost a month in such a case?

4. Should we try harder to negotiate embargo dates of security issues to
   match the (targeted) release dates?

5. Should we modify the development/hardening periods?

For 4.11 we shouldn't have this problem: while targeted for releasing in
early June it wouldn't be a nightmare to let it slip into July. 4.12
however will probably face the same problem again and we should prepare
for that possibility.


Juergen

[1]: https://lists.xen.org/archives/html/xen-devel/2015-10/msg00263.html


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [distros-debian-snapshot test] 73776: trouble: blocked/broken

[Platform Team regression test user]

flight 73776 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/73776/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvopsbroken
 build-i386   broken
 build-amd64-pvopsbroken
 build-armhf  broken
 build-amd64  broken
 build-i386-pvops broken
 build-armhf-pvops 5 capture-logsbroken REGR. vs. 73412
 build-armhf   5 capture-logsbroken REGR. vs. 73412
 build-armhf-pvops 3 syslog-serverrunning
 build-armhf   3 syslog-serverrunning

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-i386-daily-netboot-pygrub  1 build-check(1)   blocked n/a
 test-armhf-armhf-armhf-daily-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-i386-i386-current-netinst-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-weekly-netinst-pygrub  1 build-check(1)  blocked n/a
 test-amd64-i386-amd64-weekly-netinst-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-current-netinst-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-current-netinst-pygrub  1 build-check(1)blocked n/a
 test-amd64-i386-amd64-current-netinst-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-daily-netboot-pvgrub  1 build-check(1)  blocked n/a
 test-amd64-i386-i386-daily-netboot-pvgrub  1 build-check(1)blocked n/a
 test-amd64-i386-i386-weekly-netinst-pygrub  1 build-check(1)   blocked n/a
 test-amd64-amd64-amd64-weekly-netinst-pygrub  1 build-check(1) blocked n/a
 test-amd64-i386-amd64-daily-netboot-pygrub  1 build-check(1)   blocked n/a
 build-armhf-pvops 4 host-install(4)  broken like 73412
 build-armhf   4 host-install(4)  broken like 73412
 build-amd64-pvops 4 host-install(4)  broken like 73412
 build-i386-pvops  4 host-install(4)  broken like 73412
 build-i3864 host-install(4)  broken like 73412
 build-amd64   4 host-install(4)  broken like 73412

baseline version:
 flight   73412

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-daily-netboot-pvgrub  blocked 
 test-amd64-i386-i386-daily-netboot-pvgrubblocked 
 test-amd64-i386-amd64-daily-netboot-pygrub   blocked 
 test-armhf-armhf-armhf-daily-netboot-pygrub  blocked 
 test-amd64-amd64-i386-daily-netboot-pygrub   blocked 
 test-amd64-amd64-amd64-current-netinst-pygrubblocked 
 test-amd64-i386-amd64-current-netinst-pygrub blocked 
 test-amd64-amd64-i386-current-netinst-pygrub blocked 
 test-amd64-i386-i386-current-netinst-pygrub  blocked 
 test-amd64-amd64-amd64-weekly-netinst-pygrub blocked 
 test-amd64-i386-amd64-weekly-netinst-pygrub  blocked 
 test-amd64-amd64-i386-weekly-netinst-pygrub  blocked 
 test-amd64-i386-i386-weekly-netinst-pygrub   blocked 



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen release cycle revisited

[Juergen Gross]

On 02/01/18 13:54, Lars Kurth wrote:
> Hi Juergen:
> 
> thank you for raising this. As far as I can tell, the switch to the 6-monthly 
> release model has had some consequences, some of which were predicted, others 
> were not. So, I think we should probably review the decision. 
> 
> Key concerns raised:
> • Too much work in actively maintaining 4 branches (6 security branches)
> • Impact on users (too many releases)
> • I think we are definitely incurring higher overheads than with longer cycles
> • It is not clear to me whether one of the key benefits – aka vendors getting 
> patches into tree more easily – has in fact materialized
> • Better release predictability has materialized
> 
> Maybe the right approach would be to kick off some kind of survey to gather 
> input from different stake-holders and maybe plan 4.11 for June. If there is 
> a consensus for a change to say a year cadence, we probably wouldn’t execute 
> this until 4.12 anyway.

Okay, in case nobody objects I'll send out the 4.11 plan on Friday.
I'm planning for a timeline like:

* Last posting date: March 16th, 2018
* Hard code freeze: March 30th, 2018
* Release: June 1st, 2018


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/xen/time: fix section mismatch for xen_init_time_ops()

[Boris Ostrovsky]

On 12/23/2017 09:50 PM, Nick Desaulniers wrote:
> The header declares this function as __init but is defined in __ref
> section.
>
> Signed-off-by: Nick Desaulniers 

AFAIK section attributes in header files are ignored by compiler anyway
so I'd remove all of them.

-boris


> ---
>  arch/x86/xen/xen-ops.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
> index 75011b8..3b34745 100644
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -72,7 +72,7 @@ u64 xen_clocksource_read(void);
>  void xen_setup_cpu_clockevents(void);
>  void xen_save_time_memory_area(void);
>  void xen_restore_time_memory_area(void);
> -void __init xen_init_time_ops(void);
> +void __ref xen_init_time_ops(void);
>  void __init xen_hvm_init_time_ops(void);
>  
>  irqreturn_t xen_debug_interrupt(int irq, void *dev_id);


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] xen/x86: Drop unnecessary barriers

[Andrew Cooper]

x86's current implementation of wmb() is a compiler barrier.  As a result, the
only change in this patch is to remove an mfence instruction from
cpuidle_disable_deep_cstate().

None of these barriers serve any purpose.  They are not synchronising with
remote cpus, and their compiler-barrier properties are not needed for
correctness purposes.

Furthermore, these wmb()'s specifically do not want to turn into sfence
instructions in future changes where wmb()'s implementation is corrected.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/acpi/cpu_idle.c  | 2 --
 xen/arch/x86/cpu/mcheck/mce.c | 3 ---
 xen/arch/x86/crash.c  | 3 ---
 xen/arch/x86/smpboot.c| 2 --
 4 files changed, 10 deletions(-)

diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 884ee32..cb1c5da 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -1341,8 +1341,6 @@ void cpuidle_disable_deep_cstate(void)
 max_cstate = 1;
 }
 
-mb();
-
 hpet_disable_legacy_broadcast();
 }
 
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index df0106e..a8c287d 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -86,7 +86,6 @@ static x86_mce_vector_t _machine_check_vector = 
unexpected_machine_check;
 void x86_mce_vector_register(x86_mce_vector_t hdlr)
 {
 _machine_check_vector = hdlr;
-wmb();
 }
 
 /* Call the installed machine check handler for this CPU setup. */
@@ -385,8 +384,6 @@ mcheck_mca_logout(enum mca_source who, struct mca_banks 
*bankmask,
 mcabank_clear(i);
 else if ( who == MCA_MCE_SCAN && need_clear )
 mcabanks_set(i, clear_bank);
-
-wmb();
 }
 
 if ( mig && errcnt > 0 )
diff --git a/xen/arch/x86/crash.c b/xen/arch/x86/crash.c
index 82535c4..8d74258 100644
--- a/xen/arch/x86/crash.c
+++ b/xen/arch/x86/crash.c
@@ -146,9 +146,6 @@ static void nmi_shootdown_cpus(void)
 write_atomic((unsigned long *)__va(__pa(&exception_table[TRAP_nmi])),
  (unsigned long)&do_nmi_crash);
 
-/* Ensure the new callback function is set before sending out the NMI. */
-wmb();
-
 smp_send_nmi_allbutself();
 
 msecs = 1000; /* Wait at most a second for the other cpus to stop */
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 0e585b3..7b97ff8 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -361,7 +361,6 @@ void start_secondary(void *unused)
 spin_debug_enable();
 set_cpu_sibling_map(cpu);
 notify_cpu_starting(cpu);
-wmb();
 
 /*
  * We need to hold vector_lock so there the set of online cpus
@@ -377,7 +376,6 @@ void start_secondary(void *unused)
 local_irq_enable();
 mtrr_ap_init();
 
-wmb();
 startup_cpu_idle_loop();
 }
 
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/xen/time: fix section mismatch for xen_init_time_ops()

[Juergen Gross]

On 02/01/18 15:18, Boris Ostrovsky wrote:
> On 12/23/2017 09:50 PM, Nick Desaulniers wrote:
>> The header declares this function as __init but is defined in __ref
>> section.
>>
>> Signed-off-by: Nick Desaulniers 
> 
> AFAIK section attributes in header files are ignored by compiler anyway
> so I'd remove all of them.

Hmm, I'm not sure all future compilers will ignore the section
attributes. include/linux/init.h explictily mentions where to put
the attrubute in a prototype, so I'd rather keep it.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/xen/time: fix section mismatch for xen_init_time_ops()

[Andrew Cooper]

On 02/01/18 14:24, Juergen Gross wrote:
> On 02/01/18 15:18, Boris Ostrovsky wrote:
>> On 12/23/2017 09:50 PM, Nick Desaulniers wrote:
>>> The header declares this function as __init but is defined in __ref
>>> section.
>>>
>>> Signed-off-by: Nick Desaulniers 
>> AFAIK section attributes in header files are ignored by compiler anyway
>> so I'd remove all of them.
> Hmm, I'm not sure all future compilers will ignore the section
> attributes. include/linux/init.h explictily mentions where to put
> the attrubute in a prototype, so I'd rather keep it.

Attributes in the declaration are for static analysis tools such as sparse.

How else are you going to work out whether a section mismatch has occurred?

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/xen/time: fix section mismatch for xen_init_time_ops()

[Boris Ostrovsky]

On 01/02/2018 09:32 AM, Andrew Cooper wrote:
> On 02/01/18 14:24, Juergen Gross wrote:
>> On 02/01/18 15:18, Boris Ostrovsky wrote:
>>> On 12/23/2017 09:50 PM, Nick Desaulniers wrote:
 The header declares this function as __init but is defined in __ref
 section.

 Signed-off-by: Nick Desaulniers 
>>> AFAIK section attributes in header files are ignored by compiler anyway
>>> so I'd remove all of them.
>> Hmm, I'm not sure all future compilers will ignore the section
>> attributes. include/linux/init.h explictily mentions where to put
>> the attrubute in a prototype, so I'd rather keep it.
> Attributes in the declaration are for static analysis tools such as sparse.
>
> How else are you going to work out whether a section mismatch has occurred?

Isn't this done based on definitions?

Tons of __init routines don't have the attribute specified in header
files. In fact, even in this file (arch/x86/xen/xen-ops.h) there are
some that don't have it.

-boris

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen release cycle revisited

[Steven Haigh]

On Tuesday, 2 January 2018 11:54:43 PM AEDT Lars Kurth wrote:
> Hi Juergen:
> 
> thank you for raising this. As far as I can tell, the switch to the
> 6-monthly release model has had some consequences, some of which were
> predicted, others were not. So, I think we should probably review the
> decision. 
 
> Key concerns raised:
> • Too much work in actively maintaining 4 branches (6 security branches)
> • Impact on users (too many releases)
> • I think we are definitely incurring higher overheads than with longer
> cycles
 • It is not clear to me whether one of the key benefits – aka
> vendors getting patches into tree more easily – has in fact materialized •
> Better release predictability has materialized
> 
> Maybe the right approach would be to kick off some kind of survey to gather
> input from different stake-holders and maybe plan 4.11 for June. If there
> is a consensus for a change to say a year cadence, we probably wouldn’t
> execute this until 4.12 anyway. 

I would like to propose for consideration:

* 12 months between major releases (x.y)
* 3 or 4 months between point releases (x.y.z)

This way, we roll up all XSAs etc into a x.y.z release on a regular basis - 
which I believe would make the security teams job easier (let me know if I'm 
wrong with this?).

Then aim to release x.y+1 (or maybe x+1?) in, say, June each year.

I'm not sure if there has been a set time frame as a goal for x.y.z releases - 
from my not so close observations, they seem to be somewhat adhoc.

As always though - more than happy to get feedback / comments on the above.

-- 
Steven Haigh

📧 net...@crc.id.au   💻 http://www.crc.id.au
📞 +61 (3) 9001 6090📱 0412 935 897

signature.asc
Description: This is a digitally signed message part.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] xen: Add EFI_LOAD_OPTION support

[Tamas K Lengyel]

When booting Xen via UEFI the Xen config file can contain multiple sections
each describing different boot options. It is currently only possible to choose
which section to boot with if Xen is started through an EFI Shell. As UEFI
provides a standard to pass optional arguments to an application in this patch
we make Xen properly parse this buffer, thus making it possible to have
separate EFI boot options present for the different config sections.

Signed-off-by: Tamas K Lengyel 
---
Cc: Jan Beulich 
Cc: ope...@googlegroups.com
---
 xen/common/efi/boot.c| 41 ++--
 xen/include/efi/efiapi.h | 54 
 2 files changed, 89 insertions(+), 6 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 469bf980cc..b12261b662 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -236,7 +236,7 @@ static void __init DisplayUint(UINT64 Val, INTN Width)
 PrintStr(PrintString);
 }
 
-static size_t __init __maybe_unused wstrlen(const CHAR16 *s)
+static size_t __init wstrlen(const CHAR16 *s)
 {
 const CHAR16 *sc;
 
@@ -375,12 +375,40 @@ static void __init PrintErrMesg(const CHAR16 *mesg, 
EFI_STATUS ErrCode)
 
 static unsigned int __init get_argv(unsigned int argc, CHAR16 **argv,
 CHAR16 *cmdline, UINTN cmdsize,
-CHAR16 **options)
+CHAR16 **options, bool *elo_active)
 {
 CHAR16 *ptr = (CHAR16 *)(argv + argc + 1), *prev = NULL;
 bool prev_sep = true;
 
-for ( ; cmdsize > sizeof(*cmdline) && *cmdline;
+if ( cmdsize > sizeof(EFI_LOAD_OPTION) )
+{
+/*
+ * See include/efi/efiapi.h for more info about the following
+ */
+EFI_LOAD_OPTION *elo = (EFI_LOAD_OPTION*)cmdline;
+
+if ( elo->Attributes & LOAD_OPTION_ACTIVE )
+{
+UINT8 *_opts = (UINT8*)elo;
+UINTN _cmdsize = cmdsize;
+
+_opts += sizeof(elo->Attributes) + sizeof(elo->FilePathListLength);
+_opts += sizeof(L'\0') + 2*wstrlen((CHAR16*)_opts) + 
elo->FilePathListLength;
+_cmdsize -= _opts - (UINT8*)elo;
+
+/*
+ * Sanity check the new cmdsize to avoid an underflow
+ */
+if ( _cmdsize < cmdsize )
+{
+*elo_active = true;
+cmdline = (CHAR16*)_opts;
+cmdsize = _cmdsize;
+}
+}
+}
+
+for ( ; cmdsize >= sizeof(*cmdline) && *cmdline;
 cmdsize -= sizeof(*cmdline), ++cmdline )
 {
 bool cur_sep = *cmdline == L' ' || *cmdline == L'\t';
@@ -1074,6 +1102,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
 bool base_video = false;
 char *option_str;
 bool use_cfg_file;
+bool elo_active = false;
 
 __set_bit(EFI_BOOT, &efi_flags);
 __set_bit(EFI_LOADER, &efi_flags);
@@ -1096,17 +1125,17 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
 if ( use_cfg_file )
 {
 argc = get_argv(0, NULL, loaded_image->LoadOptions,
-loaded_image->LoadOptionsSize, NULL);
+loaded_image->LoadOptionsSize, NULL, &elo_active);
 if ( argc > 0 &&
  efi_bs->AllocatePool(EfiLoaderData,
   (argc + 1) * sizeof(*argv) +
   loaded_image->LoadOptionsSize,
   (void **)&argv) == EFI_SUCCESS )
 get_argv(argc, argv, loaded_image->LoadOptions,
- loaded_image->LoadOptionsSize, &options);
+ loaded_image->LoadOptionsSize, &options, &elo_active);
 else
 argc = 0;
-for ( i = 1; i < argc; ++i )
+for ( i = !elo_active; i < argc; ++i )
 {
 CHAR16 *ptr = argv[i];
 
diff --git a/xen/include/efi/efiapi.h b/xen/include/efi/efiapi.h
index a616d1238a..c3dc902ac5 100644
--- a/xen/include/efi/efiapi.h
+++ b/xen/include/efi/efiapi.h
@@ -922,5 +922,59 @@ typedef struct _EFI_SYSTEM_TABLE {
 
 } EFI_SYSTEM_TABLE;
 
+//
+// EFI Load Option. This data structure describes format of UEFI boot option 
variables.
+//
+// NOTE: EFI Load Option is a byte packed buffer of variable length fields.
+// The first two fields have fixed length. They are declared as members of the
+// EFI_LOAD_OPTION structure. All the other fields are variable length fields.
+// They are listed in the comment block below for reference purposes.
+//
+typedef struct __packed _EFI_LOAD_OPTION {
+  ///
+  /// The attributes for this load option entry. All unused bits must be zero
+  /// and are reserved by the UEFI specification for future growth.
+  ///
+  UINT32   Attributes;
+  ///
+  /// Length in bytes of the FilePathList. OptionalData starts at offset
+  /// sizeof(UINT32) + sizeof(UINT16) + StrSize(Descri

Re: [Xen-devel] Xen release cycle revisited

[Jan Beulich]

>>> On 02.01.18 at 16:07,  wrote:
> I'm not sure if there has been a set time frame as a goal for x.y.z releases 
> - 
> from my not so close observations, they seem to be somewhat adhoc.

We're trying to get them out on a 4 month cadence, but there's
almost always a reason that causes them to be delayed.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen/x86: Drop unnecessary barriers

[Jan Beulich]

>>> On 02.01.18 at 15:17,  wrote:
> x86's current implementation of wmb() is a compiler barrier.  As a result, the
> only change in this patch is to remove an mfence instruction from
> cpuidle_disable_deep_cstate().
> 
> None of these barriers serve any purpose.  They are not synchronising with
> remote cpus, and their compiler-barrier properties are not needed for
> correctness purposes.
> 
> Furthermore, these wmb()'s specifically do not want to turn into sfence
> instructions in future changes where wmb()'s implementation is corrected.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen/efi: Avoid EFI stub using absolute symbols

[Jan Beulich]

>>> On 21.12.17 at 15:55,  wrote:
> The EFI image should be relocatable. At the moment, all the stub is
> relocatable but one place.

Do you really mean relocatable here? Based on ...

> On both Arm64 and x86-64 (from a quick glance) , the compiler will generate
> absolute pointer in the ErrCodeToStr array. Those values are based on Xen
> view of the virtual memory and may not be the same as EFI.

... this I'm wondering whether you don't instead mean position
independent. xen.efi (on x86) wouldn't work right if there were
no relocations for this array.

> For instance, at least on Arm64, EFI will do a 1:1 mappings of the Stub.

I'm afraid it is not clear to me what "1:1 mapping" in this context
means. Isn't your problem rather than on ARM64 xen.efi's
.reloc section is empty (which presumably is a result of how it is
being built)?

> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -342,7 +342,7 @@ static void __init noreturn blexit(const CHAR16 *str)
>  /* generic routine for printing error messages */
>  static void __init PrintErrMesg(const CHAR16 *mesg, EFI_STATUS ErrCode)
>  {
> -static const CHAR16* const ErrCodeToStr[] __initconstrel = {
> +static const CHAR16 ErrCodeToStr[][25] __initconst  = {
>  [~EFI_ERROR_MASK & EFI_NOT_FOUND]   = L"Not found",
>  [~EFI_ERROR_MASK & EFI_NO_MEDIA]= L"The device has no 
> media",
>  [~EFI_ERROR_MASK & EFI_MEDIA_CHANGED]   = L"Media changed",

If we really wanted (needed) to go this route, at least a comment
would be needed to prevent someone later "correcting" to obvious
oddity by switching back to what we have now. But I'd prefer if this
code was left alone.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/upcall: inject a spurious event after setting upcall vector

[Jan Beulich]

>>> On 28.12.17 at 13:57,  wrote:
> In case the vCPU has pending events to inject. This fixes a bug that
> happened if the guest mapped the vcpu info area using
> VCPUOP_register_vcpu_info without having setup the event channel
> upcall, and then setup the upcall vector.
> 
> In this scenario the guest would not receive any upcalls, because the
> call to VCPUOP_register_vcpu_info would have marked the vCPU as having
> pending events, but the vector could not be injected because it was
> not yet setup.
> 
> This has not caused issues so far because all the consumers first
> setup the vector callback and then map the vcpu info page, but there's
> no limitation that prevents doing it in the inverse order.

Hmm, yes, okay, I can see that we may indeed want to do this for
symmetry reasons. There is a small theoretical risk of this causing
races, though, for not entirely well written guest drivers.

> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4069,6 +4069,7 @@ static int hvmop_set_evtchn_upcall_vector(
>  printk(XENLOG_G_INFO "%pv: upcall vector %02x\n", v, op.vector);
>  
>  v->arch.hvm_vcpu.evtchn_upcall_vector = op.vector;
> +arch_evtchn_inject(v);

Why go through the arch hook instead of calling
hvm_assert_evtchn_irq() directly?

> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -385,6 +385,7 @@ void hvm_set_callback_via(struct domain *d, uint64_t via)
>  struct hvm_irq *hvm_irq = hvm_domain_irq(d);
>  unsigned int gsi=0, pdev=0, pintx=0;
>  uint8_t via_type;
> +struct vcpu *v;
>  
>  via_type = (uint8_t)MASK_EXTR(via, HVM_PARAM_CALLBACK_IRQ_TYPE_MASK) + 1;
>  if ( ((via_type == HVMIRQ_callback_gsi) && (via == 0)) ||
> @@ -447,6 +448,9 @@ void hvm_set_callback_via(struct domain *d, uint64_t via)
>  
>  spin_unlock(&d->arch.hvm_domain.irq_lock);
>  
> +for_each_vcpu(d, v)
> +arch_evtchn_inject(v);

Wouldn't it make sense to limit this to actually active vCPU-s?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.10-testing test] 117522: trouble: blocked/broken

[osstest service owner]

flight 117522 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117522/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvhv2-intel  broken
 build-amd64-rumprun   broken
 test-amd64-amd64-xl-qemuu-win10-i386  broken
 build-i386broken
 test-amd64-amd64-xl-qcow2 broken
 test-amd64-amd64-xl-qemut-win7-amd64  broken
 test-amd64-amd64-migrupgrade  broken
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmbroken
 test-xtf-amd64-amd64-4broken
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmbroken
 build-arm64   broken
 build-amd64-libvirt   broken
 build-i386-pvops  broken
 test-amd64-amd64-xl-qemut-win10-i386  broken
 build-i386-rumprunbroken
 build-armhf-xsm   broken
 test-amd64-amd64-xl-qemuu-ovmf-amd64  broken
 test-amd64-amd64-xl-rtds  broken
 test-amd64-amd64-i386-pvgrub  broken
 test-amd64-amd64-xl-qemuu-debianhvm-amd64broken
 build-i386-prev   broken
 build-amd64-xsm   broken
 test-amd64-amd64-qemuu-nested-amd  broken
 build-amd64-pvops broken
 build-amd64-xtf   broken
 test-xtf-amd64-amd64-1broken
 build-armhf   broken
 build-amd64-prev  broken
 test-xtf-amd64-amd64-3broken
 test-amd64-amd64-xl-multivcpu  broken
 test-amd64-amd64-amd64-pvgrub  broken
 test-amd64-amd64-xl-pvhv2-amd  broken
 build-amd64   broken
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmbroken
 test-amd64-amd64-xl-qemut-ws16-amd64  broken
 build-arm64-xsm   broken
 build-i386-xsmbroken
 test-amd64-amd64-qemuu-nested-intel  broken
 test-amd64-amd64-pair broken
 test-amd64-amd64-xl-qemut-debianhvm-amd64broken
 test-amd64-amd64-xl   broken
 test-amd64-amd64-xl-credit2   broken
 test-amd64-amd64-xl-qemuu-ws16-amd64  broken
 test-xtf-amd64-amd64-2broken
 test-amd64-amd64-pygrub   broken
 test-amd64-amd64-xl-xsm   broken
 test-amd64-amd64-xl-qemuu-win7-amd64  broken
 build-armhf-pvops broken
 build-arm64-pvops broken

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64 

[Xen-devel] [xen-unstable test] 117520: trouble: blocked/broken

[osstest service owner]

flight 117520 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117520/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops broken
 test-armhf-armhf-xl-credit2   broken
 test-amd64-amd64-rumprun-amd64  broken
 build-armhf-libvirt   broken
 test-amd64-amd64-xl-qemuu-ovmf-amd64  broken
 test-amd64-i386-pair  broken
 test-amd64-i386-xl-qemut-ws16-amd64  broken
 test-amd64-i386-xl-qemut-debianhvm-amd64 broken
 test-xtf-amd64-amd64-3broken
 test-arm64-arm64-xl-credit2   broken
 test-xtf-amd64-amd64-4broken
 test-amd64-i386-xl-qemuu-win7-amd64  broken
 test-amd64-i386-examine   broken
 test-armhf-armhf-xl-xsm   broken
 test-amd64-amd64-i386-pvgrub  broken
 test-amd64-amd64-qemuu-nested-intel  broken
 build-arm64-pvops broken
 test-amd64-amd64-qemuu-nested-amd  broken
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm broken
 build-amd64-libvirt   broken
 build-arm64   broken
 test-amd64-i386-xl-qemuu-win10-i386  broken
 test-armhf-armhf-xl   broken
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm broken
 build-i386-xsmbroken
 test-amd64-amd64-xl-qemuu-win7-amd64  broken
 build-i386-prev   broken
 build-amd64-rumprun   broken
 build-i386-libvirtbroken
 test-amd64-i386-xl-xsmbroken
 build-amd64-pvops broken
 build-i386-rumprunbroken
 build-amd64-xsm   broken
 test-amd64-amd64-xl-xsm   broken
 build-armhf   broken
 test-amd64-i386-xl-qemuu-ws16-amd64  broken
 test-amd64-amd64-xl-multivcpu  broken
 test-amd64-i386-xl-rawbroken
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm broken
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmbroken
 test-xtf-amd64-amd64-2broken
 test-amd64-amd64-libvirt-vhd  broken
 test-armhf-armhf-examine  broken
 test-amd64-amd64-libvirt-xsm  broken
 test-amd64-i386-xl-qemut-win10-i386  broken
 test-amd64-i386-migrupgrade   broken
 test-amd64-i386-freebsd10-amd64  broken
 build-amd64-xtf   broken
 test-amd64-amd64-pair broken
 test-amd64-amd64-pygrub   broken
 test-amd64-i386-xl-qemuu-debianhvm-amd64 broken
 test-amd64-i386-freebsd10-i386  broken
 test-amd64-amd64-xl-qemuu-debianhvm-amd64broken
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   broken
 test-armhf-armhf-xl-rtds  broken
 test-amd64-i386-livepatch broken
 test-amd64-amd64-xl-qemuu-ws16-amd64  broken
 test-amd64-i386-xlbroken
 test-amd64-amd64-xl-qemut-win7-amd64  broken
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmbroken
 test-amd64-i386-qemuu-rhel6hvm-amd  broken
 test-amd64-i386-xl-qemuu-ovmf-amd64  broken
 build-arm64-libvirt   broken
 build-armhf-xsm   broken
 test-armhf-armhf-xl-vhd   broken
 build-i386-pvops  broken
 test-arm64-arm64-examine  broken
 test-amd64-i386-qemut-rhel6hvm-intel  broken
 test-amd64-amd64-xl-qemuu-win10-i386  broken
 test-amd64-amd64-migrupgrade  broken
 test-amd64-amd64-xl-pvhv2-intel  broken
 test-amd64-i386-xl-qemut-win7-amd64  broken
 test-arm64-arm64-xl   broken
 test-amd64-amd64-xl-qcow2 broken
 test-armhf-armhf-xl-multivcpu  broken
 test-amd64-amd64-xl   broken
 test-amd64-amd64-xl-qemut-win10-i386  broken
 build-arm64-xsm   broken
 test-amd64-amd64-libvirt  broken
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmbroken
 build-amd64-prev  broken
 test-amd64-i386-qemuu-rhel6hvm-intel  broken
 test-arm64-arm64-xl-xsm   broken
 build-i386

Re: [Xen-devel] [PATCH] xen/input: do not advertise multi-touch pressure support

[Dmitry Torokhov]

On Tue, Jan 02, 2018 at 10:12:55AM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> Some user-space applications expect multi-touch pressure
> on contact to be reported if it is advertised in device
> properties. Otherwise, such applications may treat reports
> not as actual touches, but hovering. Currently this is
> only advertised, but not reported.
> Fix this by not advertising that ABS_MT_PRESSURE is supported.
> 
> Signed-off-by: Oleksandr Andrushchenko 
> Signed-off-by: Andrii Chepurnyi 

Applied, thank you.

> ---
>  drivers/input/misc/xen-kbdfront.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/input/misc/xen-kbdfront.c 
> b/drivers/input/misc/xen-kbdfront.c
> index 6bf56bb5f8d9..d91f3b1c5375 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -326,8 +326,6 @@ static int xenkbd_probe(struct xenbus_device *dev,
>0, width, 0, 0);
>   input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
>0, height, 0, 0);
> - input_set_abs_params(mtouch, ABS_MT_PRESSURE,
> -  0, 255, 0, 0);
>  
>   ret = input_mt_init_slots(mtouch, num_cont, INPUT_MT_DIRECT);
>   if (ret) {
> -- 
> 2.7.4
> 

-- 
Dmitry

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH -next] xen/pvcalls: use GFP_ATOMIC under spin lock

[Boris Ostrovsky]

On 12/27/2017 10:46 PM, Wei Yongjun wrote:
> A spin lock is taken here so we should use GFP_ATOMIC.
>
> Fixes: 9774c6cca266 ("xen/pvcalls: implement accept command")
> Signed-off-by: Wei Yongjun 

Applied to for-linus-4.15

-boris


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xtf test] 117543: trouble: blocked/broken/pass

[osstest service owner]

flight 117543 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117543/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64  broken
 build-amd64   4 host-install(4)broken REGR. vs. 116370

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-31 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a

version targeted for testing:
 xtf  bade68b7087acd6b5ca6310a7460faeea48e4b1c
baseline version:
 xtf  167052779c0546e99aadd26ebd848e10f91fb557

Last test of basis   116370  2017-11-20 10:46:19 Z   43 days
Testing same since   117543  2018-01-02 17:33:13 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  broken  
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   blocked 
 test-xtf-amd64-amd64-2   blocked 
 test-xtf-amd64-amd64-3   blocked 
 test-xtf-amd64-amd64-4   blocked 
 test-xtf-amd64-amd64-5   blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary

broken-job build-amd64 broken
broken-step build-amd64 host-install(4)

Not pushing.


commit bade68b7087acd6b5ca6310a7460faeea48e4b1c
Author: Andrew Cooper 
Date:   Thu Dec 28 18:07:24 2017 +

xtf-runner: Sort tests by variation as well

This removes instability in the running order of tests with multiple
variations.

Signed-off-by: Andrew Cooper 

commit 1b719bb8b093c418372a58bbc7aabd3e00882d0b
Author: Andrew Cooper 
Date:   Thu Nov 9 12:09:06 2017 +

x86/msr: Introduce xtf_msr_consistency_test()

To help with testing the correctness of MSRs which may be passed directly
through to a guest.

Signed-off-by: Andrew Cooper 

commit 1295ca1d26b84932b69f876ac432ce07133c7881
Author: Andrew Cooper 
Date:   Thu Nov 9 12:09:06 2017 +

x86: Split out new msr.h header

Move the {rd,wr}msr wrappers from lib.h and bitfield unions from msr-index.h
to here, leaving msr-index.h to be purely name definitions.

Correct an XFT typo in the msr-index.h header guards, and include msr.h in
arch/xtf.h to avoid tests needing to include msr-index.h manually

Signed-off-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-smoke test] 117565: tolerable all pass - PUSHED

[osstest service owner]

flight 117565 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117565/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  971d299c04df379734d10c44d637433e9e564f36
baseline version:
 xen  1b33150fe06ab9217f7f12b01bc5e607f4f55658

Last test of basis   117339  2017-12-19 15:02:59 Z   14 days
Failing since117372  2017-12-20 09:43:28 Z   13 days2 attempts
Testing same since   117565  2018-01-02 18:02:18 Z0 days1 attempts


People who touched revisions under test:
  Adrian Hunter 
  Andrew Cooper 
  Andrew Morton 
  David Woodhouse 
  Jan Beulich 
  Linus Torvalds 
  Michel Lespinasse 
  Peter Zijlstra 
  Praveen Kumar 
  Roger Pau Monné 
  Stephen Rothwell 
  Tim Deegan 
  Wolfram Strepp 
  Yi Sun 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   1b33150fe0..971d299c04  971d299c04df379734d10c44d637433e9e564f36 -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-3.18 test] 117563: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 117563 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117563/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvopsbroken
 build-armhf  broken
 build-armhf-pvops 4 host-install(4)broken REGR. vs. 117375
 build-armhf   4 host-install(4)broken REGR. vs. 117375
 build-amd64-pvops 6 kernel-build fail REGR. vs. 117375
 build-i386-pvops  6 kernel-build fail REGR. vs. 117375

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-examine  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check

[Xen-devel] [seabios test] 117536: regressions - FAIL

[osstest service owner]

flight 117536 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117536/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 seabios  844b86464a5cbfffb62b87808632018ca250d867
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   60 days
Failing since115733  2017-11-10 17:19:59 Z   53 days   59 attempts
Testing same since   117014  2017-12-08 19:11:23 Z   25 days   14 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Paul Menzel 
  Stefan Berger 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit 844b86464a5cbfffb62b87808632018ca250d867
Author: Paul Menzel 
Date:   Mon Oct 2 08:13:13 2017 +0200

docs/Download: Use more secure HTTPS URLs where possible

Signed-off-by: Paul Menzel 

commit df46d10c8a7b88eb82f3ceb2aa31782dee15593d
Author: Stefan Berger 
Date:   Tue Nov 14 15:03:47 2017 -0500

tpm: Add support for TPM2 ACPI table

Add support for the TPM2 ACPI table. If we find it and its
of the appropriate size, we can get the log_area_start_address
and log_area_minimum_size from it.

The latest version of the spec can be found here:

https://trustedcomputinggroup.org/tcg-acpi-specification/

Signed-off-by: Stefan Berger 

commit 0541f2f0f246e77d7c726926976920e8072d1119
Author: Kevin O'Connor 
Date:   Fri Nov 10 12:20:35 2017 -0500

paravirt: Only enable sercon in NOGRAPHIC mode if no other console specified

Signed-off-by: Kevin O'Connor 

commit 9ce6778f08c632c52b25bc8f754291ef18710d53
Author: Kevin O'Connor 
Date:   Fri Nov 10 12:16:36 2017 -0500

docs: Add sercon-port to Runtime_config.md documentation

[Xen-devel] [linux-linus test] 117544: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 117544 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117544/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops broken
 build-armhf-xsm  broken
 build-i386-pvops  4 host-install(4)broken REGR. vs. 115643
 build-armhf-xsm   4 host-install(4)broken REGR. vs. 115643
 test-armhf-armhf-examine  6 xen-install  fail REGR. vs. 115643
 build-amd64-pvops 6 kernel-build fail REGR. vs. 115643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-examine  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-examine   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-chec

[Xen-devel] [xen-4.8-testing test] 117533: trouble: blocked/broken/pass

[osstest service owner]

flight 117533 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117533/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvopsbroken
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm   broken
 build-amd64  broken
 build-i386-prev  broken
 build-armhf-xsm  broken
 build-i386   broken
 build-armhf  broken
 build-amd64   4 host-install(4)broken REGR. vs. 117144
 build-i3864 host-install(4)broken REGR. vs. 117144
 build-armhf   4 host-install(4)broken REGR. vs. 117144
 build-armhf-xsm   4 host-install(4)broken REGR. vs. 117144
 build-armhf-pvops 4 host-install(4)broken REGR. vs. 117144
 build-i386-prev   4 host-install(4)broken REGR. vs. 117144
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken REGR. 
vs. 117144

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 build-i386-rumprun1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-livepatch 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 bui

Re: [Xen-devel] [RFC v4 8/8] drivers/passthrough/arm: Refactor code for arm smmu drivers

[Manish Jaggi]

Hi Sameer,


On 12/19/2017 08:47 AM, Sameer Goel wrote:

Pull common defines for SMMU drivers in a local header.

Signed-off-by: Sameer Goel 
---
  xen/drivers/passthrough/arm/arm_smmu.h | 113 +
  xen/drivers/passthrough/arm/smmu-v3.c  |  96 ++--
  xen/drivers/passthrough/arm/smmu.c | 104 +-
  3 files changed, 121 insertions(+), 192 deletions(-)
  create mode 100644 xen/drivers/passthrough/arm/arm_smmu.h

diff --git a/xen/drivers/passthrough/arm/arm_smmu.h 
b/xen/drivers/passthrough/arm/arm_smmu.h
new file mode 100644
index 00..70f97e7d50
--- /dev/null
+++ b/xen/drivers/passthrough/arm/arm_smmu.h
@@ -0,0 +1,113 @@
+/**
+ * arm_smmu.h
+ *
+ * Common compatibility defines and data_structures for porting arm smmu
+ * drivers from Linux.
+ *
+ * Copyright (c) 2017 Linaro Limited
+ *
+ * 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 .
+ */
+
+#ifndef __ARM_SMMU_H__
+#define __ARM_SMMU_H__
+
+/* Helpers to get device MMIO and IRQs */
+struct resource {
+u64 addr;
+u64 size;
+unsigned int type;
+};
+
+#define resource_size(res) ((res)->size)
+
+#define platform_device device
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+/* Stub out DMA domain related functions */
+#define iommu_get_dma_cookie(dom) 0
+#define iommu_put_dma_cookie(dom)
+
+#define VA_BITS 0   /* Only used for configuring stage-1 input size */
+
+#define MODULE_DEVICE_TABLE(type, name)
+#define module_param_named(name, value, type, perm)
+#define MODULE_PARM_DESC(_parm, desc)
+
+static void __iomem *devm_ioremap_resource(struct device *dev,
+   struct resource *res)
+{
+void __iomem *ptr;
+
+if ( !res || res->type != IORESOURCE_MEM )
+{
+dev_err(dev, "Invalid resource\n");
+return ERR_PTR(-EINVAL);
+}
+
+ptr = ioremap_nocache(res->addr, res->size);
+if ( !ptr )
+{
+dev_err(dev,
+"ioremap failed (addr 0x%"PRIx64" size 0x%"PRIx64")\n",
+res->addr, res->size);
+return ERR_PTR(-ENOMEM);
+}
+
+return ptr;
+}
+
+/*
+ * Domain type definitions. Not really needed for Xen, defining to port
+ * Linux code as-is
+ */
+#define IOMMU_DOMAIN_UNMANAGED 0
+#define IOMMU_DOMAIN_DMA 1
+#define IOMMU_DOMAIN_IDENTITY 2
+
+/* Xen: Compatibility define for iommu_domain_geometry.*/
+struct iommu_domain_geometry {
+dma_addr_t aperture_start; /* First address that can be mapped*/
+dma_addr_t aperture_end;   /* Last address that can be mapped */
+bool force_aperture;   /* DMA only allowed in mappable range? */
+};
+
+/* Xen: Dummy iommu_domain */
+struct iommu_domain {
+/* Runtime SMMU configuration for this iommu_domain */
+struct arm_smmu_domain  *priv;
Do we need to call it priv? IMHO as there are too many structures wtih 
_domain and in the bigger goal of making the code intuitive

can we remove priv to something more verbose as smmu_domain.


+unsigned inttype;
+
+/* Dummy compatibility defines */
+unsigned long pgsize_bitmap;
+struct iommu_domain_geometry geometry;
+
+atomic_t ref;
+/* Used to link iommu_domain contexts for a same domain.
+ * There is at least one per-SMMU to used by the domain.
+ */
+struct list_headlist;
+};
+
+/* Xen: Describes information required for a Xen domain */
+struct arm_smmu_xen_domain {
+spinlock_t  lock;
+/* List of iommu domains associated to this domain */
+struct list_headcontexts;
Could we use a more verbose name, How about 
%s/contexts/iommu_domain_contexts/g ?

+};
+
+#endif /* __ARM_SMMU_H__ */
+
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index 3488184ad4..6e705f63a3 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -49,20 +49,7 @@
  #include 
  #include 
  
-

-/* Xen: Helpers to get device MMIO and IRQs */
-struct resource {
-   u64 addr;
-   u64 size;
-   unsigned int type;
-};
-
-#define resource_size(res) ((res)->size)
-
-#define platform_device device
-
-#define IORESOURCE_MEM 0
-#define IORESOURCE_IRQ 1
+#include "arm_smmu.h" /* Not a self contained header. So last in the list */
  
  static struct re

[Xen-devel] [qemu-mainline test] 117534: trouble: blocked/broken/pass

[osstest service owner]

flight 117534 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117534/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm  broken
 build-armhf-xsm  broken
 build-armhf-pvopsbroken
 build-i386-pvops broken
 build-armhf  broken
 build-amd64  broken
 build-amd64-xsm   4 host-install(4)broken REGR. vs. 117335
 build-i386-pvops  4 host-install(4)broken REGR. vs. 117335
 build-armhf   4 host-install(4)broken REGR. vs. 117335
 build-amd64   4 host-install(4)broken REGR. vs. 117335
 build-armhf-pvops 4 host-install(4)broken REGR. vs. 117335
 build-armhf-xsm   4 host-install(4)broken REGR. vs. 117335

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1)  

Re: [Xen-devel] [RFC v4 6/8] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Manish Jaggi]

Hi Sameer,

Comments on this patch are only for nomenclature...

On 12/19/2017 08:47 AM, Sameer Goel wrote:

This driver follows an approach similar to smmu driver. The intent here
is to reuse as much Linux code as possible.
- Glue code has been introduced to bridge the API calls.
- Called Linux functions from the Xen IOMMU function calls.
- Xen modifications are preceded by /*Xen: comment */

Signed-off-by: Sameer Goel 
---
  xen/arch/arm/p2m.c|   1 +
  xen/drivers/Kconfig   |   2 +
  xen/drivers/passthrough/arm/Kconfig   |   8 +
  xen/drivers/passthrough/arm/Makefile  |   1 +
  xen/drivers/passthrough/arm/smmu-v3.c | 880 --
  5 files changed, 861 insertions(+), 31 deletions(-)
  create mode 100644 xen/drivers/passthrough/arm/Kconfig

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 22165ae376..6aa24cae48 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1460,6 +1460,7 @@ err:
  static void __init setup_virt_paging_one(void *data)
  {
  unsigned long val = (unsigned long)data;
+/* SMMUv3 S2 cfg vtcr reuses the following value */
  WRITE_SYSREG32(val, VTCR_EL2);
  isb();
  }
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index bc3a54f0ea..612655386d 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -12,4 +12,6 @@ source "drivers/pci/Kconfig"
  
  source "drivers/video/Kconfig"
  
+source "drivers/passthrough/arm/Kconfig"

+
  endmenu
diff --git a/xen/drivers/passthrough/arm/Kconfig 
b/xen/drivers/passthrough/arm/Kconfig
new file mode 100644
index 00..cda899f608
--- /dev/null
+++ b/xen/drivers/passthrough/arm/Kconfig
@@ -0,0 +1,8 @@
+
+config ARM_SMMU_v3
+   bool "ARM SMMUv3 Support"
+   depends on ARM_64
+   help
+Support for implementations of the ARM System MMU architecture
+version 3.
+
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index f4cd26e15d..e14732b55c 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,3 @@
  obj-y += iommu.o
  obj-y += smmu.o
+obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index e67ba6c40f..3488184ad4 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -18,28 +18,402 @@
   * Author: Will Deacon 
   *
   * This driver is powered by bad coffee and bombay mix.
+ *
+ *
+ * Based on Linux drivers/iommu/arm-smmu-v3.c
+ * => commit 7aa8619a66aea52b145e04cbab4f8d6a4e5f3f3b
+ *
+ * Xen modifications:
+ * Sameer Goel 
+ * Copyright (C) 2017, The Linux Foundation, All rights reserved.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+/* Xen: Helpers to get device MMIO and IRQs */
+struct resource {
+   u64 addr;
+   u64 size;
+   unsigned int type;
+};
+
+#define resource_size(res) ((res)->size)
+
+#define platform_device device
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+static struct resource *platform_get_resource(struct platform_device *pdev,
+ unsigned int type,
+ unsigned int num)
+{
+   /*
+* The resource is only used between 2 calls of platform_get_resource.
+* It's quite ugly but it's avoid to add too much code in the part
+* imported from Linux
+*/
+   static struct resource res;
+   struct acpi_iort_node *iort_node;
+   struct acpi_iort_smmu_v3 *node_smmu_data;
+   int ret = 0;
+
+   res.type = type;
+
+   switch (type) {
+   case IORESOURCE_MEM:
+   if (pdev->type == DEV_ACPI) {
+   ret = 1;
+   iort_node = pdev->acpi_node;
+   node_smmu_data =
+   (struct acpi_iort_smmu_v3 
*)iort_node->node_data;
+
+   if (node_smmu_data != NULL) {
+   res.addr = node_smmu_data->base_address;
+   res.size = SZ_128K;
+   ret = 0;
+   }
+   } else {
+   ret = dt_device_get_address(dev_to_dt(pdev), num,
+   &res.addr, &res.size);
+   }
+
+   return ((ret) ? NULL : &res);
+
+   case IORESOURCE_IRQ:
+   /* ACPI case not implemented as there is no use case for it */
+   ret = platform_get_irq(dev_to_dt(pdev), num);
+
+   if (ret < 0)
+   return NULL;
+
+   res.addr = ret;
+   res.size = 1;
+
+   return &res;
+
+   default:
+   return NULL