[Xen-devel] [PATCH] xen/arm: p2m: Remove p2m_operation

[Julien Grall]

This is a left over of before the P2M code was reworked. So drop it.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/p2m.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 7b2aac4c90..c484469e6c 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -611,10 +611,6 @@ static int p2m_mem_access_radix_set(struct p2m_domain 
*p2m, gfn_t gfn,
 return rc;
 }
 
-enum p2m_operation {
-MEMACCESS,
-};
-
 /*
  * Put any references on the single 4K page referenced by pte.
  * TODO: Handle superpages, for now we only take special references for leaf
-- 
2.11.0


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

[Xen-devel] [PATCH 00/11] xen/arm: Clean-up traps.c

[Julien Grall]

Hi all,

xen/arch/arm/traps.c is beginning to get very big. This series is moving out
the co-processor and sysreg emulate in separate files. This will avoid to grow
traps.c when adding more registers emulations (coming soon).

A branch with this series has been pushed:

https://xenbits.xen.org/git-http/people/julieng/xen-unstable.git
branch cleanup-traps-v1

Cheers,

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: volodymyr_babc...@epam.com

Julien Grall (11):
  xen/grant_table: Include mm.h in xen/grant_table.h
  xen/arm: domain: Re-order the includes alphabetically
  xen/arm: traps: Re-order the includes alphabetically
  xen/arm: vgic-v3: Re-order the includes alphabetically
  xen/arm: vtimer: Re-order the includes alphabetically
  xen/arm: Move arch/arm/vtimer.h to include/asm-arm/vtimer.h
  xen/arm: traps: Export a bunch of helpers to handle emulation
  xen/arm: Move sysreg emulation outside of traps.c
  xen/arm: Move co-processor emulation outside of traps.c
  xen/arm: Move sysregs.h in arm64 sub-directory
  xen/arm: Limit the scope of cpregs.h

 xen/arch/arm/Makefile  |   1 +
 xen/arch/arm/arm64/Makefile|   1 +
 xen/arch/arm/arm64/vsysreg.c   | 229 ++
 xen/arch/arm/domain.c  |  24 +-
 xen/arch/arm/smp.c |   1 -
 xen/arch/arm/traps.c   | 704 ++---
 xen/arch/arm/vcpreg.c  | 452 ++
 xen/arch/arm/vgic-v3.c |   8 +-
 xen/arch/arm/vtimer.c  |   9 +-
 xen/include/asm-arm/arm32/processor.h  |   2 +
 xen/include/asm-arm/arm32/traps.h  |  13 +
 xen/include/asm-arm/arm64/processor.h  |   2 +
 xen/include/asm-arm/{ => arm64}/sysregs.h  |  10 +-
 xen/include/asm-arm/arm64/traps.h  |  18 +
 xen/include/asm-arm/percpu.h   |   1 -
 xen/include/asm-arm/processor.h|   2 -
 xen/include/asm-arm/traps.h|  43 ++
 xen/{arch/arm => include/asm-arm}/vtimer.h |   0
 xen/include/xen/grant_table.h  |   1 +
 19 files changed, 831 insertions(+), 690 deletions(-)
 create mode 100644 xen/arch/arm/arm64/vsysreg.c
 create mode 100644 xen/arch/arm/vcpreg.c
 create mode 100644 xen/include/asm-arm/arm32/traps.h
 rename xen/include/asm-arm/{ => arm64}/sysregs.h (98%)
 create mode 100644 xen/include/asm-arm/arm64/traps.h
 create mode 100644 xen/include/asm-arm/traps.h
 rename xen/{arch/arm => include/asm-arm}/vtimer.h (100%)

-- 
2.11.0


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

[Xen-devel] [PATCH 4/5] ARM: Introduce get_hwdom_madt_size in gic_hw_operations

[mjaggi]

From: Manish Jaggi 

estimate_acpi_efi_size needs to be updated to provide correct size of
hardware domains MADT, which now adds ITS information as well.

Introducing gic_get_hwdom_madt_size.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/domain_build.c  |  7 +--
 xen/arch/arm/gic-v2.c|  6 ++
 xen/arch/arm/gic-v3-its.c| 12 
 xen/arch/arm/gic-v3.c| 17 +
 xen/arch/arm/gic.c   | 11 +++
 xen/include/asm-arm/gic.h|  3 +++
 xen/include/asm-arm/gic_v3_its.h |  6 ++
 7 files changed, 56 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1bec4fa..5739ea4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1806,12 +1806,7 @@ static int estimate_acpi_efi_size(struct domain *d, 
struct kernel_info *kinfo)
 acpi_size = ROUNDUP(sizeof(struct acpi_table_fadt), 8);
 acpi_size += ROUNDUP(sizeof(struct acpi_table_stao), 8);
 
-madt_size = sizeof(struct acpi_table_madt)
-+ sizeof(struct acpi_madt_generic_interrupt) * d->max_vcpus
-+ sizeof(struct acpi_madt_generic_distributor);
-if ( d->arch.vgic.version == GIC_V3 )
-madt_size += sizeof(struct acpi_madt_generic_redistributor)
- * d->arch.vgic.nr_regions;
+madt_size = gic_get_hwdom_madt_size(d);
 acpi_size += ROUNDUP(madt_size, 8);
 
 addr = acpi_os_get_root_pointer();
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index cbe71a9..f5ca227 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -1012,6 +1012,11 @@ static int gicv2_iomem_deny_access(const struct domain 
*d)
 return iomem_deny_access(d, mfn, mfn + nr);
 }
 
+static u32 gicv2_get_hwdom_madt_size(const struct domain *d)
+{
+return 0;
+}
+
 #ifdef CONFIG_ACPI
 static int gicv2_make_hwdom_madt(const struct domain *d, u32 offset)
 {
@@ -1248,6 +1253,7 @@ const static struct gic_hw_operations gicv2_ops = {
 .read_apr= gicv2_read_apr,
 .make_hwdom_dt_node  = gicv2_make_hwdom_dt_node,
 .make_hwdom_madt = gicv2_make_hwdom_madt,
+.get_hwdom_madt_size = gicv2_get_hwdom_madt_size,
 .map_hwdom_extra_mappings = gicv2_map_hwdown_extra_mappings,
 .iomem_deny_access   = gicv2_iomem_deny_access,
 .do_LPI  = gicv2_do_LPI,
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index f584d33..82e025e 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -924,6 +924,18 @@ int gicv3_its_deny_access(const struct domain *d)
 return rc;
 }
 
+#ifdef CONFIG_ACPI
+u32 gicv3_its_madt_generic_translator_size(void)
+{
+const struct host_its *its_data;
+u32 size = 0;
+
+list_for_each_entry(its_data, _its_list, entry)
+size += sizeof(struct acpi_madt_generic_translator);
+
+return size;
+}
+#endif
 /*
  * Create the respective guest DT nodes from a list of host ITSes.
  * This copies the reg property, so the guest sees the ITS at the same address
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 045d20d..6c2b562 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1410,6 +1410,17 @@ static int gicv3_make_hwdom_madt(const struct domain *d, 
u32 offset)
 return table_len;
 }
 
+static u32 gicv3_get_hwdom_madt_size(const struct domain *d)
+{
+u32 size;
+size  = sizeof(struct acpi_madt_generic_redistributor)
+ * d->arch.vgic.nr_regions;
+if ( gicv3_its_host_has_its() )
+size  += gicv3_its_madt_generic_translator_size();
+
+return size;
+}
+
 static int __init
 gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
 const unsigned long end)
@@ -1607,6 +1618,11 @@ static int gicv3_make_hwdom_madt(const struct domain *d, 
u32 offset)
 {
 return 0;
 }
+
+static u32 gicv3_get_hwdom_madt_size(const struct domain *d)
+{
+return 0;
+}
 #endif
 
 /* Set up the GIC */
@@ -1708,6 +1724,7 @@ static const struct gic_hw_operations gicv3_ops = {
 .secondary_init  = gicv3_secondary_cpu_init,
 .make_hwdom_dt_node  = gicv3_make_hwdom_dt_node,
 .make_hwdom_madt = gicv3_make_hwdom_madt,
+.get_hwdom_madt_size = gicv3_get_hwdom_madt_size,
 .iomem_deny_access   = gicv3_iomem_deny_access,
 .do_LPI  = gicv3_do_LPI,
 };
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 6c803bf..7bdb603 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -851,6 +851,17 @@ int gic_make_hwdom_madt(const struct domain *d, u32 offset)
 return gic_hw_ops->make_hwdom_madt(d, offset);
 }
 
+u32 gic_get_hwdom_madt_size(const struct domain *d)
+{
+u32 madt_size;
+madt_size = sizeof(struct acpi_table_madt)
++ sizeof(struct acpi_madt_generic_interrupt) * d->max_vcpus
++ sizeof(struct acpi_madt_generic_distributor)
++ 

[Xen-devel] [PATCH 3/5] ARM: ITS: Deny hardware domain access to its

[mjaggi]

From: Manish Jaggi 

This patch extends the gicv3_iomem_deny_access functionality by adding support
for its region as well. Added function gicv3_its_deny_access.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/gic-v3-its.c| 19 +++
 xen/arch/arm/gic-v3.c|  7 +++
 xen/include/asm-arm/gic_v3_its.h |  8 
 3 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index c4f1288..f584d33 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -20,6 +20,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -905,6 +906,24 @@ struct pending_irq *gicv3_assign_guest_event(struct domain 
*d,
 return pirq;
 }
 
+int gicv3_its_deny_access(const struct domain *d)
+{
+int rc = 0;
+unsigned long mfn, nr;
+const struct host_its *its_data;
+
+list_for_each_entry(its_data, _its_list, entry)
+{
+mfn = paddr_to_pfn(its_data->addr);
+nr = PFN_UP(ACPI_GICV3_ITS_MEM_SIZE);
+rc = iomem_deny_access(d, mfn, mfn + nr);
+if ( rc )
+break;
+}
+
+return rc;
+}
+
 /*
  * Create the respective guest DT nodes from a list of host ITSes.
  * This copies the reg property, so the guest sees the ITS at the same address
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 0be8942..045d20d 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1308,6 +1308,13 @@ static int gicv3_iomem_deny_access(const struct domain 
*d)
 if ( rc )
 return rc;
 
+if ( gicv3_its_host_has_its() )
+{
+rc = gicv3_its_deny_access(d);
+if ( rc )
+return rc;
+}
+
 for ( i = 0; i < gicv3.rdist_count; i++ )
 {
 mfn = gicv3.rdist_regions[i].base >> PAGE_SHIFT;
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index b9d8957..a673fba 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -139,6 +139,9 @@ void gicv3_its_dt_init(const struct dt_device_node *node);
 int gicv3_its_acpi_init(struct acpi_subtable_header *header,
 const unsigned long end);
 #endif
+/* Deny iomem access for its */
+int gicv3_its_deny_access(const struct domain *d);
+
 bool gicv3_its_host_has_its(void);
 
 unsigned int vgic_v3_its_count(const struct domain *d);
@@ -208,6 +211,11 @@ static inline int gicv3_its_acpi_init(struct 
acpi_subtable_header *header,
 }
 #endif
 
+static inline int gicv3_its_deny_access(const struct domain *d)
+{
+return 0;
+}
+
 static inline bool gicv3_its_host_has_its(void)
 {
 return false;
-- 
2.7.4


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

[Xen-devel] [PATCH 2/2] ARM: ITS: Populate host_its_list from ACPI MADT Table

[mjaggi]

From: Manish Jaggi 

Added gicv3_its_acpi_init to update host_its_list from MADT table.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/gic-v3-its.c| 14 ++
 xen/arch/arm/gic-v3.c|  8 
 xen/include/asm-arm/gic_v3_its.h | 13 +
 3 files changed, 35 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index f844a0d..c4f1288 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -32,6 +32,7 @@
 #include 
 
 #define ITS_CMD_QUEUE_SZSZ_1M
+#define ACPI_GICV3_ITS_MEM_SIZE(SZ_64K)
 
 /*
  * No lock here, as this list gets only populated upon boot while scanning
@@ -1020,6 +1021,19 @@ void gicv3_its_dt_init(const struct dt_device_node *node)
 }
 }
 
+#ifdef CONFIG_ACPI
+int gicv3_its_acpi_init(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+struct acpi_madt_generic_translator *its;
+
+its = (struct acpi_madt_generic_translator *)header;
+
+return add_to_host_its_list(its->base_address,
+ACPI_GICV3_ITS_MEM_SIZE, NULL);
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index f990eae..0be8942 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1567,6 +1567,14 @@ static void __init gicv3_acpi_init(void)
 
 gicv3.rdist_stride = 0;
 
+/* Parse ITS information */
+count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
+  gicv3_its_acpi_init, 0);
+
+if ( count <= 0 )
+panic("GICv3: Can't get ITS entry");
+
+
 /*
  * In ACPI, 0 is considered as the invalid address. However the rest
  * of the initialization rely on the invalid address to be
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index 1fac1c7..2b7493d 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -105,6 +105,7 @@
 
 #include 
 #include 
+#include 
 
 #define HOST_ITS_FLUSH_CMD_QUEUE(1U << 0)
 #define HOST_ITS_USES_PTA   (1U << 1)
@@ -135,6 +136,10 @@ extern struct list_head host_its_list;
 /* Parse the host DT and pick up all host ITSes. */
 void gicv3_its_dt_init(const struct dt_device_node *node);
 
+#ifdef CONFIG_ACPI
+int gicv3_its_acpi_init(struct acpi_subtable_header *header,
+const unsigned long end);
+#endif
 bool gicv3_its_host_has_its(void);
 
 unsigned int vgic_v3_its_count(const struct domain *d);
@@ -196,6 +201,14 @@ static inline void gicv3_its_dt_init(const struct 
dt_device_node *node)
 {
 }
 
+#ifdef CONFIG_ACPI
+static inline int gicv3_its_acpi_init(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+return false;
+}
+#endif
+
 static inline bool gicv3_its_host_has_its(void)
 {
 return false;
-- 
2.7.4


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

[Xen-devel] [PATCH 5/5] ARM: ITS: Pass ITS in Hardware Domain MADT

[mjaggi]

From: Manish Jaggi 

Adds gicv3_its_make_hwdom_madt to update hwdom MADT ITS information.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/gic-v3-its.c| 24 
 xen/arch/arm/gic-v3.c|  1 +
 xen/include/asm-arm/gic_v3_its.h |  1 +
 3 files changed, 26 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 82e025e..6e0a701 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -935,6 +935,30 @@ u32 gicv3_its_madt_generic_translator_size(void)
 
 return size;
 }
+
+u32 gicv3_its_make_hwdom_madt(u8 *base_ptr, u32 offset)
+{
+const struct host_its *its_data;
+u32 table_len = offset, i = 0, size;
+struct acpi_madt_generic_translator *fw_its;
+struct acpi_madt_generic_translator *hwdom_its;
+
+size = sizeof(struct acpi_madt_generic_translator);
+
+/* Update GIC ITS information in hardware domain's MADT */
+list_for_each_entry(its_data, _its_list, entry)
+{
+hwdom_its = (struct acpi_madt_generic_translator *)(base_ptr
+   + table_len);
+fw_its = (struct acpi_madt_generic_translator *)
+acpi_table_get_entry_madt(
+ACPI_MADT_TYPE_GENERIC_TRANSLATOR, i++);
+memcpy(hwdom_its, fw_its, size);
+table_len +=  size;
+}
+
+return table_len;
+}
 #endif
 /*
  * Create the respective guest DT nodes from a list of host ITSes.
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 6c2b562..30b29c9 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1407,6 +1407,7 @@ static int gicv3_make_hwdom_madt(const struct domain *d, 
u32 offset)
 table_len += size;
 }
 
+table_len = gicv3_its_make_hwdom_madt(base_ptr, table_len);
 return table_len;
 }
 
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index b849b16..8955451 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -139,6 +139,7 @@ void gicv3_its_dt_init(const struct dt_device_node *node);
 int gicv3_its_acpi_init(struct acpi_subtable_header *header,
 const unsigned long end);
 u32 gicv3_its_madt_generic_translator_size(void);
+u32 gicv3_its_make_hwdom_madt(u8 *base_ptr, u32 offset);
 #endif
 /* Deny iomem access for its */
 int gicv3_its_deny_access(const struct domain *d);
-- 
2.7.4


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

Re: [Xen-devel] [PATCH for-2.10 1/2] hw/acpi: Call acpi_set_pci_info when no ACPI tables needed

[Michael S. Tsirkin]

On Fri, Aug 11, 2017 at 04:11:37PM +0100, Anthony PERARD wrote:
> To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
> set, but this was done only when ACPI tables are built which is not
> needed for a Xen guest. The need for the property starts with commit
> "pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice"
> (f0c9d64a68b776374ec4732424a3e27753ce37b6).
> 
> Set pci info before checking for the needs to build ACPI tables.
> 
> Reported-by: Sander Eikelenboom 
> Tested-by: Sander Eikelenboom 
> Signed-off-by: Anthony PERARD 

I am worried that Xen will come to depend on specific
assignment of bsel which isn't guaranteed. Thoughts on
how to avoid that?



> 
> ---
> In this patch rather than always calling acpi_set_pci_info() when
> acpi_setup() is called, we could check first for acpi_enabled? (which is
> true for Xen.)

Yes, please change it like this. Also, please add
a comment explainging what it does.


Thanks!

> 
> This patch would be a canditade to backport to 2.9.
> 
> CC: Stefano Stabellini 
> CC: Bruce Rogers 
> ---
>  hw/i386/acpi-build.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 98dd424678..e1b7797408 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -2871,6 +2871,8 @@ void acpi_setup(void)
>  AcpiBuildState *build_state;
>  Object *vmgenid_dev;
>  
> +acpi_set_pci_info();
> +
>  if (!pcms->fw_cfg) {
>  ACPI_BUILD_DPRINTF("No fw cfg. Bailing out.\n");
>  return;
> @@ -2888,8 +2890,6 @@ void acpi_setup(void)
>  
>  build_state = g_malloc0(sizeof *build_state);
>  
> -acpi_set_pci_info();
> -
>  acpi_build_tables_init();
>  acpi_build(, MACHINE(pcms));
>  
> -- 
> Anthony PERARD

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

[Xen-devel] [PATCH 1/5] ARM: ITS: Introduce common function add_to_host_its_list

[mjaggi]

From: Manish Jaggi 

add_to_host_its_list will update the host_its_list. This common function to
be invoked from gicv3_its_dt_init and gic_v3_its_acpi_init.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/gic-v3-its.c | 36 +++-
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 2d36030..f844a0d 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -976,12 +976,31 @@ int gicv3_its_make_hwdom_dt_nodes(const struct domain *d,
 return res;
 }
 
+/* Common function for adding to host_its_list */
+static int add_to_host_its_list(u64 addr, u64 size, const void *node)
+{
+struct host_its *its_data;
+its_data = xzalloc(struct host_its);
+
+if ( !its_data )
+return -1;
+
+its_data->addr = addr;
+its_data->size = size;
+if ( node )
+its_data->dt_node = node;
+
+printk("GICv3: Found ITS @0x%lx\n", addr);
+
+list_add_tail(_data->entry, _its_list);
+
+return 0;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
 const struct dt_device_node *its = NULL;
-struct host_its *its_data;
-
 /*
  * Check for ITS MSI subnodes. If any, add the ITS register
  * frames to the ITS list.
@@ -996,17 +1015,8 @@ void gicv3_its_dt_init(const struct dt_device_node *node)
 if ( dt_device_get_address(its, 0, , ) )
 panic("GICv3: Cannot find a valid ITS frame address");
 
-its_data = xzalloc(struct host_its);
-if ( !its_data )
-panic("GICv3: Cannot allocate memory for ITS frame");
-
-its_data->addr = addr;
-its_data->size = size;
-its_data->dt_node = its;
-
-printk("GICv3: Found ITS @0x%lx\n", addr);
-
-list_add_tail(_data->entry, _its_list);
+if ( add_to_host_its_list(addr, size, its) )
+panic("GICV3: Adding Host ITS failed ");
 }
 }
 
-- 
2.7.4


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

[Xen-devel] [PATCH v2 0/5] ARM: ACPI: ITS: Add ITS Support for ACPI hardware domain

[mjaggi]

From: Manish Jaggi 

This patch is split into 5 patches. First two add support for updating
host_its_list from ACPI MADT table.
The rest patches provide support to update the hardware domain MADT table
with ITS information.

Changes since v1:
- split patches into smaller ones
- removed translation_id


Manish Jaggi (5):
  ARM: ITS: Introduce common function add_to_host_its_list
  ARM: ITS: Populate host_its_list from ACPI MADT Table
  ARM: ITS: Deny hardware domain access to its
  ARM: Introduce get_hwdom_madt_size in gic_hw_operations
  ARM: ITS: Pass ITS in Hardware Domain MADT

 xen/arch/arm/domain_build.c  |   7 +--
 xen/arch/arm/gic-v2.c|   6 +++
 xen/arch/arm/gic-v3-its.c| 101 ++-
 xen/arch/arm/gic-v3.c|  33 +
 xen/arch/arm/gic.c   |  11 +
 xen/include/asm-arm/gic.h|   3 ++
 xen/include/asm-arm/gic_v3_its.h |  29 ++-
 7 files changed, 172 insertions(+), 18 deletions(-)

-- 
2.7.4


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

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

[Jim Fehlig]

On 08/11/2017 05:45 AM, Wei Liu wrote:

On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote:

On 08/08/2017 09:09 AM, Wei Liu wrote:

Ian and Stefano

Oleksandr discovered that the p9fs array in libxl_domain_config is name
p9 instead of p9s. This causes problem for his work to rework device
framework.

Given that p9fs was added only during last release and the only known
external toolstack libvirt can't possibility use that, maybe we can
rename p9 to p9s. Opinions?


ATM the libvirt libxl driver doesn't use it, but it could by supporting
libvirt's  device

http://libvirt.org/formatdomain.html#elementsFilesystems


I think that means all the parameters go directly to QEMU. Without
proper plumbing via libxl driver there won't be anything in the xenstore
hence it isn't useable by Xen guest, right?


I'm not sure why they have to go directly to QEMU. My naive thinking was to map 
the  XML elements/attributes to libxl_device_p9 struct. E.g. 
/domain/devices/filesystem/source@file would map to libxl_device_p9->path, etc.


Regards,
Jim



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

[Xen-devel] [PATCH v2 3/4] x86/vtd: introduce a PVH implementation of iommu_inclusive_mapping

[Roger Pau Monne]

On certain Intel systems, as far as I can tell almost all pre-Haswell ones,
trying to boot a PVH Dom0 will freeze the box completely, up to the point that
not even the watchdog works. The freeze happens exactly when enabling the DMA
remapping in the IOMMU, the last line seen is:

(XEN) [VT-D]iommu_enable_translation: iommu->reg = 82c00021b000

In order to workaround this (which seems to be a lack of proper RMRR entries,
plus the IOMMU being unable to generate faults and freezing the entire system)
add a PVH specific implementation of iommu_inclusive_mapping, that maps
non-RAM, non-unusable regions into Dom0 p2m. Note that care is taken to not map
device MMIO regions that Xen is emulating, like the local APIC or the IO APIC.

Signed-off-by: Roger Pau Monné 
---
Cc: Kevin Tian 
---
 xen/drivers/passthrough/vtd/extern.h  |  1 +
 xen/drivers/passthrough/vtd/iommu.c   |  2 ++
 xen/drivers/passthrough/vtd/x86/vtd.c | 39 +++
 3 files changed, 42 insertions(+)

diff --git a/xen/drivers/passthrough/vtd/extern.h 
b/xen/drivers/passthrough/vtd/extern.h
index fb7edfaef9..0eaf8956ff 100644
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -100,5 +100,6 @@ bool_t platform_supports_intremap(void);
 bool_t platform_supports_x2apic(void);
 
 void vtd_set_hwdom_mapping(struct domain *d);
+void vtd_set_pvh_hwdom_mapping(struct domain *d);
 
 #endif // _VTD_EXTERN_H_
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index daaed0abbd..8ed28defe2 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1303,6 +1303,8 @@ static void __hwdom_init intel_iommu_hwdom_init(struct 
domain *d)
 /* Set up 1:1 page table for hardware domain. */
 vtd_set_hwdom_mapping(d);
 }
+else if ( is_hvm_domain(d) )
+vtd_set_pvh_hwdom_mapping(d);
 
 setup_hwdom_pci_devices(d, setup_hwdom_device);
 setup_hwdom_rmrr(d);
diff --git a/xen/drivers/passthrough/vtd/x86/vtd.c 
b/xen/drivers/passthrough/vtd/x86/vtd.c
index 88a60b3307..79c9b0526f 100644
--- a/xen/drivers/passthrough/vtd/x86/vtd.c
+++ b/xen/drivers/passthrough/vtd/x86/vtd.c
@@ -21,10 +21,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "../iommu.h"
 #include "../dmar.h"
@@ -159,3 +161,40 @@ void __hwdom_init vtd_set_hwdom_mapping(struct domain *d)
 }
 }
 
+void __hwdom_init vtd_set_pvh_hwdom_mapping(struct domain *d)
+{
+unsigned long pfn;
+
+BUG_ON(!is_hardware_domain(d));
+
+if ( !iommu_inclusive_mapping )
+return;
+
+/* NB: the low 1MB is already mapped in pvh_setup_p2m. */
+for ( pfn = PFN_DOWN(MB(1)); pfn < PFN_DOWN(GB(4)); pfn++ )
+{
+p2m_access_t a;
+int rc;
+
+if ( !(pfn & 0xfff) )
+process_pending_softirqs();
+
+/* Skip RAM, ACPI and unusable regions. */
+if ( page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL) ||
+ page_is_ram_type(pfn, RAM_TYPE_UNUSABLE) ||
+ page_is_ram_type(pfn, RAM_TYPE_ACPI) ||
+ !iomem_access_permitted(d, pfn, pfn) )
+continue;
+
+ASSERT(!xen_in_range(pfn));
+
+a = rangeset_contains_range(mmio_ro_ranges, pfn, pfn) ? p2m_access_r
+  : p2m_access_rw;
+rc = set_identity_p2m_entry(d, pfn, a, 0);
+if ( rc )
+   printk(XENLOG_WARNING VTDPREFIX
+  " d%d: IOMMU mapping failed pfn %#lx: %d\n",
+  d->domain_id, pfn, rc);
+}
+}
+
-- 
2.11.0 (Apple Git-81)


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

[Xen-devel] [PATCH v2 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0

[Roger Pau Monne]

They are emulated by Xen, so they must not be mapped into Dom0 p2m.
Introduce a helper function to add the MMCFG areas to the list of
denied iomem regions for PVH Dom0.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since RFC:
 - Introduce as helper instead of exposing the internal mmcfg
   variables to the Dom0 builder.
---
 xen/arch/x86/dom0_build.c |  4 
 xen/arch/x86/x86_64/mmconfig_64.c | 21 +
 xen/include/xen/pci.h |  2 ++
 3 files changed, 27 insertions(+)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 0c125e61eb..3e0910d779 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -440,6 +440,10 @@ int __init dom0_setup_permissions(struct domain *d)
 rc |= rangeset_add_singleton(mmio_ro_ranges, mfn);
 }
 
+/* For PVH prevent access to the MMCFG areas. */
+if ( dom0_pvh )
+rc |= pci_mmcfg_set_domain_permissions(d);
+
 return rc;
 }
 
diff --git a/xen/arch/x86/x86_64/mmconfig_64.c 
b/xen/arch/x86/x86_64/mmconfig_64.c
index e84a67dfc4..271fad407f 100644
--- a/xen/arch/x86/x86_64/mmconfig_64.c
+++ b/xen/arch/x86/x86_64/mmconfig_64.c
@@ -15,6 +15,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "mmconfig.h"
 
@@ -175,6 +177,25 @@ void pci_mmcfg_arch_disable(unsigned int idx)
cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number);
 }
 
+int pci_mmcfg_set_domain_permissions(struct domain *d)
+{
+unsigned int idx;
+int rc = 0;
+
+for ( idx = 0; idx < pci_mmcfg_config_num; idx++ )
+{
+const struct acpi_mcfg_allocation *cfg = pci_mmcfg_virt[idx].cfg;
+unsigned long start = PFN_DOWN(cfg->address) +
+  PCI_BDF(cfg->start_bus_number, 0, 0);
+unsigned long end = PFN_DOWN(cfg->address) +
+PCI_BDF(cfg->end_bus_number, ~0, ~0);
+
+rc |= iomem_deny_access(d, start, end);
+}
+
+return rc;
+}
+
 bool_t pci_mmcfg_decode(unsigned long mfn, unsigned int *seg,
 unsigned int *bdf)
 {
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 59b6e8a81c..ea6a66b248 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -170,4 +170,6 @@ int msixtbl_pt_register(struct domain *, struct pirq *, 
uint64_t gtable);
 void msixtbl_pt_unregister(struct domain *, struct pirq *);
 void msixtbl_pt_cleanup(struct domain *d);
 
+int pci_mmcfg_set_domain_permissions(struct domain *d);
+
 #endif /* __XEN_PCI_H__ */
-- 
2.11.0 (Apple Git-81)


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

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

[Stefano Stabellini]

On Fri, 11 Aug 2017, Wei Liu wrote:
> On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote:
> > On 08/08/2017 09:09 AM, Wei Liu wrote:
> > > Ian and Stefano
> > > 
> > > Oleksandr discovered that the p9fs array in libxl_domain_config is name
> > > p9 instead of p9s. This causes problem for his work to rework device
> > > framework.
> > > 
> > > Given that p9fs was added only during last release and the only known
> > > external toolstack libvirt can't possibility use that, maybe we can
> > > rename p9 to p9s. Opinions?
> > 
> > ATM the libvirt libxl driver doesn't use it, but it could by supporting
> > libvirt's  device
> > 
> > http://libvirt.org/formatdomain.html#elementsFilesystems
> 
> I think that means all the parameters go directly to QEMU. Without
> proper plumbing via libxl driver there won't be anything in the xenstore
> hence it isn't useable by Xen guest, right?

That's right.

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

[Xen-devel] [xen-unstable test] 112588: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112544

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112544
 build-arm64   2 hosts-allocate  broken like 112544
 build-arm64-xsm   3 capture-logsbroken like 112544
 build-arm64-pvops 2 hosts-allocate  broken like 112544
 build-arm64-pvops 3 capture-logsbroken like 112544
 build-arm64   3 capture-logsbroken like 112544
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112544
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112544
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112544
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112544
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112544
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112544
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 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-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install 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
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  b24731b1b4ce9f032116831ac825b227965232aa
baseline version:
 xen  f5c3e78b5c61e7dfb05749c7a0c862ec18c86384

Last test of basis   112544  2017-08-10 04:20:44 Z1 days
Failing since112561  2017-08-10 16:20:26 Z1 days2 attempts
Testing same since   112588  2017-08-11 04:40:12 Z0 days1 attempts

[Xen-devel] [PATCH 11/11] xen/arm: Limit the scope of cpregs.h

[Julien Grall]

Currently, cpregs.h is included in pretty much every files even for
arm64. However, the only use for arm64 is when emulating co-processors.

For arm32, cpregs.h rely on the presence of processor.h (define
*_SYSREG helpers). So move the inclusion in asm-arm/arm32/processor.h.

cpregs.h will also be directly included in the co-processors emulation
to accomodate arm64.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/smp.c| 1 -
 xen/arch/arm/vcpreg.c | 1 +
 xen/arch/arm/vgic-v3.c| 1 +
 xen/arch/arm/vtimer.c | 2 ++
 xen/include/asm-arm/arm32/processor.h | 2 ++
 xen/include/asm-arm/percpu.h  | 1 -
 xen/include/asm-arm/processor.h   | 1 -
 7 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c
index e7df0874d6..554f4992e6 100644
--- a/xen/arch/arm/smp.c
+++ b/xen/arch/arm/smp.c
@@ -1,6 +1,5 @@
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
index f3b08403fb..e363183ba8 100644
--- a/xen/arch/arm/vcpreg.c
+++ b/xen/arch/arm/vcpreg.c
@@ -18,6 +18,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index cbeac28b28..a0cf993d13 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 9c7e8f441c..0460962f08 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Check if regs is allowed access, user_gate is tail end of a
diff --git a/xen/include/asm-arm/arm32/processor.h 
b/xen/include/asm-arm/arm32/processor.h
index 68cc82147e..fb330812af 100644
--- a/xen/include/asm-arm/arm32/processor.h
+++ b/xen/include/asm-arm/arm32/processor.h
@@ -1,6 +1,8 @@
 #ifndef __ASM_ARM_ARM32_PROCESSOR_H
 #define __ASM_ARM_ARM32_PROCESSOR_H
 
+#include 
+
 #define ACTLR_CAXX_SMP  (1<<6)
 
 #ifndef __ASSEMBLY__
diff --git a/xen/include/asm-arm/percpu.h b/xen/include/asm-arm/percpu.h
index 7968532462..cdf64e0f77 100644
--- a/xen/include/asm-arm/percpu.h
+++ b/xen/include/asm-arm/percpu.h
@@ -4,7 +4,6 @@
 #ifndef __ASSEMBLY__
 
 #include 
-#include 
 #if defined(CONFIG_ARM_32)
 # include 
 #elif defined(CONFIG_ARM_64)
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 9eacb1be29..51ce802063 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -1,7 +1,6 @@
 #ifndef __ASM_ARM_PROCESSOR_H
 #define __ASM_ARM_PROCESSOR_H
 
-#include 
 #ifndef __ASSEMBLY__
 #include 
 #endif
-- 
2.11.0


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

[Xen-devel] [PATCH 02/11] xen/arm: domain: Re-order the includes alphabetically

[Julien Grall]

Signed-off-by: Julien Grall 
---
 xen/arch/arm/domain.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2dc8b0ab5a..1d835d321d 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -9,6 +9,9 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  */
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -16,24 +19,21 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
+#include 
+#include 
 #include 
-#include 
-
-#include 
+#include 
+#include 
 #include 
-#include 
+
 #include "vtimer.h"
 #include "vuart.h"
 
-- 
2.11.0


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

[Xen-devel] [PATCH 09/11] xen/arm: Move co-processor emulation outside of traps.c

[Julien Grall]

The co-processor emulation is quite big and pretty much standalone. Move
it in a separate file to shrink down the size of traps.c.

At the same time remove unused cpregs.h.

No functional change.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/Makefile   |   1 +
 xen/arch/arm/traps.c| 421 -
 xen/arch/arm/vcpreg.c   | 451 
 xen/include/asm-arm/traps.h |   8 +
 4 files changed, 460 insertions(+), 421 deletions(-)
 create mode 100644 xen/arch/arm/vcpreg.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 49e1fb2f84..de00c5e339 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -44,6 +44,7 @@ obj-y += smpboot.o
 obj-y += sysctl.o
 obj-y += time.o
 obj-y += traps.o
+obj-y += vcpreg.o
 obj-y += vgic.o
 obj-y += vgic-v2.o
 obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index b71354d7ff..13efb58e49 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -38,7 +38,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -1856,426 +1855,6 @@ void handle_ro_raz(struct cpu_user_regs *regs,
 advance_pc(regs, hsr);
 }
 
-static void do_cp15_32(struct cpu_user_regs *regs,
-   const union hsr hsr)
-{
-const struct hsr_cp32 cp32 = hsr.cp32;
-int regidx = cp32.reg;
-struct vcpu *v = current;
-
-if ( !check_conditional_instr(regs, hsr) )
-{
-advance_pc(regs, hsr);
-return;
-}
-
-switch ( hsr.bits & HSR_CP32_REGS_MASK )
-{
-/*
- * !CNTHCTL_EL2.EL1PCEN / !CNTHCTL.PL1PCEN
- *
- * ARMv7 (DDI 0406C.b): B4.1.22
- * ARMv8 (DDI 0487A.d): D1-1510 Table D1-60
- */
-case HSR_CPREG32(CNTP_CTL):
-case HSR_CPREG32(CNTP_TVAL):
-if ( !vtimer_emulate(regs, hsr) )
-return inject_undef_exception(regs, hsr);
-break;
-
-/*
- * HCR_EL2.TACR / HCR.TAC
- *
- * ARMv7 (DDI 0406C.b): B1.14.6
- * ARMv8 (DDI 0487A.d): G6.2.1
- */
-case HSR_CPREG32(ACTLR):
-if ( psr_mode_is_user(regs) )
-return inject_undef_exception(regs, hsr);
-if ( cp32.read )
-set_user_reg(regs, regidx, v->arch.actlr);
-break;
-
-/*
- * MDCR_EL2.TPM
- *
- * ARMv7 (DDI 0406C.b): B1.14.17
- * ARMv8 (DDI 0487A.d): D1-1511 Table D1-61
- *
- * Unhandled:
- *PMEVCNTR
- *PMEVTYPER
- *PMCCFILTR
- *
- * MDCR_EL2.TPMCR
- *
- * ARMv7 (DDI 0406C.b): B1.14.17
- * ARMv8 (DDI 0487A.d): D1-1511 Table D1-62
- *
- * NB: Both MDCR_EL2.TPM and MDCR_EL2.TPMCR cause trapping of PMCR.
- */
-/* We could trap ID_DFR0 and tell the guest we don't support
- * performance monitoring, but Linux doesn't check the ID_DFR0.
- * Therefore it will read PMCR.
- *
- * We tell the guest we have 0 counters. Unfortunately we must
- * always support PMCCNTR (the cyle counter): we just RAZ/WI for all
- * PM register, which doesn't crash the kernel at least
- */
-case HSR_CPREG32(PMUSERENR):
-/* RO at EL0. RAZ/WI at EL1 */
-if ( psr_mode_is_user(regs) )
-return handle_ro_raz(regs, regidx, cp32.read, hsr, 0);
-else
-return handle_raz_wi(regs, regidx, cp32.read, hsr, 1);
-case HSR_CPREG32(PMINTENSET):
-case HSR_CPREG32(PMINTENCLR):
-/* EL1 only, however MDCR_EL2.TPM==1 means EL0 may trap here also. */
-return handle_raz_wi(regs, regidx, cp32.read, hsr, 1);
-case HSR_CPREG32(PMCR):
-case HSR_CPREG32(PMCNTENSET):
-case HSR_CPREG32(PMCNTENCLR):
-case HSR_CPREG32(PMOVSR):
-case HSR_CPREG32(PMSWINC):
-case HSR_CPREG32(PMSELR):
-case HSR_CPREG32(PMCEID0):
-case HSR_CPREG32(PMCEID1):
-case HSR_CPREG32(PMCCNTR):
-case HSR_CPREG32(PMXEVTYPER):
-case HSR_CPREG32(PMXEVCNTR):
-case HSR_CPREG32(PMOVSSET):
-/*
- * Accessible at EL0 only if PMUSERENR_EL0.EN is set. We
- * emulate that register as 0 above.
- */
-return handle_raz_wi(regs, regidx, cp32.read, hsr, 1);
-
-/*
- * HCR_EL2.TIDCP
- *
- * ARMv7 (DDI 0406C.b): B1.14.3
- * ARMv8 (DDI 0487A.d): D1-1501 Table D1-43
- *
- *  - CRn==c9, opc1=={0-7}, CRm=={c0-c2, c5-c8}, opc2=={0-7}
- *(Cache and TCM lockdown registers)
- *  - CRn==c10, opc1=={0-7}, CRm=={c0, c1, c4, c8}, opc2=={0-7}
- *(VMSA CP15 c10 registers)
- *  - CRn==c11, opc1=={0-7}, CRm=={c0-c8, c15}, opc2=={0-7}
- *(VMSA CP15 c11 registers)
- *
- * CPTR_EL2.T{0..9,12..13}
- *
- * ARMv7 (DDI 0406C.b): B1.14.12
- * ARMv8 (DDI 0487A.d): N/A
- *
- *  - All accesses to coprocessors 0..9 and 12..13
- *
- * HSTR_EL2.T15
- *
- * ARMv7 (DDI 0406C.b): B1.14.14
- * ARMv8 (DDI 0487A.d): D1-1507 Table D1-55
- *
- *  - All 

[Xen-devel] [PATCH 07/11] xen/arm: traps: Export a bunch of helpers to handle emulation

[Julien Grall]

A follow-up patch will move some parts of traps.c in separate files.
The will require to use helpers that are currently statically defined.
Export the following helpers:
- inject_undef64_exception
- inject_undef_exception
- check_conditional_instr
- advance_pc
- handle_raz_wi
- handle_wo_wi
- handle_ro_raz

Note that asm-arm/arm32/traps.h is empty but it is to keep parity with
the arm64 counterpart.

Signed-off-by: Julien Grall 

---

Cc: volodymyr_babc...@epam.com
---
 xen/arch/arm/traps.c  | 43 +++
 xen/include/asm-arm/arm32/traps.h | 13 
 xen/include/asm-arm/arm64/traps.h | 15 ++
 xen/include/asm-arm/traps.h   | 35 +++
 4 files changed, 84 insertions(+), 22 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/traps.h
 create mode 100644 xen/include/asm-arm/arm64/traps.h
 create mode 100644 xen/include/asm-arm/traps.h

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index d79e9605b5..ab56958717 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -545,7 +546,7 @@ static vaddr_t exception_handler64(struct cpu_user_regs 
*regs, vaddr_t offset)
 }
 
 /* Inject an undefined exception into a 64 bit guest */
-static void inject_undef64_exception(struct cpu_user_regs *regs, int instr_len)
+void inject_undef64_exception(struct cpu_user_regs *regs, int instr_len)
 {
 vaddr_t handler;
 const union hsr esr = {
@@ -618,8 +619,7 @@ static void inject_iabt64_exception(struct cpu_user_regs 
*regs,
 
 #endif
 
-static void inject_undef_exception(struct cpu_user_regs *regs,
-   const union hsr hsr)
+void inject_undef_exception(struct cpu_user_regs *regs, const union hsr hsr)
 {
 if ( is_32bit_domain(current->domain) )
 inject_undef32_exception(regs);
@@ -1712,8 +1712,7 @@ static const unsigned short cc_map[16] = {
 0   /* NV */
 };
 
-static int check_conditional_instr(struct cpu_user_regs *regs,
-   const union hsr hsr)
+int check_conditional_instr(struct cpu_user_regs *regs, const union hsr hsr)
 {
 unsigned long cpsr, cpsr_cond;
 int cond;
@@ -1758,7 +1757,7 @@ static int check_conditional_instr(struct cpu_user_regs 
*regs,
 return 1;
 }
 
-static void advance_pc(struct cpu_user_regs *regs, const union hsr hsr)
+void advance_pc(struct cpu_user_regs *regs, const union hsr hsr)
 {
 unsigned long itbits, cond, cpsr = regs->cpsr;
 
@@ -1799,11 +1798,11 @@ static void advance_pc(struct cpu_user_regs *regs, 
const union hsr hsr)
 }
 
 /* Read as zero and write ignore */
-static void handle_raz_wi(struct cpu_user_regs *regs,
-  int regidx,
-  bool read,
-  const union hsr hsr,
-  int min_el)
+void handle_raz_wi(struct cpu_user_regs *regs,
+   int regidx,
+   bool read,
+   const union hsr hsr,
+   int min_el)
 {
 ASSERT((min_el == 0) || (min_el == 1));
 
@@ -1817,12 +1816,12 @@ static void handle_raz_wi(struct cpu_user_regs *regs,
 advance_pc(regs, hsr);
 }
 
-/* Write only as write ignore */
-static void handle_wo_wi(struct cpu_user_regs *regs,
- int regidx,
- bool read,
- const union hsr hsr,
- int min_el)
+/* write only as write ignore */
+void handle_wo_wi(struct cpu_user_regs *regs,
+  int regidx,
+  bool read,
+  const union hsr hsr,
+  int min_el)
 {
 ASSERT((min_el == 0) || (min_el == 1));
 
@@ -1837,11 +1836,11 @@ static void handle_wo_wi(struct cpu_user_regs *regs,
 }
 
 /* Read only as read as zero */
-static void handle_ro_raz(struct cpu_user_regs *regs,
-  int regidx,
-  bool read,
-  const union hsr hsr,
-  int min_el)
+void handle_ro_raz(struct cpu_user_regs *regs,
+   int regidx,
+   bool read,
+   const union hsr hsr,
+   int min_el)
 {
 ASSERT((min_el == 0) || (min_el == 1));
 
diff --git a/xen/include/asm-arm/arm32/traps.h 
b/xen/include/asm-arm/arm32/traps.h
new file mode 100644
index 00..e3c4a8b473
--- /dev/null
+++ b/xen/include/asm-arm/arm32/traps.h
@@ -0,0 +1,13 @@
+#ifndef __ASM_ARM32_TRAPS__
+#define __ASM_ARM32_TRAPS__
+
+#endif /* __ASM_ARM32_TRAPS__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/include/asm-arm/arm64/traps.h 
b/xen/include/asm-arm/arm64/traps.h
new file mode 100644
index 

[Xen-devel] [PATCH 03/11] xen/arm: traps: Re-order the includes alphabetically

[Julien Grall]

Signed-off-by: Julien Grall 
---
 xen/arch/arm/traps.c | 42 ++
 1 file changed, 22 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c07999b518..ca9bef712c 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -16,41 +16,43 @@
  * GNU General Public License for more details.
  */
 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
-#include 
-#include 
-#include 
-#include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
-#include 
-#include 
+
 #include 
 #include 
-#include 
-#include 
-#include 
+
+#include 
 #include 
-#include 
-#include 
+#include 
 #include 
+#include 
+#include 
 #include 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
 
 #include "decode.h"
 #include "vtimer.h"
-#include 
-#include 
-#include 
-#include 
 
 /* The base of the stack must always be double-word aligned, which means
  * that both the kernel half of struct cpu_user_regs (which is pushed in
-- 
2.11.0


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

[Xen-devel] [PATCH 10/11] xen/arm: Move sysregs.h in arm64 sub-directory

[Julien Grall]

sysregs.h contains only code protected by #ifdef CONFIG_ARM_64. Move it
in arm64 sub-directory to reflect that and remove the #ifdef.

At the same time, fixup the guards.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/arm64/processor.h |  2 ++
 xen/include/asm-arm/{ => arm64}/sysregs.h | 10 +++---
 xen/include/asm-arm/processor.h   |  1 -
 3 files changed, 5 insertions(+), 8 deletions(-)
 rename xen/include/asm-arm/{ => arm64}/sysregs.h (98%)

diff --git a/xen/include/asm-arm/arm64/processor.h 
b/xen/include/asm-arm/arm64/processor.h
index 24f836b023..c18ab7203d 100644
--- a/xen/include/asm-arm/arm64/processor.h
+++ b/xen/include/asm-arm/arm64/processor.h
@@ -3,6 +3,8 @@
 
 #include 
 
+#include 
+
 #ifndef __ASSEMBLY__
 
 /* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
diff --git a/xen/include/asm-arm/sysregs.h b/xen/include/asm-arm/arm64/sysregs.h
similarity index 98%
rename from xen/include/asm-arm/sysregs.h
rename to xen/include/asm-arm/arm64/sysregs.h
index 887368e248..084d2a1e5d 100644
--- a/xen/include/asm-arm/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -1,7 +1,5 @@
-#ifndef __ASM_ARM_SYSREGS_H
-#define __ASM_ARM_SYSREGS_H
-
-#ifdef CONFIG_ARM_64
+#ifndef __ASM_ARM_ARM64_SYSREGS_H
+#define __ASM_ARM_ARM64_SYSREGS_H
 
 #include 
 
@@ -168,9 +166,7 @@
 #define ICH_AP1R2_EL2 __AP1Rx_EL2(2)
 #define ICH_AP1R3_EL2 __AP1Rx_EL2(3)
 
-#endif
-
-#endif
+#endif /* _ASM_ARM_ARM64_SYSREGS_H */
 
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 855ded1b07..9eacb1be29 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -2,7 +2,6 @@
 #define __ASM_ARM_PROCESSOR_H
 
 #include 
-#include 
 #ifndef __ASSEMBLY__
 #include 
 #endif
-- 
2.11.0


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

[Xen-devel] [PATCH 01/11] xen/grant_table: Include mm.h in xen/grant_table.h

[Julien Grall]

While re-ordering the include alphabetically in arch/arm/domain.c, I got
a complitation error because grant_table.h is using gfn_t before been
defined:

In file included from domain.c:14:0:
xen/xen/include/xen/grant_table.h:153:29: error: unknown type name ‘gfn_t’
 gfn_t *gfn, uint16_t *status);
 ^

Fix it by including xen/mm.h in it.

Signed-off-by: Julien Grall 

---

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/include/xen/grant_table.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 4e7789968c..7913facf9f 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -23,6 +23,7 @@
 #ifndef __XEN_GRANT_TABLE_H__
 #define __XEN_GRANT_TABLE_H__
 
+#include 
 #include 
 #include 
 #include 
-- 
2.11.0


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

[Xen-devel] [PATCH 05/11] xen/arm: vtimer: Re-order the includes alphabetically

[Julien Grall]

Signed-off-by: Julien Grall 
---
 xen/arch/arm/vtimer.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 32ac1279ae..9c7e8f441c 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -18,16 +18,17 @@
  */
 
 #include 
-#include 
-#include 
 #include 
+#include 
+#include 
+
 #include 
+#include 
 #include 
+#include 
 #include 
-#include 
 #include 
 #include 
-#include 
 
 /*
  * Check if regs is allowed access, user_gate is tail end of a
-- 
2.11.0


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

[Xen-devel] [PATCH 08/11] xen/arm: Move sysreg emulation outside of traps.c

[Julien Grall]

The sysreg emulation is 64-bit specific and surrounded by #ifdef. Move
them in a separate file arm/arm64/vsysreg.c to shrink down a bit traps.c

No functional change.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/arm64/Makefile   |   1 +
 xen/arch/arm/arm64/vsysreg.c  | 229 ++
 xen/arch/arm/traps.c  | 198 
 xen/include/asm-arm/arm64/traps.h |   3 +
 4 files changed, 233 insertions(+), 198 deletions(-)
 create mode 100644 xen/arch/arm/arm64/vsysreg.c

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 149b6b3901..718fe44455 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o
 obj-y += smpboot.o
 obj-y += traps.o
 obj-y += vfp.o
+obj-y += vsysreg.o
diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
new file mode 100644
index 00..c57ac12503
--- /dev/null
+++ b/xen/arch/arm/arm64/vsysreg.c
@@ -0,0 +1,229 @@
+/*
+ * xen/arch/arm/arm64/sysreg.c
+ *
+ * Emulate system registers trapped.
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * 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 
+
+void do_sysreg(struct cpu_user_regs *regs,
+   const union hsr hsr)
+{
+int regidx = hsr.sysreg.reg;
+struct vcpu *v = current;
+
+switch ( hsr.bits & HSR_SYSREG_REGS_MASK )
+{
+/*
+ * HCR_EL2.TACR
+ *
+ * ARMv8 (DDI 0487A.d): D7.2.1
+ */
+case HSR_SYSREG_ACTLR_EL1:
+if ( psr_mode_is_user(regs) )
+return inject_undef_exception(regs, hsr);
+if ( hsr.sysreg.read )
+set_user_reg(regs, regidx, v->arch.actlr);
+break;
+
+/*
+ * MDCR_EL2.TDRA
+ *
+ * ARMv8 (DDI 0487A.d): D1-1508 Table D1-57
+ */
+case HSR_SYSREG_MDRAR_EL1:
+return handle_ro_raz(regs, regidx, hsr.sysreg.read, hsr, 1);
+
+/*
+ * MDCR_EL2.TDOSA
+ *
+ * ARMv8 (DDI 0487A.d): D1-1509 Table D1-58
+ *
+ * Unhandled:
+ *OSLSR_EL1
+ *DBGPRCR_EL1
+ */
+case HSR_SYSREG_OSLAR_EL1:
+return handle_wo_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
+case HSR_SYSREG_OSDLR_EL1:
+return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
+
+/*
+ * MDCR_EL2.TDA
+ *
+ * ARMv8 (DDI 0487A.d): D1-1510 Table D1-59
+ *
+ * Unhandled:
+ *MDCCINT_EL1
+ *DBGDTR_EL0
+ *DBGDTRRX_EL0
+ *DBGDTRTX_EL0
+ *OSDTRRX_EL1
+ *OSDTRTX_EL1
+ *OSECCR_EL1
+ *DBGCLAIMSET_EL1
+ *DBGCLAIMCLR_EL1
+ *DBGAUTHSTATUS_EL1
+ */
+case HSR_SYSREG_MDSCR_EL1:
+return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
+case HSR_SYSREG_MDCCSR_EL0:
+/*
+ * Accessible at EL0 only if MDSCR_EL1.TDCC is set to 0. We emulate 
that
+ * register as RAZ/WI above. So RO at both EL0 and EL1.
+ */
+return handle_ro_raz(regs, regidx, hsr.sysreg.read, hsr, 0);
+HSR_SYSREG_DBG_CASES(DBGBVR):
+HSR_SYSREG_DBG_CASES(DBGBCR):
+HSR_SYSREG_DBG_CASES(DBGWVR):
+HSR_SYSREG_DBG_CASES(DBGWCR):
+return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
+
+/*
+ * MDCR_EL2.TPM
+ *
+ * ARMv8 (DDI 0487A.d): D1-1511 Table D1-61
+ *
+ * Unhandled:
+ *PMEVCNTR_EL0
+ *PMEVTYPER_EL0
+ *PMCCFILTR_EL0
+ * MDCR_EL2.TPMCR
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.17
+ * ARMv8 (DDI 0487A.d): D1-1511 Table D1-62
+ *
+ * NB: Both MDCR_EL2.TPM and MDCR_EL2.TPMCR cause trapping of PMCR.
+ */
+case HSR_SYSREG_PMINTENSET_EL1:
+case HSR_SYSREG_PMINTENCLR_EL1:
+/*
+ * Accessible from EL1 only, but if EL0 trap happens handle as
+ * undef.
+ */
+return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
+case HSR_SYSREG_PMUSERENR_EL0:
+/* RO at EL0. RAZ/WI at EL1 */
+if ( psr_mode_is_user(regs) )
+return handle_ro_raz(regs, regidx, hsr.sysreg.read, hsr, 0);
+else
+return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
+case HSR_SYSREG_PMCR_EL0:
+case HSR_SYSREG_PMCNTENSET_EL0:
+case HSR_SYSREG_PMCNTENCLR_EL0:
+case HSR_SYSREG_PMOVSCLR_EL0:
+case HSR_SYSREG_PMSWINC_EL0:
+case HSR_SYSREG_PMSELR_EL0:
+case HSR_SYSREG_PMCEID0_EL0:
+case 

[Xen-devel] [PATCH v2 4/4] x86/dom0: re-order DMA remapping enabling for PVH Dom0

[Roger Pau Monne]

Make sure the reserved regions are setup before enabling the DMA
remapping in the IOMMU, by calling dom0_setup_permissions before
iommu_hwdom_init. Also, in order to workaround IOMMU issues seen on
pre-Haswell Intel hardware, as described in patch "introduce a PVH
implementation of iommu_inclusive_mapping" make sure the DMA remapping
is enabled after populating Dom0 p2m.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since RFC:
 - Expand commit message to reference patch #3.
---
 xen/arch/x86/hvm/dom0_build.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 020c355faf..0e7d06be95 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -605,13 +605,6 @@ static int __init pvh_setup_cpus(struct domain *d, paddr_t 
entry,
 return rc;
 }
 
-rc = dom0_setup_permissions(d);
-if ( rc )
-{
-panic("Unable to setup Dom0 permissions: %d\n", rc);
-return rc;
-}
-
 update_domain_wallclock_time(d);
 
 clear_bit(_VPF_down, >pause_flags);
@@ -1059,7 +1052,12 @@ int __init dom0_construct_pvh(struct domain *d, const 
module_t *image,
 
 printk("** Building a PVH Dom0 **\n");
 
-iommu_hwdom_init(d);
+rc = dom0_setup_permissions(d);
+if ( rc )
+{
+printk("Unable to setup Dom0 permissions: %d\n", rc);
+return rc;
+}
 
 rc = pvh_setup_p2m(d);
 if ( rc )
@@ -1068,6 +1066,8 @@ int __init dom0_construct_pvh(struct domain *d, const 
module_t *image,
 return rc;
 }
 
+iommu_hwdom_init(d);
+
 rc = pvh_load_kernel(d, image, image_headroom, initrd, 
bootstrap_map(image),
  cmdline, , _info);
 if ( rc )
-- 
2.11.0 (Apple Git-81)


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

[Xen-devel] [PATCH v2 0/4] x86/pvh: implement iommu_inclusive_mapping for PVH Dom0

[Roger Pau Monne]

Hello,

Currently iommu_inclusive_mapping is not working for PVH Dom0, this patch
series allows using it for a PVH Dom0, which seems to be required in order to
boot on older boxes.

Git branch can be found at:

git://xenbits.xen.org/people/royger/xen.git iommu_inclusive_v2

Thanks, Roger.

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

[Xen-devel] [PATCH v2 2/4] x86/dom0: prevent PVH Dom0 from mapping read-only the IO APIC area

[Roger Pau Monne]

This is emulated by Xen and must not be mapped into PVH Dom0 p2m.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/dom0_build.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 3e0910d779..804efee1a9 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -402,7 +402,7 @@ int __init dom0_setup_permissions(struct domain *d)
 for ( i = 0; i < nr_ioapics; i++ )
 {
 mfn = paddr_to_pfn(mp_ioapics[i].mpc_apicaddr);
-if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
+if ( dom0_pvh || !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
 rc |= iomem_deny_access(d, mfn, mfn);
 }
 /* MSI range. */
-- 
2.11.0 (Apple Git-81)


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

Re: [Xen-devel] [PATCH V2 2/3] xen-pt: bind/unbind interrupt remapping format MSI

[Anthony PERARD]

On Wed, Aug 09, 2017 at 04:51:21PM -0400, Lan Tianyu wrote:
> From: Chao Gao 
> 
> If a vIOMMU is exposed to guest, guest will configure the msi to remapping
> format. The original code isn't suitable to the new format. A new pair
> bind/unbind interfaces are added for this usage. This patch recognizes
> this case and uses new interfaces to bind/unbind msi.
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 

Reviewed-by: Anthony PERARD 

That patch series can be applied once the Xen side patches are merged.

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] Regarding changing memory for DOM0

[George John]

Hi all,
Thank you for the reply.
I checked with xen version 4.9, Still the error for the filesystem
persists. What seems to be the problem?. I am attaching the log for the
above error and also the dts file I am using.

Regards,
George
NOTICE:  BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.9
NOTICE:  BL2: PRR is R-Car H3 ES1.1
NOTICE:  BL2: Boot device is HyperFlash(80MHz)
NOTICE:  BL2: LCM state is CM
NOTICE:  BL2: AVS setting succeeded. DVFS_SetVID=0x52
NOTICE:  BL2: DDR2400(rev.0.15)
NOTICE:  BL2: DRAM Split is 4ch
NOTICE:  BL2: QoS is default setting(rev.0.32)
NOTICE:  BL2: v1.1(release):3ad02ac
NOTICE:  BL2: Built : 15:16:01, Feb 15 2017
NOTICE:  BL2: Normal boot
NOTICE:  BL2: dst=0xe631a208 src=0x818 len=512(0x200)
NOTICE:  BL2: dst=0x43f0 src=0x8180400 len=6144(0x1800)
NOTICE:  BL2: dst=0x4400 src=0x81c len=65536(0x1)
NOTICE:  BL2: dst=0x4410 src=0x820 len=524288(0x8)
NOTICE:  BL2: dst=0x4900 src=0x864 len=1048576(0x10)


U-Boot 2015.04 (Feb 15 2017 - 15:16:02)

CPU: Renesas Electronics R8A7795 rev 1.1
Board: Salvator-X
I2C:   ready
DRAM:  3.9 GiB
MMC:   sh-sdhi: 0, sh-sdhi: 1, sh-sdhi: 2
In:serial
Out:   serial
Err:   serial
Net:   ravb
Hit any key to stop autoboot:  0 
ravb Waiting for PHY auto negotiation to complete.. done
ravb: 100Base/Full
Using ravb device
TFTP from server 192.168.1.100; our IP address is 192.168.1.1
Filename 'xen-uImage'.
Load address: 0x4808
Loading: #
 #
 ###
 129.9 KiB/s
done
Bytes transferred = 721296 (b0190 hex)
ravb:0 is connected to ravb.  Reconnecting to ravb
ravb Waiting for PHY auto negotiation to complete.. done
ravb: 100Base/Full
Using ravb device
TFTP from server 192.168.1.100; our IP address is 192.168.1.1
Filename 'r8a7795-salvator-x-dom0.dtb'.
Load address: 0x4800
Loading: #
 12.7 KiB/s
done
Bytes transferred = 65776 (100f0 hex)
ravb:0 is connected to ravb.  Reconnecting to ravb
ravb Waiting for PHY auto negotiation to complete.. done
ravb: 100Base/Full
Using ravb device
TFTP from server 192.168.1.100; our IP address is 192.168.1.1
Filename 'Image'.
Load address: 0x7a00
Loading: #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #

[Xen-devel] [qemu-mainline baseline-only test] 71961: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71961 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71961/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  20 capture-logs(20)broken REGR. vs. 71942
 test-armhf-armhf-libvirt-raw  6 xen-install   fail REGR. vs. 71942
 test-armhf-armhf-xl-multivcpu 19 leak-check/check fail REGR. vs. 71942
 test-amd64-i386-xl   23 leak-check/check  fail REGR. vs. 71942

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 test-amd64-i386-xl-qemuu-win10-i386 17 guest-stopfail blocked in 71942
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 71942
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   like 71942
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   like 71942
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 71942
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10  fail like 71942
 test-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   14 saverestore-support-checkfail   never pass
 test-armhf-armhf-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
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 17 guest-stop fail never pass

version targeted for testing:
 qemuub38df311c174c98ef8cce7dec9f46603b083018e
baseline version:
 qemuuac44ed2afb7c60255e989b163301479f5b4ecd04

Last test of basis71942  2017-08-05 14:47:33 Z5 days
Testing same since71961  2017-08-11 01:49:20 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Aleksandr Bezzubikov 
  Cleber Rosa 
  Cornelia Huck 
  Daniel P. Berrange 
  David Gibson 
  Denis V. Lunev 
  Dr. David Alan Gilbert 
  Eric Auger 
  Eric Blake 
  Fam Zheng 
  Greg Kurz 

[Xen-devel] [distros-debian-jessie test] 71962: tolerable trouble: blocked/broken/pass

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-armhf-jessie-netboot-pygrub  1 build-check(1) blocked n/a
 build-arm64   2 hosts-allocate   broken like 71936
 build-arm64-pvops 2 hosts-allocate   broken like 71936
 build-arm64-pvops 3 capture-logs broken like 71936
 build-arm64   3 capture-logs broken like 71936
 test-armhf-armhf-armhf-jessie-netboot-pygrub 12 migrate-support-check fail 
like 71936
 test-armhf-armhf-armhf-jessie-netboot-pygrub 13 saverestore-support-check fail 
like 71936

baseline version:
 flight   71936

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-arm64-arm64-armhf-jessie-netboot-pygrub blocked 
 test-armhf-armhf-armhf-jessie-netboot-pygrub pass
 test-amd64-amd64-i386-jessie-netboot-pygrub  pass



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.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Regarding changing memory for DOM0

[Andrii Anisov]

Hello George,


On 11.08.17 10:16, George John wrote:
I checked with xen version 4.9, Still the error for the filesystem 
persists. What seems to be the problem?. I am attaching the log for 
the above error and also the dts file I am using.
I've looked through the log and it is the same as on my table. Yes, 
nfs-root can not be mounted with this configuration. With root on MMC 
this setup will work.
This issue should be debugged, but I have my hands full so can not do it 
now.


The only thing I see from this point that this setup has less memory 
under 4GB (640MB vs 752MB). Theoretically lack of DMA-able RAM can lead 
to network malfunction.
So the question is if it's a real cause, and why XEN does not allocate 
whole under-4GB RAM to dom0.


--

*Andrii Anisov*

*
*


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

[Xen-devel] [ovmf baseline-only test] 71963: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71963 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71963/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f8daac8121e66c46d3374f63f80308a777c2a2e7
baseline version:
 ovmf 7ef0dae092afcfb6fab7e8372c78097672168c4a

Last test of basis71957  2017-08-10 03:20:58 Z1 days
Testing same since71963  2017-08-11 10:47:57 Z0 days1 attempts


People who touched revisions under test:
  Andrew Fish 
  Chris Ruffin 
  Huajing Li 
  Michael D Kinney 
  Ruiyu Ni 
  Star Zeng 
  Yonghong Zhu 

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-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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.


commit f8daac8121e66c46d3374f63f80308a777c2a2e7
Author: Ruiyu Ni 
Date:   Fri Aug 11 11:18:34 2017 +0800

ShellPkg/drivers: Fix GCC build failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 

commit 76c6f69ccadc7835c9616b077d9ff1b8e46fe49e
Author: Star Zeng 
Date:   Thu Aug 10 13:11:14 2017 +0800

IntelSiliconPkg: Fix VS2015 NOOPT IA32 build failure in IntelVTdDxe

There are VS2015 NOOPT IA32 build failure like below in IntelVTdDxe.
XXX.lib(XXX.obj) : error LNK2001: unresolved external symbol __allshl
XXX.lib(XXX.obj) : error LNK2001: unresolved external symbol __aullshr

This patch is to update Vtd.h to use UINT32 instead of UINT64 for
bitfields in structure definition, and also update IntelVTdDxe code
accordingly.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

commit 9169c6e81854c7479fcc99ce91704f3f3947e28f
Author: Andrew Fish 
Date:   Thu Aug 3 15:05:37 2017 +0800

MdePkg: Fix Xcode 9 Beta treating 32-bit left shift as undefined

Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=635

Cc: Liming Gao 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish 
Reviewed-by: Liming Gao 

commit 9458afa33728e64049d465f052b2c5c3ca3e881c
Author: Andrew Fish 
Date:   Thu Aug 3 15:05:10 2017 +0800

IntelFrameworkModulePkg: Fix Xcode 9 Beta treating 32-bit left shift as 
undefined

Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=635

Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish 
Reviewed-by: Liming Gao 

commit aa1d330b22c1d02796bfe95ba1de539374804422
Author: Andrew Fish 
Date:   Thu Aug 3 15:04:38 2017 +0800

DuetPkg: Fix Xcode 9 Beta treating 32-bit left shift as undefined

Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=635

Cc: Ruiyu Ni 
Cc: Hao Wu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish 
Reviewed-by: Hao Wu 

commit 59bc913c10a2296b0c5c83e4024c8b91000c8c8c
Author: Yonghong Zhu 
Date:   Wed Aug 2 17:19:02 2017 +0800

BaseTools: Fix Xcode 9 Beta treating 32-bit left shift as undefined

Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=635

Cc: 

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

[Peter Zijlstra]

On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote:
> Aah, okay. Now I understand the problem. The TLB isn't the issue but the
> IPI is serving two purposes here: TLB flushing (which is allowed to
> happen at any time) and serialization regarding access to critical pages
> (which seems to be broken in the Xen case as you suggest).

Indeed, and now hyper-v as well.

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

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

[Juergen Gross]

On 11/08/17 14:54, Peter Zijlstra wrote:
> On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote:
>> Aah, okay. Now I understand the problem. The TLB isn't the issue but the
>> IPI is serving two purposes here: TLB flushing (which is allowed to
>> happen at any time) and serialization regarding access to critical pages
>> (which seems to be broken in the Xen case as you suggest).
> 
> Indeed, and now hyper-v as well.

Is it possible to distinguish between non-critical calls of
flush_tlb_others() (which should be the majority IMHO) and critical ones
regarding above problem? I guess the only problem is the case when a
page table can be freed because its last valid entry is gone, right?

We might want to add a serialization flag to indicate flushing _and_
serialization via IPI should be performed.


Juergen

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

[Xen-devel] [PATCH v2] x86: check for allocation errors in modify_xen_mappings()

[Jan Beulich]

Reported-by: Julien Grall 
Signed-off-by: Jan Beulich 
---
v2: Comment the pl2e related ASSERT().

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5903,7 +5903,7 @@ int modify_xen_mappings(unsigned long s,
 {
 l3_pgentry_t *pl3e = virt_to_xen_l3e(v);
 
-if ( !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) )
+if ( !pl3e || !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) )
 {
 /* Confirm the caller isn't trying to create new mappings. */
 ASSERT(!(nf & _PAGE_PRESENT));
@@ -5931,6 +5931,8 @@ int modify_xen_mappings(unsigned long s,
 
 /* PAGE1GB: shatter the superpage and fall through. */
 pl2e = alloc_xen_pagetable();
+if ( !pl2e )
+return -ENOMEM;
 for ( i = 0; i < L2_PAGETABLE_ENTRIES; i++ )
 l2e_write(pl2e + i,
   l2e_from_pfn(l3e_get_pfn(*pl3e) +
@@ -5951,7 +5953,11 @@ int modify_xen_mappings(unsigned long s,
 free_xen_pagetable(pl2e);
 }
 
-pl2e = virt_to_xen_l2e(v);
+/*
+ * The L3 entry has been verified to be present, and we've dealt with
+ * 1G pages as well, so the L2 table cannot require allocation.
+ */
+pl2e = l3e_to_l2e(*pl3e) + l2_table_offset(v);
 
 if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
 {
@@ -5980,6 +5986,8 @@ int modify_xen_mappings(unsigned long s,
 {
 /* PSE: shatter the superpage and try again. */
 pl1e = alloc_xen_pagetable();
+if ( !pl1e )
+return -ENOMEM;
 for ( i = 0; i < L1_PAGETABLE_ENTRIES; i++ )
 l1e_write([i],
   l1e_from_pfn(l2e_get_pfn(*pl2e) + i,
@@ -6003,7 +6011,11 @@ int modify_xen_mappings(unsigned long s,
 {
 l1_pgentry_t nl1e;
 
-/* Ordinary 4kB mapping. */
+/*
+ * Ordinary 4kB mapping: The L2 entry has been verified to be
+ * present, and we've dealt with 2M pages as well, so the L1 table
+ * cannot require allocation.
+ */
 pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(v);
 
 /* Confirm the caller isn't trying to create new mappings. */




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

Re: [Xen-devel] [PATCH v2 2/4] arm: processor: add new struct hsr_smc32 into hsr union

[Volodymyr Babchuk]

On 10.08.17 00:22, Julien Grall wrote:



On 09/08/2017 22:06, Volodymyr Babchuk wrote:

Hi Julien,

On 09.08.17 23:34, Julien Grall wrote:



On 09/08/2017 20:44, Volodymyr Babchuk wrote:

On ARMv8, one of conditional exceptions (SMC that originates
from aarch32 state) have extra field in HCR.ISS encoding:


s/aarch32/AArch32/
s/have/has/

And the register is called HSR and not HCR.



CCKNOWNPASS, bit [19]
Indicates whether the instruction might have failed its condition
code check.
   0 - The instruction was unconditional, or was conditional and
   passed  its condition code check.
   1 - The instruction was conditional, and might have failed its
   condition code check.
(ARM DDI 0487A.k page D7-1949)


Please use the latest ARM ARM.



This is instruction specific field, so better to add new structure


This is an instruction...


to union hsr. This structure describes ISS encoding for an exception
from SMC instruction execution in AArch32 state. But we define this
struct for both ARMv7 and ARMv8. The reason is described in comment
to the structure:

"Nevertheless, we define this encoding for both ARMv7 and ARMv8,
because check_conditional_inst() should properly handle SMC
instruction in all modes: ARMv7, aarch32 and aarch64."


Hmmm. There are only two existing modes: AArch32 and AArch64. ARMv7 is
just a version of the specification which happen to only support 
AArch32.

Yeah, I wondered how to formulate that better. Problem is that ARMv7
specification does not use term "AArch32". So I decided to mention ARMv7
explicitly.


The term AArch32 was introduced with ARMv8 and use to refer 32-bit 
state. ARMv7 is only 32-bit, and therefore has only AArch32 state.
Hmm, maybe it is only me, but when I see term "AArch32" I automatically 
think about ARMv8 only, because I know that there was no such term in 
ARMv7. So for me "AArch32 or AArch64 state" sounds like "It is 
ARMv8-only thing, no ARMv7 there". Thus, I'd prefer to leave mention 
about ARMv7 for clarity. Maybe, just phrase it differently.



How about this: "check_conditional_inst() should properly handle SMC
instruction on both architectures (ARMv7 and ARMv8) while running in
aarch32 or aarch64 mode" ?


"ARMv8 allows to trap conditional SMC from AArch32 state even if the 
condition check failed. Modify check_conditional_inst() to handle them."





Actually Xen does not care about ARMv8 vs ARMv7. It only care about
AArch32 vs AArch64.

Yes. And probably it can be problem in the future. Because, as we can
see, there are differences between ARMv7 and ARMv8.


I don't see any problem. Bits not used are usually made RES{0,1} to 
allow later revision using them for new features.

Okay, I'll refrain from use word "problem" :)

There are also difference between ARMv8.0, ARMv8.1, ARMv8.2. But they 
always ensure backward compatibility on reading or a way to detect the 
new feature if the kernel has to set/clear bits.


In the case of the ISS for SMC, the bits used are RES0, with the new 
meaning 0 means the SMC is unconditional or the condition passed. This 
is compatible with ARMv7 because conditional SMC are only trapped when 
the condition check passed.

I'll rewrite comments in terms of backward compatibility then.

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

Re: [Xen-devel] [PATCH v2 2/4] arm: processor: add new struct hsr_smc32 into hsr union

[Julien Grall]

On 11/08/17 14:26, Volodymyr Babchuk wrote:



On 10.08.17 00:22, Julien Grall wrote:



On 09/08/2017 22:06, Volodymyr Babchuk wrote:

Hi Julien,

On 09.08.17 23:34, Julien Grall wrote:



On 09/08/2017 20:44, Volodymyr Babchuk wrote:

On ARMv8, one of conditional exceptions (SMC that originates
from aarch32 state) have extra field in HCR.ISS encoding:


s/aarch32/AArch32/
s/have/has/

And the register is called HSR and not HCR.



CCKNOWNPASS, bit [19]
Indicates whether the instruction might have failed its condition
code check.
   0 - The instruction was unconditional, or was conditional and
   passed  its condition code check.
   1 - The instruction was conditional, and might have failed its
   condition code check.
(ARM DDI 0487A.k page D7-1949)


Please use the latest ARM ARM.



This is instruction specific field, so better to add new structure


This is an instruction...


to union hsr. This structure describes ISS encoding for an exception
from SMC instruction execution in AArch32 state. But we define this
struct for both ARMv7 and ARMv8. The reason is described in comment
to the structure:

"Nevertheless, we define this encoding for both ARMv7 and ARMv8,
because check_conditional_inst() should properly handle SMC
instruction in all modes: ARMv7, aarch32 and aarch64."


Hmmm. There are only two existing modes: AArch32 and AArch64. ARMv7 is
just a version of the specification which happen to only support
AArch32.

Yeah, I wondered how to formulate that better. Problem is that ARMv7
specification does not use term "AArch32". So I decided to mention ARMv7
explicitly.


The term AArch32 was introduced with ARMv8 and use to refer 32-bit
state. ARMv7 is only 32-bit, and therefore has only AArch32 state.

Hmm, maybe it is only me, but when I see term "AArch32" I automatically
think about ARMv8 only, because I know that there was no such term in
ARMv7. So for me "AArch32 or AArch64 state" sounds like "It is
ARMv8-only thing, no ARMv7 there". Thus, I'd prefer to leave mention
about ARMv7 for clarity. Maybe, just phrase it differently.


You are right here. For me, they are the same because ARMv8 32-bit has 
been designed to be compatible with the former. I would tend to use ARM 
32-bit and AArch32 interchangeably.





How about this: "check_conditional_inst() should properly handle SMC
instruction on both architectures (ARMv7 and ARMv8) while running in
aarch32 or aarch64 mode" ?


"ARMv8 allows to trap conditional SMC from AArch32 state even if the
condition check failed. Modify check_conditional_inst() to handle them."




Actually Xen does not care about ARMv8 vs ARMv7. It only care about
AArch32 vs AArch64.

Yes. And probably it can be problem in the future. Because, as we can
see, there are differences between ARMv7 and ARMv8.


I don't see any problem. Bits not used are usually made RES{0,1} to
allow later revision using them for new features.

Okay, I'll refrain from use word "problem" :)


There are a few differences between the both. But I would not call that 
a problem as they are mostly the same.





There are also difference between ARMv8.0, ARMv8.1, ARMv8.2. But they
always ensure backward compatibility on reading or a way to detect the
new feature if the kernel has to set/clear bits.

In the case of the ISS for SMC, the bits used are RES0, with the new
meaning 0 means the SMC is unconditional or the condition passed. This
is compatible with ARMv7 because conditional SMC are only trapped when
the condition check passed.

I'll rewrite comments in terms of backward compatibility then.


Cheers,

--
Julien Grall

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

[Xen-devel] [xen-unstable-smoke test] 112596: tolerable trouble: broken/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112559
 build-arm64   2 hosts-allocate  broken like 112559
 build-arm64-pvops 3 capture-logsbroken like 112559
 build-arm64   3 capture-logsbroken like 112559
 test-amd64-amd64-libvirt 13 migrate-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  de62402a9c2e403b049aa238b4fa4e2d618e8870
baseline version:
 xen  b24731b1b4ce9f032116831ac825b227965232aa

Last test of basis   112559  2017-08-10 15:01:47 Z0 days
Testing same since   112596  2017-08-11 12:01:28 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Pushing revision :

+ branch=xen-unstable-smoke
+ revision=de62402a9c2e403b049aa238b4fa4e2d618e8870
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
de62402a9c2e403b049aa238b4fa4e2d618e8870
+ branch=xen-unstable-smoke
+ revision=de62402a9c2e403b049aa238b4fa4e2d618e8870
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' xde62402a9c2e403b049aa238b4fa4e2d618e8870 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : 

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

[Peter Zijlstra]

On Fri, Aug 11, 2017 at 02:22:25PM +0200, Juergen Gross wrote:
> Wait - the TLB can be cleared at any time, as Andrew was pointing out.
> No cpu can rely on an address being accessible just because IF is being
> cleared. All that matters is the existing and valid page table entry.
> 
> So clearing IF on a cpu isn't meant to secure the TLB from being
> cleared, but just to avoid interrupts (as the name of the flag is
> suggesting).

Yes, but by holding off the TLB invalidate IPI, we hold off the freeing
of the concurrently unhooked page-table.

> In the Xen case the hypervisor does the following:
> 
> - it checks whether any of the vcpus specified in the cpumask of the
>   flush request is running on any physical cpu
> - if any running vcpu is found an IPI will be sent to the physical cpu
>   and the hypervisor will do the TLB flush there

And this will preempt a vcpu which could have IF cleared, right?

> - any vcpu addressed by the flush and not running will be flagged to
>   flush its TLB when being scheduled the next time
> 
> This ensures no TLB entry to be flushed can be used after return of
> xen_flush_tlb_others().

But that is not a sufficient guarantee. We need the IF to hold off the
TLB invalidate and thereby hold off the freeing of our page-table pages.

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

Re: [Xen-devel] [RFC v2 13/23] x86/power/64: Adapt assembly for PIE support

[Pavel Machek]

On Thu 2017-08-10 10:26:05, Thomas Garnier wrote:
> Change the assembly code to use only relative references of symbols for the
> kernel to be PIE compatible.
> 
> Position Independent Executable (PIE) support will allow to extended the
> KASLR randomization range below the -2G memory limit.
> 
> Signed-off-by: Thomas Garnier 

Acked-by: Pavel Machek 

> --- a/arch/x86/power/hibernate_asm_64.S
> +++ b/arch/x86/power/hibernate_asm_64.S
> @@ -24,7 +24,7 @@
>  #include 
>  
>  ENTRY(swsusp_arch_suspend)
> - movq$saved_context, %rax
> + leaqsaved_context(%rip), %rax
>   movq%rsp, pt_regs_sp(%rax)
>   movq%rbp, pt_regs_bp(%rax)
>   movq%rsi, pt_regs_si(%rax)
> @@ -115,7 +115,7 @@ ENTRY(restore_registers)
>   movq%rax, %cr4;  # turn PGE back on
>  
>   /* We don't restore %rax, it must be 0 anyway */
> - movq$saved_context, %rax
> + leaqsaved_context(%rip), %rax
>   movqpt_regs_sp(%rax), %rsp
>   movqpt_regs_bp(%rax), %rbp
>   movqpt_regs_si(%rax), %rsi

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

[Juergen Gross]

On 11/08/17 14:35, Peter Zijlstra wrote:
> On Fri, Aug 11, 2017 at 02:22:25PM +0200, Juergen Gross wrote:
>> Wait - the TLB can be cleared at any time, as Andrew was pointing out.
>> No cpu can rely on an address being accessible just because IF is being
>> cleared. All that matters is the existing and valid page table entry.
>>
>> So clearing IF on a cpu isn't meant to secure the TLB from being
>> cleared, but just to avoid interrupts (as the name of the flag is
>> suggesting).
> 
> Yes, but by holding off the TLB invalidate IPI, we hold off the freeing
> of the concurrently unhooked page-table.
> 
>> In the Xen case the hypervisor does the following:
>>
>> - it checks whether any of the vcpus specified in the cpumask of the
>>   flush request is running on any physical cpu
>> - if any running vcpu is found an IPI will be sent to the physical cpu
>>   and the hypervisor will do the TLB flush there
> 
> And this will preempt a vcpu which could have IF cleared, right?
> 
>> - any vcpu addressed by the flush and not running will be flagged to
>>   flush its TLB when being scheduled the next time
>>
>> This ensures no TLB entry to be flushed can be used after return of
>> xen_flush_tlb_others().
> 
> But that is not a sufficient guarantee. We need the IF to hold off the
> TLB invalidate and thereby hold off the freeing of our page-table pages.

Aah, okay. Now I understand the problem. The TLB isn't the issue but the
IPI is serving two purposes here: TLB flushing (which is allowed to
happen at any time) and serialization regarding access to critical pages
(which seems to be broken in the Xen case as you suggest).

Juergen

> 


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

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

[Volodymyr Babchuk]

Hi Julien,

On 11.08.17 00:09, Julien Grall wrote:



On 10/08/2017 21:09, Volodymyr Babchuk wrote:

Hi,

On 10.08.17 21:18, Julien Grall wrote:

Hi,

On 10/08/17 18:40, Volodymyr Babchuk wrote:



On 10.08.17 19:11, Julien Grall wrote:



On 10/08/17 16:33, Volodymyr Babchuk wrote:

Hi Julien,

On 09.08.17 13:10, Julien Grall wrote:

Hi Volodymyr,

CC "THE REST" maintainers to get an opinion on the public headers.

On 08/08/17 21:08, Volodymyr Babchuk wrote:

SMCCC (SMC Call Convention) describes how to handle both HVCs and
SMCs.
SMCCC states that both HVC and SMC are valid conduits to call to a
different
firmware functions. Thus, for example PSCI calls can be made 
both by

SMC or HVC. Also SMCCC defines function number coding for such
calls.
Besides functional calls there are query calls, which allows
underling
OS determine version, UID and number of functions provided by
service
provider.

This patch adds new file `vsmc.c`, which handles both generic SMCs
and HVC according to SMC. At this moment it implements only one
service: Standard Hypervisor Service.

Standard Hypervisor Service only supports query calls, so caller 
can

ask about hypervisor UID and determine that it is XEN running.

This change allows more generic handling for SMCs and HVCs and it
can
be easily extended to support new services and functions.

But, before SMC is forwarded to standard SMCCC handler, it can be
routed
to a domain monitor, if one is installed.

Signed-off-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Andrushchenko

Reviewed-by: Oleksandr Tyshchenko 
---
 - Updated description to indicate that this patch affects only SMC
call path.
 - added "xen_" prefix to definitions in
include/public/arch-arm/smc.h
 - moved do_trap_smc() into vsmc.c from traps.c
 - replaced all tabs with spaces


I would have really appreciated a summary of the discussion we 
had on

the previous version regarding the bindings. This is a real blocker
for this series and should not be ignored.



While I agree that question about bindings is important, I can't
see how
it affects this patch series. This patch series does not break
anything.
Because

1. This series add only new feature: generic hypervisor service
with no
immediate use. All ARM guests are already aware that they are
running on
XEN. All ARM guests know that they call *only* PSCI.

2. I see importance of this patch series for embedded platforms, 
where

developer exactly knows what software of which version he/she will
run.
I doubt that server platforms will need something beyond PSCI, 
which I

preserved as is.


I disagree here. SMCCC could be used to provide Dom0 a way to interact
with the firmware if necessary.

AFAIK, Dom0 usually is built with particular version of XEN in mind (or
at least minimal XEN version).


That's not true. Dom0 is a generic kernel able to probe everything
from the firmware tables and Xen interface. I use the exact Linux
kernel on multiple platforms with no issue.

Okay, I was speaking about embedded use case.


Bear in mind that Xen is not only embedded. When you upstream a new 
feature you have to think about how this could be used by anyone.



The Hypervisor and Dom0 (Linux, FreeBSD) are different projects with
different release cadence. We provide a stable interface that is
backward compatible (returning error code for non-existent
hypercalls). So a Linux released in 10 years should still work on Xen
4.10 and adapt to the features available.

I just want to clarify this. At least four hypercalls are not backward
compatible: platform_op, sysctl, domctl and flask_op. I had a problem
with this, when played with MiniOS-based monitor. Sure, your kernel will
boot up, but some well known XEN services will be absent.
This have nothing with SMC bindings problem, though.


I am not sure to follow here... Were they ever be supported on ARM? If 
not, then it is no a backward compatibility issue. You cannot assume 
that all the hypercalls existing on x86 will be available on ARM.


For a list of known available/supported hypercalls for ARM see:
public/include/arch-arm.h.

Also bear in mind that some hypercalls are not part of the stable ABI. 
For instance domctls are not stable and it is well-known that you have 
to rebuild your app for every new Xen versions...


But domctls will never be used in Linux Kernel as they only meant to be 
used to control a domain.








A I'm not denying importance of SMC bindings, but I think it is not
blocker for my patches. We can add bindings later, when there will be
consensus on how they should look. In meantime SMC handler can be 
used

by anyone who knows that is available.


I am not in favor on getting something merged in Xen until we agree on
the way for the guest to know it is there.

I think that SMC implementation will be the same, regardless the way we
can tell guest that it is available. At this time guests can safely
assume 

Re: [Xen-devel] [PATCH v2 3/3] x86/p2m-pt: pass level instead of page type to p2m_next_level()

[Jan Beulich]

>>> On 27.07.17 at 18:50,  wrote:
> On Wed, Jul 5, 2017 at 11:06 AM, Jan Beulich  wrote:
>> This in turn calls for p2m_alloc_ptp() also being passed the numeric
>> level.
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> v2: New.
>> ---
>> Question is whether passing the level to p2m_alloc_ptp() is really all
>> that useful: p2m-ept.c's only use passes zero anyway, and p2m.c's
>> uniform passing of 4 doesn't necessarily match reality afaict.
> 
> I agree that we should either fix it properly (so that it reflects
> reality), or make it always be the same value.
> 
> Well the original reason for keeping track of the different paging
> levels in type_info was for PV pagetables, right?  I can't off the top
> of my head think of a reason that it's important to keep track of the
> different levels for p2m tables.
> 
> It probably *is* good to prevent such a page from winding up in a
> writeable entry of a PV guest; so maybe following p2m.c's lead and
> always setting it to PGT_l4_page_table?

Yeah, probably that's the safest we can do.

> Other than that...
> 
> 
>>  new_entry = l1e_from_pfn(mfn_x(mfn), P2M_BASE_FLAGS | _PAGE_RW);
>>
>> -switch ( type ) {
>> -case PGT_l3_page_table:
>> -p2m_add_iommu_flags(_entry, 3, 
>> IOMMUF_readable|IOMMUF_writable);
>> -p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, 4);
>> -break;
>> -case PGT_l2_page_table:
>> -p2m_add_iommu_flags(_entry, 2, 
>> IOMMUF_readable|IOMMUF_writable);
>> -p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, 3);
>> -break;
>> -case PGT_l1_page_table:
>> -p2m_add_iommu_flags(_entry, 1, 
>> IOMMUF_readable|IOMMUF_writable);
>> -p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, 2);
>> -break;
>> -default:
>> -BUG();
>> -break;
>> -}
>> +p2m_add_iommu_flags(_entry, level, 
>> IOMMUF_readable|IOMMUF_writable);
>> +p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 1);
> 
> ...this looks *much better*, thanks!
> 
> Reviewed-by: George Dunlap 

Thanks!

Jan


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

[Xen-devel] [qemu-mainline test] 112581: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
112557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-localmigrate fail REGR. vs. 
112557

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate  broken like 112557
 build-arm64-xsm   2 hosts-allocate  broken like 112557
 build-arm64-xsm   3 capture-logsbroken like 112557
 build-arm64   3 capture-logsbroken like 112557
 build-arm64-pvops 2 hosts-allocate  broken like 112557
 build-arm64-pvops 3 capture-logsbroken like 112557
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112557
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112557
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112557
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112557
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   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:
 qemuu473a321122fd3c2c327a5a5d01a9a41f26f1734c
baseline version:
 qemuub38df311c174c98ef8cce7dec9f46603b083018e

Last test of basis   112557  2017-08-10 14:50:06 Z0 days
Testing same since   112581  2017-08-11 02:00:41 Z0 days1 attempts


People who touched revisions under test:
  Greg Kurz 
  Peter Maydell 
  Philippe Mathieu-Daudé 
  Zhi Yong Wu 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   

[Xen-devel] [PATCH v3 2/3] x86/p2m: make p2m_alloc_ptp() return an MFN

[Jan Beulich]

None of the callers really needs the struct page_info pointer.

Signed-off-by: Jan Beulich 
Acked-by: George Dunlap 
---
v3: Re-base over changes to patch 1.
v2: Re-base over changes to patch 1.

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -569,7 +569,7 @@ int p2m_set_entry(struct p2m_domain *p2m
 return rc;
 }
 
-struct page_info *p2m_alloc_ptp(struct p2m_domain *p2m, unsigned long type)
+mfn_t p2m_alloc_ptp(struct p2m_domain *p2m, unsigned long type)
 {
 struct page_info *pg;
 
@@ -577,13 +577,13 @@ struct page_info *p2m_alloc_ptp(struct p
 ASSERT(p2m->domain);
 ASSERT(p2m->domain->arch.paging.alloc_page);
 pg = p2m->domain->arch.paging.alloc_page(p2m->domain);
-if (pg == NULL)
-return NULL;
+if ( !pg )
+return INVALID_MFN;
 
 page_list_add_tail(pg, >pages);
 pg->u.inuse.type_info = type | 1 | PGT_validated;
 
-return pg;
+return page_to_mfn(pg);
 }
 
 void p2m_free_ptp(struct p2m_domain *p2m, struct page_info *pg)
@@ -609,7 +609,7 @@ void p2m_free_ptp(struct p2m_domain *p2m
  */
 int p2m_alloc_table(struct p2m_domain *p2m)
 {
-struct page_info *p2m_top;
+mfn_t top_mfn;
 struct domain *d = p2m->domain;
 int rc = 0;
 
@@ -632,14 +632,14 @@ int p2m_alloc_table(struct p2m_domain *p
 
 P2M_PRINTK("allocating p2m table\n");
 
-p2m_top = p2m_alloc_ptp(p2m, PGT_l4_page_table);
-if ( p2m_top == NULL )
+top_mfn = p2m_alloc_ptp(p2m, PGT_l4_page_table);
+if ( mfn_eq(top_mfn, INVALID_MFN) )
 {
 p2m_unlock(p2m);
 return -ENOMEM;
 }
 
-p2m->phys_table = pagetable_from_mfn(page_to_mfn(p2m_top));
+p2m->phys_table = pagetable_from_mfn(top_mfn);
 
 if ( hap_enabled(d) )
 iommu_share_p2m_table(d);
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -225,16 +225,16 @@ static void ept_p2m_type_to_flags(struct
 /* Fill in middle levels of ept table */
 static int ept_set_middle_entry(struct p2m_domain *p2m, ept_entry_t *ept_entry)
 {
-struct page_info *pg;
+mfn_t mfn;
 ept_entry_t *table;
 unsigned int i;
 
-pg = p2m_alloc_ptp(p2m, 0);
-if ( pg == NULL )
+mfn = p2m_alloc_ptp(p2m, 0);
+if ( mfn_eq(mfn, INVALID_MFN) )
 return 0;
 
 ept_entry->epte = 0;
-ept_entry->mfn = page_to_mfn(pg);
+ept_entry->mfn = mfn_x(mfn);
 ept_entry->access = p2m->default_access;
 
 ept_entry->r = ept_entry->w = ept_entry->x = 1;
@@ -243,7 +243,7 @@ static int ept_set_middle_entry(struct p
 
 ept_entry->suppress_ve = 1;
 
-table = __map_domain_page(pg);
+table = map_domain_page(mfn);
 
 for ( i = 0; i < EPT_PAGETABLE_ENTRIES; i++ )
 table[i].suppress_ve = 1;
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -204,14 +204,12 @@ p2m_next_level(struct p2m_domain *p2m, v
 /* PoD/paging: Not present doesn't imply empty. */
 if ( !flags )
 {
-struct page_info *pg;
+mfn_t mfn = p2m_alloc_ptp(p2m, type);
 
-pg = p2m_alloc_ptp(p2m, type);
-if ( pg == NULL )
+if ( mfn_eq(mfn, INVALID_MFN) )
 return -ENOMEM;
 
-new_entry = l1e_from_pfn(mfn_x(page_to_mfn(pg)),
- P2M_BASE_FLAGS | _PAGE_RW);
+new_entry = l1e_from_pfn(mfn_x(mfn), P2M_BASE_FLAGS | _PAGE_RW);
 
 switch ( type ) {
 case PGT_l3_page_table:
@@ -235,7 +233,7 @@ p2m_next_level(struct p2m_domain *p2m, v
 {
 /* Split superpages pages into smaller ones. */
 unsigned long pfn = l1e_get_pfn(*p2m_entry);
-struct page_info *pg;
+mfn_t mfn;
 l1_pgentry_t *l1_entry;
 unsigned int i, level;
 
@@ -263,11 +261,11 @@ p2m_next_level(struct p2m_domain *p2m, v
 return -EINVAL;
 }
 
-pg = p2m_alloc_ptp(p2m, type);
-if ( pg == NULL )
+mfn = p2m_alloc_ptp(p2m, type);
+if ( mfn_eq(mfn, INVALID_MFN) )
 return -ENOMEM;
 
-l1_entry = __map_domain_page(pg);
+l1_entry = map_domain_page(mfn);
 
 /* Inherit original IOMMU permissions, but update Next Level. */
 if ( iommu_hap_pt_share )
@@ -285,8 +283,7 @@ p2m_next_level(struct p2m_domain *p2m, v
 
 unmap_domain_page(l1_entry);
 
-new_entry = l1e_from_pfn(mfn_x(page_to_mfn(pg)),
- P2M_BASE_FLAGS | _PAGE_RW);
+new_entry = l1e_from_pfn(mfn_x(mfn), P2M_BASE_FLAGS | _PAGE_RW);
 p2m_add_iommu_flags(_entry, level, 
IOMMUF_readable|IOMMUF_writable);
 p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 1);
 }
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -684,7 +684,7 @@ void p2m_mem_paging_resume(struct domain
  * Internal functions, only called by other p2m code
  */
 
-struct page_info *p2m_alloc_ptp(struct p2m_domain *p2m, unsigned long type);
+mfn_t p2m_alloc_ptp(struct p2m_domain *p2m, unsigned long 

[Xen-devel] Alloc Page from fixed physical memory range

[Waseem, Amna]

Hello All,


Is there any way in linux e.g using device tree, to give a driver a fixed 
physical memory range to alloc pages from? All pages are allocated from kernel 
memory assigned using memory node in device tree. Is there any way to create a 
memory node and assign it to driver so that buddy allocator allocates pages 
from that node for that particular device?


Any help will be highly appreciated


REgards

Amna
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 9/9] vpci/msix: add MSI-X handlers

[Roger Pau Monné]

On Fri, Aug 11, 2017 at 04:01:05AM -0600, Jan Beulich wrote:
> >>> On 10.08.17 at 19:04,  wrote:
> > On Wed, Aug 02, 2017 at 09:07:54AM -0600, Jan Beulich wrote:
> >> >>> Roger Pau Monne  06/30/17 5:01 PM >>>
> >> >@@ -113,6 +148,35 @@ static int vpci_modify_bar(struct domain *d, const 
> >> >struct vpci_bar *bar,
> >> >if ( IS_ERR(mem) )
> >> >return -PTR_ERR(mem);
> >>  >
> >> >+/*
> >> >+ * Make sure the MSI-X regions of the BAR are not mapped into the 
> >> >domain
> >> >+ * p2m, or else the MSI-X handlers are useless. Only do this when 
> >> >mapping,
> >> >+ * since that's when the memory decoding on the device is enabled.
> >> >+ */
> >> >+for ( i = 0; map && i < ARRAY_SIZE(bar->msix); i++ )
> >> >+{
> >> >+struct vpci_msix_mem *msix = bar->msix[i];
> >> >+
> >> >+if ( !msix || msix->addr == INVALID_PADDR )
> >> >+continue;
> >> >+
> >> >+rc = vpci_unmap_msix(d, msix);
> >> 
> >> Why do you need this, instead of being able to simply rely on the rangeset
> >> based (un)mapping?
> > 
> > This is because the series that I've sent called: "x86/pvh: implement
> > iommu_inclusive_mapping for PVH Dom0" will map the MSI-X memory areas
> > into the guest, and thus we need to make sure they are not mapped
> > here for the emulation path to work.
> > 
> > https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg02849.html 
> 
> Oh, okay. The patch description doesn't mention any such
> dependency though.

Will make that clearer on the next version, in fact I'm going to send
this series rebased on top of the iommu_inclusive_mapping one. AFAICT
that one is closer to being committed, and in any case changing the
order is trivial, there are not conflicts.

> >> >+break;
> >> >+case PCI_MSIX_ENTRY_DATA_OFFSET:
> >> >+/*
> >> >+ * 8 byte writes to the msg data and vector control fields are
> >> >+ * only allowed if the entry is masked.
> >> >+ */
> >> >+if ( len == 8 && !entry->masked && !msix->masked && 
> >> >msix->enabled )
> >> >+{
> >> >+vpci_unlock(d);
> >> >+return X86EMUL_OKAY;
> >> >+}
> >> 
> >> I don't think this is correct - iirc such writes simply don't take effect 
> >> immediately
> >> (but I then seem to recall this to apply to the address field and 32-bit 
> >> writes to
> >> the data field as well). They'd instead take effect the next time the 
> >> entry is being
> >> unmasked (or some such). A while ago I did fix the qemu code to behave in 
> >> this
> >> way.
> > 
> > There's an Implementation Note called "Special Considerations for QWORD
> > Accesses" in the MSI-X section of the PCI 3.0 spec that states:
> > 
> > If a given entry is currently masked (via its Mask bit or the Function
> > Mask bit), software is permitted to fill in the Message Data and
> > Vector Control fields with a single QWORD write, taking advantage of
> > the fact the Message Data field is guaranteed to become visible to
> > hardware no later than the Vector Control field.
> > 
> > So I think the above chunk is correct. The specification also states
> > that:
> > 
> > Software must not modify the Address or Data fields of an entry while
> > it is unmasked. Refer to Section 6.8.3.5 for details.
> > 
> > AFAICT this is not enforced by QEMU, and you can write to the
> > address/data fields while the message is not masked. The update will
> > only take effect once the message is masked and unmasked.
> 
> The spec also says:
> 
> "For MSI-X, a function is permitted to cache Address and Data values
>  from unmasked MSIX Table entries. However, anytime software
>  unmasks a currently masked MSI-X Table entry either by clearing its
>  Mask bit or by clearing the Function Mask bit, the function must
>  update any Address or Data values that it cached from that entry. If
>  software changes the Address or Data value of an entry while the
>  entry is unmasked, the result is undefined."

I'm not sure it's clear to me what to do if the guest writes to an
entry while unmasked. For once it says that it must not modify it, but
OTHO it says result is undefined when doing so.

Would you be fine with ignoring writes to the address and data fields
if the entry is unmasked?

> >> >+for_each_domain ( d )
> >> >+{
> >> >+if ( !has_vpci(d) )
> >> >+continue;
> >> >+
> >> >+printk("vPCI MSI-X information for guest %u\n", d->domain_id);
> >> 
> >> Wouldn't it be better (more useful) to dump the MSI and MSI-X data for a
> >> domain next to each other?
> > 
> > Possibly yes, and printing the MSI and MSI-X data of each device
> > together would be even better IMHO.
> 
> Not sure about that last aspect - devices aren't permitted to enable
> both at the same time, so only one of them can really be relevant.

I think (for debugging purposes) it's useful to print both together
in order to spot if the guest is doing 

Re: [Xen-devel] [RFC] xen/arm: Suspend to RAM Support in Xen for ARM

[Mirela Simonovic]

Hi Andrii,

Thank you very much for your feedback, please see my answers below.

On Thu, Aug 10, 2017 at 1:13 PM, Andrii Anisov 
wrote:

> Dear Mirela,
>
> Please see my comments below:
>
>
>
> On 09.08.17 20:43, Mirela Simonovic wrote:
>
>> This document contains our draft proposal for implementing "suspend to
>> RAM"
>> support for ARM in Xen, as discussed during the last Xen ARM community
>> call.
>> It covers the basic suspend to RAM mechanism based on ARM PSCI standard,
>> that would allow individual guests and Xen itself to suspend.
>>
>> We would appreciate your feedback.
>>
>> Signed-off-by: Mirela Simonovic 
>> ---
>>   docs/misc/arm/suspend-to-ram.txt | 210 ++
>> +
>>   1 file changed, 210 insertions(+)
>>   create mode 100644 docs/misc/arm/suspend-to-ram.txt
>>
>> diff --git a/docs/misc/arm/suspend-to-ram.txt
>> b/docs/misc/arm/suspend-to-ram.txt
>> new file mode 100644
>> index 00..ec8080fc64
>> --- /dev/null
>> +++ b/docs/misc/arm/suspend-to-ram.txt
>> @@ -0,0 +1,210 @@
>> +% Suspend to RAM Support in Xen for ARM
>> +% Revision 1.0
>> +
>> +
>> +Overview
>> +
>> +
>> +Suspend to RAM (in the following text 'suspend') for ARM in Xen should be
>> +coordinated using ARM PSCI standard [1].
>> +
>> +EL1/2 should suspend in the following order:
>> +1) Unprivileged guests (DomUs) suspend
>> +2) Privileged guest (Dom0) suspends
>> +3) Xen suspends
>>
> This order description makes an impression that unprivileged guest suspend
> triggers the system suspend, what is not true as per following text.

Instead I would describe separately two scenarios: suspend of an
> unprivileged domain and suspend of a privileged domain. E.g:
> Suspend of an unprivileged domain will:
> - suspend this domain only
>
> Suspend of a privileged domain will consequently:
> - trigger suspend of unprivileged domains
>

By this proposal triggering suspend of unprivileged guests will not be
done. However, I agree the scenario should work as you described and we
plan to support that as well.
In this proposal we focused only on PSCI-based mechanisms that will enable
top-down suspend to RAM flow. Once we have the mechanisms, we'll send a
proposal for supporting the coordination with domains, which will include
triggering suspend of unprivileged guests. Coordination will build on top
of what we propose here.


> - suspend privileged domain itself
> - trigger suspend of Xen hypervisor
>
>
> +
>> +Since this proposal is focused on implementing PSCI-based suspend
>> mechanisms in
>> +Xen, communication with or among the guests is not covered by this
>> document.
>> +The order of suspending the guests is assumed to be guaranteed by the
>> software
>> +running in EL1.
>> +
>> +-
>> +Suspending Guests
>> +-
>> +
>> +Suspend procedure for a guest consists of the following:
>> +1) Suspending devices
>> +2) Suspending non-boot CPUs
>> +3) System suspend, performed by the boot CPU
>> +
>> +Each guest should suspend the devices it owns. Suspending of devices is
>> not
>> +covered by this document. The document covers only mechanisms for
>> suspending
>> +non-boot CPUs, as well as the system suspend.
>> +
>> +Guests should suspend their non-boot vCPUs using the hotplug mechanism.
>> +Virtual CPUs should be put offline using the already implemented PSCI
>> vCPU_OFF
>> +call (prefix 'v' is added to distinguish PSCI calls made by guests to
>> Xen, which
>> +affect virtual machines; as opposed to PSCI calls made by Xen to the
>> EL3, which
>> +can affect power state of the physical machine).
>> +
>> +After suspending its non-boot vCPUs a guest should finalize the suspend
>> by
>> +making the vSYSTEM_SUSPEND PSCI call. The resume address is specified by
>> the
>> +guest via the vSYSTEM_SUSPEND entry_point_address argument. The
>> vSYSTEM_SUSPEND
>> +call is currently not implemented in Xen.
>> +
>> +It is expected that a guest leaves enabled all interrupts that should
>> wake it
>> +up. Other interrupts should be disabled by the guest prior to calling
>> +vSYSTEM_SUSPEND.
>> +
>> +After an unprivileged guest suspends, Xen will not suspend. Xen would
>> suspend
>> +only after the Dom0 completes the system suspend.
>> +
>> +--
>> +Suspending Xen
>> +--
>> +
>> +Xen should start suspending itself upon receiving the vSYSTEM_SUSPEND
>> call
>> +from the last running guest (Dom0). At that moment all physical CPUs are
>> still
>> +online (taking offline a vCPU or suspending a VM does not affect
>> physical CPUs).
>> +Xen shall now put offline the non-boot pCPUs by making the CPU_OFF PSCI
>> call
>> +to EL3. The CPU_OFF PSCI function is currently not implemented in Xen.
>> +
>> +After putting offline the non-boot cores Xen must save the context and
>> finalize
>> +suspend by invoking SYSTEM_SUSPEND PSCI call, which is passed to EL3.
>> +The resume point 

Re: [Xen-devel] [PATCH v2 1/3] x86/p2m-pt: simplify p2m_next_level()

[Jan Beulich]

>>> On 27.07.17 at 18:19,  wrote:
> On Wed, Jul 5, 2017 at 11:05 AM, Jan Beulich  wrote:
>> Calculate entry PFN and flags just once. Convert the two successive
>> main if()-s to and if/elf-if chain. Restrict variable scope where
>> reasonable. Take the opportunity and also make the induction variable
>> unsigned.
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> v2: Re-do mostly from scratch following review feedback.
>> Note: I have trouble seeing how the old code worked, when the 2M page
>>   shattering path specified neither read nor write permission for
>>   the IOMMU. Am I overlooking a reason why this was (and should
>>   remain) so?
> 
> Hmm -- given that in all other circumstances, a 4k page which is
> ram_rw gets RW, then I think the old code must certainly be buggy.

Oh, I think this is buggy in another way than I first thought: It
looks like it's meant to inherit the original flags (as they're not
being cleared from "flags"), but afaict that breaks the next
level field - that one is also being inherited, and then being
OR-ed into with the new next level field. I suppose all of this
has not caused issues simply because we've not allowed
shared page tables on AMD for quite a while (and both fields
are of no interest in the shadow mode case).

I'll drop the use of p2m_add_iommu_flags() in that particular
case altogether.

Jan


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

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

[Ingo Molnar]

* Thomas Garnier  wrote:

> Changes:
>  - v2:
>- Add support for global stack cookie while compiler default to fs without
>  mcmodel=kernel
>- Change patch 7 to correctly jump out of the identity mapping on kexec 
> load
>  preserve.
> 
> These patches make the changes necessary to build the kernel as Position
> Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
> the top 2G of the virtual address space. It allows to optionally extend the
> KASLR randomization range from 1G to 3G.

So this:

 61 files changed, 923 insertions(+), 299 deletions(-)

... is IMHO an _awful_ lot of churn and extra complexity in pretty fragile 
pieces 
of code, to gain what appears to be only ~1.5 more bits of randomization!

Do these changes get us closer to being able to build the kernel as truly 
position 
independent, i.e. to place it anywhere in the valid x86-64 address space? Or 
any 
other advantages?

Thanks,

Ingo

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

Re: [Xen-devel] [PATCH v2 0/3] fix xen hvm guest with kaslr enabled

[Ingo Molnar]

* Juergen Gross  wrote:

> On 08/08/17 16:00, Boris Ostrovsky wrote:
> > On 08/08/2017 02:46 AM, Juergen Gross wrote:
> >> On 28/07/17 12:23, Juergen Gross wrote:
> >>> This patch series fixes a regression introduced in 4.13-rc1: A Xen
> >>> HVM guest with KASLR enabled wouldn't boot any longer due to the usage
> >>> of __va() before kernel_randomize_memory() was called.
> >>>
> >>> Changes in V2:
> >>> - patch 1: test for x86_hyper being not NULL
> >>>
> >>> Juergen Gross (3):
> >>>   x86: provide an init_mem_mapping hypervisor hook
> >>>   xen: split up xen_hvm_init_shared_info()
> >>>   xen: fix hvm guest with kaslr enabled
> >>>
> >>>  arch/x86/include/asm/hypervisor.h | 10 +++
> >>>  arch/x86/mm/init.c|  3 ++
> >>>  arch/x86/xen/enlighten_hvm.c  | 59 
> >>> ---
> >>>  3 files changed, 50 insertions(+), 22 deletions(-)
> >>>
> >> Could I have some feedback, please?
> >>
> >> I'd like to get this regression fixed in 4.13.
> >>
> >> In case nobody objects this week I'll just add the patches to the Xen
> >> tree for rc5.
> > 
> > 
> > As I said before I think .init_mem_mapping() could live in
> > x86_platform_ops() but this works too, so
> > 
> > Reviewed-by: Boris Ostrovsky 
> > 
> > But this still wants x86 maintainers' ACK.
> 
> x86 maintainers, could you please comment on at least patch 1?

LGTM:

Acked-by: Ingo Molnar 

Thanks,

Ingo

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

[Xen-devel] [PATCH v3 0/3] x86/p2m: some code simplification

[Jan Beulich]

1: simplify p2m_next_level()
2: make p2m_alloc_ptp() return an MFN
3: pass level instead of page type to p2m_next_level()

Signed-off-by: Jan Beulich 

See individual patches for change info.


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

[Xen-devel] [PATCH v3 1/3] x86/p2m-pt: simplify p2m_next_level()

[Jan Beulich]

Calculate entry PFN and flags just once. Convert the two successive
main if()-s to and if/else-if chain. Restrict variable scope where
reasonable. Take the opportunity and also make the induction variable
unsigned.

This at once fixes excessive permissions granted in the 2M PTEs
resulting from splitting a 1G one - original permissions should be
inherited instead. This is not a security issue only because all of
this takes no effect anyway, as iommu_hap_pt_share is always false on
AMD systems for all supported branches.

Signed-off-by: Jan Beulich 
---
v3: Fix IOMMU permission handling for shattered PTEs.
v2: Re-do mostly from scratch following review feedback.

--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -191,18 +191,18 @@ p2m_next_level(struct p2m_domain *p2m, v
unsigned long *gfn_remainder, unsigned long gfn, u32 shift,
u32 max, unsigned long type, bool_t unmap)
 {
-l1_pgentry_t *l1_entry;
-l1_pgentry_t *p2m_entry;
-l1_pgentry_t new_entry;
+l1_pgentry_t *p2m_entry, new_entry;
 void *next;
-int i;
+unsigned int flags;
 
 if ( !(p2m_entry = p2m_find_entry(*table, gfn_remainder, gfn,
   shift, max)) )
 return -ENOENT;
 
+flags = l1e_get_flags(*p2m_entry);
+
 /* PoD/paging: Not present doesn't imply empty. */
-if ( !l1e_get_flags(*p2m_entry) )
+if ( !flags )
 {
 struct page_info *pg;
 
@@ -231,70 +231,67 @@ p2m_next_level(struct p2m_domain *p2m, v
 break;
 }
 }
-
-ASSERT(l1e_get_flags(*p2m_entry) & (_PAGE_PRESENT|_PAGE_PSE));
-
-/* split 1GB pages into 2MB pages */
-if ( type == PGT_l2_page_table && (l1e_get_flags(*p2m_entry) & _PAGE_PSE) )
+else if ( flags & _PAGE_PSE )
 {
-unsigned long flags, pfn;
+/* Split superpages pages into smaller ones. */
+unsigned long pfn = l1e_get_pfn(*p2m_entry);
 struct page_info *pg;
+l1_pgentry_t *l1_entry;
+unsigned int i, level;
 
-pg = p2m_alloc_ptp(p2m, PGT_l2_page_table);
-if ( pg == NULL )
-return -ENOMEM;
-
-flags = l1e_get_flags(*p2m_entry);
-pfn = l1e_get_pfn(*p2m_entry);
-
-l1_entry = __map_domain_page(pg);
-for ( i = 0; i < L2_PAGETABLE_ENTRIES; i++ )
+switch ( type )
 {
-new_entry = l1e_from_pfn(pfn | (i * L1_PAGETABLE_ENTRIES), flags);
-p2m_add_iommu_flags(_entry, 1, 
IOMMUF_readable|IOMMUF_writable);
-p2m->write_p2m_entry(p2m, gfn, l1_entry + i, new_entry, 2);
-}
-unmap_domain_page(l1_entry);
-new_entry = l1e_from_pfn(mfn_x(page_to_mfn(pg)),
- P2M_BASE_FLAGS | _PAGE_RW); /* disable PSE */
-p2m_add_iommu_flags(_entry, 2, IOMMUF_readable|IOMMUF_writable);
-p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, 3);
-}
+case PGT_l2_page_table:
+level = 2;
+break;
 
+case PGT_l1_page_table:
+/*
+ * New splintered mappings inherit the flags of the old superpage,
+ * with a little reorganisation for the _PAGE_PSE_PAT bit.
+ */
+if ( pfn & 1 )   /* ==> _PAGE_PSE_PAT was set */
+pfn -= 1;/* Clear it; _PAGE_PSE becomes _PAGE_PAT 
*/
+else
+flags &= ~_PAGE_PSE; /* Clear _PAGE_PSE (== _PAGE_PAT) */
 
-/* split single 2MB large page into 4KB page in P2M table */
-if ( type == PGT_l1_page_table && (l1e_get_flags(*p2m_entry) & _PAGE_PSE) )
-{
-unsigned long flags, pfn;
-struct page_info *pg;
+level = 1;
+break;
+
+default:
+ASSERT_UNREACHABLE();
+return -EINVAL;
+}
 
-pg = p2m_alloc_ptp(p2m, PGT_l1_page_table);
+pg = p2m_alloc_ptp(p2m, type);
 if ( pg == NULL )
 return -ENOMEM;
 
-/* New splintered mappings inherit the flags of the old superpage, 
- * with a little reorganisation for the _PAGE_PSE_PAT bit. */
-flags = l1e_get_flags(*p2m_entry);
-pfn = l1e_get_pfn(*p2m_entry);
-if ( pfn & 1 )   /* ==> _PAGE_PSE_PAT was set */
-pfn -= 1;/* Clear it; _PAGE_PSE becomes _PAGE_PAT */
-else
-flags &= ~_PAGE_PSE; /* Clear _PAGE_PSE (== _PAGE_PAT) */
-
 l1_entry = __map_domain_page(pg);
-for ( i = 0; i < L1_PAGETABLE_ENTRIES; i++ )
+
+/* Inherit original IOMMU permissions, but update Next Level. */
+if ( iommu_hap_pt_share )
 {
-new_entry = l1e_from_pfn(pfn | i, flags);
-p2m_add_iommu_flags(_entry, 0, 0);
-p2m->write_p2m_entry(p2m, gfn, l1_entry + i, new_entry, 1);
+flags &= ~iommu_nlevel_to_flags(~0, 0);
+flags |= iommu_nlevel_to_flags(level - 1, 0);
 

[Xen-devel] [PATCH v3 3/3] x86/p2m-pt: pass level instead of page type to p2m_next_level()

[Jan Beulich]

This in turn calls for p2m_alloc_ptp() also being passed the numeric
level.

Signed-off-by: Jan Beulich 
Reviewed-by: George Dunlap 
---
v2: New.
---
Question is whether passing the level to p2m_alloc_ptp() is really all
that useful: p2m-ept.c's passes zero only anyway, and p2m.c's uniform
passing of 4 doesn't necessarily match reality afaict.

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -569,7 +569,7 @@ int p2m_set_entry(struct p2m_domain *p2m
 return rc;
 }
 
-mfn_t p2m_alloc_ptp(struct p2m_domain *p2m, unsigned long type)
+mfn_t p2m_alloc_ptp(struct p2m_domain *p2m, unsigned int level)
 {
 struct page_info *pg;
 
@@ -581,7 +581,10 @@ mfn_t p2m_alloc_ptp(struct p2m_domain *p
 return INVALID_MFN;
 
 page_list_add_tail(pg, >pages);
-pg->u.inuse.type_info = type | 1 | PGT_validated;
+BUILD_BUG_ON(PGT_l1_page_table * 2 != PGT_l2_page_table);
+BUILD_BUG_ON(PGT_l1_page_table * 3 != PGT_l3_page_table);
+BUILD_BUG_ON(PGT_l1_page_table * 4 != PGT_l4_page_table);
+pg->u.inuse.type_info = (PGT_l1_page_table * level) | 1 | PGT_validated;
 
 return page_to_mfn(pg);
 }
@@ -632,7 +635,7 @@ int p2m_alloc_table(struct p2m_domain *p
 
 P2M_PRINTK("allocating p2m table\n");
 
-top_mfn = p2m_alloc_ptp(p2m, PGT_l4_page_table);
+top_mfn = p2m_alloc_ptp(p2m, 4);
 if ( mfn_eq(top_mfn, INVALID_MFN) )
 {
 p2m_unlock(p2m);
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -71,12 +71,6 @@
 #define needs_recalc(level, ent) _needs_recalc(level##e_get_flags(ent))
 #define valid_recalc(level, ent) (!(level##e_get_flags(ent) & _PAGE_ACCESSED))
 
-static const unsigned long pgt[] = {
-PGT_l1_page_table,
-PGT_l2_page_table,
-PGT_l3_page_table
-};
-
 static unsigned long p2m_type_to_flags(const struct p2m_domain *p2m,
p2m_type_t t,
mfn_t mfn,
@@ -189,7 +183,7 @@ static void p2m_add_iommu_flags(l1_pgent
 static int
 p2m_next_level(struct p2m_domain *p2m, void **table,
unsigned long *gfn_remainder, unsigned long gfn, u32 shift,
-   u32 max, unsigned long type, bool_t unmap)
+   u32 max, unsigned int level, bool_t unmap)
 {
 l1_pgentry_t *p2m_entry, new_entry;
 void *next;
@@ -204,30 +198,15 @@ p2m_next_level(struct p2m_domain *p2m, v
 /* PoD/paging: Not present doesn't imply empty. */
 if ( !flags )
 {
-mfn_t mfn = p2m_alloc_ptp(p2m, type);
+mfn_t mfn = p2m_alloc_ptp(p2m, level);
 
 if ( mfn_eq(mfn, INVALID_MFN) )
 return -ENOMEM;
 
 new_entry = l1e_from_pfn(mfn_x(mfn), P2M_BASE_FLAGS | _PAGE_RW);
 
-switch ( type ) {
-case PGT_l3_page_table:
-p2m_add_iommu_flags(_entry, 3, 
IOMMUF_readable|IOMMUF_writable);
-p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, 4);
-break;
-case PGT_l2_page_table:
-p2m_add_iommu_flags(_entry, 2, 
IOMMUF_readable|IOMMUF_writable);
-p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, 3);
-break;
-case PGT_l1_page_table:
-p2m_add_iommu_flags(_entry, 1, 
IOMMUF_readable|IOMMUF_writable);
-p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, 2);
-break;
-default:
-BUG();
-break;
-}
+p2m_add_iommu_flags(_entry, level, 
IOMMUF_readable|IOMMUF_writable);
+p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 1);
 }
 else if ( flags & _PAGE_PSE )
 {
@@ -235,15 +214,14 @@ p2m_next_level(struct p2m_domain *p2m, v
 unsigned long pfn = l1e_get_pfn(*p2m_entry);
 mfn_t mfn;
 l1_pgentry_t *l1_entry;
-unsigned int i, level;
+unsigned int i;
 
-switch ( type )
+switch ( level )
 {
-case PGT_l2_page_table:
-level = 2;
+case 2:
 break;
 
-case PGT_l1_page_table:
+case 1:
 /*
  * New splintered mappings inherit the flags of the old superpage,
  * with a little reorganisation for the _PAGE_PSE_PAT bit.
@@ -252,8 +230,6 @@ p2m_next_level(struct p2m_domain *p2m, v
 pfn -= 1;/* Clear it; _PAGE_PSE becomes _PAGE_PAT 
*/
 else
 flags &= ~_PAGE_PSE; /* Clear _PAGE_PSE (== _PAGE_PAT) */
-
-level = 1;
 break;
 
 default:
@@ -261,7 +237,7 @@ p2m_next_level(struct p2m_domain *p2m, v
 return -EINVAL;
 }
 
-mfn = p2m_alloc_ptp(p2m, type);
+mfn = p2m_alloc_ptp(p2m, level);
 if ( mfn_eq(mfn, INVALID_MFN) )
 return -ENOMEM;
 
@@ -331,7 +307,7 @@ static int p2m_pt_set_recalc_range(struc
 
 err = p2m_next_level(p2m, , _remainder, first_gfn,
  i * PAGETABLE_ORDER, 1 << 

[Xen-devel] [PATCH] x86/config: Fix stale documentation concerning virtual layout

[Andrew Cooper]

The hypercall argument translation area lives in the per-domain mappings in
PML4 slot 260.  Nothing currently resides in the lower canonical half above
the 4GB boundary in a 32bit PV guest.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/include/asm-x86/config.h | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index bc0730f..25af085 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -169,12 +169,8 @@ extern unsigned char boot_edid_info[128];
  *Guest-defined use.
  *  0xf580 - 0x [168MB, PML4:0]
  *Read-only machine-to-phys translation table (GUEST ACCESSIBLE).
- *  0x0001 - 0x007f [508GB, PML4:0]
- *Unused.
- *  0x0080 - 0x00ff [512GB, 2^39 bytes, PML4:1]
- *Hypercall argument translation area.
- *  0x0100 - 0x7fff [127TB, 2^46 bytes, PML4:2-255]
- *Reserved for future use.
+ *  0x0001 - 0x7fff [128TB-4GB, PML4:0-255]
+ *Unused / Reserved for future use.
  */
 
 
-- 
2.1.4


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

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

[Peter Zijlstra]

On Fri, Aug 11, 2017 at 03:07:29PM +0200, Juergen Gross wrote:
> On 11/08/17 14:54, Peter Zijlstra wrote:
> > On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote:
> >> Aah, okay. Now I understand the problem. The TLB isn't the issue but the
> >> IPI is serving two purposes here: TLB flushing (which is allowed to
> >> happen at any time) and serialization regarding access to critical pages
> >> (which seems to be broken in the Xen case as you suggest).
> > 
> > Indeed, and now hyper-v as well.
> 
> Is it possible to distinguish between non-critical calls of
> flush_tlb_others() (which should be the majority IMHO) and critical ones
> regarding above problem? I guess the only problem is the case when a
> page table can be freed because its last valid entry is gone, right?
> 
> We might want to add a serialization flag to indicate flushing _and_
> serialization via IPI should be performed.

Possible, but not trivial. Esp things like transparent huge pages, which
swizzles PMDs around makes things tricky.

The by far easiest solution is to switch over to HAVE_RCU_TABLE_FREE
when either Xen or Hyper-V is doing this. Ideally it would not have a
significant performance hit (needs testing) and we can simply always do
this when PARAVIRT, or otherwise we need to get creative with
static_keys or something.

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

Re: [Xen-devel] [PATCH v2 0/3] fix xen hvm guest with kaslr enabled

[Juergen Gross]

On 08/08/17 16:00, Boris Ostrovsky wrote:
> On 08/08/2017 02:46 AM, Juergen Gross wrote:
>> On 28/07/17 12:23, Juergen Gross wrote:
>>> This patch series fixes a regression introduced in 4.13-rc1: A Xen
>>> HVM guest with KASLR enabled wouldn't boot any longer due to the usage
>>> of __va() before kernel_randomize_memory() was called.
>>>
>>> Changes in V2:
>>> - patch 1: test for x86_hyper being not NULL
>>>
>>> Juergen Gross (3):
>>>   x86: provide an init_mem_mapping hypervisor hook
>>>   xen: split up xen_hvm_init_shared_info()
>>>   xen: fix hvm guest with kaslr enabled
>>>
>>>  arch/x86/include/asm/hypervisor.h | 10 +++
>>>  arch/x86/mm/init.c|  3 ++
>>>  arch/x86/xen/enlighten_hvm.c  | 59 
>>> ---
>>>  3 files changed, 50 insertions(+), 22 deletions(-)
>>>
>> Could I have some feedback, please?
>>
>> I'd like to get this regression fixed in 4.13.
>>
>> In case nobody objects this week I'll just add the patches to the Xen
>> tree for rc5.
> 
> 
> As I said before I think .init_mem_mapping() could live in
> x86_platform_ops() but this works too, so
> 
> Reviewed-by: Boris Ostrovsky 
> 
> But this still wants x86 maintainers' ACK.

x86 maintainers, could you please comment on at least patch 1?


Juergen

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

Re: [Xen-devel] [PATCH 0/4] ARM: ACPI: ITS: Add ITS Support for ACPI hardware domain

[Julien Grall]

Hi,

On 11/08/17 05:54, Manish Jaggi wrote:



On 8/10/2017 6:44 PM, Julien Grall wrote:



On 08/10/2017 02:00 PM, Manish Jaggi wrote:

HI Julien,

On 8/10/2017 5:43 PM, Julien Grall wrote:



On 10/08/17 13:00, Manish Jaggi wrote:

Hi Julien,

On 8/10/2017 4:58 PM, Julien Grall wrote:



On 10/08/17 12:21, Manish Jaggi wrote:

Hi Julien,

On 6/21/2017 6:53 PM, Julien Grall wrote:

Hi Manish,

On 21/06/17 02:01, Manish Jaggi wrote:

This patch series adds the support of ITS for ACPI hardware
domain.
It is tested on staging branch with has ITS v12 patchset by Andre.

I have tried to incorporate the review comments on the RFC v1/v2
patch.
The single patch in RFC is now split into 4 patches.


I will comment here rather than on each patches.



Patch1: ARM: ITS: Add translation_id to host_its
 Adds translation_id in host_its data structure, which is
populated
from
 translation_id read from firmwar MADT. This value is then
programmed
into
 local MADT created for hardware domain in patch 4.


I don't see any reason to store value that will only be used for
generating the MADT which BTW is just a copy for the ITS.
Instead we
should copy over the MADT entries.


There are two approaches,

If I use the standard API  acpi_table_parse_madt which would iterate
over ACPI_MADT_TYPE_GENERIC_TRANSLATOR entries, I have to
maintain the
addr and translation_id in some data structure, to be filled
later in
the hwdomain copy of madt generic translator.

If I don't use the standard API I have to add code to manually
parse all
the translator entries.


There are a 3rd approach I suggested and ignored... The ITS entries
for Dom0 is exactly the same as the host entries.

Yes, and if not passed properly dom0 wont get device interrupts...

So you only need to do a verbatim copy of the entry...


Can you please check patch 4/2, the translation_id and address are
passed verbatim, the other values are reserved in
acpi_madt_generic_translator.


For ACPI, we took the approach to only rewrite what's necessary and
give the rest to Dom0 as it is. If newer version of ACPI re-used
those fields, then they will be copied over to Dom0. I don't
consider it as an issue because the problem would be the same if
those fields have an important meaning for the platform.

Few thoughts...
If we follow this approach, few points needs to be considered
- If ACPI may use the reserved information later it could be equally
important for dom0 and Xen,
  so it might be useful to keep reserved in xen as well.


I already covered that in my previous e-mail.


Yes, I am just stating it again for xen.


- For platforms which use dt, translation_id is not required to be
stored in struct host_its, similarly for platforms which use acpi
dt_node pointer might be of no use.

So we can have struct host_its having a union with dt_device_node *
for dt and acpi_madt_generic_translator * for acpi.
IMHO this could be an approach we can take.

struct host_its {
  struct list_head entry;
-const struct dt_device_node *dt_node;
+   union {
+const struct dt_device_node *dt_node;
+const struct acpi_madt_generic_translator *acpi_its_entry;
+};
 paddr_t addr;


What don't you get in my previous e-mail? A no is a no, full stop.

This is not helping.



Just do what we do in *_make_hwdom_madt. That will work here with no
need of a union or anything else.

The patchset provides two features
 (a) populates host_its list from ACPI tables, so ACPI xen can use ITS
 (b) provides a MADT with ITS information to dom0.

What I am focusing with union is for (a) ,
and (b) code would be simpler if we use the union in (a).

You seem to be discounting (a) in comments so far.

why union? as I have mentioned before...
 It will make the host_its structure accommodate dt node and
acpi_madt_generic_translator, both has same purpose.
If one is valid why not other.


You commented on "Even the DT code can be reworked to avoid storing the 
node.", so I guess you can easily deduce by yourself why I don't think 
it should be used.


To repeat for the 4th time, there are need to keep around both DT and 
ACPI pointer in the structure. Maybe some code will help you to understand:


for (i = 0; i < nr_its; i++)
{
struct acpi_madt_ *entry;

entry = acpi_table_get_entry_madt(ACPI_MADT_TYPE_ITS, i);
BUG_ON(entry);

ACPI_MEMCPY(..., ...);
}

Job done.



please provide a technical reason for not doing it.


I would appreciate to not repeat 4 times (including on IRC) the same 
things... I don't have spare time for that. So as I said either you 
address my comment or I am going to ignore this until I find spare time 
to deal with it.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

[Julien Grall]

Hi Volodymyr,

On 10/08/17 22:09, Julien Grall wrote:


We can stick to XEN-only approach, like XENFEAT_* or "xen,smccc" in DT.
But is this right?


Answering to this question after some thoughts and discussion around.

The generic approach is indeed the best solution, however I am afraid it 
will take some times to get ready and might not be ready for Xen 4.10.


As I mentioned earlier, I don't want to merge this without any way to 
discover the existence of SMCCC in the hypervisor. I also understand 
that you would like to get this merged in Xen 4.10.


So the alternative we have is to provide a XEN-only approach for the 
time being. It has to work for both ACPI and DT, this likely means we 
want a XENFEAT_* flag.


That alternative would be supersede when the generic approach will be 
available. Though we would have to keep both around, but it is it not a 
big deal.


Does it make sense?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

[Peter Zijlstra]

On Fri, Aug 11, 2017 at 11:23:10AM +0200, Vitaly Kuznetsov wrote:
> Peter Zijlstra  writes:
> 
> > On Thu, Aug 10, 2017 at 07:08:22PM +, Jork Loeser wrote:
> >
> >> > > Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote 
> >> > > TLB flush
> >> 
> >> > > Hold on.. if we don't IPI for TLB invalidation. What serializes our
> >> > > software page table walkers like fast_gup() ?
> >> > 
> >> > Hypervisor may implement this functionality via an IPI.
> >> > 
> >> > K. Y
> >> 
> >> HvFlushVirtualAddressList() states:
> >> This call guarantees that by the time control returns back to the
> >> caller, the observable effects of all flushes on the specified virtual
> >> processors have occurred.
> >> 
> >> HvFlushVirtualAddressListEx() refers to HvFlushVirtualAddressList() as 
> >> adding sparse target VP lists.
> >> 
> >> Is this enough of a guarantee, or do you see other races?
> >
> > That's nowhere near enough. We need the remote CPU to have completed any
> > guest IF section that was in progress at the time of the call.
> >
> > So if a host IPI can interrupt a guest while the guest has IF cleared,
> > and we then process the host IPI -- clear the TLBs -- before resuming the
> > guest, which still has IF cleared, we've got a problem.
> >
> > Because at that point, our software page-table walker, that relies on IF
> > being clear to guarantee the page-tables exist, because it holds off the
> > TLB invalidate and thereby the freeing of the pages, gets its pages
> > ripped out from under it.
> 
> Oh, I see your concern. Hyper-V, however, is not the first x86
> hypervisor trying to avoid IPIs on remote TLB flush, Xen does this
> too. Briefly looking at xen_flush_tlb_others() I don't see anything
> special, do we know how serialization is achieved there?

No idea on how Xen works, I always just hope it goes away :-) But lets
ask some Xen folks.


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

[Xen-devel] [libvirt test] 112586: tolerable trouble: blocked/broken/pass - PUSHED

[osstest service owner]

flight 112586 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112586/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112528
 build-arm64-xsm   3 capture-logsbroken like 112528
 build-arm64-pvops 2 hosts-allocate  broken like 112528
 build-arm64   2 hosts-allocate  broken like 112528
 build-arm64-pvops 3 capture-logsbroken like 112528
 build-arm64   3 capture-logsbroken like 112528
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112528
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112528
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112528
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 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-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  e255cf02b2a24d19412d9bf08dfa654150d9a31b
baseline version:
 libvirt  b9b0aa06a026e1f1f90223258567c524a66ffd1a

Last test of basis   112528  2017-08-09 04:20:14 Z2 days
Testing same since   112586  2017-08-11 04:30:56 Z0 days1 attempts


People who touched revisions under test:
  Michal Privoznik 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-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-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd 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 

Re: [Xen-devel] [PATCH v4 9/9] vpci/msix: add MSI-X handlers

[Jan Beulich]

>>> On 10.08.17 at 19:04,  wrote:
> On Wed, Aug 02, 2017 at 09:07:54AM -0600, Jan Beulich wrote:
>> >>> Roger Pau Monne  06/30/17 5:01 PM >>>
>> >@@ -113,6 +148,35 @@ static int vpci_modify_bar(struct domain *d, const 
>> >struct vpci_bar *bar,
>> >if ( IS_ERR(mem) )
>> >return -PTR_ERR(mem);
>>  >
>> >+/*
>> >+ * Make sure the MSI-X regions of the BAR are not mapped into the 
>> >domain
>> >+ * p2m, or else the MSI-X handlers are useless. Only do this when 
>> >mapping,
>> >+ * since that's when the memory decoding on the device is enabled.
>> >+ */
>> >+for ( i = 0; map && i < ARRAY_SIZE(bar->msix); i++ )
>> >+{
>> >+struct vpci_msix_mem *msix = bar->msix[i];
>> >+
>> >+if ( !msix || msix->addr == INVALID_PADDR )
>> >+continue;
>> >+
>> >+rc = vpci_unmap_msix(d, msix);
>> 
>> Why do you need this, instead of being able to simply rely on the rangeset
>> based (un)mapping?
> 
> This is because the series that I've sent called: "x86/pvh: implement
> iommu_inclusive_mapping for PVH Dom0" will map the MSI-X memory areas
> into the guest, and thus we need to make sure they are not mapped
> here for the emulation path to work.
> 
> https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg02849.html 

Oh, okay. The patch description doesn't mention any such
dependency though.

>> >+break;
>> >+case PCI_MSIX_ENTRY_DATA_OFFSET:
>> >+/*
>> >+ * 8 byte writes to the msg data and vector control fields are
>> >+ * only allowed if the entry is masked.
>> >+ */
>> >+if ( len == 8 && !entry->masked && !msix->masked && msix->enabled )
>> >+{
>> >+vpci_unlock(d);
>> >+return X86EMUL_OKAY;
>> >+}
>> 
>> I don't think this is correct - iirc such writes simply don't take effect 
>> immediately
>> (but I then seem to recall this to apply to the address field and 32-bit 
>> writes to
>> the data field as well). They'd instead take effect the next time the entry 
>> is being
>> unmasked (or some such). A while ago I did fix the qemu code to behave in 
>> this
>> way.
> 
> There's an Implementation Note called "Special Considerations for QWORD
> Accesses" in the MSI-X section of the PCI 3.0 spec that states:
> 
> If a given entry is currently masked (via its Mask bit or the Function
> Mask bit), software is permitted to fill in the Message Data and
> Vector Control fields with a single QWORD write, taking advantage of
> the fact the Message Data field is guaranteed to become visible to
> hardware no later than the Vector Control field.
> 
> So I think the above chunk is correct. The specification also states
> that:
> 
> Software must not modify the Address or Data fields of an entry while
> it is unmasked. Refer to Section 6.8.3.5 for details.
> 
> AFAICT this is not enforced by QEMU, and you can write to the
> address/data fields while the message is not masked. The update will
> only take effect once the message is masked and unmasked.

The spec also says:

"For MSI-X, a function is permitted to cache Address and Data values
 from unmasked MSIX Table entries. However, anytime software
 unmasks a currently masked MSI-X Table entry either by clearing its
 Mask bit or by clearing the Function Mask bit, the function must
 update any Address or Data values that it cached from that entry. If
 software changes the Address or Data value of an entry while the
 entry is unmasked, the result is undefined."

>> >+for_each_domain ( d )
>> >+{
>> >+if ( !has_vpci(d) )
>> >+continue;
>> >+
>> >+printk("vPCI MSI-X information for guest %u\n", d->domain_id);
>> 
>> Wouldn't it be better (more useful) to dump the MSI and MSI-X data for a
>> domain next to each other?
> 
> Possibly yes, and printing the MSI and MSI-X data of each device
> together would be even better IMHO.

Not sure about that last aspect - devices aren't permitted to enable
both at the same time, so only one of them can really be relevant.

Jan

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

Re: [Xen-devel] [PATCH v2] xen: remove struct domain and vcpu declarations from types.h

[Jan Beulich]

>>> On 10.08.17 at 19:22,  wrote:
> --- a/xen/include/asm-x86/xenoprof.h
> +++ b/xen/include/asm-x86/xenoprof.h
> @@ -68,6 +68,8 @@ void passive_domain_destroy(struct vcpu *v);
>  
>  #else
>  
> +struct vcpu;

There already is a forward declaration in this header - I'd suggest
moving that one up (outside the #if) instead of adding a 2nd one.
With that feel free to re-add the ack I had given on v1.

Jan


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

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

[Andrew Cooper]

On 11/08/17 11:56, Peter Zijlstra wrote:
> On Fri, Aug 11, 2017 at 11:23:10AM +0200, Vitaly Kuznetsov wrote:
>> Peter Zijlstra  writes:
>>
>>> On Thu, Aug 10, 2017 at 07:08:22PM +, Jork Loeser wrote:
>>>
>> Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote 
>> TLB flush
>> Hold on.. if we don't IPI for TLB invalidation. What serializes our
>> software page table walkers like fast_gup() ?
> Hypervisor may implement this functionality via an IPI.
>
> K. Y
 HvFlushVirtualAddressList() states:
 This call guarantees that by the time control returns back to the
 caller, the observable effects of all flushes on the specified virtual
 processors have occurred.

 HvFlushVirtualAddressListEx() refers to HvFlushVirtualAddressList() as 
 adding sparse target VP lists.

 Is this enough of a guarantee, or do you see other races?
>>> That's nowhere near enough. We need the remote CPU to have completed any
>>> guest IF section that was in progress at the time of the call.
>>>
>>> So if a host IPI can interrupt a guest while the guest has IF cleared,
>>> and we then process the host IPI -- clear the TLBs -- before resuming the
>>> guest, which still has IF cleared, we've got a problem.
>>>
>>> Because at that point, our software page-table walker, that relies on IF
>>> being clear to guarantee the page-tables exist, because it holds off the
>>> TLB invalidate and thereby the freeing of the pages, gets its pages
>>> ripped out from under it.
>> Oh, I see your concern. Hyper-V, however, is not the first x86
>> hypervisor trying to avoid IPIs on remote TLB flush, Xen does this
>> too. Briefly looking at xen_flush_tlb_others() I don't see anything
>> special, do we know how serialization is achieved there?
> No idea on how Xen works, I always just hope it goes away :-) But lets
> ask some Xen folks.

How is the software pagewalker relying on IF being clear safe at all (on
native, let alone under virtualisation)?  Hardware has no architectural
requirement to keep entries in the TLB.

In the virtualisation case, at any point the vcpu can be scheduled on a
different pcpu even during a critical region like that, so the TLB
really can empty itself under your feet.

~Andrew

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

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

[Peter Zijlstra]

On Fri, Aug 11, 2017 at 12:05:45PM +0100, Andrew Cooper wrote:
> >> Oh, I see your concern. Hyper-V, however, is not the first x86
> >> hypervisor trying to avoid IPIs on remote TLB flush, Xen does this
> >> too. Briefly looking at xen_flush_tlb_others() I don't see anything
> >> special, do we know how serialization is achieved there?
> > No idea on how Xen works, I always just hope it goes away :-) But lets
> > ask some Xen folks.
> 
> How is the software pagewalker relying on IF being clear safe at all (on
> native, let alone under virtualisation)?  Hardware has no architectural
> requirement to keep entries in the TLB.

No, but it _can_, therefore when we unhook pages we _must_ invalidate.

It goes like:

CPU0CPU1

unhook page
cli
traverse page tables
TLB invalidate ---> 
sti

 TLB invalidate
<--  complete

free page

So the CPU1 page-table walker gets an existence guarantee of the
page-tables by clearing IF.

> In the virtualisation case, at any point the vcpu can be scheduled on a
> different pcpu even during a critical region like that, so the TLB
> really can empty itself under your feet.

Not the point.


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

Re: [Xen-devel] [PATCH v4 9/9] vpci/msix: add MSI-X handlers

[Jan Beulich]

>>> On 11.08.17 at 12:11,  wrote:
> On Fri, Aug 11, 2017 at 04:01:05AM -0600, Jan Beulich wrote:
>> >>> On 10.08.17 at 19:04,  wrote:
>> > On Wed, Aug 02, 2017 at 09:07:54AM -0600, Jan Beulich wrote:
>> >> >>> Roger Pau Monne  06/30/17 5:01 PM >>>
>> >> >+case PCI_MSIX_ENTRY_DATA_OFFSET:
>> >> >+/*
>> >> >+ * 8 byte writes to the msg data and vector control fields are
>> >> >+ * only allowed if the entry is masked.
>> >> >+ */
>> >> >+if ( len == 8 && !entry->masked && !msix->masked && 
>> >> >msix->enabled )
>> >> >+{
>> >> >+vpci_unlock(d);
>> >> >+return X86EMUL_OKAY;
>> >> >+}
>> >> 
>> >> I don't think this is correct - iirc such writes simply don't take effect 
>> >> immediately
>> >> (but I then seem to recall this to apply to the address field and 32-bit 
>> >> writes to
>> >> the data field as well). They'd instead take effect the next time the 
>> >> entry is being
>> >> unmasked (or some such). A while ago I did fix the qemu code to behave in 
>> >> this
>> >> way.
>> > 
>> > There's an Implementation Note called "Special Considerations for QWORD
>> > Accesses" in the MSI-X section of the PCI 3.0 spec that states:
>> > 
>> > If a given entry is currently masked (via its Mask bit or the Function
>> > Mask bit), software is permitted to fill in the Message Data and
>> > Vector Control fields with a single QWORD write, taking advantage of
>> > the fact the Message Data field is guaranteed to become visible to
>> > hardware no later than the Vector Control field.
>> > 
>> > So I think the above chunk is correct. The specification also states
>> > that:
>> > 
>> > Software must not modify the Address or Data fields of an entry while
>> > it is unmasked. Refer to Section 6.8.3.5 for details.
>> > 
>> > AFAICT this is not enforced by QEMU, and you can write to the
>> > address/data fields while the message is not masked. The update will
>> > only take effect once the message is masked and unmasked.
>> 
>> The spec also says:
>> 
>> "For MSI-X, a function is permitted to cache Address and Data values
>>  from unmasked MSIX Table entries. However, anytime software
>>  unmasks a currently masked MSI-X Table entry either by clearing its
>>  Mask bit or by clearing the Function Mask bit, the function must
>>  update any Address or Data values that it cached from that entry. If
>>  software changes the Address or Data value of an entry while the
>>  entry is unmasked, the result is undefined."
> 
> I'm not sure it's clear to me what to do if the guest writes to an
> entry while unmasked. For once it says that it must not modify it, but
> OTHO it says result is undefined when doing so.
> 
> Would you be fine with ignoring writes to the address and data fields
> if the entry is unmasked?

No, not really. I've intentionally pointed you to the qemu code,
as there I've implemented the caching behavior described by the
quote above. I'd expect vPCI to behave similarly.

>> >> >+for_each_domain ( d )
>> >> >+{
>> >> >+if ( !has_vpci(d) )
>> >> >+continue;
>> >> >+
>> >> >+printk("vPCI MSI-X information for guest %u\n", d->domain_id);
>> >> 
>> >> Wouldn't it be better (more useful) to dump the MSI and MSI-X data for a
>> >> domain next to each other?
>> > 
>> > Possibly yes, and printing the MSI and MSI-X data of each device
>> > together would be even better IMHO.
>> 
>> Not sure about that last aspect - devices aren't permitted to enable
>> both at the same time, so only one of them can really be relevant.
> 
> I think (for debugging purposes) it's useful to print both together
> in order to spot if the guest is doing something wrong.

For Dom0 maybe. For DomU we'd have to refuse guest attempts
to do anything possibly resulting in undefined behavior.

Jan


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

Re: [Xen-devel] [PATCH v2] xen: remove struct domain and vcpu declarations from types.h

[Julien Grall]

Hi Wei,

On 10/08/17 18:22, Wei Liu wrote:

They don't belong there. Removing them causes build errors in several
places. Add the forward declarations in those places.

Signed-off-by: Wei Liu 


For ARM:

reviewed-by: Julien Grall 

Cheers,


---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Julien Grall 
---
 xen/include/asm-arm/processor.h | 1 +
 xen/include/asm-x86/xenoprof.h  | 2 ++
 xen/include/xen/compat.h| 1 +
 xen/include/xen/types.h | 3 ---
 4 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 855ded1b07..ab5225fa6c 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -699,6 +699,7 @@ void show_registers(struct cpu_user_regs *regs);

 void noreturn do_unexpected_trap(const char *msg, struct cpu_user_regs *regs);

+struct vcpu;
 void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
struct vcpu_guest_core_regs *regs);
 void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
diff --git a/xen/include/asm-x86/xenoprof.h b/xen/include/asm-x86/xenoprof.h
index 3a1b001edb..1d2464804a 100644
--- a/xen/include/asm-x86/xenoprof.h
+++ b/xen/include/asm-x86/xenoprof.h
@@ -68,6 +68,8 @@ void passive_domain_destroy(struct vcpu *v);

 #else

+struct vcpu;
+
 static inline int passive_domain_do_rdmsr(unsigned int msr,
   uint64_t *msr_content)
 {
diff --git a/xen/include/xen/compat.h b/xen/include/xen/compat.h
index ce6245c10f..895e2ff68d 100644
--- a/xen/include/xen/compat.h
+++ b/xen/include/xen/compat.h
@@ -227,6 +227,7 @@ void xlat_start_info(struct start_info *, enum 
XLAT_start_info_console);
 struct vcpu_runstate_info;
 void xlat_vcpu_runstate_info(struct vcpu_runstate_info *);

+struct domain;
 int switch_compat(struct domain *);

 #else
diff --git a/xen/include/xen/types.h b/xen/include/xen/types.h
index 170e993558..b1dbb8720a 100644
--- a/xen/include/xen/types.h
+++ b/xen/include/xen/types.h
@@ -42,9 +42,6 @@ typedef __s32   int32_t;
 typedef __u64   uint64_t;
 typedef __s64   int64_t;

-struct domain;
-struct vcpu;
-
 typedef __u16 __le16;
 typedef __u16 __be16;
 typedef __u32 __le32;



--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] xen: remove struct domain and vcpu declarations from types.h

[Wei Liu]

On Fri, Aug 11, 2017 at 04:15:59AM -0600, Jan Beulich wrote:
> >>> On 10.08.17 at 19:22,  wrote:
> > --- a/xen/include/asm-x86/xenoprof.h
> > +++ b/xen/include/asm-x86/xenoprof.h
> > @@ -68,6 +68,8 @@ void passive_domain_destroy(struct vcpu *v);
> >  
> >  #else
> >  
> > +struct vcpu;
> 
> There already is a forward declaration in this header - I'd suggest
> moving that one up (outside the #if) instead of adding a 2nd one.
> With that feel free to re-add the ack I had given on v1.
> 

Sure and thanks.

> Jan
> 

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

[Xen-devel] [ovmf test] 112585: all pass - PUSHED

[osstest service owner]

flight 112585 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112585/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f8daac8121e66c46d3374f63f80308a777c2a2e7
baseline version:
 ovmf 7ef0dae092afcfb6fab7e8372c78097672168c4a

Last test of basis   112539  2017-08-09 16:46:45 Z1 days
Failing since112545  2017-08-10 04:47:25 Z1 days7 attempts
Testing same since   112585  2017-08-11 03:47:27 Z0 days1 attempts


People who touched revisions under test:
  Andrew Fish 
  Chris Ruffin 
  Huajing Li 
  Michael D Kinney 
  Ruiyu Ni 
  Star Zeng 
  Yonghong Zhu 

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-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 :

+ branch=ovmf
+ revision=f8daac8121e66c46d3374f63f80308a777c2a2e7
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
f8daac8121e66c46d3374f63f80308a777c2a2e7
+ branch=ovmf
+ revision=f8daac8121e66c46d3374f63f80308a777c2a2e7
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' xf8daac8121e66c46d3374f63f80308a777c2a2e7 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : 

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

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 3 capture-logs   broken REGR. vs. 112102

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 112102
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 112102
 build-arm64   2 hosts-allocate broken REGR. vs. 112102

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   3 capture-logs  broken blocked in 112102
 build-arm64   3 capture-logs  broken blocked in 112102
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 112102
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112102
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112102
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 112102
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112102
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112102
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   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
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass

version targeted for testing:
 linux8c13fcce2c663b37c1134a3302b43e514961b5fa
baseline version:
 linuxdd8b674caeef9381345a6369fba29d425ff433f3

Last test of basis   112102  2017-07-21 17:53:24 Z   20 days
Testing same since   112351  

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

[Wei Liu]

On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote:
> On 08/08/2017 09:09 AM, Wei Liu wrote:
> > Ian and Stefano
> > 
> > Oleksandr discovered that the p9fs array in libxl_domain_config is name
> > p9 instead of p9s. This causes problem for his work to rework device
> > framework.
> > 
> > Given that p9fs was added only during last release and the only known
> > external toolstack libvirt can't possibility use that, maybe we can
> > rename p9 to p9s. Opinions?
> 
> ATM the libvirt libxl driver doesn't use it, but it could by supporting
> libvirt's  device
> 
> http://libvirt.org/formatdomain.html#elementsFilesystems

I think that means all the parameters go directly to QEMU. Without
proper plumbing via libxl driver there won't be anything in the xenstore
hence it isn't useable by Xen guest, right?

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

Re: [Xen-devel] [PATCH v2 1/3] x86/p2m-pt: simplify p2m_next_level()

[Jan Beulich]

>>> On 27.07.17 at 18:19,  wrote:
> On Wed, Jul 5, 2017 at 11:05 AM, Jan Beulich  wrote:
>> Calculate entry PFN and flags just once. Convert the two successive
>> main if()-s to and if/elf-if chain. Restrict variable scope where
>> reasonable. Take the opportunity and also make the induction variable
>> unsigned.
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> v2: Re-do mostly from scratch following review feedback.
>> Note: I have trouble seeing how the old code worked, when the 2M page
>>   shattering path specified neither read nor write permission for
>>   the IOMMU. Am I overlooking a reason why this was (and should
>>   remain) so?
> 
> Hmm -- given that in all other circumstances, a 4k page which is
> ram_rw gets RW, then I think the old code must certainly be buggy.
> 
> But is your code correct?  It looks like you unconditionally give it
> RW, when for ram_ro, for example it should be R (not W).  It seems
> like we should either call p2m_get_iommu_flags(), or ASSERT() that the
> resulting flags would be RW.

Hmm, good point, but that means the original code had the same
issue when splitting 1G into 2M pages. I'd prefer to not call
p2m_get_iommu_flags() though, but instead simply inherit the
IOMMU flags from the original large page.

Jan


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

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

[Juergen Gross]

On 11/08/17 12:56, Peter Zijlstra wrote:
> On Fri, Aug 11, 2017 at 11:23:10AM +0200, Vitaly Kuznetsov wrote:
>> Peter Zijlstra  writes:
>>
>>> On Thu, Aug 10, 2017 at 07:08:22PM +, Jork Loeser wrote:
>>>
>> Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote 
>> TLB flush

>> Hold on.. if we don't IPI for TLB invalidation. What serializes our
>> software page table walkers like fast_gup() ?
>
> Hypervisor may implement this functionality via an IPI.
>
> K. Y

 HvFlushVirtualAddressList() states:
 This call guarantees that by the time control returns back to the
 caller, the observable effects of all flushes on the specified virtual
 processors have occurred.

 HvFlushVirtualAddressListEx() refers to HvFlushVirtualAddressList() as 
 adding sparse target VP lists.

 Is this enough of a guarantee, or do you see other races?
>>>
>>> That's nowhere near enough. We need the remote CPU to have completed any
>>> guest IF section that was in progress at the time of the call.
>>>
>>> So if a host IPI can interrupt a guest while the guest has IF cleared,
>>> and we then process the host IPI -- clear the TLBs -- before resuming the
>>> guest, which still has IF cleared, we've got a problem.
>>>
>>> Because at that point, our software page-table walker, that relies on IF
>>> being clear to guarantee the page-tables exist, because it holds off the
>>> TLB invalidate and thereby the freeing of the pages, gets its pages
>>> ripped out from under it.
>>
>> Oh, I see your concern. Hyper-V, however, is not the first x86
>> hypervisor trying to avoid IPIs on remote TLB flush, Xen does this
>> too. Briefly looking at xen_flush_tlb_others() I don't see anything
>> special, do we know how serialization is achieved there?
> 
> No idea on how Xen works, I always just hope it goes away :-) But lets
> ask some Xen folks.

Wait - the TLB can be cleared at any time, as Andrew was pointing out.
No cpu can rely on an address being accessible just because IF is being
cleared. All that matters is the existing and valid page table entry.

So clearing IF on a cpu isn't meant to secure the TLB from being
cleared, but just to avoid interrupts (as the name of the flag is
suggesting).

In the Xen case the hypervisor does the following:

- it checks whether any of the vcpus specified in the cpumask of the
  flush request is running on any physical cpu
- if any running vcpu is found an IPI will be sent to the physical cpu
  and the hypervisor will do the TLB flush there
- any vcpu addressed by the flush and not running will be flagged to
  flush its TLB when being scheduled the next time

This ensures no TLB entry to be flushed can be used after return of
xen_flush_tlb_others().


Juergen

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine  7 reboot   fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-intel  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 110515
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
110515
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 110515
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 110515
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 110515
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 110515
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 110515
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 110515
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 110515
 test-amd64-i386-xl   10 debian-install   fail REGR. vs. 110515
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 110515
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 110515
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 110515
 build-arm64   2 hosts-allocate broken REGR. vs. 110515

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 3 capture-logs  broken blocked in 110515
 build-arm64-xsm   3 capture-logs  broken blocked in 110515
 build-arm64   3 capture-logs  broken blocked in 110515
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 110515
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110515
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 110515
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 110515
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   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-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

[Wei Liu]

On Fri, Aug 11, 2017 at 12:37:04PM -0600, Jim Fehlig wrote:
> On 08/11/2017 05:45 AM, Wei Liu wrote:
> > On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote:
> > > On 08/08/2017 09:09 AM, Wei Liu wrote:
> > > > Ian and Stefano
> > > > 
> > > > Oleksandr discovered that the p9fs array in libxl_domain_config is name
> > > > p9 instead of p9s. This causes problem for his work to rework device
> > > > framework.
> > > > 
> > > > Given that p9fs was added only during last release and the only known
> > > > external toolstack libvirt can't possibility use that, maybe we can
> > > > rename p9 to p9s. Opinions?
> > > 
> > > ATM the libvirt libxl driver doesn't use it, but it could by supporting
> > > libvirt's  device
> > > 
> > > http://libvirt.org/formatdomain.html#elementsFilesystems
> > 
> > I think that means all the parameters go directly to QEMU. Without
> > proper plumbing via libxl driver there won't be anything in the xenstore
> > hence it isn't useable by Xen guest, right?
> 
> I'm not sure why they have to go directly to QEMU. My naive thinking was to
> map the  XML elements/attributes to libxl_device_p9 struct. E.g.
> /domain/devices/filesystem/source@file would map to libxl_device_p9->path,
> etc.
> 

Right, that would require adding code somewhere in libvirt.git, right?

What I'm trying to figure out is if there could be code is libvirt that
uses the p9 array defined in libxl. It seems to me the answer is no.

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

Re: [Xen-devel] [PATCH v3 02/13] xen/pvcalls: implement frontend disconnect

[Boris Ostrovsky]

On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> Introduce a data structure named pvcalls_bedata. It contains pointers to
> the command ring, the event channel, a list of active sockets and a list
> of passive sockets. Lists accesses are protected by a spin_lock.
>
> Introduce a waitqueue to allow waiting for a response on commands sent
> to the backend.
>
> Introduce an array of struct xen_pvcalls_response to store commands
> responses.
>
> Implement pvcalls frontend removal function. Go through the list of
> active and passive sockets and free them all, one at a time.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
>  drivers/xen/pvcalls-front.c | 51 
> +
>  1 file changed, 51 insertions(+)
>
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index a8d38c2..a126195 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -20,6 +20,29 @@
>  #include 
>  #include 
>  
> +#define PVCALLS_INVALID_ID UINT_MAX
> +#define PVCALLS_RING_ORDER XENBUS_MAX_RING_GRANT_ORDER
> +#define PVCALLS_NR_REQ_PER_RING __CONST_RING_SIZE(xen_pvcalls, XEN_PAGE_SIZE)
> +
> +struct pvcalls_bedata {
> + struct xen_pvcalls_front_ring ring;
> + grant_ref_t ref;
> + int irq;
> +
> + struct list_head socket_mappings;
> + struct list_head socketpass_mappings;
> + spinlock_t pvcallss_lock;

In the backend this is called socket_lock and (subjectively) it would
sound as a better name here too.

> +
> + wait_queue_head_t inflight_req;
> + struct xen_pvcalls_response rsp[PVCALLS_NR_REQ_PER_RING];
> +};
> +static struct xenbus_device *pvcalls_front_dev;
> +
> +static irqreturn_t pvcalls_front_event_handler(int irq, void *dev_id)
> +{
> + return IRQ_HANDLED;
> +}
> +
>  static const struct xenbus_device_id pvcalls_front_ids[] = {
>   { "pvcalls" },
>   { "" }
> @@ -27,6 +50,34 @@
>  
>  static int pvcalls_front_remove(struct xenbus_device *dev)
>  {
> + struct pvcalls_bedata *bedata;
> + struct sock_mapping *map = NULL, *n;
> +
> + bedata = dev_get_drvdata(_front_dev->dev);
> +
> + list_for_each_entry_safe(map, n, >socket_mappings, list) {
> + mutex_lock(>active.in_mutex);
> + mutex_lock(>active.out_mutex);
> + pvcalls_front_free_map(bedata, map);
> + mutex_unlock(>active.out_mutex);
> + mutex_unlock(>active.in_mutex);
> + kfree(map);

I think this is the same issue as the one discussed for some other patch
--- unlocking and then immediately freeing a lock.

> + }
> + list_for_each_entry_safe(map, n, >socketpass_mappings, list) {
> + spin_lock(>pvcallss_lock);
> + list_del_init(>list);
> + spin_unlock(>pvcallss_lock);
> + kfree(map);
> + }
> + if (bedata->irq > 0)
> + unbind_from_irqhandler(bedata->irq, dev);
> + if (bedata->ref >= 0)
> + gnttab_end_foreign_access(bedata->ref, 0, 0);
> + kfree(bedata->ring.sring);
> + kfree(bedata);
> + dev_set_drvdata(>dev, NULL);
> + xenbus_switch_state(dev, XenbusStateClosed);

Should we first move the state to Closed and then free things up? Or it
doesn't matter?

-boris

> + pvcalls_front_dev = NULL;
>   return 0;
>  }
>  


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

Re: [Xen-devel] [PATCH v3 03/13] xen/pvcalls: connect to the backend

[Boris Ostrovsky]

On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> Implement the probe function for the pvcalls frontend. Read the
> supported versions, max-page-order and function-calls nodes from
> xenstore.
>
> Only one frontend<->backend connection is supported at any given time
> for a guest. Store the active frontend device to a static pointer.
>
> Introduce a stub functions for the event handler.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
>  drivers/xen/pvcalls-front.c | 130 
> 
>  1 file changed, 130 insertions(+)
>
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index a126195..2afe36d 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -84,12 +84,142 @@ static int pvcalls_front_remove(struct xenbus_device 
> *dev)
>  static int pvcalls_front_probe(struct xenbus_device *dev,
> const struct xenbus_device_id *id)
>  {
> + int ret = -ENOMEM, evtchn, i;
> + unsigned int max_page_order, function_calls, len;
> + char *versions;
> + grant_ref_t gref_head = 0;
> + struct xenbus_transaction xbt;
> + struct pvcalls_bedata *bedata = NULL;
> + struct xen_pvcalls_sring *sring;
> +
> + if (pvcalls_front_dev != NULL) {
> + dev_err(>dev, "only one PV Calls connection supported\n");
> + return -EINVAL;
> + }
> +
> + versions = xenbus_read(XBT_NIL, dev->otherend, "versions", );
> + if (!len)
> + return -EINVAL;
> + if (strcmp(versions, "1")) {
> + kfree(versions);
> + return -EINVAL;
> + }
> + kfree(versions);
> + max_page_order = xenbus_read_unsigned(dev->otherend,
> +   "max-page-order", 0);
> + if (max_page_order < PVCALLS_RING_ORDER)
> + return -ENODEV;
> + function_calls = xenbus_read_unsigned(dev->otherend,
> +   "function-calls", 0);
> + if (function_calls != 1)

XENBUS_FUNCTIONS_CALLS

> + return -ENODEV;
> + pr_info("%s max-page-order is %u\n", __func__, max_page_order);
> +
> + bedata = kzalloc(sizeof(struct pvcalls_bedata), GFP_KERNEL);
> + if (!bedata)
> + return -ENOMEM;
> +
> + dev_set_drvdata(>dev, bedata);
> + pvcalls_front_dev = dev;
> + init_waitqueue_head(>inflight_req);
> + for (i = 0; i < PVCALLS_NR_REQ_PER_RING; i++)
> + bedata->rsp[i].req_id = PVCALLS_INVALID_ID;
> +
> + sring = (struct xen_pvcalls_sring *) __get_free_page(GFP_KERNEL |
> +  __GFP_ZERO);
> + if (!sring)
> + goto error;
> + SHARED_RING_INIT(sring);
> + FRONT_RING_INIT(>ring, sring, XEN_PAGE_SIZE);
> +
> + ret = xenbus_alloc_evtchn(dev, );
> + if (ret)
> + goto error;
> +
> + bedata->irq = bind_evtchn_to_irqhandler(evtchn,
> + pvcalls_front_event_handler,
> + 0, "pvcalls-frontend", dev);
> + if (bedata->irq < 0) {

In the previous patch you free up irq if it is strictly >0. Should have
been >=0.

> + ret = bedata->irq;
> + goto error;
> + }
> +
> + ret = gnttab_alloc_grant_references(1, _head);
> + if (ret < 0)
> + goto error;
> + bedata->ref = gnttab_claim_grant_reference(_head);
> + if (bedata->ref < 0) {
> + ret = bedata->ref;
> + goto error;
> + }
> + gnttab_grant_foreign_access_ref(bedata->ref, dev->otherend_id,
> + virt_to_gfn((void *)sring), 0);
> +
> + again:
> + ret = xenbus_transaction_start();
> + if (ret) {
> + xenbus_dev_fatal(dev, ret, "starting transaction");
> + goto error;
> + }
> + ret = xenbus_printf(xbt, dev->nodename, "version", "%u", 1);
> + if (ret)
> + goto error_xenbus;
> + ret = xenbus_printf(xbt, dev->nodename, "ring-ref", "%d", bedata->ref);
> + if (ret)
> + goto error_xenbus;
> + ret = xenbus_printf(xbt, dev->nodename, "port", "%u",
> + evtchn);
> + if (ret)
> + goto error_xenbus;
> + ret = xenbus_transaction_end(xbt, 0);
> + if (ret) {
> + if (ret == -EAGAIN)
> + goto again;
> + xenbus_dev_fatal(dev, ret, "completing transaction");
> + goto error;
> + }
> +
> + INIT_LIST_HEAD(>socket_mappings);
> + INIT_LIST_HEAD(>socketpass_mappings);
> + spin_lock_init(>pvcallss_lock);
> + xenbus_switch_state(dev, XenbusStateInitialised);
> +
>   return 0;
> +
> + error_xenbus:
> + xenbus_transaction_end(xbt, 1);
> + xenbus_dev_fatal(dev, ret, "writing xenstore");
> + error:
> + pvcalls_front_remove(dev);

Going 

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

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 3 capture-logs   broken REGR. vs. 112102

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-vhd   6 xen-installfail pass in 112579
 test-amd64-amd64-amd64-pvgrub 10 debian-di-install fail pass in 112579

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 112102
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 112102
 build-arm64   2 hosts-allocate broken REGR. vs. 112102

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   3 capture-logs  broken blocked in 112102
 build-arm64   3 capture-logs  broken blocked in 112102
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 
112102
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 112102
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 112102
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112579 
like 112102
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 112579 
like 112102
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112579 
like 112102
 test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 112579 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 112579 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112085
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112102
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112102
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112102
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-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
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   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
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

[Jim Fehlig]

On 08/11/2017 02:27 PM, Wei Liu wrote:

On Fri, Aug 11, 2017 at 12:37:04PM -0600, Jim Fehlig wrote:

On 08/11/2017 05:45 AM, Wei Liu wrote:

On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote:

On 08/08/2017 09:09 AM, Wei Liu wrote:

Ian and Stefano

Oleksandr discovered that the p9fs array in libxl_domain_config is name
p9 instead of p9s. This causes problem for his work to rework device
framework.

Given that p9fs was added only during last release and the only known
external toolstack libvirt can't possibility use that, maybe we can
rename p9 to p9s. Opinions?


ATM the libvirt libxl driver doesn't use it, but it could by supporting
libvirt's  device

http://libvirt.org/formatdomain.html#elementsFilesystems


I think that means all the parameters go directly to QEMU. Without
proper plumbing via libxl driver there won't be anything in the xenstore
hence it isn't useable by Xen guest, right?


I'm not sure why they have to go directly to QEMU. My naive thinking was to
map the  XML elements/attributes to libxl_device_p9 struct. E.g.
/domain/devices/filesystem/source@file would map to libxl_device_p9->path,
etc.



Right, that would require adding code somewhere in libvirt.git, right?

What I'm trying to figure out is if there could be code is libvirt that
uses the p9 array defined in libxl. It seems to me the answer is no.


Correct, not at this time. Perhaps in the near future :-).


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

Re: [Xen-devel] [PATCH v3 01/13] xen/pvcalls: introduce the pvcalls xenbus frontend

[Boris Ostrovsky]

On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> Introduce a xenbus frontend for the pvcalls protocol, as defined by
> https://xenbits.xen.org/docs/unstable/misc/pvcalls.html.
>
> This patch only adds the stubs, the code will be added by the following
> patches.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com

Reviewed-by: Boris Ostrovsky 


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

[Xen-devel] [ovmf baseline-only test] 71966: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71966 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71966/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf bee7fe0ef950e2966cbdcd753be326f8a3c782f3
baseline version:
 ovmf f8daac8121e66c46d3374f63f80308a777c2a2e7

Last test of basis71963  2017-08-11 10:47:57 Z0 days
Testing same since71966  2017-08-11 17:49:53 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Wu Jiaxin 

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-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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.


commit bee7fe0ef950e2966cbdcd753be326f8a3c782f3
Author: Jiaxin Wu 
Date:   Tue Feb 28 08:35:26 2017 +0800

NetworkPkg/Ip6Dxe: Support SetData interface to clear specific configuration

UEFI Spec 2.7 adds the clarification on SetData interface usage to clear 
specific
individual data types. This patch is to support this feature.

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
Reviewed-by: Ye Ting 

commit 1126570464470572bcd7d59b83c6c39120e73c87
Author: Jiaxin Wu 
Date:   Tue Feb 28 08:35:08 2017 +0800

MdeModulePkg/Ip4Dxe: Support SetData interface to clear specific 
configuration

UEFI Spec 2.7 adds the clarification on SetData interface usage to clear 
specific
individual data types. This patch is to support this feature.

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
Reviewed-by: Ye Ting 

commit 1499e1ae6852efb68179071f9af1cb7584ac83af
Author: Jiaxin Wu 
Date:   Mon Feb 20 09:30:29 2017 +0800

MdePkg: Update the comments of Ip4Config2/Ip6Config Protocol

Update the comments of Ip4Config2/Ip6Config Protocol to consistent
with UEFI Spec 2.7, which provides the capability to clear specific
individual data types.

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
Reviewed-by: Ye Ting 

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

[Xen-devel] [linux-next test] 112593: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 112551
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 112551
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 112551
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 112551
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 112551
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 112551
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 112551
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 112551
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-examine   7 reboot   fail REGR. vs. 112551
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 112551
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
112551
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 112551
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 112551
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 112551
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 112551
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 112551
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
112551
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 112551
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 112551
 build-armhf   5 host-build-prep  fail REGR. vs. 112551

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop   fail REGR. vs. 112551

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  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-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112551
 build-arm64   2 hosts-allocate  broken like 112551
 build-arm64-xsm   3 capture-logsbroken like 112551
 build-arm64   3 capture-logsbroken like 112551
 build-arm64-pvops 2 hosts-allocate  broken like 112551
 build-arm64-pvops 3 capture-logsbroken like 112551
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112540
 test-amd64-amd64-examine  7 reboot   fail  like 112551
 test-amd64-amd64-pair10 xen-boot/src_hostfail  like 112551
 test-amd64-amd64-pair11 

[Xen-devel] [qemu-mainline test] 112598: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112557
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112557
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 112557

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 112557

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate  broken like 112557
 build-arm64-xsm   2 hosts-allocate  broken like 112557
 build-arm64-xsm   3 capture-logsbroken like 112557
 build-arm64   3 capture-logsbroken like 112557
 build-arm64-pvops 2 hosts-allocate  broken like 112557
 build-arm64-pvops 3 capture-logsbroken like 112557
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112557
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112557
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112557
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112557
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 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
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   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:
 qemuu95766c2cd04395e5712b4d5967b3251f35d537df
baseline version:
 qemuub38df311c174c98ef8cce7dec9f46603b083018e

Last test of basis   112557  2017-08-10 14:50:06 Z1 days
Failing since112581  2017-08-11 02:00:41 Z1 days2 attempts
Testing same since   112598  2017-08-11 13:49:28 Z0 days1 attempts


People who touched revisions under test:
  Greg Kurz 
  John Snow 
  Kevin Wolf 
  Peter Maydell 
  Philippe Mathieu-Daudé 
  Stefan Hajnoczi 
  Zhi Yong Wu 

jobs:
 build-amd64-xsm  pass
 

[Xen-devel] [linux-4.9 test] 112599: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. 
vs. 112513
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 17 guest-stop fail REGR. vs. 
112513
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112513
 build-armhf-pvops 6 kernel-build fail REGR. vs. 112513

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop   fail REGR. vs. 112497

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  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-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate  broken like 112513
 build-arm64-pvops 2 hosts-allocate  broken like 112513
 build-arm64   3 capture-logsbroken like 112513
 build-arm64-pvops 3 capture-logsbroken like 112513
 build-arm64-xsm   2 hosts-allocate  broken like 112513
 build-arm64-xsm   3 capture-logs broken never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 112497
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112513
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112513
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 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-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux4c666b0d9070a095e945387bd674476820f79528
baseline version:
 linuxdb397d9c6e66afdd34ae430172db122632b5f8a7

Last test of basis   112513  2017-08-07 20:19:27 Z4 days
Testing same since   112599  2017-08-11 16:18:32 Z0 days1 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Adrian Hunter 
  Alex Deucher 
  Alexander Potapenko 
  Amit Pundir 
  Andrew Morton 
  Anna Schumaker 
  Ard Biesheuvel 
  Arend van Spriel 
  Arnd Bergmann 
  Aviv Heller 
  Banajit 

[Xen-devel] [PATCH v2 01/12] [x86|arm]: remove code duplication

[Paul Durrant]

There is a substantial amount of code duplicated between the x86 and arm
implementations of mm.c:xenmem_add_to_physmap_one() for
XENMAPSPACE_grant_table. Also, the code in question looks like it really
should be in common/grant_table.c

This patch introduces a new function in common/grant_table.c to get the mfn
of a specified frame in the grant table of a specified guest, and calls to
that from the arch-specific code in mm.c.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/arm/mm.c | 29 -
 xen/arch/x86/mm.c | 26 +++---
 xen/common/grant_table.c  | 33 +
 xen/include/xen/grant_table.h |  3 +++
 4 files changed, 43 insertions(+), 48 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index a810a056d7..5ae9607821 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1229,32 +1229,11 @@ int xenmem_add_to_physmap_one(
 switch ( space )
 {
 case XENMAPSPACE_grant_table:
-grant_write_lock(d->grant_table);
-
-if ( d->grant_table->gt_version == 0 )
-d->grant_table->gt_version = 1;
-
-if ( d->grant_table->gt_version == 2 &&
-(idx & XENMAPIDX_grant_table_status) )
-{
-idx &= ~XENMAPIDX_grant_table_status;
-if ( idx < nr_status_frames(d->grant_table) )
-mfn = virt_to_mfn(d->grant_table->status[idx]);
-else
-return -EINVAL;
-}
-else
-{
-if ( (idx >= nr_grant_frames(d->grant_table)) &&
- (idx < max_grant_frames) )
-gnttab_grow_table(d, idx + 1);
-
-if ( idx < nr_grant_frames(d->grant_table) )
-mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
-else
-return -EINVAL;
-}
+mfn = gnttab_get_frame(d, idx);
+if ( mfn_eq(mfn, INVALID_MFN) )
+return -EINVAL;
 
+grant_write_lock(d->grant_table);
 d->arch.grant_table_gfn[idx] = gfn;
 
 t = p2m_ram_rw;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 97b3b4ba2c..e44b298df1 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4622,29 +4622,9 @@ int xenmem_add_to_physmap_one(
 mfn = virt_to_mfn(d->shared_info);
 break;
 case XENMAPSPACE_grant_table:
-grant_write_lock(d->grant_table);
-
-if ( d->grant_table->gt_version == 0 )
-d->grant_table->gt_version = 1;
-
-if ( d->grant_table->gt_version == 2 &&
- (idx & XENMAPIDX_grant_table_status) )
-{
-idx &= ~XENMAPIDX_grant_table_status;
-if ( idx < nr_status_frames(d->grant_table) )
-mfn = virt_to_mfn(d->grant_table->status[idx]);
-}
-else
-{
-if ( (idx >= nr_grant_frames(d->grant_table)) &&
- (idx < max_grant_frames) )
-gnttab_grow_table(d, idx + 1);
-
-if ( idx < nr_grant_frames(d->grant_table) )
-mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
-}
-
-grant_write_unlock(d->grant_table);
+mfn = mfn_x(gnttab_get_frame(d, idx));
+if ( mfn_eq(_mfn(mfn), INVALID_MFN) )
+return -EINVAL;
 break;
 case XENMAPSPACE_gmfn_range:
 case XENMAPSPACE_gmfn:
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index ae34547005..1411519126 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1604,6 +1604,39 @@ active_alloc_failed:
 return 0;
 }
 
+mfn_t
+gnttab_get_frame(struct domain *d, unsigned int idx)
+{
+struct grant_table *gt = d->grant_table;
+mfn_t mfn = INVALID_MFN;
+
+grant_write_lock(gt);
+
+if ( gt->gt_version == 0 )
+gt->gt_version = 1;
+
+if ( gt->gt_version == 2 &&
+ (idx & XENMAPIDX_grant_table_status) )
+{
+idx &= ~XENMAPIDX_grant_table_status;
+if ( idx < nr_status_frames(gt) )
+mfn = _mfn(virt_to_mfn(gt->status[idx]));
+}
+else
+{
+if ( (idx >= nr_grant_frames(gt)) &&
+ (idx < max_grant_frames) )
+gnttab_grow_table(d, idx + 1);
+
+if ( idx < nr_grant_frames(gt) )
+mfn = _mfn(virt_to_mfn(gt->shared_raw[idx]));
+}
+
+grant_write_unlock(gt);
+
+return mfn;
+}
+
 static long 
 gnttab_setup_table(
 XEN_GUEST_HANDLE_PARAM(gnttab_setup_table_t) uop, unsigned int count)
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 4e7789968c..685af7c578 100644
--- a/xen/include/xen/grant_table.h
+++ 

[Xen-devel] [PATCH v2 07/12] x86/hvm/ioreq: use bool rather than bool_t

[Paul Durrant]

This patch changes use of bool_t to bool in the IOREQ server code. It also
fixes an incorrect indentation in a continuation line.

This patch is purely cosmetic. No semantic or functional change.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/dm.c|   2 +-
 xen/arch/x86/hvm/hvm.c   |   2 +-
 xen/arch/x86/hvm/io.c|   4 +-
 xen/arch/x86/hvm/ioreq.c | 100 +++
 xen/include/asm-x86/hvm/domain.h |   6 +--
 xen/include/asm-x86/hvm/ioreq.h  |  14 +++---
 6 files changed, 64 insertions(+), 64 deletions(-)

diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index f7cb883fec..87ef4b6ca9 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -409,7 +409,7 @@ static int dm_op(const struct dmop_args *op_args)
 if ( data->pad[0] || data->pad[1] || data->pad[2] )
 break;
 
-rc = hvm_create_ioreq_server(d, curr_d->domain_id, 0,
+rc = hvm_create_ioreq_server(d, curr_d->domain_id, false,
  data->handle_bufioreq, >id);
 break;
 }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a78d5159fd..32ae588e44 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4360,7 +4360,7 @@ static int hvmop_get_param(
 {
 domid_t domid = d->arch.hvm_domain.params[HVM_PARAM_DM_DOMAIN];
 
-rc = hvm_create_ioreq_server(d, domid, 1,
+rc = hvm_create_ioreq_server(d, domid, true,
  HVM_IOREQSRV_BUFIOREQ_LEGACY, NULL);
 if ( rc != 0 && rc != -EEXIST )
 goto out;
diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 214ab307c4..bfac993223 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -59,7 +59,7 @@ void send_timeoffset_req(unsigned long timeoff)
 if ( timeoff == 0 )
 return;
 
-if ( hvm_broadcast_ioreq(, 1) != 0 )
+if ( hvm_broadcast_ioreq(, true) != 0 )
 gprintk(XENLOG_ERR, "Unsuccessful timeoffset update\n");
 }
 
@@ -73,7 +73,7 @@ void send_invalidate_req(void)
 .data = ~0UL, /* flush all */
 };
 
-if ( hvm_broadcast_ioreq(, 0) != 0 )
+if ( hvm_broadcast_ioreq(, false) != 0 )
 gprintk(XENLOG_ERR, "Unsuccessful map-cache invalidate\n");
 }
 
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 3e753ba224..5e01e1a6d2 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -43,7 +43,7 @@ static ioreq_t *get_ioreq(struct hvm_ioreq_server *s, struct 
vcpu *v)
 return >vcpu_ioreq[v->vcpu_id];
 }
 
-bool_t hvm_io_pending(struct vcpu *v)
+bool hvm_io_pending(struct vcpu *v)
 {
 struct domain *d = v->domain;
 struct hvm_ioreq_server *s;
@@ -59,11 +59,11 @@ bool_t hvm_io_pending(struct vcpu *v)
   list_entry )
 {
 if ( sv->vcpu == v && sv->pending )
-return 1;
+return true;
 }
 }
 
-return 0;
+return false;
 }
 
 static void hvm_io_assist(struct hvm_ioreq_vcpu *sv, uint64_t data)
@@ -82,10 +82,10 @@ static void hvm_io_assist(struct hvm_ioreq_vcpu *sv, 
uint64_t data)
 msix_write_completion(v);
 vcpu_end_shutdown_deferral(v);
 
-sv->pending = 0;
+sv->pending = false;
 }
 
-static bool_t hvm_wait_for_io(struct hvm_ioreq_vcpu *sv, ioreq_t *p)
+static bool hvm_wait_for_io(struct hvm_ioreq_vcpu *sv, ioreq_t *p)
 {
 while ( sv->pending )
 {
@@ -112,16 +112,16 @@ static bool_t hvm_wait_for_io(struct hvm_ioreq_vcpu *sv, 
ioreq_t *p)
 break;
 default:
 gdprintk(XENLOG_ERR, "Weird HVM iorequest state %u\n", state);
-sv->pending = 0;
+sv->pending = false;
 domain_crash(sv->vcpu->domain);
-return 0; /* bail */
+return false; /* bail */
 }
 }
 
-return 1;
+return true;
 }
 
-bool_t handle_hvm_io_completion(struct vcpu *v)
+bool handle_hvm_io_completion(struct vcpu *v)
 {
 struct domain *d = v->domain;
 struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
@@ -141,7 +141,7 @@ bool_t handle_hvm_io_completion(struct vcpu *v)
 if ( sv->vcpu == v && sv->pending )
 {
 if ( !hvm_wait_for_io(sv, get_ioreq(s, v)) )
-return 0;
+return false;
 
 break;
 }
@@ -178,7 +178,7 @@ bool_t handle_hvm_io_completion(struct vcpu *v)
 break;
 }
 
-return 1;
+return true;
 }
 
 static int hvm_alloc_ioreq_gfn(struct domain *d, unsigned long *gfn)
@@ -208,7 +208,7 @@ static void hvm_free_ioreq_gfn(struct domain *d, unsigned 
long gfn)
 set_bit(i, >arch.hvm_domain.ioreq_gfn.mask);
 }
 
-static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, bool_t buf)
+static 

[Xen-devel] [PATCH v2 08/12] x86/hvm/ioreq: move is_default into struct hvm_ioreq_server

[Paul Durrant]

Legacy emulators use the 'default' IOREQ server which has slightly
different semantics than other, explicitly created, IOREQ servers.

Because of this, most of the initialization and teardown code needs to
know whether the server is default or not. This is currently achieved
by passing an is_default boolean argument to the functions in question,
whereas this argument could be avoided by adding a field to the
hvm_ioreq_server structure which is also passed as an argument to all
the relevant functions.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/ioreq.c | 80 ++--
 xen/include/asm-x86/hvm/domain.h |  1 +
 2 files changed, 36 insertions(+), 45 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 5e01e1a6d2..5737082238 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -302,7 +302,7 @@ static void hvm_update_ioreq_evtchn(struct hvm_ioreq_server 
*s,
 }
 
 static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s,
- bool is_default, struct vcpu *v)
+ struct vcpu *v)
 {
 struct hvm_ioreq_vcpu *sv;
 int rc;
@@ -331,7 +331,7 @@ static int hvm_ioreq_server_add_vcpu(struct 
hvm_ioreq_server *s,
 goto fail3;
 
 s->bufioreq_evtchn = rc;
-if ( is_default )
+if ( s->is_default )
 d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN] =
 s->bufioreq_evtchn;
 }
@@ -431,7 +431,6 @@ static int hvm_ioreq_server_map_pages(struct 
hvm_ioreq_server *s,
 }
 
 static int hvm_ioreq_server_setup_pages(struct hvm_ioreq_server *s,
-bool is_default,
 bool handle_bufioreq)
 {
 struct domain *d = s->domain;
@@ -439,7 +438,7 @@ static int hvm_ioreq_server_setup_pages(struct 
hvm_ioreq_server *s,
 unsigned long bufioreq_gfn = gfn_x(INVALID_GFN);
 int rc;
 
-if ( is_default )
+if ( s->is_default )
 {
 /*
  * The default ioreq server must handle buffered ioreqs, for
@@ -468,8 +467,7 @@ static int hvm_ioreq_server_setup_pages(struct 
hvm_ioreq_server *s,
 return rc;
 }
 
-static void hvm_ioreq_server_unmap_pages(struct hvm_ioreq_server *s,
- bool is_default)
+static void hvm_ioreq_server_unmap_pages(struct hvm_ioreq_server *s)
 {
 struct domain *d = s->domain;
 bool handle_bufioreq = !!s->bufioreq.va;
@@ -479,7 +477,7 @@ static void hvm_ioreq_server_unmap_pages(struct 
hvm_ioreq_server *s,
 
 hvm_unmap_ioreq_page(s, false);
 
-if ( !is_default )
+if ( !s->is_default )
 {
 if ( handle_bufioreq )
 hvm_free_ioreq_gfn(d, s->bufioreq.gfn);
@@ -488,25 +486,23 @@ static void hvm_ioreq_server_unmap_pages(struct 
hvm_ioreq_server *s,
 }
 }
 
-static void hvm_ioreq_server_free_rangesets(struct hvm_ioreq_server *s,
-bool is_default)
+static void hvm_ioreq_server_free_rangesets(struct hvm_ioreq_server *s)
 {
 unsigned int i;
 
-if ( is_default )
+if ( s->is_default )
 return;
 
 for ( i = 0; i < NR_IO_RANGE_TYPES; i++ )
 rangeset_destroy(s->range[i]);
 }
 
-static int hvm_ioreq_server_alloc_rangesets(struct hvm_ioreq_server *s,
-bool is_default)
+static int hvm_ioreq_server_alloc_rangesets(struct hvm_ioreq_server *s)
 {
 unsigned int i;
 int rc;
 
-if ( is_default )
+if ( s->is_default )
 goto done;
 
 for ( i = 0; i < NR_IO_RANGE_TYPES; i++ )
@@ -537,13 +533,12 @@ static int hvm_ioreq_server_alloc_rangesets(struct 
hvm_ioreq_server *s,
 return 0;
 
  fail:
-hvm_ioreq_server_free_rangesets(s, false);
+hvm_ioreq_server_free_rangesets(s);
 
 return rc;
 }
 
-static void hvm_ioreq_server_enable(struct hvm_ioreq_server *s,
-bool is_default)
+static void hvm_ioreq_server_enable(struct hvm_ioreq_server *s)
 {
 struct domain *d = s->domain;
 struct hvm_ioreq_vcpu *sv;
@@ -554,7 +549,7 @@ static void hvm_ioreq_server_enable(struct hvm_ioreq_server 
*s,
 if ( s->enabled )
 goto done;
 
-if ( !is_default )
+if ( !s->is_default )
 {
 hvm_remove_ioreq_gfn(d, >ioreq);
 
@@ -573,8 +568,7 @@ static void hvm_ioreq_server_enable(struct hvm_ioreq_server 
*s,
 spin_unlock(>lock);
 }
 
-static void hvm_ioreq_server_disable(struct hvm_ioreq_server *s,
- bool is_default)
+static void hvm_ioreq_server_disable(struct hvm_ioreq_server *s)
 {
 struct domain *d = s->domain;
 bool handle_bufioreq = !!s->bufioreq.va;
@@ -584,7 +578,7 @@ static void hvm_ioreq_server_disable(struct 
hvm_ioreq_server *s,
 if ( !s->enabled )
  

[Xen-devel] [PATCH v2 03/12] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

[Paul Durrant]

Certain memory resources associated with a guest are not necessarily
present in the guest P2M and so are not necessarily available to be
foreign-mapped by a tools domain unless they are inserted, which risks
shattering a super-page mapping.

This patch adds a new memory op to allow such resourced to be priv-mapped
directly, by either a PV or HVM tools domain.

NOTE: Whilst the new op is not intrinsicly specific to the x86 architecture,
  I have no means to test it on an ARM platform and so cannot verify
  that it functions correctly. Hence it is currently only implemented
  for x86.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
---
 xen/arch/x86/mm.c   | 111 
 xen/arch/x86/mm/p2m.c   |   3 +-
 xen/include/asm-x86/p2m.h   |   3 ++
 xen/include/public/memory.h |  38 ++-
 4 files changed, 152 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index d71dc5f16a..c0cd63689a 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4700,6 +4700,107 @@ int xenmem_add_to_physmap_one(
 return rc;
 }
 
+static int xenmem_acquire_grant_table(struct domain *d,
+  unsigned long frame,
+  unsigned long nr_frames,
+  unsigned long mfn_list[])
+{
+unsigned int i;
+
+/*
+ * Iterate through the list backwards so that gnttab_get_frame() is
+ * first called for the highest numbered frame. This means that the
+ * out-of-bounds check will be done on the first iteration and, if
+ * the table needs to grow, it will only grow once.
+ */
+i = nr_frames;
+while ( i-- != 0 )
+{
+mfn_t mfn = gnttab_get_frame(d, frame + i);
+
+if ( mfn_eq(mfn, INVALID_MFN) )
+return -EINVAL;
+
+mfn_list[i] = mfn_x(mfn);
+}
+
+return 0;
+}
+
+static int xenmem_acquire_resource(xen_mem_acquire_resource_t *xmar)
+{
+struct domain *d, *currd = current->domain;
+unsigned long *mfn_list;
+int rc;
+
+if ( xmar->nr_frames == 0 )
+return -EINVAL;
+
+d = rcu_lock_domain_by_any_id(xmar->domid);
+if ( d == NULL )
+return -ESRCH;
+
+rc = xsm_domain_memory_map(XSM_TARGET, d);
+if ( rc )
+goto out;
+
+mfn_list = xmalloc_array(unsigned long, xmar->nr_frames);
+
+rc = -ENOMEM;
+if ( !mfn_list )
+goto out;
+
+switch ( xmar->type )
+{
+case XENMEM_resource_grant_table:
+rc = -EINVAL;
+if ( xmar->id ) /* must be zero for grant_table */
+break;
+
+rc = xenmem_acquire_grant_table(d, xmar->frame, xmar->nr_frames,
+mfn_list);
+break;
+
+default:
+rc = -EOPNOTSUPP;
+break;
+}
+
+if ( rc )
+goto free_and_out;
+
+if ( !paging_mode_translate(currd) )
+{
+if ( __copy_to_guest_offset(xmar->gmfn_list, 0, mfn_list,
+xmar->nr_frames) )
+rc = -EFAULT;
+}
+else
+{
+unsigned int i;
+
+for ( i = 0; i < xmar->nr_frames; i++ )
+{
+xen_pfn_t gfn;
+
+rc = -EFAULT;
+if ( __copy_from_guest_offset(, xmar->gmfn_list, i, 1) )
+goto free_and_out;
+
+rc = set_foreign_p2m_entry(currd, gfn, _mfn(mfn_list[i]));
+if ( rc )
+goto free_and_out;
+}
+}
+
+ free_and_out:
+xfree(mfn_list);
+
+ out:
+rcu_unlock_domain(d);
+return rc;
+}
+
 long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 int rc;
@@ -4922,6 +5023,16 @@ long arch_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 return rc;
 }
 
+case XENMEM_acquire_resource:
+{
+xen_mem_acquire_resource_t xmar;
+
+if ( copy_from_guest(, arg, 1) )
+return -EFAULT;
+
+return xenmem_acquire_resource();
+}
+
 default:
 return subarch_memory_op(cmd, arg);
 }
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index e8a57d118c..c503a7f1d2 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1118,8 +1118,7 @@ static int set_typed_p2m_entry(struct domain *d, unsigned 
long gfn, mfn_t mfn,
 }
 
 /* Set foreign mfn in the given guest's p2m table. */
-static int set_foreign_p2m_entry(struct domain *d, unsigned long gfn,
- mfn_t mfn)
+int set_foreign_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
 {
 return set_typed_p2m_entry(d, gfn, mfn, PAGE_ORDER_4K, p2m_map_foreign,
p2m_get_hostp2m(d)->default_access);
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 

[Xen-devel] [PATCH v2 04/12] tools/libxenforeignmemory: add support for resource mapping

[Paul Durrant]

A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.

This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).

[1] 
http://xenbits.xen.org/gitweb/?p=people/pauldu/linux.git;a=commit;h=c5cf2b15f7a448277716a7e96fea1c93df6c17a5

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 

v2:
 - Bump minor version up to 3
---
 tools/include/xen-sys/Linux/privcmd.h  | 11 ++
 tools/libs/foreignmemory/Makefile  |  2 +-
 tools/libs/foreignmemory/core.c| 42 
 .../libs/foreignmemory/include/xenforeignmemory.h  | 39 +++
 tools/libs/foreignmemory/libxenforeignmemory.map   |  5 +++
 tools/libs/foreignmemory/linux.c   | 45 ++
 tools/libs/foreignmemory/private.h | 30 +++
 7 files changed, 173 insertions(+), 1 deletion(-)

diff --git a/tools/include/xen-sys/Linux/privcmd.h 
b/tools/include/xen-sys/Linux/privcmd.h
index 732ff7c15a..9531b728f9 100644
--- a/tools/include/xen-sys/Linux/privcmd.h
+++ b/tools/include/xen-sys/Linux/privcmd.h
@@ -86,6 +86,15 @@ typedef struct privcmd_dm_op {
const privcmd_dm_op_buf_t __user *ubufs;
 } privcmd_dm_op_t;
 
+typedef struct privcmd_mmap_resource {
+   domid_t dom;
+   __u32 type;
+   __u32 id;
+   __u32 idx;
+   __u64 num;
+   __u64 addr;
+} privcmd_mmap_resource_t;
+
 /*
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: _hypercall_t
@@ -103,5 +112,7 @@ typedef struct privcmd_dm_op {
_IOC(_IOC_NONE, 'P', 5, sizeof(privcmd_dm_op_t))
 #define IOCTL_PRIVCMD_RESTRICT \
_IOC(_IOC_NONE, 'P', 6, sizeof(domid_t))
+#define IOCTL_PRIVCMD_MMAP_RESOURCE\
+   _IOC(_IOC_NONE, 'P', 7, sizeof(privcmd_mmap_resource_t))
 
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
diff --git a/tools/libs/foreignmemory/Makefile 
b/tools/libs/foreignmemory/Makefile
index b110076621..7eb59c78cb 100644
--- a/tools/libs/foreignmemory/Makefile
+++ b/tools/libs/foreignmemory/Makefile
@@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 MAJOR= 1
-MINOR= 2
+MINOR= 3
 SHLIB_LDFLAGS += -Wl,--version-script=libxenforeignmemory.map
 
 CFLAGS   += -Werror -Wmissing-prototypes
diff --git a/tools/libs/foreignmemory/core.c b/tools/libs/foreignmemory/core.c
index a6897dc561..291ee44516 100644
--- a/tools/libs/foreignmemory/core.c
+++ b/tools/libs/foreignmemory/core.c
@@ -120,6 +120,48 @@ int xenforeignmemory_restrict(xenforeignmemory_handle 
*fmem,
 return osdep_xenforeignmemory_restrict(fmem, domid);
 }
 
+xenforeignmemory_resource_handle *xenforeignmemory_map_resource(
+xenforeignmemory_handle *fmem, domid_t domid, unsigned int type,
+unsigned int id, unsigned long frame, unsigned long nr_frames,
+void **paddr, int prot, int flags)
+{
+xenforeignmemory_resource_handle *fres;
+int rc;
+
+fres = calloc(1, sizeof(*fres));
+if ( !fres )
+return NULL;
+
+fres->domid = domid;
+fres->type = type;
+fres->id = id;
+fres->frame = frame;
+fres->nr_frames = nr_frames;
+fres->addr = *paddr;
+fres->prot = prot;
+fres->flags = flags;
+
+rc = osdep_xenforeignmemory_map_resource(fmem, fres);
+if ( rc )
+goto fail;
+
+*paddr = fres->addr;
+return fres;
+
+fail:
+free(fres);
+
+return NULL;
+}
+
+void xenforeignmemory_unmap_resource(
+xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres)
+{
+osdep_xenforeignmemory_unmap_resource(fmem, fres);
+
+free(fres);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h 
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index f4814c390f..e56eb3c4d4 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -138,6 +138,45 @@ int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
 int xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
   domid_t domid);
 
+typedef struct xenforeignmemory_resource_handle 
xenforeignmemory_resource_handle;
+
+/**
+ * This function maps a guest resource.
+ *
+ * @parm fmem handle to the open foreignmemory interface
+ * @parm domid the domain id
+ * @parm type the resource type
+ * @parm id the type-specific resource identifier
+ * @parm frame base frame index within the resource
+ * @parm nr_frames number of frames to map
+ * @parm paddr pointer to an address passed through to mmap(2)
+ * @parm prot passed through to mmap(2)
+ * @parm flags passed through to mmap(2)
+ * @return pointer to foreignmemory resource handle on success, NULL on
+ * failure
+ 

[Xen-devel] [PATCH v2 09/12] x86/hvm/ioreq: simplify code and use consistent naming

[Paul Durrant]

This patch re-works much of the IOREQ server initialization and teardown
code:

- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
  to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
  separately by outer functions.
- Several functions now test the validity of the hvm_ioreq_page gfn value
  to determine whether they need to act. This means can be safely called
  for the bufioreq page even when it is not used.
- hvm_add/remove_ioreq_gfn() simply return in the case of the default
  IOREQ server so callers no longer need to test before calling.
- hvm_ioreq_server_setup_pages() is renamed to hvm_ioreq_server_map_pages()
  to mirror the existing hvm_ioreq_server_unmap_pages().

All of this significantly shortens the code.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/ioreq.c | 181 ++-
 1 file changed, 69 insertions(+), 112 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 5737082238..edfb394c59 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -181,63 +181,76 @@ bool handle_hvm_io_completion(struct vcpu *v)
 return true;
 }
 
-static int hvm_alloc_ioreq_gfn(struct domain *d, unsigned long *gfn)
+static unsigned long hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
 {
+struct domain *d = s->domain;
 unsigned int i;
-int rc;
 
-rc = -ENOMEM;
+ASSERT(!s->is_default);
+
 for ( i = 0; i < sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8; i++ )
 {
 if ( test_and_clear_bit(i, >arch.hvm_domain.ioreq_gfn.mask) )
 {
-*gfn = d->arch.hvm_domain.ioreq_gfn.base + i;
-rc = 0;
-break;
+return d->arch.hvm_domain.ioreq_gfn.base + i;
 }
 }
 
-return rc;
+return gfn_x(INVALID_GFN);
 }
 
-static void hvm_free_ioreq_gfn(struct domain *d, unsigned long gfn)
+static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s,
+   unsigned long gfn)
 {
+struct domain *d = s->domain;
 unsigned int i = gfn - d->arch.hvm_domain.ioreq_gfn.base;
 
-if ( gfn != gfn_x(INVALID_GFN) )
-set_bit(i, >arch.hvm_domain.ioreq_gfn.mask);
+ASSERT(!s->is_default);
+
+set_bit(i, >arch.hvm_domain.ioreq_gfn.mask);
 }
 
-static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, bool buf)
+static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
 {
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 
+if ( iorp->gfn == gfn_x(INVALID_GFN) )
+return;
+
 destroy_ring_for_helper(>va, iorp->page);
+iorp->page = NULL;
+
+if ( !s->is_default )
+hvm_free_ioreq_gfn(s, iorp->gfn);
+
+iorp->gfn = gfn_x(INVALID_GFN);
 }
 
-static int hvm_map_ioreq_page(
-struct hvm_ioreq_server *s, bool buf, unsigned long gfn)
+static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
 {
 struct domain *d = s->domain;
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
-struct page_info *page;
-void *va;
 int rc;
 
-if ( (rc = prepare_ring_for_helper(d, gfn, , )) )
-return rc;
-
-if ( (iorp->va != NULL) || d->is_dying )
-{
-destroy_ring_for_helper(, page);
+if ( d->is_dying )
 return -EINVAL;
-}
 
-iorp->va = va;
-iorp->page = page;
-iorp->gfn = gfn;
+if ( s->is_default )
+iorp->gfn = buf ?
+d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
+d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN];
+else
+iorp->gfn = hvm_alloc_ioreq_gfn(s);
+
+if ( iorp->gfn == gfn_x(INVALID_GFN) )
+return -ENOMEM;
 
-return 0;
+rc = prepare_ring_for_helper(d, iorp->gfn, >page, >va);
+
+if ( rc )
+hvm_unmap_ioreq_gfn(s, buf);
+
+return rc;
 }
 
 bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
@@ -251,8 +264,7 @@ bool is_ioreq_server_page(struct domain *d, const struct 
page_info *page)
   >arch.hvm_domain.ioreq_server.list,
   list_entry )
 {
-if ( (s->ioreq.va && s->ioreq.page == page) ||
- (s->bufioreq.va && s->bufioreq.page == page) )
+if ( (s->ioreq.page == page) || (s->bufioreq.page == page) )
 {
 found = true;
 break;
@@ -264,20 +276,30 @@ bool is_ioreq_server_page(struct domain *d, const struct 
page_info *page)
 return found;
 }
 
-static void hvm_remove_ioreq_gfn(
-struct domain *d, struct hvm_ioreq_page *iorp)
+static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
+
 {
+struct domain *d = s->domain;
+struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
+
+if ( s->is_default || iorp->gfn == gfn_x(INVALID_GFN) )
+return;
+
 if ( guest_physmap_remove_page(d, 

[Xen-devel] [PATCH v2 05/12] tools/libxenctrl: use new xenforeignmemory API to seed grant table

[Paul Durrant]

A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).

This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in which
case the old scheme is used.

NOTE: The call to xc_dom_gnttab_hvm_seed() in hvm_build_set_params() was
  actually unnecessary, as the grant table has already been seeded
  by a prior call to xc_dom_gnttab_init() made by libxl__build_dom().

Signed-off-by: Paul Durrant 
Acked-by: Marek Marczykowski-Górecki 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/libxc/include/xc_dom.h|   8 +--
 tools/libxc/xc_dom_boot.c   | 102 
 tools/libxc/xc_sr_restore_x86_hvm.c |  10 ++--
 tools/libxc/xc_sr_restore_x86_pv.c  |   2 +-
 tools/libxl/libxl_dom.c |   1 -
 tools/python/xen/lowlevel/xc/xc.c   |   6 +--
 6 files changed, 92 insertions(+), 37 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index ce47058c41..d6ca0a8680 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -323,12 +323,8 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, 
xen_pfn_t pfn,
 int xc_dom_boot_image(struct xc_dom_image *dom);
 int xc_dom_compat_check(struct xc_dom_image *dom);
 int xc_dom_gnttab_init(struct xc_dom_image *dom);
-int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
-   xen_pfn_t console_gmfn,
-   xen_pfn_t xenstore_gmfn,
-   domid_t console_domid,
-   domid_t xenstore_domid);
-int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
+int xc_dom_gnttab_seed(xc_interface *xch, domid_t guest_domid,
+   bool is_hvm,
xen_pfn_t console_gmfn,
xen_pfn_t xenstore_gmfn,
domid_t console_domid,
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index c3b44dd399..fc3174ad7e 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -280,11 +280,11 @@ static xen_pfn_t xc_dom_gnttab_setup(xc_interface *xch, 
domid_t domid)
 return gmfn;
 }
 
-int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
-   xen_pfn_t console_gmfn,
-   xen_pfn_t xenstore_gmfn,
-   domid_t console_domid,
-   domid_t xenstore_domid)
+static int compat_gnttab_seed(xc_interface *xch, domid_t domid,
+  xen_pfn_t console_gmfn,
+  xen_pfn_t xenstore_gmfn,
+  domid_t console_domid,
+  domid_t xenstore_domid)
 {
 
 xen_pfn_t gnttab_gmfn;
@@ -337,11 +337,11 @@ int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
 return 0;
 }
 
-int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
-   xen_pfn_t console_gpfn,
-   xen_pfn_t xenstore_gpfn,
-   domid_t console_domid,
-   domid_t xenstore_domid)
+static int compat_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
+  xen_pfn_t console_gpfn,
+  xen_pfn_t xenstore_gpfn,
+  domid_t console_domid,
+  domid_t xenstore_domid)
 {
 int rc;
 xen_pfn_t scratch_gpfn;
@@ -380,7 +380,7 @@ int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
 return -1;
 }
 
-rc = xc_dom_gnttab_seed(xch, domid,
+rc = compat_gnttab_seed(xch, domid,
 console_gpfn, xenstore_gpfn,
 console_domid, xenstore_domid);
 if (rc != 0)
@@ -405,18 +405,78 @@ int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t 
domid,
 return 0;
 }
 
-int xc_dom_gnttab_init(struct xc_dom_image *dom)
+int xc_dom_gnttab_seed(xc_interface *xch, domid_t guest_domid,
+   bool is_hvm, xen_pfn_t console_gmfn,
+   xen_pfn_t xenstore_gmfn, domid_t console_domid,
+   domid_t xenstore_domid)
 {
-if ( xc_dom_translated(dom) ) {
-return xc_dom_gnttab_hvm_seed(dom->xch, dom->guest_domid,
-  dom->console_pfn, dom->xenstore_pfn,
-  dom->console_domid, dom->xenstore_domid);
-} else {
-return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
-  xc_dom_p2m(dom, dom->console_pfn),
-  xc_dom_p2m(dom, dom->xenstore_pfn),
-  dom->console_domid, dom->xenstore_domid);
+

[Xen-devel] [PATCH v2 02/12] x86/mm: allow a privileged PV domain to map guest mfns

[Paul Durrant]

In the case where a PV domain is mapping guest resources then it needs make
the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the guest
domid, so that the passed in gmfn values are correctly treated as mfns
rather than gfns present in the guest p2m.

This patch removes a check which currently disallows mapping of a page when
the owner of the page tables matches the domain passed to
HYPERVISOR_mmu_update, but that domain is not the real owner of the page.
The check was introduced by patch d3c6a215ca9 ("x86: Clean up
get_page_from_l1e() to correctly distinguish between owner-of-pte and
owner-of-data-page in all cases") but it's not clear why it was needed.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/mm.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index e44b298df1..d71dc5f16a 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -989,12 +989,15 @@ get_page_from_l1e(
(real_pg_owner != dom_cow) ) )
 {
 /*
- * Let privileged domains transfer the right to map their target
- * domain's pages. This is used to allow stub-domain pvfb export to
- * dom0, until pvfb supports granted mappings. At that time this
- * minor hack can go away.
+ * If the real page owner is not the domain specified in the
+ * hypercall then establish that the specified domain has
+ * mapping privilege over the page owner.
+ * This is used to allow stub-domain pvfb export to dom0. It is
+ * also used to allow a privileged PV domain to map mfns using
+ * DOMID_SELF, which is needed for mapping guest resources such
+ * grant table frames.
  */
-if ( (real_pg_owner == NULL) || (pg_owner == l1e_owner) ||
+if ( (real_pg_owner == NULL) ||
  xsm_priv_mapping(XSM_TARGET, pg_owner, real_pg_owner) )
 {
 gdprintk(XENLOG_WARNING,
-- 
2.11.0


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

[Xen-devel] [PATCH v2 06/12] x86/hvm/ioreq: rename .*pfn and .*gmfn to .*gfn

[Paul Durrant]

Since IOREQ servers are only relevant to HVM guests and all the names in
question unequivocally refer to guest frame numbers, name them all .*gfn
to avoid any confusion.

This patch is purely cosmetic. No semantic or functional change.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 tools/libs/devicemodel/core.c   | 10 ++--
 tools/libs/devicemodel/include/xendevicemodel.h | 12 ++--
 xen/arch/x86/hvm/dm.c   |  4 +-
 xen/arch/x86/hvm/hvm.c  |  6 +-
 xen/arch/x86/hvm/ioreq.c| 74 -
 xen/include/asm-x86/hvm/domain.h|  4 +-
 xen/include/asm-x86/hvm/ioreq.h |  4 +-
 xen/include/public/hvm/dm_op.h  | 20 +++
 8 files changed, 67 insertions(+), 67 deletions(-)

diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index d7c6476006..fcb260d29b 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c
@@ -174,7 +174,7 @@ int xendevicemodel_create_ioreq_server(
 
 int xendevicemodel_get_ioreq_server_info(
 xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
-xen_pfn_t *ioreq_pfn, xen_pfn_t *bufioreq_pfn,
+xen_pfn_t *ioreq_gfn, xen_pfn_t *bufioreq_gfn,
 evtchn_port_t *bufioreq_port)
 {
 struct xen_dm_op op;
@@ -192,11 +192,11 @@ int xendevicemodel_get_ioreq_server_info(
 if (rc)
 return rc;
 
-if (ioreq_pfn)
-*ioreq_pfn = data->ioreq_pfn;
+if (ioreq_gfn)
+*ioreq_gfn = data->ioreq_gfn;
 
-if (bufioreq_pfn)
-*bufioreq_pfn = data->bufioreq_pfn;
+if (bufioreq_gfn)
+*bufioreq_gfn = data->bufioreq_gfn;
 
 if (bufioreq_port)
 *bufioreq_port = data->bufioreq_port;
diff --git a/tools/libs/devicemodel/include/xendevicemodel.h 
b/tools/libs/devicemodel/include/xendevicemodel.h
index 580fad2f49..13216db04a 100644
--- a/tools/libs/devicemodel/include/xendevicemodel.h
+++ b/tools/libs/devicemodel/include/xendevicemodel.h
@@ -60,17 +60,17 @@ int xendevicemodel_create_ioreq_server(
  * @parm dmod a handle to an open devicemodel interface.
  * @parm domid the domain id to be serviced
  * @parm id the IOREQ Server id.
- * @parm ioreq_pfn pointer to a xen_pfn_t to receive the synchronous ioreq
- *  gmfn
- * @parm bufioreq_pfn pointer to a xen_pfn_t to receive the buffered ioreq
- *gmfn
+ * @parm ioreq_gfn pointer to a xen_pfn_t to receive the synchronous ioreq
+ *  gfn
+ * @parm bufioreq_gfn pointer to a xen_pfn_t to receive the buffered ioreq
+ *gfn
  * @parm bufioreq_port pointer to a evtchn_port_t to receive the buffered
  * ioreq event channel
  * @return 0 on success, -1 on failure.
  */
 int xendevicemodel_get_ioreq_server_info(
 xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
-xen_pfn_t *ioreq_pfn, xen_pfn_t *bufioreq_pfn,
+xen_pfn_t *ioreq_gfn, xen_pfn_t *bufioreq_gfn,
 evtchn_port_t *bufioreq_port);
 
 /**
@@ -168,7 +168,7 @@ int xendevicemodel_destroy_ioreq_server(
  * This function sets IOREQ Server state. An IOREQ Server
  * will not be passed emulation requests until it is in
  * the enabled state.
- * Note that the contents of the ioreq_pfn and bufioreq_pfn are
+ * Note that the contents of the ioreq_gfn and bufioreq_gfn are
  * not meaningful until the IOREQ Server is in the enabled state.
  *
  * @parm dmod a handle to an open devicemodel interface.
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 4cf6deedc7..f7cb883fec 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -426,8 +426,8 @@ static int dm_op(const struct dmop_args *op_args)
 break;
 
 rc = hvm_get_ioreq_server_info(d, data->id,
-   >ioreq_pfn,
-   >bufioreq_pfn,
+   >ioreq_gfn,
+   >bufioreq_gfn,
>bufioreq_port);
 break;
 }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 555133f2d3..a78d5159fd 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4184,20 +4184,20 @@ static int hvmop_set_param(
 rc = -EINVAL;
 break;
 case HVM_PARAM_IOREQ_SERVER_PFN:
-d->arch.hvm_domain.ioreq_gmfn.base = a.value;
+d->arch.hvm_domain.ioreq_gfn.base = a.value;
 break;
 case HVM_PARAM_NR_IOREQ_SERVER_PAGES:
 {
 unsigned int i;
 
 if ( a.value == 0 ||
- a.value > sizeof(d->arch.hvm_domain.ioreq_gmfn.mask) * 8 )
+ a.value > sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8 )
 {
 rc = -EINVAL;
 break;
 }
 for ( i = 0; i < a.value; i++ )
-

[Xen-devel] [PATCH v2 00/12] x86: guest resource mapping

[Paul Durrant]

This series introduces support for direct mapping of guest resources.
The resources are:
 - Grant tables
 - IOREQ server pages

Paul Durrant (12):
  [x86|arm]: remove code duplication
  x86/mm: allow a privileged PV domain to map guest mfns
  x86/mm: add HYPERVISOR_memory_op to acquire guest resources
  tools/libxenforeignmemory: add support for resource mapping
  tools/libxenctrl: use new xenforeignmemory API to seed grant table
  x86/hvm/ioreq: rename .*pfn and .*gmfn to .*gfn
  x86/hvm/ioreq: use bool rather than bool_t
  x86/hvm/ioreq: move is_default into struct hvm_ioreq_server
  x86/hvm/ioreq: simplify code and use consistent naming
  x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page
  x86/hvm/ioreq: defer mapping gfns until they are actually requsted
  x86/hvm/ioreq: add a new mappable resource type...

 tools/include/xen-sys/Linux/privcmd.h  |  11 +
 tools/libs/devicemodel/core.c  |  18 +-
 tools/libs/devicemodel/include/xendevicemodel.h|  14 +-
 tools/libs/foreignmemory/Makefile  |   2 +-
 tools/libs/foreignmemory/core.c|  42 ++
 .../libs/foreignmemory/include/xenforeignmemory.h  |  39 ++
 tools/libs/foreignmemory/libxenforeignmemory.map   |   5 +
 tools/libs/foreignmemory/linux.c   |  45 ++
 tools/libs/foreignmemory/private.h |  30 ++
 tools/libxc/include/xc_dom.h   |   8 +-
 tools/libxc/xc_dom_boot.c  | 102 -
 tools/libxc/xc_sr_restore_x86_hvm.c|  10 +-
 tools/libxc/xc_sr_restore_x86_pv.c |   2 +-
 tools/libxl/libxl_dom.c|   1 -
 tools/python/xen/lowlevel/xc/xc.c  |   6 +-
 xen/arch/arm/mm.c  |  29 +-
 xen/arch/x86/hvm/dm.c  |  11 +-
 xen/arch/x86/hvm/hvm.c |   8 +-
 xen/arch/x86/hvm/io.c  |   4 +-
 xen/arch/x86/hvm/ioreq.c   | 453 -
 xen/arch/x86/mm.c  | 177 ++--
 xen/arch/x86/mm/p2m.c  |   3 +-
 xen/common/grant_table.c   |  33 ++
 xen/include/asm-x86/hvm/domain.h   |  11 +-
 xen/include/asm-x86/hvm/ioreq.h|  20 +-
 xen/include/asm-x86/p2m.h  |   3 +
 xen/include/public/hvm/dm_op.h |  46 ++-
 xen/include/public/memory.h|  41 +-
 xen/include/xen/grant_table.h  |   3 +
 29 files changed, 846 insertions(+), 331 deletions(-)

---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

v2:
 - Support for IOREQ server pages added

-- 
2.11.0


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

Re: [Xen-devel] [RFC PATCH v2 09/22] ARM: vITS: protect LPI priority update with pending_irq lock

[Julien Grall]

Hi Andre,

On 21/07/17 20:59, Andre Przywara wrote:

As the priority value is now officially a member of struct pending_irq,
we need to take its lock when manipulating it via ITS commands.
Make sure we take the IRQ lock after the VCPU lock when we need both.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 66095d4..705708a 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -402,6 +402,7 @@ static int update_lpi_property(struct domain *d, struct 
pending_irq *p)
 uint8_t property;
 int ret;

+ASSERT(spin_is_locked(>lock));
 /*
  * If no redistributor has its LPIs enabled yet, we can't access the
  * property table. In this case we just can't update the properties,
@@ -419,7 +420,7 @@ static int update_lpi_property(struct domain *d, struct 
pending_irq *p)
 if ( ret )
 return ret;

-write_atomic(>priority, property & LPI_PROP_PRIO_MASK);
+p->priority = property & LPI_PROP_PRIO_MASK;

 if ( property & LPI_PROP_ENABLED )
 set_bit(GIC_IRQ_GUEST_ENABLED, >status);
@@ -457,7 +458,7 @@ static int its_handle_inv(struct virt_its *its, uint64_t 
*cmdptr)
 uint32_t devid = its_cmd_get_deviceid(cmdptr);
 uint32_t eventid = its_cmd_get_id(cmdptr);
 struct pending_irq *p;
-unsigned long flags;
+unsigned long flags, vcpu_flags;


Same remark as patch #8 for the vcpu_flags and the locking.


 struct vcpu *vcpu;
 uint32_t vlpi;
 int ret = -1;
@@ -485,7 +486,8 @@ static int its_handle_inv(struct virt_its *its, uint64_t 
*cmdptr)
 if ( unlikely(!p) )
 goto out_unlock_its;

-spin_lock_irqsave(>arch.vgic.lock, flags);
+spin_lock_irqsave(>arch.vgic.lock, vcpu_flags);
+vgic_irq_lock(p, flags);

 /* Read the property table and update our cached status. */
 if ( update_lpi_property(d, p) )
@@ -497,7 +499,8 @@ static int its_handle_inv(struct virt_its *its, uint64_t 
*cmdptr)
 ret = 0;

 out_unlock:
-spin_unlock_irqrestore(>arch.vgic.lock, flags);
+vgic_irq_unlock(p, flags);
+spin_unlock_irqrestore(>arch.vgic.lock, vcpu_flags);

 out_unlock_its:
 spin_unlock(>its_lock);
@@ -517,7 +520,7 @@ static int its_handle_invall(struct virt_its *its, uint64_t 
*cmdptr)
 struct pending_irq *pirqs[16];
 uint64_t vlpi = 0;  /* 64-bit to catch overflows */
 unsigned int nr_lpis, i;
-unsigned long flags;
+unsigned long flags, vcpu_flags;
 int ret = 0;

 /*
@@ -542,7 +545,7 @@ static int its_handle_invall(struct virt_its *its, uint64_t 
*cmdptr)
 vcpu = get_vcpu_from_collection(its, collid);
 spin_unlock(>its_lock);

-spin_lock_irqsave(>arch.vgic.lock, flags);
+spin_lock_irqsave(>arch.vgic.lock, vcpu_flags);
 read_lock(>d->arch.vgic.pend_lpi_tree_lock);

 do
@@ -555,9 +558,13 @@ static int its_handle_invall(struct virt_its *its, 
uint64_t *cmdptr)

 for ( i = 0; i < nr_lpis; i++ )
 {
+vgic_irq_lock(pirqs[i], flags);
 /* We only care about LPIs on our VCPU. */
 if ( pirqs[i]->lpi_vcpu_id != vcpu->vcpu_id )
+{
+vgic_irq_unlock(pirqs[i], flags);


This locking does not seem to be related to the priority.


 continue;
+}

 vlpi = pirqs[i]->irq;
 /* If that fails for a single LPI, carry on to handle the rest. */
@@ -566,6 +573,8 @@ static int its_handle_invall(struct virt_its *its, uint64_t 
*cmdptr)
 update_lpi_vgic_status(vcpu, pirqs[i]);
 else
 ret = err;
+
+vgic_irq_unlock(pirqs[i], flags);
 }
 /*
  * Loop over the next gang of pending_irqs until we reached the end of
@@ -576,7 +585,7 @@ static int its_handle_invall(struct virt_its *its, uint64_t 
*cmdptr)
   (nr_lpis == ARRAY_SIZE(pirqs)) );

 read_unlock(>d->arch.vgic.pend_lpi_tree_lock);
-spin_unlock_irqrestore(>arch.vgic.lock, flags);
+spin_unlock_irqrestore(>arch.vgic.lock, vcpu_flags);

 return ret;
 }
@@ -712,6 +721,7 @@ static int its_handle_mapti(struct virt_its *its, uint64_t 
*cmdptr)
 uint32_t intid = its_cmd_get_physical_id(cmdptr), _intid;
 uint16_t collid = its_cmd_get_collection(cmdptr);
 struct pending_irq *pirq;
+unsigned long flags;
 struct vcpu *vcpu = NULL;
 int ret = -1;

@@ -765,7 +775,9 @@ static int its_handle_mapti(struct virt_its *its, uint64_t 
*cmdptr)
  * We don't need the VGIC VCPU lock here, because the pending_irq isn't
  * in the radix tree yet.
  */
+vgic_irq_lock(pirq, flags);
 ret = update_lpi_property(its->d, pirq);
+vgic_irq_unlock(pirq, flags);
 if ( ret )
 goto out_remove_host_entry;




Cheers,

--
Julien Grall

Re: [Xen-devel] [PATCH 3/5] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.

[Dario Faggioli]

On Wed, 2017-08-09 at 12:38 +0100, Tim Deegan wrote:
> Hi,
> 
Hey! :-)

> At 10:01 +0200 on 27 Jul (1501149684), Dario Faggioli wrote:
> > In Xen, that is impossible, and that's particularly problematic
> > when system is idle (or lightly loaded) systems, as CPUs that
> > are idle may never have the chance to tell RCU about their
> > quiescence, and grace periods could extend indefinitely!
> 
> [...]
> > The first step for fixing this situation is for RCU to record,
> > at the beginning of a grace period, which CPUs are already idle.
> > In fact, being idle, they can't be in the middle of any read-side
> > critical section, and we don't have to wait for them to declare
> > a grace period finished.
> 
> AIUI this patch fixes a bug where:
>  - a CPU is idle/asleep;
>  - it is added to the cpumask of a new RCU grace period; and
>  - because the CPU is asleep, the grace period never ends. 
> Have I understood?
> 
Yes indeed.

Basically, without this patch, all the CPUs are always added/considered
for all the grace periods. And if there are some that are idle/asleep,
we need to wait for them to wake up, before declared the grace period
ended.

So the duration of the grace period itself is out of any control (and
in fact, it happens to be reasonable, on x86, even on fully idle
system, while not so much on ARM). Even virtually infinite... :-O

> I think we might be left with a race condition:
>  - CPU A is about to idle.  It runs the RCU softirq and
>    clears itself from the current grace period.
>  - CPU B ends the grace period and starts a new one.
>  - CPU A calls rcu_idle_enter() and sleeps.
>  - The new grace period never ends.
> 
Yes, I think this is a thing.

I've give it some thoughts, and will post something about it as another
email.

> Is that fixed by your later rcu_idle_timer patch?  AIUI that's only
> invoked when the calling CPU has pending RCU callbacks.
> 
The timer is meant at dealing with the CPU with pending callback, yes.
I don't think we can solve this issue with the timer, even if we extend
its scope to all CPUs with whatever pending RCU processing... we'd
still have problems with grace periods that starts (on CPU B) after the
check for whether or not we need the timer has happened.

> Or can it be fixed here by something like this in rcu_idle_enter?
>  - lock rcp->lock
>  - add ourselves to the idle mask
>  - if we are in rcp->cpumask:
>  - cpu_quiet()
>  - unlock rcp->lock
> 
If rcu_idle_enter() leaves inside an IRQ disabled section (e.g., in
mwait_idle(), as it does right now), I can't take rcp->lock (because of
spinlock IRQ safety).

If I move it outside of that, then yes, the above may work. Or,
actually, we may not even need it... But as I said, more on this in
another message.

> There's also the code at the top of rcu_check_quiescent_state() that
> requres _two_ idle states per batch.  I don't know what race that's
> protecting against so I don't know whether we need to worry about it
> here as well. :)
> 
Not sure I'm getting this part. It's not a race, it is that, literally,
the first time (after someone has started a new batch) a CPU executes
rcu_check_quiescent_state(), realizes we're in a new grace period:

   6.681421066 -.-.-.|.--x-|--- d0v7 rcu_call fn=0x82d080207c4c, 
rcp_cur=-300, rdp_quiescbatch=-300
   6.681422601 -.-.-.|.--x-|--- d0v7 do_softirq, pending = 0x0010
   6.681422889 -.-.-.|.--x-|--- d0v7 rcu_pending? yes (ret=2): no pending 
entries but new entries
   6.681423214 -.-.-.|.--x-|--- d0v7 raise_softirq nr 3
   6.681423494 -.-.-.|.--x-|--- d0v7 softirq_handler nr 3
   6.681423494 -.-.-.|.--x-|--- d0v7 rcu_process_callbacks, rcp_completed=-300, 
rdp_batch=0, rdp_curlist: null, rdp_nxtlist: yes, rdp_donelist: null
   6.681423494 -.-.-.|.--x-|--- d0v7 rcu_next_batch, rcp_cur=-300, 
rdp_batch=-299, rcp_next_pending? no
   6.681423494 -.-.-.|.--x-|--- d0v7 rcu_start_batch, rcp_cur=-299, 
rcp_cpumask=0x1442
1->6.681423494 -.-.-.|.--x-|--- d0v7 rcu_check_quiesc_state, rcp_cur=-299, 
rdp_quiescbatch=-300, rdp_qs_pending: no
   6.681423494 -.-.-.|.--x-|--- d0v7 rcu_grace_start, rcp_cur=-299

The second realizes the grace period ended:

   6.681425277 -.-.-.|.--x-|--- d0v7 do_softirq, pending = 0x0010
   6.681425647 -.-.-.|.--x-|--- d0v7 rcu_pending? yes (ret=5): waiting for CPU 
to quiesce (rdp_qs_pending=1)
   6.681425872 -.-.-.|.--x-|--- d0v7 raise_softirq nr 3
   6.681426117 -.-.-.|.--x-|--- d0v7 softirq_handler nr 3
   6.681426117 -.-.-.|.--x-|--- d0v7 rcu_process_callbacks, rcp_completed=-300, 
rdp_batch=-299, rdp_curlist: yes, rdp_nxtlist: null, rdp_donelist: null
2->6.681426117 -.-.-.|.--x-|--- d0v7 rcu_check_quiesc_state, rcp_cur=-299, 
rdp_quiescbatch=-299, rdp_qs_pending: yes
   6.681426117 -.-.-.|.--x-|--- d0v7 rcu_grace_done, rcp_cur=-299, 
rcp_completed=-300, rdp_quiescbatch=-299
   6.681426117 -.-.-.|.--x-|--- d0v7 rcu_cpu_quiet, rcp_cur=-299, 
rcp_cpumask=0x1042

This trace above was for the CPU which actaully started the grace

[Xen-devel] [ovmf test] 112594: all pass - PUSHED

[osstest service owner]

flight 112594 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112594/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf bee7fe0ef950e2966cbdcd753be326f8a3c782f3
baseline version:
 ovmf f8daac8121e66c46d3374f63f80308a777c2a2e7

Last test of basis   112585  2017-08-11 03:47:27 Z0 days
Testing same since   112594  2017-08-11 10:42:10 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Wu Jiaxin 

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-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 :

+ branch=ovmf
+ revision=bee7fe0ef950e2966cbdcd753be326f8a3c782f3
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
bee7fe0ef950e2966cbdcd753be326f8a3c782f3
+ branch=ovmf
+ revision=bee7fe0ef950e2966cbdcd753be326f8a3c782f3
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' xbee7fe0ef950e2966cbdcd753be326f8a3c782f3 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

[Xen-devel] [PATCH 04/11] xen/arm: vgic-v3: Re-order the includes alphabetically

[Julien Grall]

Signed-off-by: Julien Grall 
---
 xen/arch/arm/vgic-v3.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 48c7682671..cbeac28b28 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -19,16 +19,17 @@
  */
 
 #include 
-#include 
 #include 
-#include 
 #include 
+#include 
 #include 
+#include 
 #include 
+
 #include 
-#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.11.0


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

[Xen-devel] [PATCH 06/11] xen/arm: Move arch/arm/vtimer.h to include/asm-arm/vtimer.h

[Julien Grall]

It will be necessary to include vtimer.h from subdirectory making the
inclusion a bit awkward.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/domain.c  | 2 +-
 xen/arch/arm/traps.c   | 2 +-
 xen/{arch/arm => include/asm-arm}/vtimer.h | 0
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename xen/{arch/arm => include/asm-arm}/vtimer.h (100%)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1d835d321d..355021e452 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -33,8 +33,8 @@
 #include 
 #include 
 #include 
+#include 
 
-#include "vtimer.h"
 #include "vuart.h"
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index ca9bef712c..d79e9605b5 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -50,9 +50,9 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "decode.h"
-#include "vtimer.h"
 
 /* The base of the stack must always be double-word aligned, which means
  * that both the kernel half of struct cpu_user_regs (which is pushed in
diff --git a/xen/arch/arm/vtimer.h b/xen/include/asm-arm/vtimer.h
similarity index 100%
rename from xen/arch/arm/vtimer.h
rename to xen/include/asm-arm/vtimer.h
-- 
2.11.0


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

[Xen-devel] [PATCH 00/11] xen/arm: Clean-up traps.c

[Julien Grall]

Hi all,

xen/arch/arm/traps.c is beginning to get very big. This series is moving out
the co-processor and sysreg emulate in separate files. This will avoid to grow
traps.c when adding more registers emulations (coming soon).

A branch with this series has been pushed:

https://xenbits.xen.org/git-http/people/julieng/xen-unstable.git
branch cleanup-traps-v1

Cheers,

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: volodymyr_babc...@epam.com

Julien Grall (11):
  xen/grant_table: Include mm.h in xen/grant_table.h
  xen/arm: domain: Re-order the includes alphabetically
  xen/arm: traps: Re-order the includes alphabetically
  xen/arm: vgic-v3: Re-order the includes alphabetically
  xen/arm: vtimer: Re-order the includes alphabetically
  xen/arm: Move arch/arm/vtimer.h to include/asm-arm/vtimer.h
  xen/arm: traps: Export a bunch of helpers to handle emulation
  xen/arm: Move sysreg emulation outside of traps.c
  xen/arm: Move co-processor emulation outside of traps.c
  xen/arm: Move sysregs.h in arm64 sub-directory
  xen/arm: Limit the scope of cpregs.h

 xen/arch/arm/Makefile  |   1 +
 xen/arch/arm/arm64/Makefile|   1 +
 xen/arch/arm/arm64/vsysreg.c   | 229 ++
 xen/arch/arm/domain.c  |  24 +-
 xen/arch/arm/smp.c |   1 -
 xen/arch/arm/traps.c   | 704 ++---
 xen/arch/arm/vcpreg.c  | 452 ++
 xen/arch/arm/vgic-v3.c |   8 +-
 xen/arch/arm/vtimer.c  |   9 +-
 xen/include/asm-arm/arm32/processor.h  |   2 +
 xen/include/asm-arm/arm32/traps.h  |  13 +
 xen/include/asm-arm/arm64/processor.h  |   2 +
 xen/include/asm-arm/{ => arm64}/sysregs.h  |  10 +-
 xen/include/asm-arm/arm64/traps.h  |  18 +
 xen/include/asm-arm/percpu.h   |   1 -
 xen/include/asm-arm/processor.h|   2 -
 xen/include/asm-arm/traps.h|  43 ++
 xen/{arch/arm => include/asm-arm}/vtimer.h |   0
 xen/include/xen/grant_table.h  |   1 +
 19 files changed, 831 insertions(+), 690 deletions(-)
 create mode 100644 xen/arch/arm/arm64/vsysreg.c
 create mode 100644 xen/arch/arm/vcpreg.c
 create mode 100644 xen/include/asm-arm/arm32/traps.h
 rename xen/include/asm-arm/{ => arm64}/sysregs.h (98%)
 create mode 100644 xen/include/asm-arm/arm64/traps.h
 create mode 100644 xen/include/asm-arm/traps.h
 rename xen/{arch/arm => include/asm-arm}/vtimer.h (100%)

-- 
2.11.0


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