Re: [Xen-devel] [RFC PATCH 06/31] cpufreq: make cpufreq driver more generalizable

[Jan Beulich]

>>> On 05.12.17 at 21:48,  wrote:
> You are right. We need to define a new struct for internal usage, for
> example:
> 
> struct xen_processor_performance_internal {
> uint32_t flags; /* flag for Px sub info type */
> uint32_t platform_limit;  /* Platform limitation on freq usage */
> struct xen_pct_register control_register;
> struct xen_pct_register status_register;
> uint32_t state_count; /* total available performance states */
> struct xen_processor_px states;
> struct xen_psd_package domain_info;
> uint32_t shared_type; /* coordination type of this processor */
> };
> 
> Jan, Andrew, does this sound like a good approach to you?

I'm afraid I don't have the time to go through this discussion (and
the original patch) in detail to figure out the full context in which
you raise the question. IOW please summarize things alongside
the proposed structure, or alternatively Oleksandr could simply
submit an updated patch to allow seeing the actual context
(albeit in any case I can't promise timely feedback, given the
number of pending patches plus all the work I still hope to be
able to get done myself eventually.

From a brief check, I can't really figure much of a difference to
the already existing (and internal) struct processor_performance.

Jan


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

[Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

[Chao Gao]

Signed-off-by: Chao Gao 
---
 xen/include/public/hvm/hvm_info_table.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/public/hvm/hvm_info_table.h 
b/xen/include/public/hvm/hvm_info_table.h
index 08c252e..6833a4c 100644
--- a/xen/include/public/hvm/hvm_info_table.h
+++ b/xen/include/public/hvm/hvm_info_table.h
@@ -32,7 +32,7 @@
 #define HVM_INFO_PADDR   ((HVM_INFO_PFN << 12) + HVM_INFO_OFFSET)
 
 /* Maximum we can support with current vLAPIC ID mapping. */
-#define HVM_MAX_VCPUS128
+#define HVM_MAX_VCPUS512
 
 /*
  * In some cases SMP HVM guests may require knowledge of Xen's idea of vCPU ids
-- 
1.8.3.1


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

[Xen-devel] [RFC Patch v4 6/8] hvmload: Add x2apic entry support in the MADT and SRAT build

[Chao Gao]

From: Lan Tianyu 

This patch contains the following changes:
1. add x2apic entry support for ACPI MADT table according to
 ACPI spec 5.2.12.12 Processor Local x2APIC Structure.
2. add x2apic entry support for ACPI SRAT table according to
 ACPI spec 5.2.16.3 Processor Local x2APIC Affinity Structure.

Signed-off-by: Lan Tianyu 
Signed-off-by: Chao Gao 
---
v4:
 - also add x2apic entry in SRAT
---
 tools/libacpi/acpi2_0.h | 25 --
 tools/libacpi/build.c   | 57 +++--
 2 files changed, 69 insertions(+), 13 deletions(-)

diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
index 6081417..7eb983d 100644
--- a/tools/libacpi/acpi2_0.h
+++ b/tools/libacpi/acpi2_0.h
@@ -322,6 +322,7 @@ struct acpi_20_waet {
 #define ACPI_IO_SAPIC   0x06
 #define ACPI_PROCESSOR_LOCAL_SAPIC  0x07
 #define ACPI_PLATFORM_INTERRUPT_SOURCES 0x08
+#define ACPI_PROCESSOR_LOCAL_X2APIC 0x09
 
 /*
  * APIC Structure Definitions.
@@ -338,6 +339,15 @@ struct acpi_20_madt_lapic {
 uint32_t flags;
 };
 
+struct acpi_20_madt_x2apic {
+uint8_t  type;
+uint8_t  length;
+uint16_t reserved;
+uint32_t x2apic_id;
+uint32_t flags;
+uint32_t acpi_processor_uid;
+};
+
 /*
  * Local APIC Flags.  All other bits are reserved and must be 0.
  */
@@ -378,8 +388,9 @@ struct acpi_20_srat {
 /*
  * System Resource Affinity Table structure types.
  */
-#define ACPI_PROCESSOR_AFFINITY 0x0
-#define ACPI_MEMORY_AFFINITY0x1
+#define ACPI_PROCESSOR_AFFINITY 0x0
+#define ACPI_MEMORY_AFFINITY0x1
+#define ACPI_PROCESSOR_X2APIC_AFFINITY  0x2
 struct acpi_20_srat_processor {
 uint8_t type;
 uint8_t length;
@@ -391,6 +402,16 @@ struct acpi_20_srat_processor {
 uint32_t reserved;
 };
 
+struct acpi_20_srat_processor_x2apic {
+uint8_t type;
+uint8_t length;
+uint16_t reserved;
+uint32_t domain;
+uint32_t x2apic_id;
+uint32_t flags;
+uint32_t reserved2[2];
+};
+
 /*
  * Local APIC Affinity Flags.  All other bits are reserved and must be 0.
  */
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index df0a67c..5cbf6a9 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -30,6 +30,11 @@
 
 #define align16(sz)(((sz) + 15) & ~15)
 #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
+#define min(X, Y) ({ \
+const typeof (X) _x = (X);   \
+const typeof (Y) _y = (Y);   \
+(void) (&_x == &_y); \
+(_x < _y) ? _x : _y; })
 
 extern struct acpi_20_rsdp Rsdp;
 extern struct acpi_20_rsdt Rsdt;
@@ -79,16 +84,19 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 struct acpi_20_madt_intsrcovr *intsrcovr;
 struct acpi_20_madt_ioapic*io_apic;
 struct acpi_20_madt_lapic *lapic;
+struct acpi_20_madt_x2apic*x2apic;
 const struct hvm_info_table   *hvminfo = config->hvminfo;
-int i, sz;
+int i, sz, nr_apic;
 
 if ( config->lapic_id == NULL )
 return NULL;
 
+nr_apic = min(hvminfo->nr_vcpus, MADT_MAX_LOCAL_APIC);
 sz  = sizeof(struct acpi_20_madt);
 sz += sizeof(struct acpi_20_madt_intsrcovr) * 16;
 sz += sizeof(struct acpi_20_madt_ioapic);
-sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus;
+sz += sizeof(struct acpi_20_madt_lapic) * nr_apic;
+sz += sizeof(struct acpi_20_madt_x2apic) * (hvminfo->nr_vcpus - nr_apic);
 
 madt = ctxt->mem_ops.alloc(ctxt, sz, 16);
 if (!madt) return NULL;
@@ -149,7 +157,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 
 info->nr_cpus = hvminfo->nr_vcpus;
 info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, lapic);
-for ( i = 0; i < hvminfo->nr_vcpus; i++ )
+for ( i = 0; i < nr_apic; i++ )
 {
 memset(lapic, 0, sizeof(*lapic));
 lapic->type= ACPI_PROCESSOR_LOCAL_APIC;
@@ -157,12 +165,26 @@ static struct acpi_20_madt *construct_madt(struct 
acpi_ctxt *ctxt,
 /* Processor ID must match processor-object IDs in the DSDT. */
 lapic->acpi_processor_id = i;
 lapic->apic_id = config->lapic_id(i);
-lapic->flags = (test_bit(i, hvminfo->vcpu_online)
-? ACPI_LOCAL_APIC_ENABLED : 0);
+lapic->flags = test_bit(i, hvminfo->vcpu_online)
+   ? ACPI_LOCAL_APIC_ENABLED : 0;
 lapic++;
 }
 
-madt->header.length = (unsigned char *)lapic - (unsigned char *)madt;
+x2apic = (void *)lapic;
+for ( ; i < hvminfo->nr_vcpus; i++ )
+{
+memset(x2apic, 0, sizeof(*x2apic));
+x2apic->type= ACPI_PROCESSOR_LOCAL_X2APIC;
+x2apic->length  = sizeof(*x2apic);
+/* Processor UID must match processor-object UIDs in the DSDT. */
+x2apic->acpi_processor_uid = i;
+

[Xen-devel] [RFC Patch v4 1/8] ioreq: remove most 'buf' parameter from static functions

[Chao Gao]

It is a preparation to support multiple IOREQ pages.
No functional change.

Signed-off-by: Chao Gao 
---
v4:
 -new
---
 xen/arch/x86/hvm/ioreq.c | 48 +++-
 1 file changed, 23 insertions(+), 25 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index d991ac9..a879f20 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -237,10 +237,9 @@ static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s, 
gfn_t gfn)
 set_bit(i, >arch.hvm_domain.ioreq_gfn.mask);
 }
 
-static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
+static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s,
+struct hvm_ioreq_page *iorp)
 {
-struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
-
 if ( gfn_eq(iorp->gfn, INVALID_GFN) )
 return;
 
@@ -289,15 +288,15 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
  >va);
 
 if ( rc )
-hvm_unmap_ioreq_gfn(s, buf);
+hvm_unmap_ioreq_gfn(s, iorp);
 
 return rc;
 }
 
-static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
+static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s,
+   struct hvm_ioreq_page *iorp)
 {
 struct domain *currd = current->domain;
-struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 
 if ( iorp->page )
 {
@@ -344,10 +343,9 @@ static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s, 
bool buf)
 return 0;
 }
 
-static void hvm_free_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
+static void hvm_free_ioreq_mfn(struct hvm_ioreq_server *s,
+   struct hvm_ioreq_page *iorp)
 {
-struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
-
 if ( !iorp->page )
 return;
 
@@ -380,11 +378,11 @@ bool is_ioreq_server_page(struct domain *d, const struct 
page_info *page)
 return found;
 }
 
-static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
+static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server *s,
+ struct hvm_ioreq_page *iorp)
 
 {
 struct domain *d = s->domain;
-struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 
 if ( IS_DEFAULT(s) || gfn_eq(iorp->gfn, INVALID_GFN) )
 return;
@@ -395,10 +393,10 @@ static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server 
*s, bool buf)
 clear_page(iorp->va);
 }
 
-static int hvm_add_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
+static int hvm_add_ioreq_gfn(struct hvm_ioreq_server *s,
+ struct hvm_ioreq_page *iorp)
 {
 struct domain *d = s->domain;
-struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 int rc;
 
 if ( IS_DEFAULT(s) || gfn_eq(iorp->gfn, INVALID_GFN) )
@@ -550,36 +548,36 @@ static int hvm_ioreq_server_map_pages(struct 
hvm_ioreq_server *s)
 rc = hvm_map_ioreq_gfn(s, true);
 
 if ( rc )
-hvm_unmap_ioreq_gfn(s, false);
+hvm_unmap_ioreq_gfn(s, >ioreq);
 
 return rc;
 }
 
 static void hvm_ioreq_server_unmap_pages(struct hvm_ioreq_server *s)
 {
-hvm_unmap_ioreq_gfn(s, true);
-hvm_unmap_ioreq_gfn(s, false);
+hvm_unmap_ioreq_gfn(s, >ioreq);
+hvm_unmap_ioreq_gfn(s, >bufioreq);
 }
 
 static int hvm_ioreq_server_alloc_pages(struct hvm_ioreq_server *s)
 {
 int rc;
 
-rc = hvm_alloc_ioreq_mfn(s, false);
+rc = hvm_alloc_ioreq_mfn(s, >ioreq);
 
 if ( !rc && (s->bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF) )
-rc = hvm_alloc_ioreq_mfn(s, true);
+rc = hvm_alloc_ioreq_mfn(s, >bufioreq);
 
 if ( rc )
-hvm_free_ioreq_mfn(s, false);
+hvm_free_ioreq_mfn(s, >ioreq);
 
 return rc;
 }
 
 static void hvm_ioreq_server_free_pages(struct hvm_ioreq_server *s)
 {
-hvm_free_ioreq_mfn(s, true);
-hvm_free_ioreq_mfn(s, false);
+hvm_free_ioreq_mfn(s, >bufioreq);
+hvm_free_ioreq_mfn(s, >ioreq);
 }
 
 static void hvm_ioreq_server_free_rangesets(struct hvm_ioreq_server *s)
@@ -646,8 +644,8 @@ static void hvm_ioreq_server_enable(struct hvm_ioreq_server 
*s)
 if ( s->enabled )
 goto done;
 
-hvm_remove_ioreq_gfn(s, false);
-hvm_remove_ioreq_gfn(s, true);
+hvm_remove_ioreq_gfn(s, >ioreq);
+hvm_remove_ioreq_gfn(s, >bufioreq);
 
 s->enabled = true;
 
@@ -667,8 +665,8 @@ static void hvm_ioreq_server_disable(struct 
hvm_ioreq_server *s)
 if ( !s->enabled )
 goto done;
 
-hvm_add_ioreq_gfn(s, true);
-hvm_add_ioreq_gfn(s, false);
+hvm_add_ioreq_gfn(s, >bufioreq);
+hvm_add_ioreq_gfn(s, >ioreq);
 
 s->enabled = false;
 
-- 
1.8.3.1


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

[Xen-devel] [RFC Patch v4 3/8] xl/acpi: unify the computation of lapic_id

[Chao Gao]

There were two places where the lapic_id is computed, one in hvmloader and one
in libacpi. Unify them by defining LAPIC_ID in a header file and incluing it
in both places.

To address compilation issue and make libacpi.h self-contained, include
stdint.h in libacpi.h.

Signed-off-by: Chao Gao 
---
v4:
 - new
---
 tools/firmware/hvmloader/config.h | 3 +--
 tools/libacpi/libacpi.h   | 3 +++
 tools/libxl/libxl_x86_acpi.c  | 2 +-
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/firmware/hvmloader/config.h 
b/tools/firmware/hvmloader/config.h
index 6e00413..55e3a27 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -1,7 +1,7 @@
 #ifndef __HVMLOADER_CONFIG_H__
 #define __HVMLOADER_CONFIG_H__
 
-#include 
+#include 
 
 enum virtual_vga { VGA_none, VGA_std, VGA_cirrus, VGA_pt };
 extern enum virtual_vga virtual_vga;
@@ -48,7 +48,6 @@ extern uint8_t ioapic_version;
 #define IOAPIC_ID   0x01
 
 #define LAPIC_BASE_ADDRESS  0xfee0
-#define LAPIC_ID(vcpu_id)   ((vcpu_id) * 2)
 
 #define PCI_ISA_DEVFN   0x08/* dev 1, fn 0 */
 #define PCI_ISA_IRQ_MASK0x0c20U /* ISA IRQs 5,10,11 are PCI connected */
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index 46a819d..b89fdb5 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -21,6 +21,9 @@
 #define __LIBACPI_H__
 
 #include 
+#include   /* uintXX_t */
+
+#define LAPIC_ID(vcpu_id)   ((vcpu_id) * 2)
 
 #define ACPI_HAS_COM1  (1<<0)
 #define ACPI_HAS_COM2  (1<<1)
diff --git a/tools/libxl/libxl_x86_acpi.c b/tools/libxl/libxl_x86_acpi.c
index bbe9219..0b7507d 100644
--- a/tools/libxl/libxl_x86_acpi.c
+++ b/tools/libxl/libxl_x86_acpi.c
@@ -87,7 +87,7 @@ static void acpi_mem_free(struct acpi_ctxt *ctxt,
 
 static uint32_t acpi_lapic_id(unsigned cpu)
 {
-return cpu * 2;
+return LAPIC_ID(cpu);
 }
 
 static int init_acpi_config(libxl__gc *gc, 
-- 
1.8.3.1


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

[Xen-devel] [RFC Patch v4 0/8] Extend resources to support more vcpus in single VM

[Chao Gao]

This series is based on Paul Durrant's "x86: guest resource mapping"
(https://lists.xenproject.org/archives/html/xen-devel/2017-11/msg01735.html)
and "add vIOMMU support with irq remapping  function of virtual VT-d"
(https://lists.xenproject.org/archives/html/xen-devel/2017-11/msg01063.html).

In order to support more vcpus in hvm, this series is to remove VCPU number
constraint imposed by several components:
1. IOREQ server: current only one IOREQ page is used, which limits
   the maximum number of vcpus to 128.
2. libacpi: no x2apic entry is built in MADT and SRAT
3. Size of pre-allocated shadow memory
4. The way how we boot up APs.

This series is RFC for
1. I am not sure whether changes in patch 2 are acceptable. 
2. It depends on our VIOMMU patches which are still under review.

Change since v3:
- Respond Wei and Roger's comments.
- Support multiple IOREQ pages. Seeing patch 1 and 2.
- boot APs through broadcast. Seeing patch 4.
- unify the computation of lapic_id.
- Add x2apic entry in SRAT.
- Increase shadow memory according to the maximum vcpus of HVM.

Change since v2:
1) Increase page pool size during setting max vcpu
2) Allocate madt table size according APIC id of each vcpus
3) Fix some code style issues.

Change since v1:
1) Increase hap page pool according vcpu number
2) Use "Processor" syntax to define vcpus with APIC id < 255
in dsdt and use "Device" syntax for other vcpus in ACPI DSDT table.
3) Use XAPIC structure for vcpus with APIC id < 255
in dsdt and use x2APIC structure for other vcpus in the ACPI MADT table.

This patchset is to extend some resources(i.e, event channel,
hap and so) to support more vcpus for single VM.

Chao Gao (6):
  ioreq: remove most 'buf' parameter from static functions
  ioreq: bump the number of IOREQ page to 4 pages
  xl/acpi: unify the computation of lapic_id
  hvmloader: boot cpu through broadcast
  x86/hvm: bump the number of pages of shadow memory
  x86/hvm: bump the maximum number of vcpus to 512

Lan Tianyu (2):
  Tool/ACPI: DSDT extension to support more vcpus
  hvmload: Add x2apic entry support in the MADT and SRAT build

 tools/firmware/hvmloader/apic_regs.h|   4 +
 tools/firmware/hvmloader/config.h   |   3 +-
 tools/firmware/hvmloader/smp.c  |  64 --
 tools/libacpi/acpi2_0.h |  25 +-
 tools/libacpi/build.c   |  57 +---
 tools/libacpi/libacpi.h |   9 ++
 tools/libacpi/mk_dsdt.c |  40 +++--
 tools/libxc/include/xc_dom.h|   2 +-
 tools/libxc/xc_dom_x86.c|   6 +-
 tools/libxl/libxl_x86_acpi.c|   2 +-
 xen/arch/x86/hvm/hvm.c  |   1 +
 xen/arch/x86/hvm/ioreq.c| 150 ++--
 xen/arch/x86/mm/hap/hap.c   |   2 +-
 xen/arch/x86/mm/shadow/common.c |   2 +-
 xen/include/asm-x86/hvm/domain.h|   6 +-
 xen/include/public/hvm/hvm_info_table.h |   2 +-
 xen/include/public/hvm/ioreq.h  |   2 +
 xen/include/public/hvm/params.h |   8 +-
 18 files changed, 303 insertions(+), 82 deletions(-)

-- 
1.8.3.1


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

Re: [Xen-devel] Ping#3: [PATCH v3] x86/HVM: don't #GP/#SS on wrapping virt->linear translations

[Jan Beulich]

>>> On 04.12.17 at 17:39,  wrote:
> On 04/12/17 10:16, Jan Beulich wrote:
> On 25.08.17 at 16:59,  wrote:
>> On 10.08.17 at 09:19,  wrote:
>>> On 10.07.17 at 12:39,  wrote:
> Real hardware wraps silently in most cases, so we should behave the
> same. Also split real and VM86 mode handling, as the latter really
> ought to have limit checks applied.
>
> Signed-off-by: Jan Beulich 
> ---
> v3: Restore 32-bit wrap check for AMD.
> v2: Extend to non-64-bit modes. Reduce 64-bit check to a single
> is_canonical_address() invocation.
>> Same here - I think I've been carrying this for long enough.
> 
> I'm not sure what to say.  I'm not comfortable taking this change
> without a regression test in place, which also serves to demonstrate the
> correctness of the change.
> 
> Its simply a matter of time, not any other objection to the change.

Well, I had sent you a tentative XTF test long ago (non-publicly
at the time, I believe). Here it is again. I'll send a second change
in a minute, which iirc is necessary as prereq to the one here.

Jan

add split memory access tests

Add tests to verify that accesses crossing the upper address boundary
are being handled similarly with and without the emulator involved.

Signed-off-by: Jan Beulich 
---
v2: Use FS overrides. Add 64-bit and PV tests. Remove stray '-s from
log messages. Add "X" (ex_record_fault_eax) constraints.

--- /dev/null
+++ b/tests/split-access/Makefile
@@ -0,0 +1,9 @@
+include $(ROOT)/build/common.mk
+
+NAME  := split-access
+CATEGORY  := functional
+TEST-ENVS := $(ALL_ENVIRONMENTS)
+
+obj-perenv += main.o
+
+include $(ROOT)/build/gen.mk
--- /dev/null
+++ b/tests/split-access/main.c
@@ -0,0 +1,251 @@
+/**
+ * @file tests/split-access/main.c
+ * @ref test-split-access
+ *
+ * @page test-split-access split-access
+ *
+ * @todo Docs for test-split-access
+ *
+ * @see tests/split-access/main.c
+ */
+#include 
+
+#include 
+#include 
+
+const char test_title[] = "Split memory access insns";
+
+const void *volatile boundary = NULL;
+
+/* Keep the compiler from leveraging undefined behavior. */
+#define touch(x) ({ asm ( "" : "+g" (x) ); })
+
+void do_mov(bool force)
+{
+const unsigned long *ptr = boundary;
+
+touch(ptr);
+for ( --ptr; ; )
+{
+unsigned long val;
+exinfo_t fault = 0;
+
+asm volatile ( "test %[fep], %[fep];"
+   "jz 1f;"
+   _ASM_XEN_FEP
+   "1: mov %%fs:%[src],%[dst]; 2:"
+   _ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_eax)
+   : [dst] "=r" (val), "+a" (fault)
+   : [src] "m" (*ptr), [fep] "q" (force),
+ "X" (ex_record_fault_eax) );
+if ( fault )
+xtf_warning("Got %pe for %p\n", _p(fault), ptr);
+else if ( val != *ptr )
+xtf_failure("%lx != %lx for %p\n", val, *ptr, ptr);
+
+touch(ptr);
+if ( ptr == boundary )
+break;
+
+ptr = (void *)(long)ptr + 1;
+}
+}
+
+void do_lfs(bool force)
+{
+const struct __packed { unsigned long off; uint16_t sel; } *ptr = boundary;
+
+touch(ptr);
+for ( --ptr; ; )
+{
+unsigned long off;
+exinfo_t fault = 0;
+
+asm volatile ( "test %[fep], %[fep];"
+   "jz 1f;"
+   _ASM_XEN_FEP
+   "1: lfs %%fs:%[src],%[dst]; 2:"
+   _ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_eax)
+   : [dst] "=r" (off), "+a" (fault)
+   : [src] "m" (*ptr), [fep] "q" (force),
+ "X" (ex_record_fault_eax) );
+if ( fault )
+xtf_warning("Got %pe for %p\n", _p(fault), ptr);
+else if ( off != ptr->off )
+xtf_failure("%lx != %lx for %p\n", off, ptr->off, ptr);
+
+touch(ptr);
+if ( ptr == boundary )
+break;
+
+ptr = (void *)(long)ptr + 1;
+}
+}
+
+#ifdef CONFIG_HVM
+void do_lidt(bool force)
+{
+const desc_ptr *ptr = boundary;
+
+touch(ptr);
+for ( --ptr; ; )
+{
+exinfo_t fault = 0;
+
+asm volatile ( "test %[fep], %[fep];"
+   "jz 1f;"
+   _ASM_XEN_FEP
+   "1: lidt %%fs:%[src]; 2:"
+   _ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_eax)
+   : "+a" (fault)
+   : [src] "m" (*ptr), [fep] "q" (force),
+ "X" (ex_record_fault_eax) );
+if ( fault )
+xtf_warning("Got %pe for %p\n", _p(fault), ptr);
+else
+asm volatile ( "lidt %0" :: "m" (idt_ptr) );
+
+touch(ptr);
+if ( ptr == boundary )
+break;
+
+ptr = (void *)(long)ptr + 1;
+}
+}

[Xen-devel] [PATCH] xen-netback: Fix logging message with spurious period after newline

[Joe Perches]

Using a period after a newline causes bad output.

Signed-off-by: Joe Perches 
---
 drivers/net/xen-netback/interface.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index d6dff347f896..78ebe494fef0 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -186,7 +186,7 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
/* Obtain the queue to be used to transmit this packet */
index = skb_get_queue_mapping(skb);
if (index >= num_queues) {
-   pr_warn_ratelimited("Invalid queue %hu for packet on interface 
%s\n.",
+   pr_warn_ratelimited("Invalid queue %hu for packet on interface 
%s\n",
index, vif->dev->name);
index %= num_queues;
}
-- 
2.15.0


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

[Xen-devel] [qemu-mainline test] 116868: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 116683
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 116683
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 116683
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116683
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 116683
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-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-xl-pvhv2-amd 12 guest-start  fail  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-i386-libvirt-qcow2 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-amd64-libvirt-vhd 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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-xsm 13 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-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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  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-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:
 qemuu2994cb2ee244b7d6a00576b4fd178932d8b31439
baseline version:
 qemuuc11d61271b9e6e7a1f0479ef1ca8fb55fa457a62

Last test of basis   116683  2017-11-29 19:21:45 Z6 days
Failing since116831  2017-12-04 12:54:52 Z1 days3 attempts
Testing same since   116868  2017-12-05 13:53:43 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Chao Gao 
  David Gibson 
  Eric Farman 
  Greg Kurz 
  Igor Mammedov 
  Kevin Wolf 
  Kurban Mallachiev 
  Lan Tianyu 
  Laurent Vivier 
  Marc-André Lureau 
  Maxime Coquelin 
  Michael S. Tsirkin 
  Peter Maydell 
  Prasad J Pandit 
  Richard Purdie 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt 

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-raw

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-raw
testid xen-boot

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  2391f0b4808e3d5af348324d69f5f45c56a26836
  Bug not present: d4c2e9fca5b7db8d315d93a072e65d0847f8e0c5
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/116893/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-xl-raw.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-xl-raw.xen-boot
 --summary-out=tmp/116893.bisection-summary --basis-template=115643 
--blessings=real,real-bisect linux-linus test-amd64-i386-xl-raw xen-boot
Searching for failure / basis pass:
 116840 fail [host=merlot1] / 116268 [host=nobling1] 116226 [host=nocera0] 
116215 [host=italia0] 116182 [host=elbling1] 116164 [host=baroque1] 116152 
[host=baroque0] 116136 [host=chardonnay1] 116119 [host=nocera1] 116103 
[host=huxelrebe1] 115718 [host=nobling0] 115690 [host=italia1] 115678 
[host=italia1] 115643 [host=chardonnay0] 115628 [host=rimava1] 115615 
[host=italia0] 115599 [host=merlot0] 115573 [host=huxelrebe0] 115543 ok.
Failure / basis pass flights: 116840 / 115543
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 2391f0b4808e3d5af348324d69f5f45c56a26836 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
b79708a8ed1b3d18bee67baeaf33b3fa529493e2 
6da091d95dfcbe00daf91308d044ee5151b1ac9e
Basis pass d4c2e9fca5b7db8d315d93a072e65d0847f8e0c5 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5cd7ce5dde3f228b3b669ed9ca432f588947bd40 
ff93dc55431517ed29c70dbff6721c6b0803acf9
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#d4c2e9fca5b7db8d315d93a072e65d0847f8e0c5-2391f0b4808e3d5af348324d69f5f45c56a26836
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60
 
git://xenbits.xen.org/qemu-xen.git#5cd7ce5dde3f228b3b669ed9ca432f588947bd40-b79708a8ed1b3d18bee67baeaf33b3fa529493e2
 
git://xenbits.xen.org/xen.git#ff93dc55431517ed29c70dbff6721c6b0803acf9-6da091d95dfcbe00daf91308d044ee5151b1ac9e
From 
git://cache:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
   b562c17..328b4ed  master -> origin/master
adhoc-revtuple-generator: tree discontiguous: linux-2.6
Loaded 2006 nodes in revision graph
Searching for test results:
 115599 [host=merlot0]
 115543 pass d4c2e9fca5b7db8d315d93a072e65d0847f8e0c5 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5cd7ce5dde3f228b3b669ed9ca432f588947bd40 
ff93dc55431517ed29c70dbff6721c6b0803acf9
 115573 [host=huxelrebe0]
 115615 [host=italia0]
 115628 [host=rimava1]
 115643 [host=chardonnay0]
 115678 [host=italia1]
 115690 [host=italia1]
 115718 [host=nobling0]
 116103 [host=huxelrebe1]
 116152 [host=baroque0]
 116119 [host=nocera1]
 116136 [host=chardonnay1]
 116164 [host=baroque1]
 116182 [host=elbling1]
 116215 [host=italia0]
 116226 [host=nocera0]
 116268 [host=nobling1]
 116316 fail irrelevant
 116343 fail irrelevant
 116433 fail irrelevant
 116461 fail irrelevant
 116514 fail irrelevant
 116536 fail irrelevant
 116550 fail irrelevant
 116577 fail irrelevant
 116592 fail irrelevant
 116628 fail irrelevant
 116775 fail irrelevant
 116735 fail irrelevant
 116855 fail irrelevant
 116845 pass d4c2e9fca5b7db8d315d93a072e65d0847f8e0c5 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
b79708a8ed1b3d18bee67baeaf33b3fa529493e2 
9976f3874d4cca829f2d2916feab18615337bb5c
 116830 pass d4c2e9fca5b7db8d315d93a072e65d0847f8e0c5 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5cd7ce5dde3f228b3b669ed9ca432f588947bd40 
ff93dc55431517ed29c70dbff6721c6b0803acf9
 116833 fail irrelevant
 116810 fail 

[Xen-devel] [xen-unstable baseline-only test] 72519: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 72519 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72519/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 72506
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 72506
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 72506
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 72506
 test-amd64-amd64-xl-qemut-win10-i386 16 guest-localmigrate/x10 fail REGR. vs. 
72506
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install   fail REGR. vs. 72506
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 72506
 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install   fail REGR. vs. 72506
 test-amd64-i386-xl-qemut-win7-amd64 10 windows-installfail REGR. vs. 72506
 test-amd64-i386-xl-qemut-win10-i386 10 windows-installfail REGR. vs. 72506

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 72506
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail like 72506
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   like 72506
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   like 72506
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   like 72506
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 72506
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 72506
 test-amd64-amd64-examine  4 memdisk-try-append   fail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  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-xl-qemut-ws16-amd64 10 windows-install fail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 12 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-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   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 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass

version targeted for testing:
 xen  553ac37137c2d1c03bf1b69cfb192ffbfe29daa4
baseline version:
 xen  6da091d95dfcbe00daf91308d044ee5151b1ac9e

Last test of basis72506  2017-12-01 13:45:48 Z4 days
Testing same since72519  2017-12-05 15:18:23 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Brian Woods 
  David Esler 
  Euan Harris 
  Gregory Herrero 
  Haozhong Zhang 
  Ian 

Re: [Xen-devel] [PATCH for-next 09/16] xen/arm: domain_build: Rework initrd_load to use the generic copy helper

[Stefano Stabellini]

On Thu, 23 Nov 2017, Julien Grall wrote:
> The function initrd_load is dealing with IPA but uses gvirt_to_maddr to
> do the translation. This is currently working fine because the stage-1 MMU
> is disabled.
> 
> Furthermore, the function is implementing its own copy to guest resulting
> in code duplication and making more difficult to update the logic in
> page-tables (such support for Populate On Demand).
> 
> The new copy_to_guest_phys_flush_dcache could be used here by temporarily
> mapping the full initrd in the virtual space.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/domain_build.c | 31 ---
>  1 file changed, 8 insertions(+), 23 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 3f87bf2051..42c2e16ef6 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1966,11 +1966,11 @@ static void initrd_load(struct kernel_info *kinfo)
>  const struct bootmodule *mod = kinfo->initrd_bootmodule;
>  paddr_t load_addr = kinfo->initrd_paddr;
>  paddr_t paddr, len;
> -unsigned long offs;
>  int node;
>  int res;
>  __be32 val[2];
>  __be32 *cellp;
> +void __iomem *initrd;
>  
>  if ( !mod || !mod->size )
>  return;
> @@ -2000,29 +2000,14 @@ static void initrd_load(struct kernel_info *kinfo)
>  if ( res )
>  panic("Cannot fix up \"linux,initrd-end\" property");
>  
> -for ( offs = 0; offs < len; )
> -{
> -uint64_t par;
> -paddr_t s, l, ma = 0;
> -void *dst;
> -
> -s = offs & ~PAGE_MASK;
> -l = min(PAGE_SIZE - s, len);
> -
> -par = gvirt_to_maddr(load_addr + offs, , GV2M_WRITE);
> -if ( par )
> -{
> -panic("Unable to translate guest address");
> -return;
> -}
> -
> -dst = map_domain_page(maddr_to_mfn(ma));
> +initrd = ioremap_wc(paddr, len);
> +if ( !initrd )
> +panic("Unable to map the hwdom initrd");
>  
> -copy_from_paddr(dst + s, paddr + offs, l);
> -
> -unmap_domain_page(dst);
> -offs += l;
> -}
> +res = copy_to_guest_phys_flush_dcache(kinfo->d, load_addr,
> +  initrd, len);
> +if ( res != 0 )
> +panic("Unable to copy the initrd in the hwdom memory");
>  }
>  
>  static void evtchn_fixup(struct domain *d, struct kernel_info *kinfo)

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

Re: [Xen-devel] [PATCH for-next 08/16] xen/arm: kernel: Rework kernel_zimage_load to use the generic copy helper

[Stefano Stabellini]

On Tue, 5 Dec 2017, Stefano Stabellini wrote:
> On Thu, 23 Nov 2017, Julien Grall wrote:
> > The function kernel_zimage is dealing with IPA but uses gvirt_to_maddr to
> > do the translation. This is currently working fine because the stage-1 MMU
> > is disabled.
> > 
> > Furthermore, the function is implementing its own copy to guest resulting
> > in code duplication and making more difficult to update the logic in
> > page-tables (such support for Populate On Demand).
> > 
> > The new copy_to_guest_phys_flush_dcache could be used here by
> > temporarily mapping the full kernel in the virtual space.
> > 
> > Signed-off-by: Julien Grall 
> > ---
> >  xen/arch/arm/domain_build.c |  1 +
> >  xen/arch/arm/kernel.c   | 33 -
> >  xen/arch/arm/kernel.h   |  2 ++
> >  3 files changed, 15 insertions(+), 21 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index c74f4dd69d..3f87bf2051 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2133,6 +2133,7 @@ int construct_dom0(struct domain *d)
> >  d->max_pages = ~0U;
> >  
> >  kinfo.unassigned_mem = dom0_mem;
> > +kinfo.d = d;
> >  
> >  rc = kernel_probe();
> >  if ( rc < 0 )
> > diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> > index a6c6413712..2fb0b9684d 100644
> > --- a/xen/arch/arm/kernel.c
> > +++ b/xen/arch/arm/kernel.c
> > @@ -15,6 +15,8 @@
> >  #include 
> >  #include 
> >  
> > +#include 
> > +
> >  #include "kernel.h"
> >  
> >  #define UIMAGE_MAGIC  0x27051956
> > @@ -157,7 +159,8 @@ static void kernel_zimage_load(struct kernel_info *info)
> >  paddr_t load_addr = kernel_zimage_place(info);
> >  paddr_t paddr = info->zimage.kernel_addr;
> >  paddr_t len = info->zimage.len;
> > -unsigned long offs;
> > +void *kernel;
> > +int rc;
> >  
> >  info->entry = load_addr;
> >  
> > @@ -165,29 +168,17 @@ static void kernel_zimage_load(struct kernel_info 
> > *info)
> >  
> >  printk("Loading zImage from %"PRIpaddr" to %"PRIpaddr"-%"PRIpaddr"\n",
> > paddr, load_addr, load_addr + len);
> > -for ( offs = 0; offs < len; )
> > -{
> > -uint64_t par;
> > -paddr_t s, l, ma = 0;
> > -void *dst;
> > -
> > -s = offs & ~PAGE_MASK;
> > -l = min(PAGE_SIZE - s, len);
> > -
> > -par = gvirt_to_maddr(load_addr + offs, , GV2M_WRITE);
> > -if ( par )
> > -{
> > -panic("Unable to map translate guest address");
> > -return;
> > -}
> >  
> > -dst = map_domain_page(maddr_to_mfn(ma));
> > +kernel = ioremap_wc(paddr, len);
> 
> Why ioremap_wc?

That is because we kept the same attributes used today by
copy_from_paddr. Makes sense.

Reviewed-by: Stefano Stabellini 


> > +if ( !kernel )
> > +panic("Unable to map the hwdom kernel");
> >  
> > -copy_from_paddr(dst + s, paddr + offs, l);
> > +rc = copy_to_guest_phys_flush_dcache(info->d, load_addr,
> > + kernel, len);
> > +if ( rc != 0 )
> > +panic("Unable to copy the kernel in the hwdom memory");
> >  
> > -unmap_domain_page(dst);
> > -offs += l;
> > -}
> > +iounmap(kernel);
> >  }
> >  
> >  /*
> > diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
> > index c1b07d4f7b..6d695097b5 100644
> > --- a/xen/arch/arm/kernel.h
> > +++ b/xen/arch/arm/kernel.h
> > @@ -15,6 +15,8 @@ struct kernel_info {
> >  enum domain_type type;
> >  #endif
> >  
> > +struct domain *d;
> > +
> >  void *fdt; /* flat device tree */
> >  paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
> >  struct meminfo mem;
> > -- 
> > 2.11.0
> > 
> 

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

Re: [Xen-devel] [PATCH for-next 07/16] xen/arm: Introduce copy_to_guest_phys_flush_dcache

[Stefano Stabellini]

On Thu, 23 Nov 2017, Julien Grall wrote:
> Hi Andrew,
> 
> On 23/11/17 18:49, Andrew Cooper wrote:
> > On 23/11/17 18:32, Julien Grall wrote:
> > > This new function will be used in a follow-up patch to copy data to the
> > > guest
> > > using the IPA (aka guest physical address) and then clean the cache.
> > > 
> > > Signed-off-by: Julien Grall 
> > > ---
> > >   xen/arch/arm/guestcopy.c   | 10 ++
> > >   xen/include/asm-arm/guest_access.h |  6 ++
> > >   2 files changed, 16 insertions(+)
> > > 
> > > diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> > > index be53bee559..7958663970 100644
> > > --- a/xen/arch/arm/guestcopy.c
> > > +++ b/xen/arch/arm/guestcopy.c
> > > @@ -110,6 +110,16 @@ unsigned long raw_copy_from_guest(void *to, const
> > > void __user *from, unsigned le
> > > COPY_from_guest | COPY_linear);
> > >   }
> > >   +unsigned long copy_to_guest_phys_flush_dcache(struct domain *d,
> > > +  paddr_t gpa,
> > > +  void *buf,
> > > +  unsigned int len)
> > > +{
> > > +/* P2M is shared between all vCPUs, so the vCPU used does not matter.
> > > */
> > 
> > Be very careful with this line of thinking.  It is only works after
> > DOMCTL_max_vcpus has succeeded, and before that point, it is a latent
> > NULL pointer dereference.
> 
> I really don't expect that function been used before DOMCT_max_vcpus is set.
> It is only used for hardware emulation or Xen loading image into the hardware
> domain memory. I could add a check d->vcpus to be safe.
> 
> > 
> > Also, what about vcpus configured with alternative views?
> 
> It is not important because the underlying call is get_page_from_gfn that does
> not care about the alternative view (that function take a domain in
> parameter). I can update the comment.
 
Since this is a new function, would it make sense to take a struct
vcpu* as parameter, instead of a struct domain* ?___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-next 06/16] xen/arm: Extend copy_to_guest to support copying from/to guest physical address

[Stefano Stabellini]

On Tue, 5 Dec 2017, Stefano Stabellini wrote:
> On Thu, 23 Nov 2017, Julien Grall wrote:
> > The only differences between copy_to_guest and access_guest_memory_by_ipa 
> > are:
> > - The latter does not support copying data crossing page boundary
> > - The former is copying from/to guest VA whilst the latter from
> > guest PA
> > 
> > copy_to_guest can easily be extended to support copying from/to guest
> > physical address. For that a new bit is used to tell whether linear
> > address or ipa is been used.
> > 
> > Lastly access_guest_memory_by_ipa is reimplemented using copy_to_guest.
> > This also has the benefits to extend the use of it, it is now possible
> > to copy data crossing page boundary.
> > 
> > Signed-off-by: Julien Grall 
> 
> Ah! This is the reason why previous patches were not using vaddr_t. It
> makes sense now. May I suggest we use something different from paddr_t
> in copy_guest for addr type? I don't think is correct to specify addr as
> paddr_t when it could be vaddr_t; in the future we could have type
> checks on them.
> 
> I suggest we specify it as u64, but if you have a better idea go for it.
> 
> 
> > ---
> >  xen/arch/arm/guestcopy.c | 86 
> > ++--
> >  1 file changed, 39 insertions(+), 47 deletions(-)
> > 
> > diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> > index 487f5ab82d..be53bee559 100644
> > --- a/xen/arch/arm/guestcopy.c
> > +++ b/xen/arch/arm/guestcopy.c
> > @@ -8,6 +8,31 @@
> >  #define COPY_flush_dcache   (1U << 0)
> >  #define COPY_from_guest (0U << 1)
> >  #define COPY_to_guest   (1U << 1)
> > +#define COPY_ipa(0U << 2)
> > +#define COPY_linear (1U << 2)
> > +
> > +static struct page_info *translate_get_page(struct vcpu *v, paddr_t addr,
> > +bool linear, bool write)
> > +{
> > +p2m_type_t p2mt;
> > +struct page_info *page;
> > +
> > +if ( linear )
> > +return get_page_from_gva(v, addr, write ? GV2M_WRITE : GV2M_READ);
> > +
> > +page = get_page_from_gfn(v->domain, paddr_to_pfn(addr), , 
> > P2M_ALLOC);
> > +
> > +if ( !page )
> > +return NULL;
> > +
> > +if ( !p2m_is_ram(p2mt) )
> > +{
> > +put_page(page);
> > +return NULL;
> > +}
> > +
> > +return page;
> > +}
> >  
> >  static unsigned long copy_guest(void *buf, paddr_t addr, unsigned int len,
> >  struct vcpu *v, unsigned int flags)
> > @@ -21,8 +46,8 @@ static unsigned long copy_guest(void *buf, paddr_t addr, 
> > unsigned int len,
> >  unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
> >  struct page_info *page;
> >  
> > -page = get_page_from_gva(v, addr,
> > - (flags & COPY_to_guest) ? GV2M_WRITE : 
> > GV2M_READ);
> > +page = translate_get_page(v, addr, flags & COPY_linear,
> > +  flags & COPY_to_guest);
> >  if ( page == NULL )
> >  return len;
> >  
> > @@ -63,73 +88,40 @@ static unsigned long copy_guest(void *buf, paddr_t 
> > addr, unsigned int len,
> >  unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
> >  {
> >  return copy_guest((void *)from, (unsigned long)to, len,
> > -  current, COPY_to_guest);
> > +  current, COPY_to_guest | COPY_linear);
> >  }
> >  
> >  unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from,
> >   unsigned len)
> >  {
> >  return copy_guest((void *)from, (unsigned long)to, len,
> > -  current, COPY_to_guest | COPY_flush_dcache);
> > +  current, COPY_to_guest | COPY_flush_dcache | 
> > COPY_linear);
> >  }
> >  
> >  unsigned long raw_clear_guest(void *to, unsigned len)
> >  {
> > -return copy_guest(NULL, (unsigned long)to, len, current, 
> > COPY_to_guest);
> > +return copy_guest(NULL, (unsigned long)to, len, current,
> > +  COPY_to_guest | COPY_linear);
> >  }
> >  
> >  unsigned long raw_copy_from_guest(void *to, const void __user *from, 
> > unsigned len)
> >  {
> > -return copy_guest(to, (unsigned long)from, len, current, 
> > COPY_from_guest);
> > +return copy_guest(to, (unsigned long)from, len, current,
> > +  COPY_from_guest | COPY_linear);
> >  }
> >  
> > -/*
> > - * Temporarily map one physical guest page and copy data to or from it.
> > - * The data to be copied cannot cross a page boundary.
> > - */
> >  int access_guest_memory_by_ipa(struct domain *d, paddr_t gpa, void *buf,
> > uint32_t size, bool is_write)
> >  {
> > -struct page_info *page;
> > -uint64_t offset = gpa & ~PAGE_MASK;  /* Offset within the mapped page 
> > */
> > -p2m_type_t p2mt;
> > -void *p;
> > -
> > -/* Do not cross a page 

Re: [Xen-devel] [PATCH for-next 06/16] xen/arm: Extend copy_to_guest to support copying from/to guest physical address

[Stefano Stabellini]

On Thu, 23 Nov 2017, Julien Grall wrote:
> The only differences between copy_to_guest and access_guest_memory_by_ipa are:
> - The latter does not support copying data crossing page boundary
> - The former is copying from/to guest VA whilst the latter from
> guest PA
> 
> copy_to_guest can easily be extended to support copying from/to guest
> physical address. For that a new bit is used to tell whether linear
> address or ipa is been used.
> 
> Lastly access_guest_memory_by_ipa is reimplemented using copy_to_guest.
> This also has the benefits to extend the use of it, it is now possible
> to copy data crossing page boundary.
> 
> Signed-off-by: Julien Grall 

Ah! This is the reason why previous patches were not using vaddr_t. It
makes sense now. May I suggest we use something different from paddr_t
in copy_guest for addr type? I don't think is correct to specify addr as
paddr_t when it could be vaddr_t; in the future we could have type
checks on them.

I suggest we specify it as u64, but if you have a better idea go for it.


> ---
>  xen/arch/arm/guestcopy.c | 86 
> ++--
>  1 file changed, 39 insertions(+), 47 deletions(-)
> 
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index 487f5ab82d..be53bee559 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -8,6 +8,31 @@
>  #define COPY_flush_dcache   (1U << 0)
>  #define COPY_from_guest (0U << 1)
>  #define COPY_to_guest   (1U << 1)
> +#define COPY_ipa(0U << 2)
> +#define COPY_linear (1U << 2)
> +
> +static struct page_info *translate_get_page(struct vcpu *v, paddr_t addr,
> +bool linear, bool write)
> +{
> +p2m_type_t p2mt;
> +struct page_info *page;
> +
> +if ( linear )
> +return get_page_from_gva(v, addr, write ? GV2M_WRITE : GV2M_READ);
> +
> +page = get_page_from_gfn(v->domain, paddr_to_pfn(addr), , 
> P2M_ALLOC);
> +
> +if ( !page )
> +return NULL;
> +
> +if ( !p2m_is_ram(p2mt) )
> +{
> +put_page(page);
> +return NULL;
> +}
> +
> +return page;
> +}
>  
>  static unsigned long copy_guest(void *buf, paddr_t addr, unsigned int len,
>  struct vcpu *v, unsigned int flags)
> @@ -21,8 +46,8 @@ static unsigned long copy_guest(void *buf, paddr_t addr, 
> unsigned int len,
>  unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
>  struct page_info *page;
>  
> -page = get_page_from_gva(v, addr,
> - (flags & COPY_to_guest) ? GV2M_WRITE : 
> GV2M_READ);
> +page = translate_get_page(v, addr, flags & COPY_linear,
> +  flags & COPY_to_guest);
>  if ( page == NULL )
>  return len;
>  
> @@ -63,73 +88,40 @@ static unsigned long copy_guest(void *buf, paddr_t addr, 
> unsigned int len,
>  unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
>  {
>  return copy_guest((void *)from, (unsigned long)to, len,
> -  current, COPY_to_guest);
> +  current, COPY_to_guest | COPY_linear);
>  }
>  
>  unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from,
>   unsigned len)
>  {
>  return copy_guest((void *)from, (unsigned long)to, len,
> -  current, COPY_to_guest | COPY_flush_dcache);
> +  current, COPY_to_guest | COPY_flush_dcache | 
> COPY_linear);
>  }
>  
>  unsigned long raw_clear_guest(void *to, unsigned len)
>  {
> -return copy_guest(NULL, (unsigned long)to, len, current, COPY_to_guest);
> +return copy_guest(NULL, (unsigned long)to, len, current,
> +  COPY_to_guest | COPY_linear);
>  }
>  
>  unsigned long raw_copy_from_guest(void *to, const void __user *from, 
> unsigned len)
>  {
> -return copy_guest(to, (unsigned long)from, len, current, 
> COPY_from_guest);
> +return copy_guest(to, (unsigned long)from, len, current,
> +  COPY_from_guest | COPY_linear);
>  }
>  
> -/*
> - * Temporarily map one physical guest page and copy data to or from it.
> - * The data to be copied cannot cross a page boundary.
> - */
>  int access_guest_memory_by_ipa(struct domain *d, paddr_t gpa, void *buf,
> uint32_t size, bool is_write)
>  {
> -struct page_info *page;
> -uint64_t offset = gpa & ~PAGE_MASK;  /* Offset within the mapped page */
> -p2m_type_t p2mt;
> -void *p;
> -
> -/* Do not cross a page boundary. */
> -if ( size > (PAGE_SIZE - offset) )
> -{
> -printk(XENLOG_G_ERR "d%d: guestcopy: memory access crosses page 
> boundary.\n",
> -   d->domain_id);
> -return -EINVAL;
> -}

I don't know if we necessarely care about this, but with this change
this error path goes 

[Xen-devel] [linux-4.9 test] 116861: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 116754
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 116754
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116754
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail 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-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-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-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-i386-libvirt-qcow2 12 migrate-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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-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-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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  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-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail 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
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux284bbc782445283e9a5124666dda8010f379f179
baseline version:
 linux8743ce3d7c9698285310920c443c086e337aef44

Last test of basis   116754  2017-12-01 16:36:51 Z4 days
Testing same since   116861  2017-12-05 11:08:00 Z0 days1 attempts


People who touched revisions under test:
  Adam Ford 
  Adrian Hunter 
  Alex Deucher 
  Andrew Morton 
  Anna Schumaker 
  Bartosz Golaszewski 
  Bastian Stender 
  Ben Hutchings 
  chenjie 
  Christian König 
  Christoph Hellwig 
  Dan Carpenter 
  Dan Williams 
  David Sterba 
  Dr. David Alan Gilbert 
  Greg Kroah-Hartman 
  Guenter Roeck 
  

Re: [Xen-devel] [PATCH for-next 05/16] xen/arm: guest_copy: Extend the prototype to pass the vCPU

[Stefano Stabellini]

On Thu, 23 Nov 2017, Julien Grall wrote:
> Currently, guest_copy assumes the copy will only be done for the current
> vCPU. A follow-up patch will require to use a different vCPU.
> 
> So extend the prototype to pass the vCPU.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/guestcopy.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index 3aaa80859e..487f5ab82d 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -10,7 +10,7 @@
>  #define COPY_to_guest   (1U << 1)
>  
>  static unsigned long copy_guest(void *buf, paddr_t addr, unsigned int len,
> -unsigned int flags)
> +struct vcpu *v, unsigned int flags)
>  {
>  /* XXX needs to handle faults */
>  unsigned offset = addr & ~PAGE_MASK;
> @@ -21,7 +21,7 @@ static unsigned long copy_guest(void *buf, paddr_t addr, 
> unsigned int len,
>  unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
>  struct page_info *page;
>  
> -page = get_page_from_gva(current, addr,
> +page = get_page_from_gva(v, addr,
>   (flags & COPY_to_guest) ? GV2M_WRITE : 
> GV2M_READ);
>  if ( page == NULL )
>  return len;
> @@ -62,24 +62,25 @@ static unsigned long copy_guest(void *buf, paddr_t addr, 
> unsigned int len,
>  
>  unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
>  {
> -return copy_guest((void *)from, (unsigned long)to, len, COPY_to_guest);
> +return copy_guest((void *)from, (unsigned long)to, len,
> +  current, COPY_to_guest);
>  }
>  
>  unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from,
>   unsigned len)
>  {
>  return copy_guest((void *)from, (unsigned long)to, len,
> -  COPY_to_guest | COPY_flush_dcache);
> +  current, COPY_to_guest | COPY_flush_dcache);
>  }
>  
>  unsigned long raw_clear_guest(void *to, unsigned len)
>  {
> -return copy_guest(NULL, (unsigned long)to, len, COPY_to_guest);
> +return copy_guest(NULL, (unsigned long)to, len, current, COPY_to_guest);
>  }
>  
>  unsigned long raw_copy_from_guest(void *to, const void __user *from, 
> unsigned len)
>  {
> -return copy_guest(to, (unsigned long)from, len, COPY_from_guest);
> +return copy_guest(to, (unsigned long)from, len, current, 
> COPY_from_guest);
>  }
>  
>  /*
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH for-next 04/16] xen/arm: Extend copy_to_guest to support zeroing guest VA and use it

[Stefano Stabellini]

On Thu, 23 Nov 2017, Julien Grall wrote:
> The function copy_to_guest can easily be extended to support zeroing
> guest VA. To avoid using a new bit, it is considered that a NULL buffer
> (i.e buf == NULL) means the guest memory will be zeroed.
> 
> Lastly, reimplement raw_clear_guest using copy_to_guest.
> 
> Signed-off-by: Julien Grall 

Aside from the usual question about vaddr_t:

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/guestcopy.c | 41 +++--
>  1 file changed, 11 insertions(+), 30 deletions(-)
> 
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index 1ffa717ca6..3aaa80859e 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -29,7 +29,16 @@ static unsigned long copy_guest(void *buf, paddr_t addr, 
> unsigned int len,
>  p = __map_domain_page(page);
>  p += offset;
>  if ( flags & COPY_to_guest )
> -memcpy(p, buf, size);
> +{
> +/*
> + * buf will be NULL when the caller request to zero the
> + * guest memory.
> + */
> +if ( buf )
> +memcpy(p, buf, size);
> +else
> +memset(p, 0, size);
> +}
>  else
>  memcpy(buf, p, size);
>  
> @@ -65,35 +74,7 @@ unsigned long raw_copy_to_guest_flush_dcache(void *to, 
> const void *from,
>  
>  unsigned long raw_clear_guest(void *to, unsigned len)
>  {
> -/* XXX needs to handle faults */
> -unsigned offset = (vaddr_t)to & ~PAGE_MASK;
> -
> -while ( len )
> -{
> -void *p;
> -unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
> -struct page_info *page;
> -
> -page = get_page_from_gva(current, (vaddr_t) to, GV2M_WRITE);
> -if ( page == NULL )
> -return len;
> -
> -p = __map_domain_page(page);
> -p += offset;
> -memset(p, 0x00, size);
> -
> -unmap_domain_page(p - offset);
> -put_page(page);
> -len -= size;
> -to += size;
> -/*
> - * After the first iteration, guest virtual address is correctly
> - * aligned to PAGE_SIZE.
> - */
> -offset = 0;
> -}
> -
> -return 0;
> +return copy_guest(NULL, (unsigned long)to, len, COPY_to_guest);
>  }
>  
>  unsigned long raw_copy_from_guest(void *to, const void __user *from, 
> unsigned len)
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH for-next 03/16] xen/arm: Extend copy_to_guest to support copying from guest VA and use it

[Stefano Stabellini]

On Thu, 23 Nov 2017, Julien Grall wrote:
> The only differences between copy_to_guest (formerly called
> raw_copy_to_guest_helper) and raw_copy_from_guest is:
> - The direction of the memcpy
> - The permission use for translating the address
> 
> Extend copy_to_guest to support copying from guest VA by adding using a
> bit in the flags to tell the direction of the copy.
> 
> Lastly, reimplement raw_copy_from_guest using copy_to_guest.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/guestcopy.c | 46 +-
>  1 file changed, 13 insertions(+), 33 deletions(-)
> 
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index d1cfbe922c..1ffa717ca6 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -6,6 +6,8 @@
>  #include 
>  
>  #define COPY_flush_dcache   (1U << 0)
> +#define COPY_from_guest (0U << 1)
> +#define COPY_to_guest   (1U << 1)
>  
>  static unsigned long copy_guest(void *buf, paddr_t addr, unsigned int len,
>  unsigned int flags)
> @@ -19,13 +21,18 @@ static unsigned long copy_guest(void *buf, paddr_t addr, 
> unsigned int len,
>  unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
>  struct page_info *page;
>  
> -page = get_page_from_gva(current, addr, GV2M_WRITE);
> +page = get_page_from_gva(current, addr,
> + (flags & COPY_to_guest) ? GV2M_WRITE : 
> GV2M_READ);
>  if ( page == NULL )
>  return len;
>  
>  p = __map_domain_page(page);
>  p += offset;
> -memcpy(p, buf, size);
> +if ( flags & COPY_to_guest )
> +memcpy(p, buf, size);
> +else
> +memcpy(buf, p, size);
> +
>  if ( flags & COPY_flush_dcache )
>  clean_dcache_va_range(p, size);
>  
> @@ -46,13 +53,14 @@ static unsigned long copy_guest(void *buf, paddr_t addr, 
> unsigned int len,
>  
>  unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
>  {
> -return copy_guest((void *)from, (unsigned long)to, len, 0);
> +return copy_guest((void *)from, (unsigned long)to, len, COPY_to_guest);
>  }
>  
>  unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from,
>   unsigned len)
>  {
> -return copy_guest((void *)from, (unsigned long)to, len, 
> COPY_flush_dcache);
> +return copy_guest((void *)from, (unsigned long)to, len,
> +  COPY_to_guest | COPY_flush_dcache);
>  }
>  
>  unsigned long raw_clear_guest(void *to, unsigned len)
> @@ -90,35 +98,7 @@ unsigned long raw_clear_guest(void *to, unsigned len)
>  
>  unsigned long raw_copy_from_guest(void *to, const void __user *from, 
> unsigned len)
>  {
> -unsigned offset = (vaddr_t)from & ~PAGE_MASK;
> -
> -while ( len )
> -{
> -void *p;
> -unsigned size = min(len, (unsigned)(PAGE_SIZE - offset));
> -struct page_info *page;
> -
> -page = get_page_from_gva(current, (vaddr_t) from, GV2M_READ);
> -if ( page == NULL )
> -return len;
> -
> -p = __map_domain_page(page);
> -p += ((vaddr_t)from & (~PAGE_MASK));
> -
> -memcpy(to, p, size);
> -
> -unmap_domain_page(p);
> -put_page(page);
> -len -= size;
> -from += size;
> -to += size;
> -/*
> - * After the first iteration, guest virtual address is correctly
> - * aligned to PAGE_SIZE.
> - */
> -offset = 0;
> -}
> -return 0;
> +return copy_guest(to, (unsigned long)from, len, COPY_from_guest);
>  }

Same question about vaddr_t for the cast.

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

Re: [Xen-devel] [PATCH for-next 01/16] xen/arm: raw_copy_to_guest_helper: Rename flush_dcache to flags

[Stefano Stabellini]

On Thu, 23 Nov 2017, Julien Grall wrote:
> In a follow-up patch, it will be necessary to pass more flags to the
> function.
> 
> Rename flush_dcache to flags and introduce a define to tell whether the
> cache needs to be flushed after the copy.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/guestcopy.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index 4ee07fcea3..2620e659b4 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -5,8 +5,10 @@
>  #include 
>  #include 
>  
> +#define COPY_flush_dcache   (1U << 0)
> +
>  static unsigned long raw_copy_to_guest_helper(void *to, const void *from,
> -  unsigned len, int flush_dcache)
> +  unsigned len, int flags)
>  {
>  /* XXX needs to handle faults */
>  unsigned offset = (vaddr_t)to & ~PAGE_MASK;
> @@ -24,7 +26,7 @@ static unsigned long raw_copy_to_guest_helper(void *to, 
> const void *from,
>  p = __map_domain_page(page);
>  p += offset;
>  memcpy(p, from, size);
> -if ( flush_dcache )
> +if ( flags & COPY_flush_dcache )
>  clean_dcache_va_range(p, size);
>  
>  unmap_domain_page(p - offset);
> @@ -50,7 +52,7 @@ unsigned long raw_copy_to_guest(void *to, const void *from, 
> unsigned len)
>  unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from,
>   unsigned len)
>  {
> -return raw_copy_to_guest_helper(to, from, len, 1);
> +return raw_copy_to_guest_helper(to, from, len, COPY_flush_dcache);
>  }
>  
>  unsigned long raw_clear_guest(void *to, unsigned len)
> -- 
> 2.11.0
> 

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

[Xen-devel] [xen-unstable test] 116857: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 116744

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 10 windows-install fail pass in 116832

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 116832 
like 116744
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail in 116832 like 116744
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 116722
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 116744
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 116744
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116744
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 116744
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 116744
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 116744
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 116744
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 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 13 migrate-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-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-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-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-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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 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-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 13 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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail 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  553ac37137c2d1c03bf1b69cfb192ffbfe29daa4
baseline version:
 xen  6da091d95dfcbe00daf91308d044ee5151b1ac9e

Last test of basis   116744  2017-12-01 13:53:15 Z4 days
Failing since116779  2017-12-02 17:06:23 Z3 days4 attempts
Testing same since   116832  2017-12-04 13:57:29 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Brian Woods 
  David Esler 
  Euan Harris 
  Gregory Herrero 
  Haozhong Zhang 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm  broken
 build-armhf-xsm   5 host-build-prep  fail REGR. vs. 116760

Tests which did not succeed, but are not blocking:
 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-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 116760
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 116760
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 116760
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 116760
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 116760
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116760
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail 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-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-qcow2 12 migrate-support-checkfail  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-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-credit2  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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-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-qemuu-ws16-amd64 17 guest-stop  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-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  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-ws16-amd64 17 guest-stop fail 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
 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

version targeted for testing:
 linux1d2acf22c2539c568e0a4bd63bf464e10acd8070
baseline version:
 linuxb42518053ffd221d79cff2df8c0257db88a71334

Last test of basis   116760  2017-12-01 20:48:24 Z4 days
Testing same since   116862  2017-12-05 11:07:59 Z0 days1 attempts


People who touched revisions under test:
  Andrew Morton 
  Anna Schumaker 
  Bartosz Golaszewski 
  Ben Hutchings 
  chenjie 
  David S. Miller 
  David Sterba 
  Greg Kroah-Hartman 
  guoxuenan 
  Heiner Kallweit 
  Herbert Xu 
  Jonathan Liu 
  Joonas Lahtinen 
  Josef Bacik 
  Kirill A. Shutemov 
  Konrad Rzeszutek Wilk 
  Linus Torvalds 
  Liran Alon 

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

[Julien Grall]

On 05/12/2017 22:35, Stefano Stabellini wrote:

On Tue, 5 Dec 2017, Julien Grall wrote:

Hi all,

Even though it is an Arm failure, I have CCed x86 folks to get feedback on the
approach. I have a WIP branch I could share if that interest people.

Few months ago, we noticed an heisenbug on jobs run by osstest on the
cubietrucks (see [1]). From the log, we figured out that the guest vCPU 0 is
in data/prefetch abort state at early boot. I have been able to reproduce it
reliably, although from the little information I have I think it is related to
a cache issue because we don't trap cache maintenance instructions by set/way.

This is a set of 3 instructions (clean, clean & invalidate, invalidate)
working on a given cache level by S/W. Because the OS is not allowed to infer
the S/W to PA mapping, it can only use S/W to nuke the whole cache. "The
expected usage of the cache maintenance that operate by set/way is associated
with powerdown and powerup of caches, if this is required by the
implementation" (see D3-2020 ARM DDI 0487B.b).

Those instructions will target a local processor and usually working in batch
for nuking the cache. This means if the vCPU is migrated to another pCPU in
the middle of the process, the cache may not be cleaned. This would result to
data corruption and potential crash of the OS.

Thankfully, the Arm architecture offers a way to trap all the cache
maintenance instructions by S/W (e.g HCR_EL2.TSW). Xen will need to set that
bit and handle S/W.

The major question now is how to handle them. S/W instructions are difficult
to virtualize (see ARMv7 ARM B1.14.4).

The suggested policy is based on the KVM one:
- If we trap a S/W instructions, we enable VM trapping (e.g
HCR_EL2.TVM) to detect cache being turned on/off, and do a full clean.
- We flush the caches on both caches being turned on and off.
- Once the caches are enabled, we stop trapping VM instructions.

Doing a full clean will require to go through the P2M and flush the entries
one by one. At the moment, all the memory is mapped. As you can imagine
flushing guest with hundreds of MB will take a very long time (Linux timeout
during CPU bring).

Therefore, we need a way to limit the number of entries we need to flush. The
suggested solution here is to introduce Populate On Demand (PoD) on Arm.

The guest would boot with no RAM mapped in stage-2 page-table. At every
prefetch/data abort, the RAM would be mapped using preferably 2MB chunk or
4KB. This means that when S/W would be used, the number of entries mapped
would be very limited. However, for safety, the flush should be preemptible.

For those been worry about the performance impact, I have looked at the
current use of S/W instructions:
- Linux Arm64: The last used in the kernel was beginning of 2015
- Linux Arm32: Still use S/W for boot and secondary CPU bring-up. No
plan to change.
- UEFI: A couple of use in UEFI, but I have heard they plan to remove
them (need confirmation).

I haven't looked at all the OSes. However, given the Arm Arm clearly state S/W
instructions are not easily virtualizable, I would expect guest OSes
developers to try there best to limit the use of the instructions.

To limit the performance impact, we could introduce a guest option to tell
whether the guest will use S/W. If it does plan to use S/W, PoD will be
disabled.

Now regarding the hardware domain. At the moment, it has its RAM direct
mapped. Supporting direct mapping in PoD will be quite a pain for a limited
benefits (see why above). In that case I would suggest to impose vCPU pinning
for the hardware domain if the S/W are expected to be used. Again, a command
line option could be introduced here.

Any feedbacks on the approach will be welcomed.
  
Could we pin the hwdom vcpus only at boot time, until all S/W operations

are issued, then "release" them? If we can detect the last expected S/W
operation with some sort of heuristic.


Feel free to suggest a way. I haven't found it. But to be honest, you 
have seen how much people care about 32-bit hwdom today. So I would not 
spend too much time thinking about optimizing it.




Given the information provided above, would it make sense to consider
avoiding PoD for arm64 kernel direct boots?


Please suggest a way to kernel an arm64 kernel direct boot and not using 
S/W. I don't see any.


The only solution, I can see, is to provide a configuration option at 
boot time as I suggested a bit above:


"To limit the performance impact, we could introduce a guest option to 
tell whether the guest will use S/W. If it does plan to use S/W, PoD 
will be disabled."


But at this stage, my concern is fixing blatant bug in Xen and 
performance is a second step.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

[Stefano Stabellini]

On Tue, 5 Dec 2017, Julien Grall wrote:
> Hi all,
> 
> Even though it is an Arm failure, I have CCed x86 folks to get feedback on the
> approach. I have a WIP branch I could share if that interest people.
> 
> Few months ago, we noticed an heisenbug on jobs run by osstest on the
> cubietrucks (see [1]). From the log, we figured out that the guest vCPU 0 is
> in data/prefetch abort state at early boot. I have been able to reproduce it
> reliably, although from the little information I have I think it is related to
> a cache issue because we don't trap cache maintenance instructions by set/way.
> 
> This is a set of 3 instructions (clean, clean & invalidate, invalidate)
> working on a given cache level by S/W. Because the OS is not allowed to infer
> the S/W to PA mapping, it can only use S/W to nuke the whole cache. "The
> expected usage of the cache maintenance that operate by set/way is associated
> with powerdown and powerup of caches, if this is required by the
> implementation" (see D3-2020 ARM DDI 0487B.b).
> 
> Those instructions will target a local processor and usually working in batch
> for nuking the cache. This means if the vCPU is migrated to another pCPU in
> the middle of the process, the cache may not be cleaned. This would result to
> data corruption and potential crash of the OS.
> 
> Thankfully, the Arm architecture offers a way to trap all the cache
> maintenance instructions by S/W (e.g HCR_EL2.TSW). Xen will need to set that
> bit and handle S/W.
> 
> The major question now is how to handle them. S/W instructions are difficult
> to virtualize (see ARMv7 ARM B1.14.4).
> 
> The suggested policy is based on the KVM one:
>   - If we trap a S/W instructions, we enable VM trapping (e.g
> HCR_EL2.TVM) to detect cache being turned on/off, and do a full clean.
>   - We flush the caches on both caches being turned on and off.
>   - Once the caches are enabled, we stop trapping VM instructions.
> 
> Doing a full clean will require to go through the P2M and flush the entries
> one by one. At the moment, all the memory is mapped. As you can imagine
> flushing guest with hundreds of MB will take a very long time (Linux timeout
> during CPU bring).
> 
> Therefore, we need a way to limit the number of entries we need to flush. The
> suggested solution here is to introduce Populate On Demand (PoD) on Arm.
> 
> The guest would boot with no RAM mapped in stage-2 page-table. At every
> prefetch/data abort, the RAM would be mapped using preferably 2MB chunk or
> 4KB. This means that when S/W would be used, the number of entries mapped
> would be very limited. However, for safety, the flush should be preemptible.
> 
> For those been worry about the performance impact, I have looked at the
> current use of S/W instructions:
>   - Linux Arm64: The last used in the kernel was beginning of 2015
>   - Linux Arm32: Still use S/W for boot and secondary CPU bring-up. No
> plan to change.
>   - UEFI: A couple of use in UEFI, but I have heard they plan to remove
> them (need confirmation).
> 
> I haven't looked at all the OSes. However, given the Arm Arm clearly state S/W
> instructions are not easily virtualizable, I would expect guest OSes
> developers to try there best to limit the use of the instructions.
> 
> To limit the performance impact, we could introduce a guest option to tell
> whether the guest will use S/W. If it does plan to use S/W, PoD will be
> disabled.
> 
> Now regarding the hardware domain. At the moment, it has its RAM direct
> mapped. Supporting direct mapping in PoD will be quite a pain for a limited
> benefits (see why above). In that case I would suggest to impose vCPU pinning
> for the hardware domain if the S/W are expected to be used. Again, a command
> line option could be introduced here.
> 
> Any feedbacks on the approach will be welcomed.
 
Could we pin the hwdom vcpus only at boot time, until all S/W operations
are issued, then "release" them? If we can detect the last expected S/W
operation with some sort of heuristic.

Given the information provided above, would it make sense to consider
avoiding PoD for arm64 kernel direct boots?

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

Re: [Xen-devel] [RFC PATCH 06/31] cpufreq: make cpufreq driver more generalizable

[Oleksandr Tyshchenko]

Hi Stefano

On Tue, Dec 5, 2017 at 12:46 AM, Stefano Stabellini
 wrote:
> On Mon, 4 Dec 2017, Oleksandr Tyshchenko wrote:
>> Hi, Stefano
>>
>> On Sat, Dec 2, 2017 at 3:37 AM, Stefano Stabellini
>>  wrote:
>> > On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
>> >> From: Oleksandr Dmytryshyn 
>> >>
>> >> First implementation of the cpufreq driver has been
>> >> written with x86 in mind. This patch makes possible
>> >> the cpufreq driver be working on both x86 and arm
>> >> architectures.
>> >>
>> >> This is a rebased version of the original patch:
>> >> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00932.html
>> >>
>> >> Signed-off-by: Oleksandr Dmytryshyn 
>> >> Signed-off-by: Oleksandr Tyshchenko 
>> >> CC: Jan Beulich 
>> >> CC: Andrew Cooper 
>> >> CC: Stefano Stabellini 
>> >> CC: Julien Grall 
>> >> ---
>> >>  xen/drivers/cpufreq/cpufreq.c| 81 
>> >> +---
>> >>  xen/include/public/platform.h|  1 +
>> >>  xen/include/xen/processor_perf.h |  6 +++
>> >>  3 files changed, 82 insertions(+), 6 deletions(-)
>> >>
>> >> diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
>> >> index ab909e2..64e1ae7 100644
>> >> --- a/xen/drivers/cpufreq/cpufreq.c
>> >> +++ b/xen/drivers/cpufreq/cpufreq.c
>> >> @@ -42,7 +42,6 @@
>> >>  #include 
>> >>  #include 
>> >>  #include 
>> >> -#include 
>> >>  #include 
>> >>
>> >>  static unsigned int __read_mostly usr_min_freq;
>> >> @@ -206,6 +205,7 @@ int cpufreq_add_cpu(unsigned int cpu)
>> >>  } else {
>> >>  /* domain sanity check under whatever coordination type */
>> >>  firstcpu = cpumask_first(cpufreq_dom->map);
>> >> +#ifdef CONFIG_ACPI
>> >>  if ((perf->domain_info.coord_type !=
>> >>  processor_pminfo[firstcpu]->perf.domain_info.coord_type) ||
>> >>  (perf->domain_info.num_processors !=
>> >> @@ -221,6 +221,19 @@ int cpufreq_add_cpu(unsigned int cpu)
>> >>  );
>> >>  return -EINVAL;
>> >>  }
>> >> +#else /* !CONFIG_ACPI */
>> >> +if ((perf->domain_info.num_processors !=
>> >> +
>> >> processor_pminfo[firstcpu]->perf.domain_info.num_processors)) {
>> >> +
>> >> +printk(KERN_WARNING "cpufreq fail to add CPU%d:"
>> >> +   "incorrect num processors (%"PRIu64"), "
>> >> +   "expect(%"PRIu64")\n",
>> >> +   cpu, perf->domain_info.num_processors,
>> >> +   
>> >> processor_pminfo[firstcpu]->perf.domain_info.num_processors
>> >> +);
>> >> +return -EINVAL;
>> >> +}
>> >> +#endif /* CONFIG_ACPI */
>> >
>> > Why is this necessary? I am asking this question, because I think it
>> > would be best to avoid more #ifdef's if we can avoid them, and some of
>> > the code #ifdef'ed doesn't look very acpi specific (at least at first
>> > sight). It doesn't look like this change is very beneficial. What am I
>> > missing?
>>
>> Probably, the original author of this patch wanted to avoid playing
>> with some stuff (code & variables) which didn't make sense/wouldn't be
>> used on non-ACPI systems.
>>
>> Agree here, we are able to avoid this #ifdef as well as many others. I
>> don't see an issue, for example, to print something defaulting for
>> coord_type/num_entries/revision/etc.
>
> I agree
>
>
>> >
>> >
>> >>  }
>> >>
>> >>  if (!domexist || hw_all) {
>> >> @@ -380,6 +393,7 @@ int cpufreq_del_cpu(unsigned int cpu)
>> >>  return 0;
>> >>  }
>> >>
>> >> +#ifdef CONFIG_ACPI
>> >>  static void print_PCT(struct xen_pct_register *ptr)
>> >>  {
>> >>  printk("\t_PCT: descriptor=%d, length=%d, space_id=%d, "
>> >> @@ -387,12 +401,14 @@ static void print_PCT(struct xen_pct_register *ptr)
>> >> ptr->descriptor, ptr->length, ptr->space_id, ptr->bit_width,
>> >> ptr->bit_offset, ptr->reserved, ptr->address);
>> >>  }
>> >> +#endif /* CONFIG_ACPI */
>> >
>> > same question
>>
>> definitely omit #ifdef
>>
>> >
>> >
>> >>  static void print_PSS(struct xen_processor_px *ptr, int count)
>> >>  {
>> >>  int i;
>> >>  printk("\t_PSS: state_count=%d\n", count);
>> >>  for (i=0; i> >> +#ifdef CONFIG_ACPI
>> >>  printk("\tState%d: %"PRId64"MHz %"PRId64"mW %"PRId64"us "
>> >> "%"PRId64"us %#"PRIx64" %#"PRIx64"\n",
>> >> i,
>> >> @@ -402,15 +418,26 @@ static void print_PSS(struct xen_processor_px *ptr, 
>> >> int count)
>> >> ptr[i].bus_master_latency,
>> >> ptr[i].control,
>> >> ptr[i].status);
>> >> +#else /* !CONFIG_ACPI */
>> >> +printk("\tState%d: %"PRId64"MHz %"PRId64"us\n",
>> >> +   i,
>> >> +   

[Xen-devel] [OSSTEST PATCH] Revert "make-flight etc.: drop arm64"

[Ian Jackson]

We have the laxtons back and they seem to be working.

This reverts commit 329ef52c9866b2a8608a598836b7d5813de1e979.

Signed-off-by: Ian Jackson 
---
 make-flight   | 2 +-
 make-hosts-flight | 2 +-
 mfi-common| 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/make-flight b/make-flight
index 76620c1..48fbc01 100755
--- a/make-flight
+++ b/make-flight
@@ -634,7 +634,7 @@ do_pv_debian_tests () {
   # Within each fmt we rotate through the list of arches
   # The starting list rotates once per ts, so that we try to
   # exercise each fmt on each arch family.
-  local fmtarches_outer="i386 armhf amd64"
+  local fmtarches_outer="i386 armhf amd64 arm64"
   local endfmt="do_pv_debian_tests-missing-ts-fmt-for-dom0arch="
 
   for ts in xl libvirt ; do
diff --git a/make-hosts-flight b/make-hosts-flight
index ff8c84a..d567085 100755
--- a/make-hosts-flight
+++ b/make-hosts-flight
@@ -25,7 +25,7 @@ hostflags=$3
 blessing=$4
 buildflight=$5
 
-: ${ALL_ARCHES:=amd64 i386 armhf}
+: ${ALL_ARCHES:=amd64 i386 arm64 armhf}
 : ${ALL_SUITES:=jessie stretch}
 
 : ${PERHOST_MAXWAIT:=2} # seconds
diff --git a/mfi-common b/mfi-common
index a86c87c..8a9546a 100644
--- a/mfi-common
+++ b/mfi-common
@@ -158,7 +158,7 @@ create_build_jobs () {
  BUILD_RUNVARS+=" build_lvextend_max=$BUILD_LVEXTEND_MAX "
   fi
 
-  for arch in ${BUILD_ARCHES- i386 amd64 armhf }; do
+  for arch in ${BUILD_ARCHES- i386 amd64 armhf arm64 }; do
 
 if [ "x$arch" = xdisable ]; then continue; fi
 
@@ -459,7 +459,7 @@ test_matrix_iterate () {
   ;;
   esac
 
-  for xenarch in ${TEST_ARCHES- i386 amd64 armhf } ; do
+  for xenarch in ${TEST_ARCHES- i386 amd64 armhf arm64 } ; do
 
 if [ "x$xenarch" = xdisable ]; then continue; fi
 
@@ -517,7 +517,7 @@ test_matrix_iterate () {
   *)  echo >&2 "kernkind ?  $kern"; exit 1 ;;
   esac
 
-  for dom0arch in i386 amd64 armhf; do
+  for dom0arch in i386 amd64 armhf arm64; do
 
 case ${xenarch}_${dom0arch} in
 amd64_amd64) ;;
-- 
2.1.4


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

Re: [Xen-devel] [OSSTEST PATCH] linux-arm-xen: Get from shared arm/linux.git xenbits tree

[Julien Grall]

Hi Ian,

On 05/12/17 18:41, Ian Jackson wrote:

Stefano Stabellini writes ("Re: [OSSTEST PATCH] linux-arm-xen: Get from shared 
arm/linux.git xenbits tree"):

On Tue, 5 Dec 2017, Julien Grall wrote:

Acked-by: Julien Grall 


Acked-by: Stefano Stabellini 


Thanks.  This queued for my next osstest push, which I expect to do
some time tomorrow.


Thank you! Once we get the push, I will update the tree to the latest 
4.9 (we are using an ancient version).


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [OSSTEST PATCH] linux-arm-xen: Get from shared arm/linux.git xenbits tree

[Ian Jackson]

Stefano Stabellini writes ("Re: [OSSTEST PATCH] linux-arm-xen: Get from shared 
arm/linux.git xenbits tree"):
> On Tue, 5 Dec 2017, Julien Grall wrote:
> > Acked-by: Julien Grall 
> 
> Acked-by: Stefano Stabellini 

Thanks.  This queued for my next osstest push, which I expect to do
some time tomorrow.

Ian.

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

[Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

[Julien Grall]

Hi all,

Even though it is an Arm failure, I have CCed x86 folks to get feedback 
on the approach. I have a WIP branch I could share if that interest people.


Few months ago, we noticed an heisenbug on jobs run by osstest on the 
cubietrucks (see [1]). From the log, we figured out that the guest vCPU 
0 is in data/prefetch abort state at early boot. I have been able to 
reproduce it reliably, although from the little information I have I 
think it is related to a cache issue because we don't trap cache 
maintenance instructions by set/way.


This is a set of 3 instructions (clean, clean & invalidate, invalidate) 
working on a given cache level by S/W. Because the OS is not allowed to 
infer the S/W to PA mapping, it can only use S/W to nuke the whole 
cache. "The expected usage of the cache maintenance that operate by 
set/way is associated with powerdown and powerup of caches, if this is 
required by the implementation" (see D3-2020 ARM DDI 0487B.b).


Those instructions will target a local processor and usually working in 
batch for nuking the cache. This means if the vCPU is migrated to 
another pCPU in the middle of the process, the cache may not be cleaned. 
This would result to data corruption and potential crash of the OS.


Thankfully, the Arm architecture offers a way to trap all the cache 
maintenance instructions by S/W (e.g HCR_EL2.TSW). Xen will need to set 
that bit and handle S/W.


The major question now is how to handle them. S/W instructions are 
difficult to virtualize (see ARMv7 ARM B1.14.4).


The suggested policy is based on the KVM one:
	- If we trap a S/W instructions, we enable VM trapping (e.g 
HCR_EL2.TVM) to detect cache being turned on/off, and do a full clean.

- We flush the caches on both caches being turned on and off.
- Once the caches are enabled, we stop trapping VM instructions.

Doing a full clean will require to go through the P2M and flush the 
entries one by one. At the moment, all the memory is mapped. As you can 
imagine flushing guest with hundreds of MB will take a very long time 
(Linux timeout during CPU bring).


Therefore, we need a way to limit the number of entries we need to 
flush. The suggested solution here is to introduce Populate On Demand 
(PoD) on Arm.


The guest would boot with no RAM mapped in stage-2 page-table. At every 
prefetch/data abort, the RAM would be mapped using preferably 2MB chunk 
or 4KB. This means that when S/W would be used, the number of entries 
mapped would be very limited. However, for safety, the flush should be 
preemptible.


For those been worry about the performance impact, I have looked at the 
current use of S/W instructions:

- Linux Arm64: The last used in the kernel was beginning of 2015
	- Linux Arm32: Still use S/W for boot and secondary CPU bring-up. No 
plan to change.
	- UEFI: A couple of use in UEFI, but I have heard they plan to remove 
them (need confirmation).


I haven't looked at all the OSes. However, given the Arm Arm clearly 
state S/W instructions are not easily virtualizable, I would expect 
guest OSes developers to try there best to limit the use of the 
instructions.


To limit the performance impact, we could introduce a guest option to 
tell whether the guest will use S/W. If it does plan to use S/W, PoD 
will be disabled.


Now regarding the hardware domain. At the moment, it has its RAM direct 
mapped. Supporting direct mapping in PoD will be quite a pain for a 
limited benefits (see why above). In that case I would suggest to impose 
vCPU pinning for the hardware domain if the S/W are expected to be used. 
Again, a command line option could be introduced here.


Any feedbacks on the approach will be welcomed.

Cheers,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-09/msg03191.html


--
Julien Grall

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

Re: [Xen-devel] [OSSTEST PATCH] linux-arm-xen: Get from shared arm/linux.git xenbits tree

[Stefano Stabellini]

On Tue, 5 Dec 2017, Julien Grall wrote:
> Hi Ian,
> 
> On 05/12/17 18:28, Ian Jackson wrote:
> > This drops the dependency on Stefano's personal git tree.
> > The osstest output branch remains unmoved.
> > 
> > CC: Stefano Stabellini 
> > CC: Julien Grall 
> > Signed-off-by: Ian Jackson 
> 
> Acked-by: Julien Grall 

Acked-by: Stefano Stabellini 


> Cheers,
> 
> > ---
> >   ap-common | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/ap-common b/ap-common
> > index bc7c03c..4576ac9 100644
> > --- a/ap-common
> > +++ b/ap-common
> > @@ -100,8 +100,8 @@ info_linux_tree () {
> > : ${TREE_LINUX_THIS:=${KERNEL_SCM}/torvalds/linux-2.6.git}
> > ;;
> > linux-arm-xen)
> > -   : ${TREE_LINUX_THIS:=${KERNEL_SCM}/sstabellini/xen.git}
> > -   : ${TREE_LINUX_ARM_THIS:=${KERNEL_SCM}/sstabellini/xen.git}
> > +   : ${TREE_LINUX_THIS:=git://xenbits.xen.org/arm/linux.git}
> > +   : ${TREE_LINUX_ARM_THIS:=git://xenbits.xen.org/arm/linux.git}
> > : ${TAG_LINUX_THIS:=linux-arm-xen}
> > : ${TAG_LINUX_ARM_THIS:=linux-arm-xen}
> > ;;
> > 
> 
> -- 
> Julien Grall
> 

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

Re: [Xen-devel] [OSSTEST PATCH] linux-arm-xen: Get from shared arm/linux.git xenbits tree

[Julien Grall]

Hi Ian,

On 05/12/17 18:28, Ian Jackson wrote:

This drops the dependency on Stefano's personal git tree.
The osstest output branch remains unmoved.

CC: Stefano Stabellini 
CC: Julien Grall 
Signed-off-by: Ian Jackson 


Acked-by: Julien Grall 

Cheers,


---
  ap-common | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ap-common b/ap-common
index bc7c03c..4576ac9 100644
--- a/ap-common
+++ b/ap-common
@@ -100,8 +100,8 @@ info_linux_tree () {
: ${TREE_LINUX_THIS:=${KERNEL_SCM}/torvalds/linux-2.6.git}
;;
linux-arm-xen)
-   : ${TREE_LINUX_THIS:=${KERNEL_SCM}/sstabellini/xen.git}
-   : ${TREE_LINUX_ARM_THIS:=${KERNEL_SCM}/sstabellini/xen.git}
+   : ${TREE_LINUX_THIS:=git://xenbits.xen.org/arm/linux.git}
+   : ${TREE_LINUX_ARM_THIS:=git://xenbits.xen.org/arm/linux.git}
: ${TAG_LINUX_THIS:=linux-arm-xen}
: ${TAG_LINUX_ARM_THIS:=linux-arm-xen}
;;



--
Julien Grall

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

[Xen-devel] [OSSTEST PATCH] linux-arm-xen: Get from shared arm/linux.git xenbits tree

[Ian Jackson]

This drops the dependency on Stefano's personal git tree.
The osstest output branch remains unmoved.

CC: Stefano Stabellini 
CC: Julien Grall 
Signed-off-by: Ian Jackson 
---
 ap-common | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ap-common b/ap-common
index bc7c03c..4576ac9 100644
--- a/ap-common
+++ b/ap-common
@@ -100,8 +100,8 @@ info_linux_tree () {
: ${TREE_LINUX_THIS:=${KERNEL_SCM}/torvalds/linux-2.6.git}
;;
linux-arm-xen)
-   : ${TREE_LINUX_THIS:=${KERNEL_SCM}/sstabellini/xen.git}
-   : ${TREE_LINUX_ARM_THIS:=${KERNEL_SCM}/sstabellini/xen.git}
+   : ${TREE_LINUX_THIS:=git://xenbits.xen.org/arm/linux.git}
+   : ${TREE_LINUX_ARM_THIS:=git://xenbits.xen.org/arm/linux.git}
: ${TAG_LINUX_THIS:=linux-arm-xen}
: ${TAG_LINUX_ARM_THIS:=linux-arm-xen}
;;
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] xen/pvcalls: check for xenbus_read() errors

[Stefano Stabellini]

On Tue, 5 Dec 2017, Dan Carpenter wrote:
> Smatch complains that "len" is uninitialized if xenbus_read() fails so
> let's add some error handling.
> 
> Signed-off-by: Dan Carpenter 

Reviewed-by: Stefano Stabellini 


> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index 40caa92bff33..afa3f1b5d807 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -1128,6 +1128,8 @@ static int pvcalls_front_probe(struct xenbus_device 
> *dev,
>   }
>  
>   versions = xenbus_read(XBT_NIL, dev->otherend, "versions", );
> + if (IS_ERR(versions))
> + return PTR_ERR(versions);
>   if (!len)
>   return -EINVAL;
>   if (strcmp(versions, "1")) {
> 

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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 seabios  df46d10c8a7b88eb82f3ceb2aa31782dee15593d
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   31 days
Failing since115733  2017-11-10 17:19:59 Z   25 days   41 attempts
Testing same since   116211  2017-11-16 00:20:45 Z   19 days   31 attempts


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

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



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

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

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

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


Not pushing.


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

tpm: Add support for TPM2 ACPI table

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

The latest version of the spec can be found here:

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

Signed-off-by: Stefan Berger 

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

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

Signed-off-by: Kevin O'Connor 

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

docs: Add sercon-port to Runtime_config.md documentation

Signed-off-by: Kevin O'Connor 

Re: [Xen-devel] linux-arm-xen branch, commit access, etc.

[Julien Grall]

Hi Ian,

On 05/12/17 17:42, Ian Jackson wrote:

Stefano Stabellini writes ("Re: [Xen-devel] linux-arm-xen branch, commit access, 
etc."):

let's create a /arm/linux.git tree on xenbits where both Julien and I
can push. The idea is that we'll try to use vanilla kernel releases but
we'll keep it around just in case we'll need special patches for
hardware support in the future. If it turns out that we don't actually
need it, we can get rid of it in a year or two.


No-one objected to this, so I have done it.  There's a bare repo
there.


Thank you!




We'll initialize /arm/linux.git based on the current linux-arm-xen
branch. /arm/linux.git will replace linux-arm-xen in OSSTest.


Let me know when you've populated it and I'll change osstest.


The tree has been populated based on Stefano's tree. Branch linux-arm-xen.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v17 19/19] osstest: use -DWITHOUT_AUTO_OBJ with FreeBSD release targets

[Ian Jackson]

Roger Pau Monné writes ("Re: [PATCH v17 19/19] osstest: use -DWITHOUT_AUTO_OBJ 
with FreeBSD release targets"):
> On Tue, Dec 05, 2017 at 03:09:47PM +, Ian Jackson wrote:
> > Is that why you're not just updating osstest to expect the new
> > behaviour ?
> 
> Yes, I think it's more sensible to restore the previous behavior so
> that the same osstest script can be used to build FreeBSD from the
> master branch or the stable branches.

OK, jolly good.

Acked-by: Ian Jackson 

Ian.

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

Re: [Xen-devel] [PATCH] x86/HVM: don't retain emulated insn cache when exiting back to guest

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 December 2017 17:19
> To: Paul Durrant 
> Cc: Julien Grall ; Andrew Cooper
> ; xen-devel  de...@lists.xenproject.org>
> Subject: RE: [PATCH] x86/HVM: don't retain emulated insn cache when
> exiting back to guest
> 
> >>> On 05.12.17 at 17:44,  wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 05 December 2017 16:14
> >> --- a/xen/arch/x86/hvm/emulate.c
> >> +++ b/xen/arch/x86/hvm/emulate.c
> >> @@ -2109,20 +2109,22 @@ static int _hvm_emulate_one(struct hvm_e
> >>
> >>  vio->mmio_retry = 0;
> >>
> >> -rc = x86_emulate(_ctxt->ctxt, ops);
> >> -
> >> -if ( rc == X86EMUL_OKAY && vio->mmio_retry )
> >> -rc = X86EMUL_RETRY;
> >> -if ( rc != X86EMUL_RETRY )
> >> +switch ( rc = x86_emulate(_ctxt->ctxt, ops) )
> >>  {
> >> +case X86EMUL_OKAY:
> >> +if ( vio->mmio_retry )
> >> +rc = X86EMUL_RETRY;
> >> +/* fall through */
> >> +default:
> >>  vio->mmio_cache_count = 0;
> >>  vio->mmio_insn_bytes = 0;
> >> -}
> >> -else
> >> -{
> >> +break;
> >> +
> >> +case X86EMUL_RETRY:
> >>  BUILD_BUG_ON(sizeof(vio->mmio_insn) < sizeof(hvmemul_ctxt-
> >> >insn_buf));
> >>  vio->mmio_insn_bytes = hvmemul_ctxt->insn_buf_bytes;
> >>  memcpy(vio->mmio_insn, hvmemul_ctxt->insn_buf, vio-
> >> >mmio_insn_bytes);
> >> +break;
> >
> > So, we have two distinct cases when X86EMUL_RETRY will be returned: the
> > former when we do want to return to guest part way through a rep
> operation,
> > and another when an MMIO has been sent for external emulation and we
> are
> > expecting a completion. The code looks correct so...
> >
> > Reviewed-by: Paul Durrant 
> 
> Thanks.
> 
> > ...but I wonder there should be two distinct return codes for these two
> > cases.
> 
> The question is - does any of the callers care about the difference.
> I think the relevant information has been recorded in data structures
> by the time we get here.

Technically, no I don't think the callers need to know but I've certainly got a 
bit tied in knots while trying to remember how this stuff is supposed to work 
so I was just hoping something could be done to make the 'don't return to guest 
because we need to retry mmio' and the 'return to guest even though want to 
retry a string operation' cases more obviously distinct.

  Paul

> 
> Jan


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

Re: [Xen-devel] [RFC PATCH 16/31] arm: add SMC wrapper that is compatible with SMCCC

[Stefano Stabellini]

On Tue, 5 Dec 2017, Volodymyr Babchuk wrote:
> Hi Stefano,
> 
> On Mon, Dec 04, 2017 at 06:30:13PM -0800, Stefano Stabellini wrote:
> > On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> > > From: Volodymyr Babchuk 
> > > 
> > > Existing SMC wrapper call_smc() allows only 4 parameters and
> > > returns only one value. This is enough for existing
> > > use in PSCI code, but TEE mediator will need a call that is
> > > fully compatible with ARM SMCCC.
> > > This patch adds this call for both arm32 and arm64.
> > > 
> > > There was similar patch by Edgar E. Iglesias ([1]), but looks
> > > like it is abandoned.
> > > 
> > > [1] 
> > > https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00636.html
> > > 
> > > CC: "Edgar E. Iglesias" 
> > > 
> > > Signed-off-by: Volodymyr Babchuk 
> > > CC: Stefano Stabellini 
> > > CC: Julien Grall 
> > > ---
> > >  xen/arch/arm/arm32/Makefile |  1 +
> > >  xen/arch/arm/arm32/smc.S| 32 
> > >  xen/arch/arm/arm64/Makefile |  1 +
> > >  xen/arch/arm/arm64/smc.S| 29 +
> > >  xen/include/asm-arm/processor.h |  4 
> > >  5 files changed, 67 insertions(+)
> > >  create mode 100644 xen/arch/arm/arm32/smc.S
> > >  create mode 100644 xen/arch/arm/arm64/smc.S
> > > 
> > > diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
> > > index 0ac254f..a2362f3 100644
> > > --- a/xen/arch/arm/arm32/Makefile
> > > +++ b/xen/arch/arm/arm32/Makefile
> > > @@ -8,6 +8,7 @@ obj-y += insn.o
> > >  obj-$(CONFIG_LIVEPATCH) += livepatch.o
> > >  obj-y += proc-v7.o proc-caxx.o
> > >  obj-y += smpboot.o
> > > +obj-y += smc.o
> > >  obj-y += traps.o
> > >  obj-y += vfp.o
> > >  
> > > diff --git a/xen/arch/arm/arm32/smc.S b/xen/arch/arm/arm32/smc.S
> > > new file mode 100644
> > > index 000..1cc9528
> > > --- /dev/null
> > > +++ b/xen/arch/arm/arm32/smc.S
> > > @@ -0,0 +1,32 @@
> > > +/*
> > > + * xen/arch/arm/arm32/smc.S
> > > + *
> > > + * Wrapper for Secure Monitors Calls
> > > + *
> > > + * 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 
> > > +
> > > +/*
> > > + * void call_smccc_smc(register_t a0, register_t a1, register_t a2,
> > > + * register_t a3, register_t a4, register_t a5,
> > > + * register_t a6, register_t a7, register_t res[4])
> > > + */
> > > +ENTRY(call_smccc_smc)
> > > +mov r12, sp
> > > +push{r4-r7}
> > > +ldm r12, {r4-r7}
> > > +smc #0
> > > +pop {r4-r7}
> > > +ldr r12, [sp, #(4 * 4)]
> > 
> > I haven't run this, but shouldn't it be:
> > 
> >   ldr r12, [sp, #20]
> > 
> > ?
> > 
> I took this code from linux (arch/arm/kernel/arm-smccc.h).
> But, why #20? There are 5 parameters on the stack: a4-a7 and res:
> a4:  [sp]
> a5:  [sp, #4]
> a6:  [sp, #8]
> a7:  [sp, #12]
> res: [sp, #16]
> 
> We need to save returnred values to res. So it looks right. Unless
> I'm terribly wrong :)

Ops, I miscounted.
When taking code from Linux, it would be nice to say where you took it
from. Also, you definitely need to add the right signed-off-by lines for
copyright reasons.

Cheers,

Stefano

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

Re: [Xen-devel] [PATCH] x86/HVM: don't retain emulated insn cache when exiting back to guest

[Jan Beulich]

>>> On 05.12.17 at 17:44,  wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 05 December 2017 16:14
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -2109,20 +2109,22 @@ static int _hvm_emulate_one(struct hvm_e
>> 
>>  vio->mmio_retry = 0;
>> 
>> -rc = x86_emulate(_ctxt->ctxt, ops);
>> -
>> -if ( rc == X86EMUL_OKAY && vio->mmio_retry )
>> -rc = X86EMUL_RETRY;
>> -if ( rc != X86EMUL_RETRY )
>> +switch ( rc = x86_emulate(_ctxt->ctxt, ops) )
>>  {
>> +case X86EMUL_OKAY:
>> +if ( vio->mmio_retry )
>> +rc = X86EMUL_RETRY;
>> +/* fall through */
>> +default:
>>  vio->mmio_cache_count = 0;
>>  vio->mmio_insn_bytes = 0;
>> -}
>> -else
>> -{
>> +break;
>> +
>> +case X86EMUL_RETRY:
>>  BUILD_BUG_ON(sizeof(vio->mmio_insn) < sizeof(hvmemul_ctxt-
>> >insn_buf));
>>  vio->mmio_insn_bytes = hvmemul_ctxt->insn_buf_bytes;
>>  memcpy(vio->mmio_insn, hvmemul_ctxt->insn_buf, vio-
>> >mmio_insn_bytes);
>> +break;
> 
> So, we have two distinct cases when X86EMUL_RETRY will be returned: the 
> former when we do want to return to guest part way through a rep operation, 
> and another when an MMIO has been sent for external emulation and we are 
> expecting a completion. The code looks correct so...
> 
> Reviewed-by: Paul Durrant 

Thanks.

> ...but I wonder there should be two distinct return codes for these two 
> cases.

The question is - does any of the callers care about the difference.
I think the relevant information has been recorded in data structures
by the time we get here.

Jan


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

Re: [Xen-devel] [RFC PATCH 16/31] arm: add SMC wrapper that is compatible with SMCCC

[Oleksandr Tyshchenko]

On Tue, Dec 5, 2017 at 7:08 PM, Volodymyr Babchuk
 wrote:
> Hi Julien,
Hi Julien, Volodymyr.

>
> On 05.12.17 16:58, Julien Grall wrote:
>>
>> Hi Oleksandr,
>>
>> On 09/11/17 17:10, Oleksandr Tyshchenko wrote:
>>>
>>> From: Volodymyr Babchuk 
>>>
>>> Existing SMC wrapper call_smc() allows only 4 parameters and
>>> returns only one value. This is enough for existing
>>> use in PSCI code, but TEE mediator will need a call that is
>>> fully compatible with ARM SMCCC.
>>> This patch adds this call for both arm32 and arm64.
>>>
>>> There was similar patch by Edgar E. Iglesias ([1]), but looks
>>> like it is abandoned.
>>>
>>> [1]
>>> https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00636.html
>>>
>>> CC: "Edgar E. Iglesias" 
>>>
>>> Signed-off-by: Volodymyr Babchuk 
>>> CC: Stefano Stabellini 
>>> CC: Julien Grall 
>>
>>
>> This patch was sent by Volodymyr a month ago (see [2]) and I had comments
>> on it. I would appreciate if you address them.
>
> I can address your comments and send it as a separate patch to the ML.
That would be really great! I will be able to apply and test on ARM64.

> Will it be fine?
>
> WBR
> --
> Volodymyr



-- 
Regards,

Oleksandr Tyshchenko

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

Re: [Xen-devel] [RFC PATCH 16/31] arm: add SMC wrapper that is compatible with SMCCC

[Julien Grall]

On 05/12/17 17:08, Volodymyr Babchuk wrote:

Hi Julien,

On 05.12.17 16:58, Julien Grall wrote:

Hi Oleksandr,

On 09/11/17 17:10, Oleksandr Tyshchenko wrote:

From: Volodymyr Babchuk 

Existing SMC wrapper call_smc() allows only 4 parameters and
returns only one value. This is enough for existing
use in PSCI code, but TEE mediator will need a call that is
fully compatible with ARM SMCCC.
This patch adds this call for both arm32 and arm64.

There was similar patch by Edgar E. Iglesias ([1]), but looks
like it is abandoned.

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00636.html 



CC: "Edgar E. Iglesias" 

Signed-off-by: Volodymyr Babchuk 
CC: Stefano Stabellini 
CC: Julien Grall 


This patch was sent by Volodymyr a month ago (see [2]) and I had 
comments on it. I would appreciate if you address them.

I can address your comments and send it as a separate patch to the ML.
Will it be fine?


Sure.



WBR


--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH 16/31] arm: add SMC wrapper that is compatible with SMCCC

[Volodymyr Babchuk]

Hi Julien,

On 05.12.17 16:58, Julien Grall wrote:

Hi Oleksandr,

On 09/11/17 17:10, Oleksandr Tyshchenko wrote:

From: Volodymyr Babchuk 

Existing SMC wrapper call_smc() allows only 4 parameters and
returns only one value. This is enough for existing
use in PSCI code, but TEE mediator will need a call that is
fully compatible with ARM SMCCC.
This patch adds this call for both arm32 and arm64.

There was similar patch by Edgar E. Iglesias ([1]), but looks
like it is abandoned.

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00636.html 



CC: "Edgar E. Iglesias" 

Signed-off-by: Volodymyr Babchuk 
CC: Stefano Stabellini 
CC: Julien Grall 


This patch was sent by Volodymyr a month ago (see [2]) and I had 
comments on it. I would appreciate if you address them.

I can address your comments and send it as a separate patch to the ML.
Will it be fine?

WBR
--
Volodymyr

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

Re: [Xen-devel] [PATCH] x86/HVM: don't retain emulated insn cache when exiting back to guest

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 December 2017 16:14
> To: xen-devel 
> Cc: Julien Grall ; Andrew Cooper
> ; Paul Durrant 
> Subject: [PATCH] x86/HVM: don't retain emulated insn cache when exiting
> back to guest
> 
> vio->mmio_retry is being set when a repeated string insn is being split
> up. In that case we'll exit to the guest, expecting immediate re-entry.
> Interruptions, however, may be serviced by the guest before re-entry
> from the repeated string insn. Any emulation needed in the course of
> handling the interruption must not fetch from the internally maintained
> cache.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -2109,20 +2109,22 @@ static int _hvm_emulate_one(struct hvm_e
> 
>  vio->mmio_retry = 0;
> 
> -rc = x86_emulate(_ctxt->ctxt, ops);
> -
> -if ( rc == X86EMUL_OKAY && vio->mmio_retry )
> -rc = X86EMUL_RETRY;
> -if ( rc != X86EMUL_RETRY )
> +switch ( rc = x86_emulate(_ctxt->ctxt, ops) )
>  {
> +case X86EMUL_OKAY:
> +if ( vio->mmio_retry )
> +rc = X86EMUL_RETRY;
> +/* fall through */
> +default:
>  vio->mmio_cache_count = 0;
>  vio->mmio_insn_bytes = 0;
> -}
> -else
> -{
> +break;
> +
> +case X86EMUL_RETRY:
>  BUILD_BUG_ON(sizeof(vio->mmio_insn) < sizeof(hvmemul_ctxt-
> >insn_buf));
>  vio->mmio_insn_bytes = hvmemul_ctxt->insn_buf_bytes;
>  memcpy(vio->mmio_insn, hvmemul_ctxt->insn_buf, vio-
> >mmio_insn_bytes);
> +break;

So, we have two distinct cases when X86EMUL_RETRY will be returned: the former 
when we do want to return to guest part way through a rep operation, and 
another when an MMIO has been sent for external emulation and we are expecting 
a completion. The code looks correct so...

Reviewed-by: Paul Durrant 

...but I wonder there should be two distinct return codes for these two cases.

>  }
> 
>  if ( hvmemul_ctxt->ctxt.retire.singlestep )
> 
> 


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

[Xen-devel] [linux-linus test] 116840: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
115643
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 115643
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 115643
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 115643
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-xl-pvhv2-amd  7 xen-bootfail REGR. vs. 115643
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-xl-qemuu-win10-i386  7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
115643
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 115643
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 115643
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 115643
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 115643
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-libvirt-qcow2  7 xen-bootfail REGR. vs. 115643
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail REGR. vs. 115643
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 115643
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 115643
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 115643
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
115643
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 115643
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 115643
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 115643
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 115643
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 115643
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-xl-qemut-win7-amd64  7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-xl-credit2   7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 115643
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 115643
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-examine  8 reboot   fail REGR. vs. 115643

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  7 xen-boot fail REGR. vs. 115643

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 115643
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115643
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115643
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 115643
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 115643
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115643
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 115643
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 115643
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 

Re: [Xen-devel] [PATCH] xen/pvcalls: check for xenbus_read() errors

[Juergen Gross]

On 05/12/17 15:38, Dan Carpenter wrote:
> Smatch complains that "len" is uninitialized if xenbus_read() fails so
> let's add some error handling.
> 
> Signed-off-by: Dan Carpenter 

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH 2/2] xen/pvcalls: Fix a check in pvcalls_front_remove()

[Juergen Gross]

On 05/12/17 15:38, Dan Carpenter wrote:
> bedata->ref can't be less than zero because it's unsigned.  This affects
> certain error paths in probe.  We first set ->ref = -1 and then we set
> it to a valid value later.
> 
> Fixes: 219681909913 ("xen/pvcalls: connect to the backend")
> Signed-off-by: Dan Carpenter 

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH v17 19/19] osstest: use -DWITHOUT_AUTO_OBJ with FreeBSD release targets

[Roger Pau Monné]

On Tue, Dec 05, 2017 at 03:09:47PM +, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v17 19/19] osstest: use -DWITHOUT_AUTO_OBJ 
> with FreeBSD release targets"):
> > Due to a recent FreeBSD change the default output directory of the release
> > targets is changed to the object directory instead of the source
> > directory. Use WITHOUT_AUTO_OBJ to restore previous behavior. This is
> > harmless if used with previous versions, it will be ignored.
> 
> So the purpose of this is to make both versions of the build do the
> same thing, so osstest doesn't have to care ?
> 
> Is that why you're not just updating osstest to expect the new
> behaviour ?

Yes, I think it's more sensible to restore the previous behavior so
that the same osstest script can be used to build FreeBSD from the
master branch or the stable branches.

Roger.

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

Re: [Xen-devel] [for-4.10] Re: [PATCH v2] tools/libxl: mark special pages as reserved in e820 map for PVH

[Juergen Gross]

On 05/12/17 16:23, Julien Grall wrote:
> Hi Juergen,
> 
> On 04/12/17 15:49, Juergen Gross wrote:
>> On 21/11/17 12:06, Juergen Gross wrote:
>>> The "special pages" for PVH guests include the frames for console and
>>> Xenstore ring buffers. Those have to be marked as "Reserved" in the
>>> guest's E820 map, as otherwise conflicts might arise later e.g. when
>>> hotplugging memory into the guest.
>>>
>>> Signed-off-by: Juergen Gross 
>>> ---
>>> This is a bugfix for PVH guests. Please consider for 4.10.
>>
>> Ping?
> 
> I was waiting an ack from tools maintainers before looking for a release
> perspective.
> 
> I would recommend to tag your patch is 4.10 to help reviewers prioritize
> review on your patch. I have done it now.
> 
> I am looking at releasing Xen 4.10 in the next few days. Can you explain
> the pros/cons of this patch?

Pros: PVH guests with 4GB of memory or more will work. :-)
Cons: There is a more general solution (as Roger pointed out), but
  this would require much more work.


Juergen

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

Re: [Xen-devel] [PATCH v6 00/16] xen: common: rbtree: ported updates from Linux tree

[Praveen Kumar]

Hi All,

Can you please provide your comments over the changes shared. Thanks in advance.

Regards,

~Praveen.

On Tue, Nov 21, 2017 at 8:49 PM, Praveen Kumar  wrote:
> Hi All,
>
> The patch imports the changes and updates of the rbtree implementaiton
> from Linux tree. But since, the only current implementation is with tmem.c,
> which am not much aware off much and therefore, was unable to test the changes
> thoroughly. Having said that, I do have plans of adding futher code changes
> which will be using rb-tree more in credit2 scheduler and that will help in
> further testing the same.
>
> I have not imported augmented, rcu and patches which added new rbtree
> functionality, as there was no specific requirement for current planned
> implementation.
>
> Below are the categorized Linux commit versions which are not imported :
>
> Augmented rbtree :
> 14b94af0b251a2c80885b60538166fb7d04a642e
> 9d9e6f9703bbd642f3f2f807e6aaa642a4cbcec9
> 9c079add0d0f45220f4bb37febf0621137ec2d38
> 3cb7a56344ca45ee56d71c5f8fe9f922306bff1f
> f231aebfc4cae2f6ed27a46a31e2630909513d77
>
>
> Add postorder iteration functions:
> 9dee5c51516d2c3fff22633c1272c5652e68075a
>
> RCU related implementation :
> d72da4a4d973d8a0a0d3c97e7cdebf287fbe3a99
> c1adf20052d80f776849fa2c1acb472cdeb7786c
> ce093a04543c403d52c1a5788d8cb92e47453aba
>
> Please share your inputs. Thanks in advance.
>
> Regards,
>
> ~Praveen.
>
> Praveen Kumar (16):
>   rbtree: remove redundant if()-condition in rb_erase()
>   rbtree: empty nodes have no color
>   rbtree: move some implementation details from rbtree.h to rbtree.c
>   rbtree: break out of rb_insert_color loop after tree rotation
>   rbtree: adjust root color in rb_insert_color() only when necessary
>   rbtree: low level optimizations in rb_insert_color()
>   rbtree: adjust node color in __rb_erase_color() only when necessary
>   rbtree: optimize case selection logic in __rb_erase_color()
>   rbtree: low level optimizations in __rb_erase_color()
>   rbtree: coding style adjustments
>   rbtree: optimize fetching of sibling node
>   rbtree: add __rb_change_child() helper function
>   rbtree: place easiest case first in rb_erase()
>   rbtree: handle 1-child recoloring in rb_erase() instead of
> rb_erase_color()
>   rbtree: low level optimizations in rb_erase()
>   rbtree: fix typo in comment of rb_insert_color
>
>  xen/common/rbtree.c  | 646 
> ++-
>  xen/include/xen/rbtree.h |  38 +--
>  2 files changed, 428 insertions(+), 256 deletions(-)
>
> ---
> Updated set of changes catering the comments provided.
> 2.13.1
>

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

[Xen-devel] [PATCH] x86/HVM: don't retain emulated insn cache when exiting back to guest

[Jan Beulich]

vio->mmio_retry is being set when a repeated string insn is being split
up. In that case we'll exit to the guest, expecting immediate re-entry.
Interruptions, however, may be serviced by the guest before re-entry
from the repeated string insn. Any emulation needed in the course of
handling the interruption must not fetch from the internally maintained
cache.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2109,20 +2109,22 @@ static int _hvm_emulate_one(struct hvm_e
 
 vio->mmio_retry = 0;
 
-rc = x86_emulate(_ctxt->ctxt, ops);
-
-if ( rc == X86EMUL_OKAY && vio->mmio_retry )
-rc = X86EMUL_RETRY;
-if ( rc != X86EMUL_RETRY )
+switch ( rc = x86_emulate(_ctxt->ctxt, ops) )
 {
+case X86EMUL_OKAY:
+if ( vio->mmio_retry )
+rc = X86EMUL_RETRY;
+/* fall through */
+default:
 vio->mmio_cache_count = 0;
 vio->mmio_insn_bytes = 0;
-}
-else
-{
+break;
+
+case X86EMUL_RETRY:
 BUILD_BUG_ON(sizeof(vio->mmio_insn) < sizeof(hvmemul_ctxt->insn_buf));
 vio->mmio_insn_bytes = hvmemul_ctxt->insn_buf_bytes;
 memcpy(vio->mmio_insn, hvmemul_ctxt->insn_buf, vio->mmio_insn_bytes);
+break;
 }
 
 if ( hvmemul_ctxt->ctxt.retire.singlestep )




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

Re: [Xen-devel] [RFC] WIP: optee: add OP-TEE mediator

[Stuart Yoder]

There are limit on pCPUs, though. But this is not a problem, because
XEN scheduler will decide which guest will access OP-TEE right now.
OP-TEE don't have own scheduler at all, by the way. It is scheduled
by normal world.


Do you mind to give a bit more explanation here? Do you plan to add knowledge 
of OP-TEE in the scheduler?


Regarding scheduling-- OP-TEE runs with interrupts enabled (generally).  So 
when an SMC
is in process in OP-TEE and the normal OS or hypervisor timer tick fires, 
OP-TEE halts
the current the in-progress thread, saves states, and returns to the normal 
world to
let the normal world timer interrupt handler and scheduler do its normal thing. 
 Eventually
when the normal world thread is re-scheduled and the in-progress thread 
restarts the
SMC.  That process continues until the SMC is completely done. So the OS/VMM 
scheduler
needs no awareness of OP-TEE since OP-TEE is cooperating with the normal world.

Stuart



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

[Xen-devel] [OSSTEST PATCH] README.dev: Say how to do a commissioning flight for a new architecture

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 README.dev | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/README.dev b/README.dev
index dc0dafd..37e2953 100644
--- a/README.dev
+++ b/README.dev
@@ -132,6 +132,13 @@ If that works, a more thorough test:
 This should show no regressions.  (Or, at least, none that are a cause
 for concern.)
 
+For a new architecture, there may not be an existing flight with
+suitable jobs.  In that case, something like this can be useful:
+
+ $ OSSTEST_BLESSING=commission-mudcake DAILY_BRANCH_PREEXEC_HOOK=false 
OSSTEST_BASELINES_ONLY=y ./cr-daily-branch xen-unstable
+
+You'll need to fish the flight number out of the debug spew.
+
 Bless
 -
 
-- 
2.1.4


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

Re: [Xen-devel] [xen-unstable test] 116832: regressions - FAIL [and 1 more messages]

[Andrew Cooper]

On 05/12/17 15:31, Jan Beulich wrote:
 On 05.12.17 at 16:05,  wrote:
>> Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 116832: regressions 
>> - 
>> FAIL"):
>>> This is a blue screen, recurring, and has first been reported in flight
>>> 116779, i.e. was likely introduced in the batch ending in commit
>>> 4cd0fad645. Among those the most likely candidates appear to be
>>> the SVM changes (the failures are all on AMD hardware). The logs
>>> there also have huge amounts of "Unexpected nested vmexit",
>>> albeit not directly connected with the failed test afaict.
>> Ian Jackson writes ("Re: [xen-unstable test] 116832: regressions - FAIL"):
>>> This is the expected Windows failure.  Force pushed.
>> Oops.  Sorry about that.
>>
>> I think this goes to show that (i) leaving known failures languishing
>> for months and expecting them to be force pushed results in human
>> error (ii) I should read the whole email thread first.
> Oh, that's pretty unfortunate. I think we'll then need a custom flight
> tied to the box that this failure occurred on, to have a way to tell
> whether the fix I'm about to prepare has actually helped, the more
> that the same issue is presumably also present on the 4.10 branch.
> Thing is that newer AMD hardware (with decode assist) doesn't
> appear to demonstrate the misbehavior, and for some reason it also
> doesn't show on Intel systems.
>
> I've spent quite a bit of time to repro this on my old AMD box, but the
> distro on there is just too old to be able to start a suitable Windows
> guest (part(?) of the reason being that scripts in /etc/xen/scripts
> appear to get invoked alongside the ones from the separate unstable
> install tree, and at some point I then decided to give up trying to hack
> things up so they would work together again).

If you've got a provisional patch, I can get some testing organised on
newer and older hardware.

~Andrew

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

Re: [Xen-devel] linux-arm-xen branch, commit access, etc.

[Julien Grall]

Hi,

Ping? This is going to be very helpful for bringing up osstest on Thunder-X.

Cheers,

On 02/11/17 13:34, Julien Grall wrote:

Hi,

On 23/10/17 22:33, Stefano Stabellini wrote:

On Fri, 20 Oct 2017, Julien Grall wrote:
   Julien, do you think we need to keep a special linux tree 
around for Xen
   on ARM testing in OSSTest or we can start using vanilla kernel 
releases?
   I would love to get rid of it, if you know of any reasons why 
we have to

   keep it, this is the time to speak :-)


I think it would be better to keep aroundSome platform may be 
available before the code is merged.


Sure.


Ian,

let's create a /arm/linux.git tree on xenbits where both Julien and I
can push. The idea is that we'll try to use vanilla kernel releases but
we'll keep it around just in case we'll need special patches for
hardware support in the future. If it turns out that we don't actually
need it, we can get rid of it in a year or two.

We'll initialize /arm/linux.git based on the current linux-arm-xen
branch. /arm/linux.git will replace linux-arm-xen in OSSTest.

Sounds good?


I don't mind as long as I have access to the arm linux tree. Ian do you 
have any opinions?


Cheers,



--
Julien Grall

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

Re: [Xen-devel] [xen-unstable test] 116832: regressions - FAIL [and 1 more messages]

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 116832: regressions - 
FAIL [and 1 more messages]"):
> Oh, that's pretty unfortunate. I think we'll then need a custom flight
> tied to the box that this failure occurred on, to have a way to tell
> whether the fix I'm about to prepare has actually helped,

Even though it is no longer regarded as a regression by osstest, the
job will still be host-sticky.  So if you commit a patch to staging,
you should be able to see whether it has helped.

Ian.

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

[Xen-devel] [for-4.10] Re: [PATCH v2] tools/libxl: mark special pages as reserved in e820 map for PVH

[Ian Jackson]

Julien Grall writes ("[for-4.10] Re: [Xen-devel] [PATCH v2] tools/libxl: mark 
special pages as reserved in e820 map for PVH"):
> I would recommend to tag your patch is 4.10 to help reviewers prioritize 
> review on your patch. I have done it now.

Thanks.  Looking at the thread, I would have liked to see an answer to
this comment by Roger:

| Albeit I would also prefer this to not be PVH specific. Ideally I
| would like both PVH and HVM to share the logic to mark the reserved
| regions in the memory map. I guess this can be fixed afterwards by
| moving away this logic from hvmloader and handling the creation of
| the memory map for both HVM and PVH in libxl.

But it seems to be a bugfix and has had review from the x86
perspective, so:

Acked-by: Ian Jackson 


If anyone is feeling up to doing some improvement, I would like to see
a rework of the algorithm to avoid this error-prone duplicated-
information construction:

  +/* Add mmio entry for PVH. */
  +if (dom->mmio_size && d_config->b_info.type == LIBXL_DOMAIN_TYPE_PVH)
  +e820_entries++;

  @@ -564,6 +567,14 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,

  +/* mmio area */
  +if (dom->mmio_size && d_config->b_info.type == LIBXL_DOMAIN_TYPE_PVH) {
  +e820[nr].addr = dom->mmio_start;
  +e820[nr].size = dom->mmio_size;
  +e820[nr].type = E820_RESERVED;
  +nr++;
  +}
  +

That is, there should be no separate pre-calculation of the number of
entries.  There would have to be an expanding array instead.

Regards,
Ian.

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

Re: [Xen-devel] [RFC PATCH 16/31] arm: add SMC wrapper that is compatible with SMCCC

[Volodymyr Babchuk]

Hi Stefano,

On Mon, Dec 04, 2017 at 06:30:13PM -0800, Stefano Stabellini wrote:
> On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> > From: Volodymyr Babchuk 
> > 
> > Existing SMC wrapper call_smc() allows only 4 parameters and
> > returns only one value. This is enough for existing
> > use in PSCI code, but TEE mediator will need a call that is
> > fully compatible with ARM SMCCC.
> > This patch adds this call for both arm32 and arm64.
> > 
> > There was similar patch by Edgar E. Iglesias ([1]), but looks
> > like it is abandoned.
> > 
> > [1] 
> > https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00636.html
> > 
> > CC: "Edgar E. Iglesias" 
> > 
> > Signed-off-by: Volodymyr Babchuk 
> > CC: Stefano Stabellini 
> > CC: Julien Grall 
> > ---
> >  xen/arch/arm/arm32/Makefile |  1 +
> >  xen/arch/arm/arm32/smc.S| 32 
> >  xen/arch/arm/arm64/Makefile |  1 +
> >  xen/arch/arm/arm64/smc.S| 29 +
> >  xen/include/asm-arm/processor.h |  4 
> >  5 files changed, 67 insertions(+)
> >  create mode 100644 xen/arch/arm/arm32/smc.S
> >  create mode 100644 xen/arch/arm/arm64/smc.S
> > 
> > diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
> > index 0ac254f..a2362f3 100644
> > --- a/xen/arch/arm/arm32/Makefile
> > +++ b/xen/arch/arm/arm32/Makefile
> > @@ -8,6 +8,7 @@ obj-y += insn.o
> >  obj-$(CONFIG_LIVEPATCH) += livepatch.o
> >  obj-y += proc-v7.o proc-caxx.o
> >  obj-y += smpboot.o
> > +obj-y += smc.o
> >  obj-y += traps.o
> >  obj-y += vfp.o
> >  
> > diff --git a/xen/arch/arm/arm32/smc.S b/xen/arch/arm/arm32/smc.S
> > new file mode 100644
> > index 000..1cc9528
> > --- /dev/null
> > +++ b/xen/arch/arm/arm32/smc.S
> > @@ -0,0 +1,32 @@
> > +/*
> > + * xen/arch/arm/arm32/smc.S
> > + *
> > + * Wrapper for Secure Monitors Calls
> > + *
> > + * 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 
> > +
> > +/*
> > + * void call_smccc_smc(register_t a0, register_t a1, register_t a2,
> > + * register_t a3, register_t a4, register_t a5,
> > + * register_t a6, register_t a7, register_t res[4])
> > + */
> > +ENTRY(call_smccc_smc)
> > +mov r12, sp
> > +push{r4-r7}
> > +ldm r12, {r4-r7}
> > +smc #0
> > +pop {r4-r7}
> > +ldr r12, [sp, #(4 * 4)]
> 
> I haven't run this, but shouldn't it be:
> 
>   ldr r12, [sp, #20]
> 
> ?
> 
I took this code from linux (arch/arm/kernel/arm-smccc.h).
But, why #20? There are 5 parameters on the stack: a4-a7 and res:
a4:  [sp]
a5:  [sp, #4]
a6:  [sp, #8]
a7:  [sp, #12]
res: [sp, #16]

We need to save returnred values to res. So it looks right. Unless
I'm terribly wrong :)

> > +stm r12, {r0-r3}
> > +bx  lr
> > diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
> > index 149b6b3..7831dc1 100644
> > --- a/xen/arch/arm/arm64/Makefile
> > +++ b/xen/arch/arm/arm64/Makefile
> > @@ -8,5 +8,6 @@ obj-y += entry.o
> >  obj-y += insn.o
> >  obj-$(CONFIG_LIVEPATCH) += livepatch.o
> >  obj-y += smpboot.o
> > +obj-y += smc.o
> >  obj-y += traps.o
> >  obj-y += vfp.o
> > diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S
> > new file mode 100644
> > index 000..aa44fba
> > --- /dev/null
> > +++ b/xen/arch/arm/arm64/smc.S
> > @@ -0,0 +1,29 @@
> > +/*
> > + * xen/arch/arm/arm64/smc.S
> > + *
> > + * Wrapper for Secure Monitors Calls
> > + *
> > + * 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 
> > +
> > +/*
> > + * void call_smccc_smc(register_t a0, register_t a1, register_t a2,
> > + * register_t a3, register_t a4, register_t a5,
> > + * register_t a6, register_t a7, register_t res[4])
> > + */
> > +ENTRY(call_smccc_smc)
> > +

Re: [Xen-devel] [xen-unstable test] 116832: regressions - FAIL [and 1 more messages]

[Jan Beulich]

>>> On 05.12.17 at 16:05,  wrote:
> Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 116832: regressions 
> - 
> FAIL"):
>> This is a blue screen, recurring, and has first been reported in flight
>> 116779, i.e. was likely introduced in the batch ending in commit
>> 4cd0fad645. Among those the most likely candidates appear to be
>> the SVM changes (the failures are all on AMD hardware). The logs
>> there also have huge amounts of "Unexpected nested vmexit",
>> albeit not directly connected with the failed test afaict.
> 
> Ian Jackson writes ("Re: [xen-unstable test] 116832: regressions - FAIL"):
>> This is the expected Windows failure.  Force pushed.
> 
> Oops.  Sorry about that.
> 
> I think this goes to show that (i) leaving known failures languishing
> for months and expecting them to be force pushed results in human
> error (ii) I should read the whole email thread first.

Oh, that's pretty unfortunate. I think we'll then need a custom flight
tied to the box that this failure occurred on, to have a way to tell
whether the fix I'm about to prepare has actually helped, the more
that the same issue is presumably also present on the 4.10 branch.
Thing is that newer AMD hardware (with decode assist) doesn't
appear to demonstrate the misbehavior, and for some reason it also
doesn't show on Intel systems.

I've spent quite a bit of time to repro this on my old AMD box, but the
distro on there is just too old to be able to start a suitable Windows
guest (part(?) of the reason being that scripts in /etc/xen/scripts
appear to get invoked alongside the ones from the separate unstable
install tree, and at some point I then decided to give up trying to hack
things up so they would work together again).

Jan


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

[Xen-devel] [for-4.10] Re: [PATCH v2] tools/libxl: mark special pages as reserved in e820 map for PVH

[Julien Grall]

Hi Juergen,

On 04/12/17 15:49, Juergen Gross wrote:

On 21/11/17 12:06, Juergen Gross wrote:

The "special pages" for PVH guests include the frames for console and
Xenstore ring buffers. Those have to be marked as "Reserved" in the
guest's E820 map, as otherwise conflicts might arise later e.g. when
hotplugging memory into the guest.

Signed-off-by: Juergen Gross 
---
This is a bugfix for PVH guests. Please consider for 4.10.


Ping?


I was waiting an ack from tools maintainers before looking for a release
perspective.

I would recommend to tag your patch is 4.10 to help reviewers prioritize 
review on your patch. I have done it now.


I am looking at releasing Xen 4.10 in the next few days. Can you explain 
the pros/cons of this patch?


Cheers,




---
  tools/libxl/libxl_x86.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 5f91fe4f92..d82013f6ed 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -530,6 +530,9 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
  if (d_config->rdms[i].policy != LIBXL_RDM_RESERVE_POLICY_INVALID)
  e820_entries++;
  
+/* Add mmio entry for PVH. */

+if (dom->mmio_size && d_config->b_info.type == LIBXL_DOMAIN_TYPE_PVH)
+e820_entries++;
  
  /* If we should have a highmem range. */

  if (highmem_size)
@@ -564,6 +567,14 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
  nr++;
  }
  
+/* mmio area */

+if (dom->mmio_size && d_config->b_info.type == LIBXL_DOMAIN_TYPE_PVH) {
+e820[nr].addr = dom->mmio_start;
+e820[nr].size = dom->mmio_size;
+e820[nr].type = E820_RESERVED;
+nr++;
+}
+
  for (i = 0; i < MAX_ACPI_MODULES; i++) {
  if (dom->acpi_modules[i].length) {
  e820[nr].addr = dom->acpi_modules[i].guest_addr_out & ~(page_size 
- 1);




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



--
Julien Grall

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

Re: [Xen-devel] [PATCH v17 19/19] osstest: use -DWITHOUT_AUTO_OBJ with FreeBSD release targets

[Ian Jackson]

Roger Pau Monne writes ("[PATCH v17 19/19] osstest: use -DWITHOUT_AUTO_OBJ with 
FreeBSD release targets"):
> Due to a recent FreeBSD change the default output directory of the release
> targets is changed to the object directory instead of the source
> directory. Use WITHOUT_AUTO_OBJ to restore previous behavior. This is
> harmless if used with previous versions, it will be ignored.

So the purpose of this is to make both versions of the build do the
same thing, so osstest doesn't have to care ?

Is that why you're not just updating osstest to expect the new
behaviour ?

Ian.

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

Re: [Xen-devel] [PATCH v17 17/19] osstest: remove the loader timeout from the install image

[Ian Jackson]

Roger Pau Monne writes ("[PATCH v17 17/19] osstest: remove the loader timeout 
from the install image"):
> When the FreeBSD installer is booted on the godello{0/1} boxes it
> receives spurious key strokes. This doesn't happen so far when booted
> from disk, or with any other boxes.
> 
> In order to cope with this remove the loader timeout on the install
> image. Note that failure to boot will still drop the loader into a
> manual prompt.

I don't feel qualified to review this and it is confined to FreeBSD
bootloader stuff, so

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [RFC PATCH 16/31] arm: add SMC wrapper that is compatible with SMCCC

[Julien Grall]

Hi Oleksandr,

On 09/11/17 17:10, Oleksandr Tyshchenko wrote:

From: Volodymyr Babchuk 

Existing SMC wrapper call_smc() allows only 4 parameters and
returns only one value. This is enough for existing
use in PSCI code, but TEE mediator will need a call that is
fully compatible with ARM SMCCC.
This patch adds this call for both arm32 and arm64.

There was similar patch by Edgar E. Iglesias ([1]), but looks
like it is abandoned.

[1] https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00636.html

CC: "Edgar E. Iglesias" 

Signed-off-by: Volodymyr Babchuk 
CC: Stefano Stabellini 
CC: Julien Grall 


This patch was sent by Volodymyr a month ago (see [2]) and I had 
comments on it. I would appreciate if you address them.


Cheers,

[2] 
https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg01881.html



---
  xen/arch/arm/arm32/Makefile |  1 +
  xen/arch/arm/arm32/smc.S| 32 
  xen/arch/arm/arm64/Makefile |  1 +
  xen/arch/arm/arm64/smc.S| 29 +
  xen/include/asm-arm/processor.h |  4 
  5 files changed, 67 insertions(+)
  create mode 100644 xen/arch/arm/arm32/smc.S
  create mode 100644 xen/arch/arm/arm64/smc.S

diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 0ac254f..a2362f3 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -8,6 +8,7 @@ obj-y += insn.o
  obj-$(CONFIG_LIVEPATCH) += livepatch.o
  obj-y += proc-v7.o proc-caxx.o
  obj-y += smpboot.o
+obj-y += smc.o
  obj-y += traps.o
  obj-y += vfp.o
  
diff --git a/xen/arch/arm/arm32/smc.S b/xen/arch/arm/arm32/smc.S

new file mode 100644
index 000..1cc9528
--- /dev/null
+++ b/xen/arch/arm/arm32/smc.S
@@ -0,0 +1,32 @@
+/*
+ * xen/arch/arm/arm32/smc.S
+ *
+ * Wrapper for Secure Monitors Calls
+ *
+ * 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 
+
+/*
+ * void call_smccc_smc(register_t a0, register_t a1, register_t a2,
+ * register_t a3, register_t a4, register_t a5,
+ * register_t a6, register_t a7, register_t res[4])
+ */
+ENTRY(call_smccc_smc)
+mov r12, sp
+push{r4-r7}
+ldm r12, {r4-r7}
+smc #0
+pop {r4-r7}
+ldr r12, [sp, #(4 * 4)]
+stm r12, {r0-r3}
+bx  lr
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 149b6b3..7831dc1 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -8,5 +8,6 @@ obj-y += entry.o
  obj-y += insn.o
  obj-$(CONFIG_LIVEPATCH) += livepatch.o
  obj-y += smpboot.o
+obj-y += smc.o
  obj-y += traps.o
  obj-y += vfp.o
diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S
new file mode 100644
index 000..aa44fba
--- /dev/null
+++ b/xen/arch/arm/arm64/smc.S
@@ -0,0 +1,29 @@
+/*
+ * xen/arch/arm/arm64/smc.S
+ *
+ * Wrapper for Secure Monitors Calls
+ *
+ * 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 
+
+/*
+ * void call_smccc_smc(register_t a0, register_t a1, register_t a2,
+ * register_t a3, register_t a4, register_t a5,
+ * register_t a6, register_t a7, register_t res[4])
+ */
+ENTRY(call_smccc_smc)
+smc #0
+ldr x4, [sp]
+stp x0, x1, [x4, 0]
+stp x2, x3, [x4, 16]
+ret
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 9f7a42f..4ce5bb6 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -786,6 +786,10 @@ void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
  int call_smc(register_t function_id, register_t arg0, register_t arg1,
   register_t arg2);
  
+void call_smccc_smc(register_t a0, register_t a1, register_t a2,

+register_t a3, register_t a4, register_t a5,
+register_t a6, register_t a7, register_t 

Re: [Xen-devel] [xen-unstable test] 116832: regressions - FAIL

[Ian Jackson]

osstest service owner writes ("[xen-unstable test] 116832: regressions - FAIL"):
> flight 116832 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/116832/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 
> 116744
> version targeted for testing:
>  xen  553ac37137c2d1c03bf1b69cfb192ffbfe29daa4

This is the expected Windows failure.  Force pushed.

Ian.

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

[Xen-devel] [PATCH 2/2] xen/pvcalls: Fix a check in pvcalls_front_remove()

[Dan Carpenter]

bedata->ref can't be less than zero because it's unsigned.  This affects
certain error paths in probe.  We first set ->ref = -1 and then we set
it to a valid value later.

Fixes: 219681909913 ("xen/pvcalls: connect to the backend")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 40caa92bff33..d1e1d8d2b9d5 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -1103,7 +1103,7 @@ static int pvcalls_front_remove(struct xenbus_device *dev)
kfree(map);
}
}
-   if (bedata->ref >= 0)
+   if (bedata->ref != -1)
gnttab_end_foreign_access(bedata->ref, 0, 0);
kfree(bedata->ring.sring);
kfree(bedata);

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

[Xen-devel] [PATCH] xen/pvcalls: check for xenbus_read() errors

[Dan Carpenter]

Smatch complains that "len" is uninitialized if xenbus_read() fails so
let's add some error handling.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 40caa92bff33..afa3f1b5d807 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -1128,6 +1128,8 @@ static int pvcalls_front_probe(struct xenbus_device *dev,
}
 
versions = xenbus_read(XBT_NIL, dev->otherend, "versions", );
+   if (IS_ERR(versions))
+   return PTR_ERR(versions);
if (!len)
return -EINVAL;
if (strcmp(versions, "1")) {

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

Re: [Xen-devel] [PATCH v2] x86/hvm: fix interaction between internal and external emulation

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 December 2017 14:32
> To: Paul Durrant 
> Cc: xen-devel@lists.xenproject.org
> Subject: RE: [PATCH v2] x86/hvm: fix interaction between internal and
> external emulation
> 
> >>> On 05.12.17 at 15:00,  wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 05 December 2017 13:53
> >> >>> On 28.11.17 at 15:05,  wrote:
> >> rc = x86_emulate(_ctxt->ctxt, ops);
> >>
> >> if ( rc != X86EMUL_RETRY )
> >> {
> >> vio->mmio_cache_count = 0;
> >> vio->mmio_insn_bytes = 0;
> >> }
> >> else
> >> {
> >> ...
> >> }
> >> if ( rc == X86EMUL_OKAY && vio->mmio_retry )
> >> rc = X86EMUL_RETRY;
> >>
> >
> > But that's not safe is it? If we've only completed some of the reps of an
> > instruction then we can't flush the instruction cache and we can't allow the
> > guest to take interrupts, can we?
> 
> Of course we can, just like a repeated string insn may be
> interrupted on bare hardware between any two iterations (with
> RIP still pointing at that insn). In fact with EFLAGS.TF set it is a
> requirement to deliver #DB after every iteration.

Ok. In that case your re-ordering would seem sound.

  Paul

> 
> Jan


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

Re: [Xen-devel] [PATCH v2] x86/hvm: fix interaction between internal and external emulation

[Jan Beulich]

>>> On 05.12.17 at 15:11,  wrote:
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Paul Durrant
>> Sent: 05 December 2017 14:00
>> To: 'Jan Beulich' 
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: 05 December 2017 13:53
>> > >>> On 28.11.17 at 15:05,  wrote:
>> > > --- a/xen/arch/x86/hvm/io.c
>> > > +++ b/xen/arch/x86/hvm/io.c
>> > > @@ -88,7 +88,7 @@ bool
>> > hvm_emulate_one_insn(hvm_emulate_validate_t *validate, const char
>> > *descr)
>> > >
>> > >  rc = hvm_emulate_one();
>> > >
>> > > -if ( hvm_vcpu_io_need_completion(vio) || vio->mmio_retry )
>> > > +if ( hvm_vcpu_io_need_completion(vio) )
>> > >  vio->io_completion = HVMIO_mmio_completion;
>> > >  else
>> > >  vio->mmio_access = (struct npfec){};
>> >
>> > While I can't (yet) say why without this change things would have
>> > behaved better on that old AMD box which is causing the osstest
>> > failure, I think Andrew's suggestion that we might be trying to
>> > emulate from a stale instruction cache is spot on: Doesn't
>> 
>> Yes, I can't see how the above was ever correct.
> 
> I think I see why this worked before...
> 
> Setting up the io_completion value meant that when hvm_do_resume() called 
> handle_hvm_io_completion() there was apparently an mmio outstanding and thus 
> handle_mmio() was called. At some point handle_mmio() has become a static 
> inline that calls hvm_emulate_one_insn() and that took care of the remaining 
> reps.

That would have worked sometimes, but as we've recently clarified
handle_hvm_io_completion() won't be called every time before
exiting back to the guest. IOW I would have expected random
failures with the same pattern as we see now, but I don't recall
ever having seen such before. (Otoh I admit I don't always look
closely when a transient failure occurs and then disappears in the
next flight.)

Jan


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

Re: [Xen-devel] [PATCH v2] x86/hvm: fix interaction between internal and external emulation

[Jan Beulich]

>>> On 05.12.17 at 15:00,  wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 05 December 2017 13:53
>> >>> On 28.11.17 at 15:05,  wrote:
>> rc = x86_emulate(_ctxt->ctxt, ops);
>> 
>> if ( rc != X86EMUL_RETRY )
>> {
>> vio->mmio_cache_count = 0;
>> vio->mmio_insn_bytes = 0;
>> }
>> else
>> {
>> ...
>> }
>> if ( rc == X86EMUL_OKAY && vio->mmio_retry )
>> rc = X86EMUL_RETRY;
>> 
> 
> But that's not safe is it? If we've only completed some of the reps of an 
> instruction then we can't flush the instruction cache and we can't allow the 
> guest to take interrupts, can we?

Of course we can, just like a repeated string insn may be
interrupted on bare hardware between any two iterations (with
RIP still pointing at that insn). In fact with EFLAGS.TF set it is a
requirement to deliver #DB after every iteration.

Jan


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

Re: [Xen-devel] [RFC PATCH 09/31] xen/device-tree: Add dt_property_for_each_string macros

[Oleksandr Tyshchenko]

Hi, Stefano

On Tue, Dec 5, 2017 at 1:24 AM, Stefano Stabellini
 wrote:
> On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko 
>>
>> This is a port from Linux.
>
> When you port stuff from Linux you have to retain the original
> copyright. Please add the original Signed-off-by lines (you actually
> have to use git log and git blame to narrow them down for copyright
> reasons):
>
>   Signed-off-by: Stephen Warren 
>   Signed-off-by: Linus Walleij 

Sure, I will add original author(s) here and in all device-tree
patches I ported.

>
> With those:
>
> Acked-by: Stefano Stabellini 

Thanks.

>
>
>> Signed-off-by: Oleksandr Tyshchenko 
>> CC: Stefano Stabellini 
>> CC: Julien Grall 
>> ---
>>  xen/common/device_tree.c  | 18 ++
>>  xen/include/xen/device_tree.h | 21 +
>>  2 files changed, 39 insertions(+)
>>
>> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
>> index 60b0095..08f8072 100644
>> --- a/xen/common/device_tree.c
>> +++ b/xen/common/device_tree.c
>> @@ -208,6 +208,24 @@ int dt_property_read_string(const struct dt_device_node 
>> *np,
>>  return 0;
>>  }
>>
>> +const char *dt_property_next_string(const struct dt_property *prop,
>> +const char *cur)
>> +{
>> +const void *curv = cur;
>> +
>> +if ( !prop )
>> +return NULL;
>> +
>> +if ( !cur )
>> +return prop->value;
>> +
>> +curv += strlen(cur) + 1;
>> +if ( curv >= prop->value + prop->length )
>> +return NULL;
>> +
>> +return curv;
>> +}
>> +
>>  bool_t dt_device_is_compatible(const struct dt_device_node *device,
>> const char *compat)
>>  {
>> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
>> index 738f1b6..9e0931c 100644
>> --- a/xen/include/xen/device_tree.h
>> +++ b/xen/include/xen/device_tree.h
>> @@ -420,6 +420,27 @@ int dt_property_read_string(const struct dt_device_node 
>> *np,
>>  const char *propname, const char **out_string);
>>
>>  /**
>> + * dt_property_for_each_string - Iterate over an array of strings within
>> + * a property with a given name for a given node.
>> + *
>> + * Example:
>> + *
>> + * struct dt_property *prop;
>> + * const char *s;
>> + *
>> + * dt_property_for_each_string(np, "propname", prop, s)
>> + * printk("String value: %s\n", s);
>> + */
>> +const char *dt_property_next_string(const struct dt_property *prop,
>> +const char *cur);
>> +
>> +#define dt_property_for_each_string(np, propname, prop, s)\
>> +for (prop = dt_find_property(np, propname, NULL), \
>> +s = dt_property_next_string(prop, NULL);  \
>> +s;\
>> +s = dt_property_next_string(prop, s))
>> +
>> +/**
>>   * Checks if the given "compat" string matches one of the strings in
>>   * the device's "compatible" property
>>   */
>> --
>> 2.7.4
>>



-- 
Regards,

Oleksandr Tyshchenko

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

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

[Julien Grall]

Hello,

On 05/12/17 03:59, Sameer Goel wrote:

This driver follows an approach similar to smmu driver. The intent here
is to reuse as much Linux code as possible.
- Glue code has been introduced in headers to bridge the API calls.
- Called Linux functions from the Xen IOMMU function calls.
- Xen modifications are preceded by /*Xen: comment */
- New config items for SMMUv3 and legacy SMMU have been defined.


There are no reason to touch legacy SMMU in this patch. Please move that 
outside of it.




Signed-off-by: Sameer Goel 
---
  xen/drivers/Kconfig|   2 +
  xen/drivers/passthrough/arm/Kconfig|  14 +
  xen/drivers/passthrough/arm/Makefile   |   3 +-
  xen/drivers/passthrough/arm/arm_smmu.h | 189 ++
  xen/drivers/passthrough/arm/smmu-v3.c  | 619 ++---
  5 files changed, 768 insertions(+), 59 deletions(-)
  create mode 100644 xen/drivers/passthrough/arm/Kconfig
  create mode 100644 xen/drivers/passthrough/arm/arm_smmu.h

diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index bc3a54f..6126553 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -12,4 +12,6 @@ source "drivers/pci/Kconfig"
  
  source "drivers/video/Kconfig"
  
+source "drivers/passthrough/arm/Kconfig"

+
  endmenu
diff --git a/xen/drivers/passthrough/arm/Kconfig 
b/xen/drivers/passthrough/arm/Kconfig
new file mode 100644
index 000..9ac4cea
--- /dev/null
+++ b/xen/drivers/passthrough/arm/Kconfig
@@ -0,0 +1,14 @@
+
+config ARM_SMMU
+   bool "ARM SMMU v1/2 support"
+   depends on ARM_64


Why? SMMUv1 and SMMUv2 supports Arm 32-bit.


+   help
+Support for implementations of the ARM System MMU architecture. (1/2)


I am not sure to understand the (1/2) after the final point.


+
+config ARM_SMMU_v3
+   bool "ARM SMMUv3 Support"
+   depends on ARM_64
+   help
+Support for implementations of the ARM System MMU architecture
+version 3.
+
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index f4cd26e..5b3eb15 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,3 @@
  obj-y += iommu.o
-obj-y += smmu.o
+obj-$(CONFIG_ARM_SMMU) += smmu.o
+obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o
diff --git a/xen/drivers/passthrough/arm/arm_smmu.h 
b/xen/drivers/passthrough/arm/arm_smmu.h
new file mode 100644
index 000..b5e161f
--- /dev/null
+++ b/xen/drivers/passthrough/arm/arm_smmu.h


I don't think there are any value to use Linux coding style in this 
header. It contains Xen stubs.


I would also have expected this new file to come in a separate patch 
with the modification associated in SMMUv2. This would make easier to 
see what could be common.



@@ -0,0 +1,189 @@
+/**
+ * ./arm_smmu.h
+ *
+ * Common compatibility defines and data_structures for porting arm smmu
+ * drivers from Linux.


[...]


+static struct resource *platform_get_resource(struct platform_device *pdev,
+ unsigned int type,
+ unsigned int num)
+{
+   /*
+* The resource is only used between 2 calls of platform_get_resource.
+* It's quite ugly but it's avoid to add too much code in the part
+* imported from Linux
+*/
+   static struct resource res;
+   struct acpi_iort_node *iort_node;
+   struct acpi_iort_smmu_v3 *node_smmu_data;
+   int ret = 0;
+
+   res.type = type;
+
+   switch (type) {
+   case IORESOURCE_MEM:
+   if (pdev->type == DEV_ACPI) {
+   ret = 1;
+   iort_node = pdev->acpi_node;
+   node_smmu_data =
+   (struct acpi_iort_smmu_v3 
*)iort_node->node_data;


Above you say: "Common compatibility defines and data_structures for 
porting arm smmu driver from Linux". But this code is clearly SMMUv3.



+
+   if (node_smmu_data != NULL) {
+   res.addr = node_smmu_data->base_address;
+   res.size = SZ_128K;
+   ret = 0;
+   }
+   } else {
+   ret = dt_device_get_address(dev_to_dt(pdev), num,
+   , );
+   }
+
+   return ((ret) ? NULL : );
+
+   case IORESOURCE_IRQ:
+   /* ACPI case not implemented as there is no use case for it */
+   ret = platform_get_irq(dev_to_dt(pdev), num);
+
+   if (ret < 0)
+   return NULL;
+
+   res.addr = ret;
+   res.size = 1;
+
+   return 
+
+   default:
+   return NULL;
+   }
+}
+
+static int platform_get_irq_byname(struct platform_device *pdev, const char 

Re: [Xen-devel] [PATCH v2] x86/hvm: fix interaction between internal and external emulation

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 05 December 2017 14:00
> To: 'Jan Beulich' 
> Cc: xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: fix interaction between
> internal and external emulation
> 
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 05 December 2017 13:53
> > To: Paul Durrant 
> > Cc: xen-devel@lists.xenproject.org
> > Subject: Re: [PATCH v2] x86/hvm: fix interaction between internal and
> > external emulation
> >
> > >>> On 28.11.17 at 15:05,  wrote:
> > > --- a/xen/arch/x86/hvm/io.c
> > > +++ b/xen/arch/x86/hvm/io.c
> > > @@ -88,7 +88,7 @@ bool
> > hvm_emulate_one_insn(hvm_emulate_validate_t *validate, const char
> > *descr)
> > >
> > >  rc = hvm_emulate_one();
> > >
> > > -if ( hvm_vcpu_io_need_completion(vio) || vio->mmio_retry )
> > > +if ( hvm_vcpu_io_need_completion(vio) )
> > >  vio->io_completion = HVMIO_mmio_completion;
> > >  else
> > >  vio->mmio_access = (struct npfec){};
> >
> > While I can't (yet) say why without this change things would have
> > behaved better on that old AMD box which is causing the osstest
> > failure, I think Andrew's suggestion that we might be trying to
> > emulate from a stale instruction cache is spot on: Doesn't
> 
> Yes, I can't see how the above was ever correct.

I think I see why this worked before...

Setting up the io_completion value meant that when hvm_do_resume() called 
handle_hvm_io_completion() there was apparently an mmio outstanding and thus 
handle_mmio() was called. At some point handle_mmio() has become a static 
inline that calls hvm_emulate_one_insn() and that took care of the remaining 
reps.

  Paul

> 
> >
> > rc = x86_emulate(_ctxt->ctxt, ops);
> >
> > if ( rc == X86EMUL_OKAY && vio->mmio_retry )
> > rc = X86EMUL_RETRY;
> > if ( rc != X86EMUL_RETRY )
> > {
> > vio->mmio_cache_count = 0;
> > vio->mmio_insn_bytes = 0;
> > }
> > else
> > ...
> >
> > in _hvm_emulate_one() need re-ordering of the two conditionals?
> > ->mmio_retry set, as described earlier, means we're exiting back to
> > the guest. At that point the guest can take interrupts and alike,
> > which means that if we're being re-entered we're not necessarily
> > going to continue emulation of the same previous instruction. I.e.
> >
> > rc = x86_emulate(_ctxt->ctxt, ops);
> >
> > if ( rc != X86EMUL_RETRY )
> > {
> > vio->mmio_cache_count = 0;
> > vio->mmio_insn_bytes = 0;
> > }
> > else
> > {
> > ...
> > }
> > if ( rc == X86EMUL_OKAY && vio->mmio_retry )
> > rc = X86EMUL_RETRY;
> >
> 
> But that's not safe is it? If we've only completed some of the reps of an
> instruction then we can't flush the instruction cache and we can't allow the
> guest to take interrupts, can we?
> 
>   Paul
> 
> > (or the equivalent thereof with switch() and fall-through from
> > OKAY to default). Any "more clever" solution (like deferring the
> > cache invalidation until we're being re-entered, making it
> > dependent on CS:RIP having changed) feels fragile.
> >
> > Jan
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] x86/hvm: fix interaction between internal and external emulation

[Jan Beulich]

>>> On 28.11.17 at 15:05,  wrote:
> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -88,7 +88,7 @@ bool hvm_emulate_one_insn(hvm_emulate_validate_t *validate, 
> const char *descr)
>  
>  rc = hvm_emulate_one();
>  
> -if ( hvm_vcpu_io_need_completion(vio) || vio->mmio_retry )
> +if ( hvm_vcpu_io_need_completion(vio) )
>  vio->io_completion = HVMIO_mmio_completion;
>  else
>  vio->mmio_access = (struct npfec){};

While I can't (yet) say why without this change things would have
behaved better on that old AMD box which is causing the osstest
failure, I think Andrew's suggestion that we might be trying to
emulate from a stale instruction cache is spot on: Doesn't

rc = x86_emulate(_ctxt->ctxt, ops);

if ( rc == X86EMUL_OKAY && vio->mmio_retry )
rc = X86EMUL_RETRY;
if ( rc != X86EMUL_RETRY )
{
vio->mmio_cache_count = 0;
vio->mmio_insn_bytes = 0;
}
else
...

in _hvm_emulate_one() need re-ordering of the two conditionals?
->mmio_retry set, as described earlier, means we're exiting back to
the guest. At that point the guest can take interrupts and alike,
which means that if we're being re-entered we're not necessarily
going to continue emulation of the same previous instruction. I.e.

rc = x86_emulate(_ctxt->ctxt, ops);

if ( rc != X86EMUL_RETRY )
{
vio->mmio_cache_count = 0;
vio->mmio_insn_bytes = 0;
}
else
{
...
}
if ( rc == X86EMUL_OKAY && vio->mmio_retry )
rc = X86EMUL_RETRY;

(or the equivalent thereof with switch() and fall-through from
OKAY to default). Any "more clever" solution (like deferring the
cache invalidation until we're being re-entered, making it
dependent on CS:RIP having changed) feels fragile.

Jan


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

Re: [Xen-devel] [RFC] WIP: optee: add OP-TEE mediator

[Volodymyr Babchuk]

Hi Stefano,


On 05.12.17 00:06, Stefano Stabellini wrote:

On Mon, 4 Dec 2017, Volodymyr Babchuk wrote:

= Xen command forwarding =

In the code below, it looks like Xen is forwarding everything to OP-TEE.
Are there some commands Xen should avoid forwarding? Should we have a
whitelist or a blacklist?

My code implements whitelists (at least, I hope so :-) ). It forwards
only known requests. If it does not know type of the request, it
returns error back to a caller.


Actually, see below:



+static bool optee_handle_smc(struct cpu_user_regs *regs)
+{
+
+switch ( get_user_reg(regs, 0) )
+{
+case OPTEE_SMC_GET_SHM_CONFIG:
+return handle_get_shm_config(regs);
+case OPTEE_SMC_EXCHANGE_CAPABILITIES:
+return handle_exchange_capabilities(regs);
+case OPTEE_SMC_CALL_WITH_ARG:
+return handle_std_call(regs);
+case OPTEE_SMC_CALL_RETURN_FROM_RPC:
+return handle_rpc(regs);
+default:
+return forward_call(regs);
+}
+return false;
+}


In the unknown ("default") case the smc is still forwarded. Am I missing
anything?
No, you are right. It is I who missed to complete this piece of code. 
There should be a list of all known OPTEE_SMC_* commands, plus "return 
false" in "default" case.


WBR,
--
Volodymyr Babchuk

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

Re: [Xen-devel] [RFC PATCH 13/31] xen/arm: Add driver_data field to struct device

[Oleksandr Tyshchenko]

Hi, Julien.

On Tue, Dec 5, 2017 at 1:26 PM, Julien Grall  wrote:
>
>
> On 09/11/17 17:10, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko 
>
>
> Please explain the rationale behind adding a new field in struct device.

Basically it is needed for the "direct ported" drivers from Linux. I
added this field in order to
make SCPI protocol driver happy. It operates with
platform_set_drvdata/platform_get_drvdata helpers.

Sure, I will add detailed description if we decide to go this way.

>
>>
>> Signed-off-by: Oleksandr Tyshchenko 
>> CC: Stefano Stabellini 
>> CC: Julien Grall 
>> ---
>>   xen/include/asm-arm/device.h | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
>> index 6734ae8..3e2f34a 100644
>> --- a/xen/include/asm-arm/device.h
>> +++ b/xen/include/asm-arm/device.h
>> @@ -20,6 +20,7 @@ struct device
>>   struct dt_device_node *of_node; /* Used by drivers imported from
>> Linux */
>>   #endif
>>   struct dev_archdata archdata;
>> +void *driver_data;
>>   };
>> typedef struct device device_t;
>>
>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

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

Re: [Xen-devel] [RFC v3 2/4] xen/linux_compat: Add a Linux compat header

[Julien Grall]

Hi Sameer,

On 05/12/17 03:59, Sameer Goel wrote:

For porting files from Linux it is useful to have a Linux API to Xen API
mapping header at a common location.
This file adds common API functions and other defines that are needed for
porting arm SMMU drivers.

---
  xen/include/xen/linux_compat.h | 106 +
  1 file changed, 106 insertions(+)
  create mode 100644 xen/include/xen/linux_compat.h

diff --git a/xen/include/xen/linux_compat.h b/xen/include/xen/linux_compat.h
new file mode 100644
index 000..217e0cc
--- /dev/null
+++ b/xen/include/xen/linux_compat.h
@@ -0,0 +1,106 @@
+/**
+ * include/xen/linux_compat.h
+ *
+ * Compatibility defines for porting code from Linux to Xen
+ *
+ * Copyright (c) 2017 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ */
+
+#ifndef __XEN_LINUX_COMPAT_H__
+#define __XEN_LINUX_COMPAT_H__
+
+#include 
+
+typedef paddr_t phys_addr_t;
+typedef paddr_t dma_addr_t;
+
+/* Alias to Xen device tree helpers */
+#define device_node dt_device_node
+#define of_phandle_args dt_phandle_args
+#define of_device_id dt_device_match
+#define of_match_node dt_match_node
+#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
out))
+#define of_property_read_bool dt_property_read_bool
+#define of_parse_phandle_with_args dt_parse_phandle_with_args
+/* The user should consider if it is safe to treat mutex as a spinlock */


I am against defining mutex as spinlock in a generic header. People will 
overlook it and it is hardly going to be detected in a verbatim port.


This should be done on the case by case basis.


+#define mutex spinlock_t
+#define mutex_init spin_lock_init
+#define mutex_lock spin_lock
+#define mutex_unlock spin_unlock
+
+#define ilog2 LOG_2


There is only one user of LOG_2 in Xen. So wouldn't it be better to 
rename directly to ilog2?



+
+#define readx_poll_timeout(op, addr, val, cond, sleep_us, timeout_us) \
+({ \
+s_time_t deadline = NOW() + MICROSECS(timeout_us); \
+for (;;) \
+{ \
+(val) = op(addr); \
+if ( cond ) \
+break; \
+if ( NOW() > deadline ) \
+{ \
+(val) = op(addr); \
+break; \
+} \
+udelay(sleep_us); \
+} \
+(cond) ? 0 : -ETIMEDOUT; \
+})
+
+#define readl_relaxed_poll_timeout(addr, val, cond, delay_us, timeout_us) \
+readx_poll_timeout(readl_relaxed, addr, val, cond, delay_us, timeout_us)


I don't think putting read* macros in a common header is necessary. 
Their use in Linux is very limited.



+
+/* Xen: Helpers for IRQ functions */
+#define request_irq(irq, func, flags, name, dev) request_irq(irq, flags, func, 
name, dev)
+#define free_irq release_irq
+
+enum irqreturn {
+IRQ_NONE= (0 << 0),
+IRQ_HANDLED = (1 << 0),
+IRQ_WAKE_THREAD = (2 << 0),
+};
+
+typedef enum irqreturn irqreturn_t;
+
+/* Device logger functions */
+#define dev_print(dev, lvl, fmt, ...)   \
+ printk(lvl fmt, ## __VA_ARGS__)
+
+#define dev_dbg(dev, fmt, ...) dev_print(dev, XENLOG_DEBUG, fmt, ## 
__VA_ARGS__)
+#define dev_notice(dev, fmt, ...) dev_print(dev, XENLOG_INFO, fmt, ## 
__VA_ARGS__)
+#define dev_warn(dev, fmt, ...) dev_print(dev, XENLOG_WARNING, fmt, ## 
__VA_ARGS__)
+#define dev_err(dev, fmt, ...) dev_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
+#define dev_info(dev, fmt, ...) dev_print(dev, XENLOG_INFO, fmt, ## 
__VA_ARGS__)
+
+#define dev_err_ratelimited(dev, fmt, ...)  \
+ dev_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
+
+#define dev_name(dev) dt_node_full_name(dev_to_dt(dev))
+
+/* Alias to Xen allocation helpers */
+#define kfree xfree
+#define kmalloc(size, flags)_xmalloc(size, sizeof(void *))
+#define kzalloc(size, flags)_xzalloc(size, sizeof(void *))
+#define devm_kzalloc(dev, size, flags)  _xzalloc(size, sizeof(void *))
+#define kmalloc_array(size, n, flags)   _xmalloc_array(size, sizeof(void *), n)
+
+/* Alias to Xen time functions */
+#define ktime_t s_time_t
+#define ktime_add_us(t,i)   (NOW() + MICROSECS(i))
+#define ktime_compare(t,i)  (NOW() > (i))
+
+#endif /* __XEN_LINUX_COMPAT_H__ */



Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org

Re: [Xen-devel] [patch 01/60] x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

[Juergen Gross]

On 04/12/17 15:07, Thomas Gleixner wrote:
> From: Boris Ostrovsky 
> 
> Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make them
> NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses eflags
> using 'pushfq' instruction when testing for IF bit. On PV Xen guests
> looking at IF flag directly will always see it set, resulting in 'ud2'.
> 
> Introduce SAVE_FLAGS() macro that will use appropriate save_fl pv op when
> running paravirt.
> 
> Signed-off-by: Boris Ostrovsky 
> Signed-off-by: Thomas Gleixner 
> Cc: jgr...@suse.com
> Cc: xen-devel@lists.xenproject.org
> Cc: l...@kernel.org
> Link: 
> https://lkml.kernel.org/r/1512159805-6314-1-git-send-email-boris.ostrov...@oracle.com

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [xen-unstable test] 116832: regressions - FAIL

[Andrew Cooper]

On 05/12/17 11:16, Jan Beulich wrote:
 On 05.12.17 at 11:03,  wrote:
>> On 05/12/2017 09:30, Jan Beulich wrote:
>> On 05.12.17 at 09:49,  wrote:
 flight 116832 xen-unstable real [real]
 http://logs.test-lab.xenproject.org/osstest/logs/116832/ 

 Regressions :-(

 Tests which did not succeed and are blocking,
 including tests which could not be run:
  test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 
>> 116744
>>> This is a blue screen, recurring, and has first been reported in flight
>>> 116779, i.e. was likely introduced in the batch ending in commit
>>> 4cd0fad645. Among those the most likely candidates appear to be
>>> the SVM changes (the failures are all on AMD hardware). The logs
>>> there also have huge amounts of "Unexpected nested vmexit",
>>> albeit not directly connected with the failed test afaict.
>> The unexpected nested vmexit is from a previous test, (and hopefully the
>> nested virt test, as that path shouldn't be reachable elsehow).
>>
>> The windows boot which actually failed has:
>>
>> Dec  5 04:20:08.735216 (XEN) CR access emulation failed (1): d1v0 64bit @ 
>> 0010:f8000ce9e4ab -> 66 f3 6d 48 8b 7c 24 08 c3 cc cc cc cc cc cc cc
> How did I not spot this? This is a REP INSW, which then makes it
> far more likely to be a result of Paul's 9c9384d6d8. Sadly the
> windows-install tests of the two 4.10 flights we've had so far all
> ran on Intel hardware, so we can't easily tell whether the
> problem is present there as well (in which case it would for sure
> be that commit).
>
> For the moment I'm struggling to understand how we can end up
> on the CR access emulation path here, but I'll take a closer look.

I am equally perplexed.  The SVM code definitely used to (ab)use the
MMIO path, so I expect there is still some remnants left.

The CR access in the message proves that we started this emulation from
a CR vmexit.  My best guess is that _hvm_emulate_one() reused the
instruction cache rather than starting fresh.  The unhandleable is
probably from a ->validate() failure, and the bytes are probably stale
from the previous emulation.

~Andrew

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

[Xen-devel] Xen 4.10 RC8

[Julien Grall]

Hi all,

Xen 4.10 RC8 is tagged. You can check that out from xen.git:

  git://xenbits.xen.org/xen.git 4.10.0-rc8

For your convenience, there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.10.0-rc8/xen-4.10.0-rc8.tar.gz

And the signature is at:
https://downloads.xenproject.org/release/xen/4.10.0-rc8/xen-4.10.0-rc8.tar.gz.sig

In this RC, debug has been disabled to get ready for the release.

Please send bug reports and test reports to
xen-devel@lists.xenproject.org. When sending bug reports, please CC
relevant maintainers and me (julien.gr...@linaro.org).

Thanks,

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

Re: [Xen-devel] [RFC PATCH 13/31] xen/arm: Add driver_data field to struct device

[Julien Grall]

On 09/11/17 17:10, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 


Please explain the rationale behind adding a new field in struct device.



Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
  xen/include/asm-arm/device.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 6734ae8..3e2f34a 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -20,6 +20,7 @@ struct device
  struct dt_device_node *of_node; /* Used by drivers imported from Linux */
  #endif
  struct dev_archdata archdata;
+void *driver_data;
  };
  
  typedef struct device device_t;




Cheers,

--
Julien Grall

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

Re: [Xen-devel] [xen-unstable test] 116832: regressions - FAIL

[Jan Beulich]

>>> On 05.12.17 at 11:03,  wrote:
> On 05/12/2017 09:30, Jan Beulich wrote:
> On 05.12.17 at 09:49,  wrote:
>>> flight 116832 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/116832/ 
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>>  test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 
> 116744
>> This is a blue screen, recurring, and has first been reported in flight
>> 116779, i.e. was likely introduced in the batch ending in commit
>> 4cd0fad645. Among those the most likely candidates appear to be
>> the SVM changes (the failures are all on AMD hardware). The logs
>> there also have huge amounts of "Unexpected nested vmexit",
>> albeit not directly connected with the failed test afaict.
> 
> The unexpected nested vmexit is from a previous test, (and hopefully the
> nested virt test, as that path shouldn't be reachable elsehow).
> 
> The windows boot which actually failed has:
> 
> Dec  5 04:20:08.735216 (XEN) CR access emulation failed (1): d1v0 64bit @ 
> 0010:f8000ce9e4ab -> 66 f3 6d 48 8b 7c 24 08 c3 cc cc cc cc cc cc cc

How did I not spot this? This is a REP INSW, which then makes it
far more likely to be a result of Paul's 9c9384d6d8. Sadly the
windows-install tests of the two 4.10 flights we've had so far all
ran on Intel hardware, so we can't easily tell whether the
problem is present there as well (in which case it would for sure
be that commit).

For the moment I'm struggling to understand how we can end up
on the CR access emulation path here, but I'll take a closer look.

Jan


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

Re: [Xen-devel] [RFC] WIP: optee: add OP-TEE mediator

[Julien Grall]

Hi,

On 04/12/17 22:04, Stefano Stabellini wrote:

On Mon, 4 Dec 2017, Volodymyr Babchuk wrote:

Hi Julien,


On Mon, Dec 04, 2017 at 04:27:14PM +, Julien Grall wrote:

[...]

= Error checking / DOS protection =

We need powerful checks on arguments passed by the caller and evaluated
by the mediator.

For example, we cannot expect the guest to actually pass arguments in
the format expected by translate_params. ctx->xen_arg could be
gibberish.

Yes. The same arguments stands also for OP-TEE itself. OP-TEE checks
validity of arguments and mediator should do the same. Actaully, I
implemented this checks in mediator.


 From the resource allocation point of view, it looks like every
handle_std_call allocates a new context; every copy_std_request
allocates a new Xen page. It would be easy to exhaust Xen resources.
Maybe we need a max concurrent request limit or max page allocation per
domain or something of the kind.

This is a very good point. Thanks. Yes, it is currently missing.
Is there any mechanism in XEN to provide quotas? I think, this mediator
is not the single entity that allocates memory to handle guest calls?


Most of the time, the memory is either accounted to the guest or only a
small amount of memory is allocated for a known period of time (the time of
an hypercall for instance).

Aha, so in my case, I will need to implement own quota mechanism.
I think something like "max_pages", initialized with value from
xenpolicy will be fine. What do you think?


Yes, that should work.


I think "max_pages" will be difficult to size by a user. It would be 
better to think about another metrics  (e.g number of OP-TEE commands in 
//) and/or limit the use of xmalloc within the code.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH 04/31] cpufreq: make turbo settings to be configurable

[Oleksandr Tyshchenko]

Hi Stefano

On Tue, Dec 5, 2017 at 12:18 AM, Stefano Stabellini
 wrote:
> On Sat, 2 Dec 2017, Oleksandr Tyshchenko wrote:
>> On Sat, Dec 2, 2017 at 3:06 AM, Stefano Stabellini
>>  wrote:
>> > On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
>> >> From: Oleksandr Dmytryshyn 
>> >>
>> >> This settings is not needed for some architectures.
>> >> So make it to be configurable and use it for x86
>> >> architecture.
>> >>
>> >> This is a rebased version of the original patch:
>> >> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00942.html
>> >>
>> >> Signed-off-by: Oleksandr Dmytryshyn 
>> >> Signed-off-by: Oleksandr Tyshchenko 
>> >> CC: Jan Beulich 
>> >> CC: Andrew Cooper 
>> >> CC: Stefano Stabellini 
>> >> CC: Julien Grall 
>> >> ---
>> >>  xen/arch/x86/Kconfig  |  1 +
>> >>  xen/drivers/cpufreq/Kconfig   |  3 +++
>> >>  xen/drivers/cpufreq/utility.c | 11 ++-
>> >>  xen/drivers/pm/stat.c |  6 ++
>> >>  xen/include/xen/cpufreq.h |  6 ++
>> >>  5 files changed, 26 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
>> >> index 86c8eca..c1eac1d 100644
>> >> --- a/xen/arch/x86/Kconfig
>> >> +++ b/xen/arch/x86/Kconfig
>> >> @@ -24,6 +24,7 @@ config X86
>> >>   select NUMA
>> >>   select VGA
>> >>   select HAS_PM
>> >> + select HAS_CPU_TURBO
>> >>
>> >>  config ARCH_DEFCONFIG
>> >>   string
>> >> diff --git a/xen/drivers/cpufreq/Kconfig b/xen/drivers/cpufreq/Kconfig
>> >> index cce80f4..427ea2a 100644
>> >> --- a/xen/drivers/cpufreq/Kconfig
>> >> +++ b/xen/drivers/cpufreq/Kconfig
>> >> @@ -1,3 +1,6 @@
>> >>
>> >>  config HAS_CPUFREQ
>> >>   bool
>> >> +
>> >> +config HAS_CPU_TURBO
>> >> + bool
>> >> diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
>> >> index a687e5a..25bf983 100644
>> >> --- a/xen/drivers/cpufreq/utility.c
>> >> +++ b/xen/drivers/cpufreq/utility.c
>> >> @@ -209,7 +209,9 @@ int cpufreq_frequency_table_cpuinfo(struct 
>> >> cpufreq_policy *policy,
>> >>  {
>> >>  unsigned int min_freq = ~0;
>> >>  unsigned int max_freq = 0;
>> >> +#ifdef CONFIG_HAS_CPU_TURBO
>> >>  unsigned int second_max_freq = 0;
>> >> +#endif
>> >>  unsigned int i;
>> >>
>> >>  for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
>> >> @@ -221,6 +223,7 @@ int cpufreq_frequency_table_cpuinfo(struct 
>> >> cpufreq_policy *policy,
>> >>  if (freq > max_freq)
>> >>  max_freq = freq;
>> >>  }
>> >> +#ifdef CONFIG_HAS_CPU_TURBO
>> >>  for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
>> >>  unsigned int freq = table[i].frequency;
>> >>  if (freq == CPUFREQ_ENTRY_INVALID || freq == max_freq)
>> >> @@ -234,9 +237,13 @@ int cpufreq_frequency_table_cpuinfo(struct 
>> >> cpufreq_policy *policy,
>> >>  printk("max_freq: %usecond_max_freq: %u\n",
>> >> max_freq, second_max_freq);
>> >>
>> >> +policy->cpuinfo.second_max_freq = second_max_freq;
>> >> +#else /* !CONFIG_HAS_CPU_TURBO */
>> >> +if (cpufreq_verbose)
>> >> +printk("max_freq: %u\n", max_freq);
>> >> +#endif /* CONFIG_HAS_CPU_TURBO */
>> >>  policy->min = policy->cpuinfo.min_freq = min_freq;
>> >>  policy->max = policy->cpuinfo.max_freq = max_freq;
>> >> -policy->cpuinfo.second_max_freq = second_max_freq;
>> >>
>> >>  if (policy->min == ~0)
>> >>  return -EINVAL;
>> >> @@ -390,6 +397,7 @@ int cpufreq_driver_getavg(unsigned int cpu, unsigned 
>> >> int flag)
>> >>  return policy->cur;
>> >>  }
>> >>
>> >> +#ifdef CONFIG_HAS_CPU_TURBO
>> >>  int cpufreq_update_turbo(int cpuid, int new_state)
>> >>  {
>> >>  struct cpufreq_policy *policy;
>> >> @@ -430,6 +438,7 @@ int cpufreq_get_turbo_status(int cpuid)
>> >>  policy = per_cpu(cpufreq_cpu_policy, cpuid);
>> >>  return policy && policy->turbo == CPUFREQ_TURBO_ENABLED;
>> >>  }
>> >> +#endif /* CONFIG_HAS_CPU_TURBO */
>> >>
>> >>  /*
>> >>   * POLICY*
>> >
>> > I am wondering if we need to go as far as #ifdef'ing
>> > cpufreq_update_turbo. For the sake of reducing the number if #ifdef's,
>> > would it be enough if we only make sure it is disabled?
>> >
>> > In other words, I would keep the changes to stat.c but I would leave
>> > utility.c and cpufreq.h pretty much untouched.
>>
>> Yes. I was thinking about dropping this patch at all. If platform
>> doesn't support CPU Boost, the platform
>> driver should just inform framework about that (policy->turbo =
>> CPUFREQ_TURBO_UNSUPPORTED).
>> That's all.
>
> Right
>
>
>> cpufreq_update_turbo() will return -EOPNOTSUPP 

[Xen-devel] [libvirt test] 116849: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 116770
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 116770
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 116770
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   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-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-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 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

version targeted for testing:
 libvirt  c32ab71034e10aa20fbd377be50f80eeb5c27d2b
baseline version:
 libvirt  9f0ccc717ba9026c30ce38951a354dd66fa12e3b

Last test of basis   116770  2017-12-02 04:20:11 Z3 days
Testing same since   116849  2017-12-05 04:27:08 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Daniel Veillard 
  Jim Fehlig 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 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-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-i386-libvirt-qcow2pass
 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 general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

To osst...@xenbits.xen.org:/home/xen/git/libvirt.git
   9f0ccc7..c32ab71  c32ab71034e10aa20fbd377be50f80eeb5c27d2b -> 
xen-tested-master

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

Re: [Xen-devel] [xen-unstable test] 116832: regressions - FAIL

[Andrew Cooper]

On 05/12/2017 10:03, Andrew Cooper wrote:
> On 05/12/2017 09:30, Jan Beulich wrote:
> On 05.12.17 at 09:49,  wrote:
>>> flight 116832 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/116832/ 
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>>  test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 
>>> 116744
>> This is a blue screen, recurring, and has first been reported in flight
>> 116779, i.e. was likely introduced in the batch ending in commit
>> 4cd0fad645. Among those the most likely candidates appear to be
>> the SVM changes (the failures are all on AMD hardware). The logs
>> there also have huge amounts of "Unexpected nested vmexit",
>> albeit not directly connected with the failed test afaict.
> The unexpected nested vmexit is from a previous test, (and hopefully the
> nested virt test, as that path shouldn't be reachable elsehow).
>
> The windows boot which actually failed has:
>
> Dec  5 04:20:08.735216 (XEN) CR access emulation failed (1): d1v0 64bit @ 
> 0010:f8000ce9e4ab -> 66 f3 6d 48 8b 7c 24 08 c3 cc cc cc cc cc cc cc
> Dec  5 04:21:49.555130 (XEN) stdvga.c:173:d1v0 entering stdvga mode
>
> which I expect is the root of the problem.

Yes - that is the cause of the problem.  The BSOD is a 0x3D (exception
not handled) referencing the same %rip as the CR emulation failure.

~Andrew

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

Re: [Xen-devel] [xen-unstable test] 116832: regressions - FAIL

[Andrew Cooper]

On 05/12/2017 09:30, Jan Beulich wrote:
 On 05.12.17 at 09:49,  wrote:
>> flight 116832 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/116832/ 
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 
>> 116744
> This is a blue screen, recurring, and has first been reported in flight
> 116779, i.e. was likely introduced in the batch ending in commit
> 4cd0fad645. Among those the most likely candidates appear to be
> the SVM changes (the failures are all on AMD hardware). The logs
> there also have huge amounts of "Unexpected nested vmexit",
> albeit not directly connected with the failed test afaict.

The unexpected nested vmexit is from a previous test, (and hopefully the
nested virt test, as that path shouldn't be reachable elsehow).

The windows boot which actually failed has:

Dec  5 04:20:08.735216 (XEN) CR access emulation failed (1): d1v0 64bit @ 
0010:f8000ce9e4ab -> 66 f3 6d 48 8b 7c 24 08 c3 cc cc cc cc cc cc cc
Dec  5 04:21:49.555130 (XEN) stdvga.c:173:d1v0 entering stdvga mode

which I expect is the root of the problem.

~Andrew

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

Re: [Xen-devel] [xen-unstable test] 116832: regressions - FAIL

[Jan Beulich]

>>> On 05.12.17 at 09:49,  wrote:
> flight 116832 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/116832/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 
> 116744

This is a blue screen, recurring, and has first been reported in flight
116779, i.e. was likely introduced in the batch ending in commit
4cd0fad645. Among those the most likely candidates appear to be
the SVM changes (the failures are all on AMD hardware). The logs
there also have huge amounts of "Unexpected nested vmexit",
albeit not directly connected with the failed test afaict.

Jan


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

Re: [Xen-devel] [PATCH v9 00/16] Enable Memory Bandwidth Allocation in Xen

[Yi Sun]

On 17-12-05 02:09:14, Jan Beulich wrote:
> >>> On 05.12.17 at 03:53,  wrote:
> > This patch set has got all Acked-by/Reviewed-by months ago. So, I am
> > wondering when it can be integrated? Any plan? Thanks!
> 
> It is not being forgotten. But the tree is not fully open yet, so it is
> subject to the judgment of committers whether any patch (or
> series) is suitable of committing at this point. A 16-patch series imo
> clearly isn't. Please be a little more patient - even once the tree is
> fully open, a few working days should be allowed for everyone
> to deal with backlog, before sending pings merely related to
> patches (not) going in right away.
> 
Got it, thanks! Just want to know the plan or flow.

> Jan

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

Re: [Xen-devel] [RFC v3 2/4] xen/linux_compat: Add a Linux compat header

[Jan Beulich]

>>> On 05.12.17 at 04:59,  wrote:
> For porting files from Linux it is useful to have a Linux API to Xen API
> mapping header at a common location.

Looking at what you add here I really think "no, please don't". But
let's see what other maintainers thinks.

Jan


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

Re: [Xen-devel] [RFC v3 1/4] Port WARN_ON_ONCE() from Linux

[Jan Beulich]

>>> On 05.12.17 at 04:59,  wrote:
> Port WARN_ON_ONCE macro from Linux. A return value is expected from this
> macro, so the implementation  does not follow the Xen convention of wrapping
> macros in a do..while.

There's no such convention for macros producing a value.

> ---

Missing S-o-b.

> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -11,6 +11,17 @@
>  #define BUG_ON(p)  do { if (unlikely(p)) BUG();  } while (0)
>  #define WARN_ON(p) do { if (unlikely(p)) WARN(); } while (0)
>  
> +#define WARN_ON_ONCE(p)  ({  \
> +static bool __section(".data.unlikely") __warned; \

I think this will need an addition to xen.lds.S (both x86 and ARM).

> +int __ret_warn_once = !!(p);\

bool and please don't use leading underscores for identifiers when
those are in conflict with the C spec.

> +if (unlikely(__ret_warn_once && !__warned)) {   \

I don't think using likely() / unlikely() on expressions involving && or
|| is ever a useful thing - in the case here you really mean

if (unlikely(__ret_warn_once) && unlikely(!__warned)) {

> +__warned = true;\
> +WARN_ON(1); \

WARN()

I also think that you would better use Xen style here, despite
BUG_ON() and WARN_ON() themselves slightly violating this. The
file clearly is not a Linux derived file (anymore).

Jan


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

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

[Jan Beulich]

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

Sure, and it is not being forgotten. But the tree is not fully open
yet, so it is subject to the judgment of committers whether any
patch (or series) is suitable of committing at this point. I did think
about committing this patch yesterday, but decided against
doing so. Please be a little more patient - even once the tree is
fully open, a few working days should be allowed for everyone
to deal with backlog, before sending pings.

Jan


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

[Xen-devel] [xen-unstable test] 116832: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 116744

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 116744
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 116744
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 116744
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116744
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 116744
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 116744
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 116744
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 116744
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 116744
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 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 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 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-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-i386-libvirt-qcow2 12 migrate-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-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-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-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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 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 13 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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail 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  553ac37137c2d1c03bf1b69cfb192ffbfe29daa4
baseline version:
 xen  6da091d95dfcbe00daf91308d044ee5151b1ac9e

Last test of basis   116744  2017-12-01 13:53:15 Z3 days
Failing since116779  2017-12-02 17:06:23 Z2 days3 attempts
Testing same since   116832  2017-12-04 13:57:29 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Brian Woods 
  David Esler 
  Euan Harris 
  Gregory Herrero 
  Haozhong Zhang 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Paul Durrant 
  Roger Pau Monné 
  Sergey Dyasli 
  Stefano Stabellini 
  Zhenzhong Duan 

Re: [Xen-devel] [PATCH 4/5] x86: use switch() in _put_page_type()

[Jan Beulich]

>>> On 04.12.17 at 16:40,  wrote:
> On 04/12/17 10:46, Jan Beulich wrote:
>> Use this to cheaply add another assertion.
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> TBD: Would it perhaps be better to return after the assertion?
> 
> Yes, otherwise we risk falling into an infinite continue loop.

I've used -EILSEQ, but no, there's no infinite loop potential here, as
there's a preemption check past the switch() statement (and there
was "break" rather than "continue" after the assertion). This and
the lack of reasonably suitable error code to return here was why
I didn't use "return" in the first version. Or did you mean "infinite
continuation loop" (affecting just the guest)?

> With a suitable return value, Reviewed-by: Andrew Cooper
> 

Thanks.

Jan


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