Re: [Xen-devel] [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies

[Julien Grall]

Hi Parth,

On 04/02/2015 14:02, parth.di...@linaro.org wrote:

From: Parth Dixit 

Some bugs are identified in edk2 and some of the functionality is not
yet merged. This patch contains workarounds for them


While I understand some workaround (based on your cover letter), some of 
them is unclear to me and need explanation.




Signed-off-by: Parth Dixit 
---


[..]


diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 97061ce..e74555d 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -254,6 +254,8 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
  }
  }

+#define VGIC_ICFG_MASK(intr) ( 1 << ( ( 2 * ( intr % 16 ) ) + 1 ) )
+
  void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
  {
  struct domain *d = v->domain;
@@ -266,6 +268,20 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)

  while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
  irq = i + (32 * n);
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+if( ( n!=0 ) && is_hardware_domain(d) ){
+struct vgic_irq_rank *vr = vgic_get_rank(v, n);
+uint32_t tr;
+tr = vr->icfg[i >> 4] ;
+
+if( ( tr & VGIC_ICFG_MASK(i) ) )
+acpi_set_irq(irq, DT_IRQ_TYPE_EDGE_BOTH);
+else
+acpi_set_irq(irq, DT_IRQ_TYPE_LEVEL_MASK);


What's the status of the dynamic IRQ configuration?


+
+route_irq_to_guest(d,irq,NULL);


Hmmm, do you really plan to keep that here? What's your plan for this?


+}
+#endif
  v_target = d->arch.vgic.handler->get_target_vcpu(v, irq);
  p = irq_to_pending(v_target, irq);
  set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index 73da9d9..2d78ba0 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -66,7 +66,7 @@ void __init acpi_os_vprintf(const char *fmt, va_list args)

  acpi_physical_address __init acpi_os_get_root_pointer(void)
  {
-   if (efi_enabled) {
+if (efi_enabled) {


Spurious change


if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
return efi.acpi20;
else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
@@ -198,8 +198,11 @@ acpi_os_write_memory(acpi_physical_address phys_addr, u32 
value, u32 width)

return AE_OK;
  }
-
+#ifdef CONFIG_X86
  #define is_xmalloc_memory(ptr) ((unsigned long)(ptr) & (PAGE_SIZE - 1))
+#else
+#define is_xmalloc_memory(ptr) 1
+#endif


Why? I though this was resolved?


  void *__init acpi_os_alloc_memory(size_t sz)
  {



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 25/35] arm: acpi add helper functions to map memory regions

[Julien Grall]

Hi parth,

Title: this is not acpi specific.

On 04/02/2015 14:02, parth.di...@linaro.org wrote:

From: Parth Dixit 

For passing ACPI tables to dom0, UEFI memory needs to be mapped
by xen in dom0 address space. This patch adds helper functions for mapping.


I believe that this is not ACPI/RAM specific. Any cached MMIO regions 
will have same issue.


This because Device memory is too strong and disallow unaligned access.


Signed-off-by: Parth Dixit 
---
  xen/arch/arm/p2m.c| 24 
  xen/include/asm-arm/p2m.h | 10 ++
  2 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 8809f5a..5593a91 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -943,6 +943,30 @@ int p2m_populate_ram(struct domain *d,
   0, MATTR_MEM, p2m_ram_rw);
  }

+int map_ram_regions(struct domain *d,
+ unsigned long start_gfn,
+ unsigned long nr,
+ unsigned long mfn)


I don't like the name of the function. It gives the impression that we 
map any RAM region to the guest via this function.


Which is obviously wrong and should never be done.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 33/35] arm : acpi enable efi for acpi

[Julien Grall]

Hi Parth,

On 04/02/2015 14:02, parth.di...@linaro.org wrote:

From: Parth Dixit 

efi should be enabled to fetch the root pointer from uefi

Signed-off-by: Parth Dixit 
---
  xen/common/efi/runtime.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index c840e08..c8b8642 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
  #ifndef COMPAT

  #ifdef CONFIG_ARM  /* Disabled until runtime services implemented */


This comment seems irrelevant now.


+
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)


#ifdef CONFIG_ACPI


+const bool_t efi_enabled = 1;
+#else
  const bool_t efi_enabled = 0;
+#endif
+
  #else
  # include 
  # include 



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 30/35] arm : acpi map XSDT table to dom0

[Julien Grall]

Hi Parth,



On 04/02/2015 14:02, parth.di...@linaro.org wrote:

From: Parth Dixit 

XSDT table cannot be passed as is to dom0 because new tables specific to xen
need to be added to its table entries

Signed-off-by: Parth Dixit 
---
  xen/arch/arm/arm64/acpi/arm-core.c | 65 --
  1 file changed, 63 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c
index 9a26202..a210596 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -256,13 +256,74 @@ static void set_psci_fadt(void)
  fadt->header.checksum = (u8)( fadt->header.checksum-checksum );
  }

+#define NR_NEW_XEN_TABLES 2


Please add a comment to specify what is the 2 new tables.


+
+static int map_xsdt_table(struct domain *d, u64 *xsdt)
+{
+int res;
+u64 size;
+u64 addr = *xsdt;
+u64 *new_xsdt;
+struct acpi_table_header *table;
+u64 *table_entry;
+u8 checksum;
+
+/* map xsdt table */
+table = acpi_os_map_memory(addr, sizeof(struct acpi_table_header) );


No space before the last )

Also acpi_os_map_memory can fail.



+size = table->length ;


No space before the ;


+acpi_os_unmap_memory(table, sizeof(struct acpi_table_header) );


Ditto


+
+table = acpi_os_map_memory(addr, size);


acpi_os_map_memory can fail


+size += ( NR_NEW_XEN_TABLES*sizeof(acpi_native_uint) );



(NR_NEW_XEN_TABLELS * sizeof(...));


+new_xsdt = ACPI_ALLOCATE_ZEROED(size);
+if( new_xsdt == NULL)


if ( ... )


+return -ENOMEM;
+ACPI_MEMCPY(new_xsdt, table,table->length);


Missing space after the comma.


+acpi_os_unmap_memory(table, table->length);
+
+table = (struct acpi_table_header *) new_xsdt;
+table->length = size;
+*xsdt = addr = virt_to_maddr(new_xsdt);
+
+/* map xsdt region */
+res = map_ram_regions(d,
+paddr_to_pfn(addr & PAGE_MASK),
+DIV_ROUND_UP(size, PAGE_SIZE),
+paddr_to_pfn(addr & PAGE_MASK));
+if ( res )
+{
+ printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+" - 0x%"PRIx64" in domain \n",
+addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+}
+
+table_entry = ACPI_CAST_PTR(u64,
+( ACPI_CAST_PTR(u8, new_xsdt) + sizeof(struct acpi_table_header) ) );


Too much space in general.


+table_entry +=
+( ( (size - sizeof(struct acpi_table_header) ) /
+sizeof(acpi_native_uint) ) );


Ditto


+
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, table), table->length);
+table->checksum = (u8)( table->checksum - checksum );


(table->checksum - checksum);

Also I'm not sure the the u8 cast is useful.


+return 0;
+}
+
  int acpi_map_tables(struct domain *d)
  {
  int i,res;
-u64 addr, size;
+u64 addr, size, rsdp;
+struct acpi_table_rsdp *rsdt;
+
+addr = rsdp = acpi_os_get_root_pointer();


Why do you set addr, but only use below rather than rsdp?


+rsdt = acpi_os_map_memory(addr, sizeof(struct acpi_table_rsdp) );


No space before )



+addr = rsdt->xsdt_physical_address;
+map_xsdt_table(d, &addr);
+rsdt->xsdt_physical_address = addr;
+acpi_os_unmap_memory(rsdt, sizeof(struct acpi_table_rsdp) );


No space before )

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 28/35] arm: acpi map acpi tables in dom0

[Julien Grall]

Hi Parth,

On 04/02/2015 14:02, parth.di...@linaro.org wrote:

From: Parth Dixit 

map acpi tables described in uefi table to dom0 address space

Signed-off-by: Parth Dixit 
---
  xen/arch/arm/arm64/acpi/arm-core.c | 43 ++
  xen/arch/arm/domain_build.c|  4 
  xen/include/asm-arm/acpi.h |  1 +
  3 files changed, 48 insertions(+)

diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c
index cc11fce..6707e4c 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -31,6 +31,7 @@

  #include 
  #include 
+#include 

  /*
   * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
@@ -241,6 +242,48 @@ static int __init acpi_parse_fadt(struct acpi_table_header 
*table)
 return 0;
  }

+int acpi_map_tables(struct domain *d)


This should be __init


+{
+int i,res;
+u64 addr, size;
+
+/* map rsdp table */
+addr = acpi_os_get_root_pointer();
+size = sizeof(struct acpi_table_rsdp);
+
+res = map_ram_regions(d,
+paddr_to_pfn(addr & PAGE_MASK),
+DIV_ROUND_UP(size, PAGE_SIZE),
+paddr_to_pfn(addr & PAGE_MASK));


It's not related to this patch. As ACPI may reside in RAM, this mean 
that the ACPI region should be marked as reserved to avoid Xen 
allocating the memory for a guest.


Did you take care of it?


+if ( res )
+{
+ printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+" - 0x%"PRIx64" in domain \n",
+addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+}
+
+for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
+{
+addr = acpi_gbl_root_table_list.tables[i].address;
+size = acpi_gbl_root_table_list.tables[i].length;
+
+res = map_ram_regions(d,
+paddr_to_pfn(addr & PAGE_MASK),
+DIV_ROUND_UP(size, PAGE_SIZE),
+paddr_to_pfn(addr & PAGE_MASK));
+if ( res )
+{
+ printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+" - 0x%"PRIx64" in domain \n",
+addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+}
+}
+
+return 0;
+}
+
  /*
   * acpi_boot_table_init() called from setup_arch(), always.
   *  1. find RSDP and get its address, and then find XSDT
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 49eb52a..a504064 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1278,6 +1278,10 @@ static int map_acpi_regions(struct domain *d)
  {
  int res;

+res = acpi_map_tables(d);
+if ( res )
+return res;
+
  res = acpi_map_mmio(d);
  if ( res )
  return res;
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 01ce28d..4f52cd6 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -108,5 +108,6 @@ static inline void acpi_disable_pci(void)
  #define MAX_GIC_CPU_INTERFACE 65535
  #define MAX_GIC_DISTRIBUTOR   1/* should be the same as 
MAX_GIC_NR */
  extern int __init acpi_gic_init(void);
+int acpi_map_tables(struct domain *d);

  #endif /*_ASM_ARM_ACPI_H*/



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 31/35] arm : acpi map status override table to dom0

[Julien Grall]

Hi Parth,

You don't only map the status override table. You also create it.
I would update the commit title to reflect it.


On 04/02/2015 14:02, parth.di...@linaro.org wrote:

From: Parth Dixit 

hide UART used by xen by indicating it in STAO table
and map it to dom0

Signed-off-by: Parth Dixit 
---
  xen/arch/arm/arm64/acpi/arm-core.c | 50 ++
  1 file changed, 50 insertions(+)

diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c
index a210596..9fd02f9 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -256,6 +256,48 @@ static void set_psci_fadt(void)
  fadt->header.checksum = (u8)( fadt->header.checksum-checksum );
  }

+static int map_stao_table(struct domain *d, u64 *mstao)
+{
+u64 addr;
+u64 size;
+int res;
+u8 checksum;
+struct acpi_table_stao *stao=NULL;


stao = NULL


+
+stao = ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_table_stao) );


No space before the last )


+if( stao == NULL )
+return -ENOMEM;
+
+ACPI_MEMCPY(stao->header.signature,ACPI_SIG_STAO, 4);


Space after comma


+stao->header.length = sizeof(struct acpi_table_header) + 1;
+stao->header.checksum = 0;
+ACPI_MEMCPY(stao->header.oem_id, "LINARO", 6);
+ACPI_MEMCPY(stao->header.oem_table_id, "RTSMVEV8", 8);


I though the plan was to use a Xen OEM ID?


+stao->header.revision = 1;
+ACPI_MEMCPY(stao->header.asl_compiler_id, "INTL", 4);
+stao->header.asl_compiler_revision = 0x20140828;


Where does this revision comes from?


+stao->uart = 1;


What about the devpath?


+size = sizeof(struct acpi_table_stao);
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, stao), size);
+stao->header.checksum = (u8)( stao->header.checksum - checksum );


No space before the last )


+*mstao = addr = virt_to_maddr(stao);
+
+res = map_ram_regions(d,
+  paddr_to_pfn(addr & PAGE_MASK),
+  DIV_ROUND_UP(size, PAGE_SIZE),
+  paddr_to_pfn(addr & PAGE_MASK));


I'm concerned with this mapping, as long as most of the others. 
map_ram_regions is mapping Read/Write the region. In this case, the STAO 
size may not be aligned to PAGE_SIZE.


So we may end up to map to DOM0 RW Xen memory. Even if DOM0 is a trusted 
domain, we should never let DOM0 write in Xen memory.


IIRC, the plan was to map at least RO all the ACPI tables.


+if ( res )
+{
+printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+   " - 0x%"PRIx64" in domain \n",
+   addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+return res;
+}
+
+return 0;
+}
+
+
  #define NR_NEW_XEN_TABLES 2

  static int map_xsdt_table(struct domain *d, u64 *xsdt)
@@ -304,6 +346,14 @@ static int map_xsdt_table(struct domain *d, u64 *xsdt)
  ( ( (size - sizeof(struct acpi_table_header) ) /
  sizeof(acpi_native_uint) ) );

+/* map stao table */
+map_stao_table(d, &addr);
+if(res)


if ( ... )


+return res;
+
+table_entry--;
+*table_entry = addr ;
+


No space before ;


  checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, table), table->length);
  table->checksum = (u8)( table->checksum - checksum );


No space before the last )

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 32/35] arm : acpi map xen environment table to dom0

[Julien Grall]

Hi Parth,

As for the STAO table, this is not only mapping but also creating the table.

On 04/02/2015 14:02, parth.di...@linaro.org wrote:

From: Parth Dixit 

xen environment table contains the grant table address,size and event


, size


channel interrupt information required by dom0.

Signed-off-by: Parth Dixit 
---
  xen/arch/arm/arm64/acpi/arm-core.c | 52 +-
  1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c
index 9fd02f9..9e9285c 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -33,7 +33,6 @@
  #include 
  #include 
  #include 
-


Spurious change.


  /*
   * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
   * variable is still required by the ACPI core
@@ -297,6 +296,49 @@ static int map_stao_table(struct domain *d, u64 *mstao)
  return 0;
  }

+static int map_xenv_table(struct domain *d, u64 *mxenv)
+{
+u64 addr;
+u64 size;
+int res;
+u8 checksum;
+struct acpi_table_xenv *xenv=NULL;


*xenv = NULL


+
+xenv = ACPI_ALLOCATE_ZEROED( sizeof(struct acpi_table_xenv) );


No space necessary after the first ( and before the last )


+if( xenv == NULL )
+return -ENOMEM;
+
+ACPI_MEMCPY(xenv->header.signature, ACPI_SIG_XENV, 4);
+xenv->header.length = sizeof(struct acpi_table_header)+12;


Where does the 12 comes from?


+xenv->header.checksum = 0;
+ACPI_MEMCPY(xenv->header.oem_id, "XenVMM", 6);
+ACPI_MEMCPY(xenv->header.oem_table_id, "RTSMVEV8", 8);


RTSMVEV8? Why?


+xenv->header.revision = 1;
+ACPI_MEMCPY(xenv->header.asl_compiler_id, "INTL", 4);
+xenv->header.asl_compiler_revision = 0x20140828;


Why this compiler revision?


+xenv->gnt_start = 0x001000;
+xenv->gnt_size = 0x2;


This is hardcoded. Even if you precise it in the cover letter, you 
should make clear in the patch that we have hardcoded.



+xenv->evt_intr = 31;
+xenv->evt_intr_flag =3;


Ditto

Also intr_flag = 3; and please use define rather than a value.


+size = sizeof(struct acpi_table_xenv);
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, xenv), size);
+xenv->header.checksum = (u8)( xenv->header.checksum - checksum );


No space after the ( and before )


+*mxenv = addr = virt_to_maddr(xenv);
+
+res = map_ram_regions(d,
+paddr_to_pfn(addr & PAGE_MASK),
+DIV_ROUND_UP(size, PAGE_SIZE),
+paddr_to_pfn(addr & PAGE_MASK));


Same remark as for the Xen Environment table (see patch #31).


+if ( res )
+{
+ printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+" - 0x%"PRIx64" in domain \n",
+addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+}
+
+return 0;
+}

  #define NR_NEW_XEN_TABLES 2

@@ -346,6 +388,14 @@ static int map_xsdt_table(struct domain *d, u64 *xsdt)
  ( ( (size - sizeof(struct acpi_table_header) ) /
  sizeof(acpi_native_uint) ) );

+/* map xen env table */
+res = map_xenv_table(d, &addr);
+if(res)
+return res;
+
+table_entry--;
+*table_entry = addr ;
+


No space before ;


  /* map stao table */
  map_stao_table(d, &addr);
  if(res)



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 29/35] arm : acpi enable PSCI and hvc in acpi FADT table

[Julien Grall]

Hi Parth,

On 04/02/2015 14:02, parth.di...@linaro.org wrote:

From: Parth Dixit 

Enable PSCI and hvc flags in FADT table so that dom0 uses PSCI to
boot vcpu's


VCPUs



Signed-off-by: Parth Dixit 
---
  xen/arch/arm/arm64/acpi/arm-core.c | 16 
  1 file changed, 16 insertions(+)

diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c
index 6707e4c..9a26202 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -28,6 +28,7 @@
  #include 
  #include 
  #include 
+#include 

  #include 
  #include 
@@ -242,6 +243,19 @@ static int __init acpi_parse_fadt(struct acpi_table_header 
*table)
 return 0;
  }

+static void set_psci_fadt(void)
+{
+struct acpi_table_fadt *fadt=NULL;
+struct acpi_table_header *table=NULL;
+u8 checksum;
+
+acpi_get_table(ACPI_SIG_FADT, 0, &table);
+fadt = (struct acpi_table_fadt *)table;
+fadt->arm_boot_flags |= ( ACPI_FADT_PSCI_COMPLIANT | 
ACPI_FADT_PSCI_USE_HVC );
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, fadt), fadt->header.length);
+fadt->header.checksum = (u8)( fadt->header.checksum-checksum );
+}
+
  int acpi_map_tables(struct domain *d)
  {
  int i,res;
@@ -263,6 +277,8 @@ int acpi_map_tables(struct domain *d)
   return res;
  }

+set_psci_fadt();
+


With this change, the name of the function (acpi_map_tables) doesn't 
seem correct.



  for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
  {
  addr = acpi_gbl_root_table_list.tables[i].address;



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 21/35] xen/arm: Create memory node for DOM0

[Julien Grall]

Hi Parth,

On 04/02/2015 14:02, parth.di...@linaro.org wrote:

From: Naresh Bhat 

Create a memory node for DOM0.


I'm not convince it's necessary to have a separate patch for this. I 
would squash it the #20.



Signed-off-by: Naresh Bhat 
---
  xen/arch/arm/domain_build.c | 48 +
  1 file changed, 48 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index bb7f043..30bebe5 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1155,6 +1155,50 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
  return res;
  }

+static int make_memory_node_acpi(const struct domain *d,
+void *fdt,
+int addr_cells,
+int size_cells,
+const struct kernel_info *kinfo)
+{
+int res, i;
+int reg_size = addr_cells + size_cells;
+int nr_cells = reg_size*kinfo->mem.nr_banks;
+__be32 reg[nr_cells];
+__be32 *cells;
+
+DPRINT("Create memory node (reg size %d, nr cells %d)\n", reg_size, 
nr_cells);
+
+/* ePAPR 3.4 */
+res = fdt_begin_node(fdt, "memory");
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "device_type", "memory");
+if ( res )
+return res;
+
+cells = ®[0];
+for ( i = 0 ; i < kinfo->mem.nr_banks; i++ )
+{
+u64 start = kinfo->mem.bank[i].start;
+u64 size = kinfo->mem.bank[i].size;
+
+DPRINT("  Bank %d: %#"PRIx64"->%#"PRIx64"\n",
+i, start, start + size);
+
+dt_set_range(&cells, fdt, start, size);
+}
+
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if ( res )
+return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+


Why did you duplicate make_memory_node rather than slightly modify the 
function to support both ACPI and DT version?



  /*
   * Prepare a minimal DTB for DOM0 which contains
   * bootargs, memory information,
@@ -1196,6 +1240,10 @@ static int prepare_dtb_acpi(struct domain *d, struct 
kernel_info *kinfo)
  if ( ret )
  return ret;

+ret = make_memory_node_acpi(d, kinfo->fdt, 2, 1, kinfo);


I forget to mention it on the previous patch. Please add 2 defines for 
the value 2/1.



+if ( ret )
+goto err;
+
  ret = fdt_end_node(kinfo->fdt);
  if ( ret < 0 )
  goto err;



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 26/35] arm : acpi read mmio tables from uefi

[Julien Grall]

Hi Parth,

On 04/02/2015 14:02, parth.di...@linaro.org wrote:

From: Parth Dixit 

For ACPI on arm device initialization is done by dom0 after parsing DSDT.


For ACPI on ARM, device ...


xen requires mmio region information described in uefi tables
for mapping it to dom0.

Signed-off-by: Parth Dixit 
---
  xen/arch/arm/efi/efi-boot.h | 16 
  xen/arch/arm/setup.c|  1 +
  xen/include/asm-arm/setup.h |  1 +
  3 files changed, 18 insertions(+)

diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index 639942d..535f484 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -127,6 +127,8 @@ static EFI_STATUS __init 
efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
  {
  int Index;
  int i = 0;
+int j = 0;
+
  EFI_MEMORY_DESCRIPTOR *desc_ptr = map;

  for ( Index = 0; Index < (mmap_size / desc_size); Index++ )
@@ -145,10 +147,24 @@ static EFI_STATUS __init 
efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
  break;
  }
  }
+else if ( desc_ptr->Type == EfiMemoryMappedIO
+  || desc_ptr->Type == EfiMemoryMappedIOPortSpace )


I would turn the function into a switch case. if ... else if ... is 
really difficult to read and ...



+{
+acpi_mmio.bank[j].start = desc_ptr->PhysicalStart;
+acpi_mmio.bank[j].size  = desc_ptr->NumberOfPages * EFI_PAGE_SIZE;
+if ( ++j >= NR_MEM_BANKS )
+{
+PrintStr(L"Warning: All ");
+DisplayUint(NR_MEM_BANKS, -1);
+PrintStr(L" acpi meminfo mem banks exhausted.\r\n");
+break;


... make this such problem appears.

While the number of MMIO banks has expired, we should continue to loop 
to get the RAM regions. Leaving the loop will make less obvious the 
further issue (such as no memory bank found).



+}
+}
  desc_ptr = NextMemoryDescriptor(desc_ptr, desc_size);
  }

  bootinfo.mem.nr_banks = i;
+acpi_mmio.nr_banks = j;
  return EFI_SUCCESS;
  }

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 93c8a8a..930746b 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -50,6 +50,7 @@
  #include 

  struct bootinfo __initdata bootinfo;


#ifdef CONFIG_ACPI?


+struct meminfo __initdata acpi_mmio;

  struct cpuinfo_arm __read_mostly boot_cpu_data;

diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index ba5a67d..5ea9ed6 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -46,6 +46,7 @@ struct bootinfo {
  };

  extern struct bootinfo bootinfo;
+extern struct meminfo acpi_mmio;


I'm not sure that it's the right things to use meminfo. It only has 64 
banks...


Could not we re-read at runtime the UEFI memory map?

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 20/35] xen/arm: Prepare a min DT for DOM0

[Julien Grall]

Hi Parth,

On 04/02/2015 14:02, parth.di...@linaro.org wrote:

From: Naresh Bhat 

This patch prepare a DT from scratch for DOM0 for
ACPI-case only. Basically the DT contains minmal
required informations such as DOM0 bootargs, memory
and ACPI RSDP informations only.

Signed-off-by: Naresh Bhat 
---
  xen/arch/arm/domain_build.c | 67 -
  1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index de180d8..bb7f043 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -18,6 +18,7 @@
  #include 
  #include 
  #include 
+#include 

  #include 
  #include 
@@ -61,6 +62,9 @@ custom_param("dom0_mem", parse_dom0_mem);
   */
  #define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))

+/* Reserve DOM0 FDT size in ACPI case only */
+#define DOM0_FDT_MIN_SIZE 4096
+
  struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
  {
  if ( opt_dom0_max_vcpus == 0 )
@@ -1151,6 +1155,63 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
  return res;
  }

+/*
+ * Prepare a minimal DTB for DOM0 which contains
+ * bootargs, memory information,
+ * ACPI RSDP pointer.
+ */
+static int prepare_dtb_acpi(struct domain *d, struct kernel_info *kinfo)
+{
+int new_size;
+int ret;
+
+DPRINT("Prepare a min DTB for DOM0\n");
+
+/* Allocate min size for DT */
+new_size = DOM0_FDT_MIN_SIZE;
+kinfo->fdt = xmalloc_bytes(DOM0_FDT_MIN_SIZE);
+
+if ( kinfo->fdt == NULL )
+return -ENOMEM;
+
+/* Create a new empty DT for DOM0 */
+ret = fdt_create(kinfo->fdt, new_size);
+if ( ret < 0 )
+goto err;
+
+/* Reserve the memory space for new DT */


Wrong comment.


+ret = fdt_finish_reservemap(kinfo->fdt);
+if ( ret < 0 )
+goto err;
+
+ret = fdt_begin_node(kinfo->fdt, "/");
+if ( ret < 0 )
+goto err;
+
+ret = fdt_property_cell(kinfo->fdt, "#address-cells", 2);
+if ( ret )
+return ret;
+
+ret = fdt_property_cell(kinfo->fdt, "#size-cells", 1);
+if ( ret )
+return ret;
+
+ret = fdt_end_node(kinfo->fdt);
+if ( ret < 0 )
+goto err;
+
+ret = fdt_finish(kinfo->fdt);
+if ( ret < 0 )
+goto err;
+
+return 0;
+
+  err:
+printk("Device tree generation failed (%d).\n", ret);
+xfree(kinfo->fdt);
+return -EINVAL;
+}
+
  static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
  {
  const void *fdt;
@@ -1305,7 +1366,11 @@ int construct_dom0(struct domain *d)



I bet the change in construct_dom0 should be more complex than the 4 
lines. For instance, initrd_load fixup the DTB when the initrd is present.


How initrd should be loaded in presence of ACPI?


  allocate_memory(d, &kinfo);

-rc = prepare_dtb(d, &kinfo);
+if (acpi_disabled)
+rc = prepare_dtb(d, &kinfo);


The name prepare_dtb is now confusing. We should find a better name.


+else
+rc = prepare_dtb_acpi(d, &kinfo);
+
  if ( rc < 0 )
  return rc;




Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 18/35] arm : add helper function for setting interrupt type

[Julien Grall]

Hi Parth,

On 04/02/2015 14:02, parth.di...@linaro.org wrote:

From: Parth Dixit 

set edge/level type information for an interrupt

Signed-off-by: Parth Dixit 
---
  xen/arch/arm/irq.c| 19 +++
  xen/include/asm-arm/irq.h |  4 
  2 files changed, 23 insertions(+)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 25ecf1d..ae4e99a 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -545,6 +545,25 @@ int platform_get_irq(const struct dt_device_node *device, 
int index)
  return irq;
  }

+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+int acpi_set_irq(int irq,int type)
+{
+int res;
+
+/* Setup the IRQ type */
+if ( irq < NR_LOCAL_IRQS )
+res = irq_local_set_type(irq, type);
+else
+res = irq_set_spi_type(irq, type);
+
+if ( res )
+return -1;
+
+return 0;
+
+}
+#endif
+


IIRC Ian was requiring a similar function for PCI. So I would rename to 
a generic name.


Also, now that we start to support ACPI the name of the define DT_IRQ_* 
are not anymore relevant. Maybe we should rename it.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 17/35] pl011: Initialize serial from ACPI SPCR table

[Julien Grall]

Hi Parth,

On 04/02/2015 14:02, parth.di...@linaro.org wrote:

From: Naresh Bhat 

Parse ACPI SPCR (Serial Port Console Redirection table) table and
initialize the serial port pl011.

Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
---
  xen/arch/arm/setup.c  |  6 +
  xen/drivers/char/pl011.c  | 69 +++
  xen/include/acpi/actbl2.h |  6 +
  xen/include/xen/serial.h  |  1 +
  4 files changed, 82 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index af9f429..317b985 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -762,7 +762,13 @@ void __init start_xen(unsigned long boot_phys_offset,

  init_IRQ();

+/* If ACPI enabled and ARM64 arch then UART initialization from SPCR table 
*/
+#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
+acpi_uart_init();
+#else
  dt_uart_init();
+#endif
+


Same as the previous patch, a Xen binary should both work on ACPI and DT.


  console_init_preirq();
  console_init_ring();

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index dd19ce8..3499ee3 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -280,6 +280,75 @@ DT_DEVICE_START(pl011, "PL011 UART", DEVICE_SERIAL)
  .init = pl011_uart_init,
  DT_DEVICE_END

+/* Parse the SPCR table and initialize the Serial UART */
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)


#ifdef CONFIG_ACPI


+
+#include 
+


No include in the middle of the file. Please move it a the beginning.


+static int __init acpi_pl011_uart_init(struct acpi_table_spcr *spcr)
+{
+struct pl011 *uart;
+u64 addr, size;
+
+uart = &pl011_com;
+uart->clock_hz  = 0x16e3600;
+uart->baud  = spcr->baud_rate;
+uart->data_bits = 8;
+uart->parity= spcr->parity;
+uart->stop_bits = spcr->stop_bits;
+
+if ( spcr->interrupt < 0 )
+{
+printk("pl011: Unable to retrieve the IRQ\n");
+return -EINVAL;
+}
+
+uart->irq = spcr->interrupt;
+addr = spcr->serial_port.address;
+size = 0x1000;


Please explain this size.


+uart->regs = ioremap_nocache(addr, size);
+
+acpi_set_irq(uart->irq, DT_IRQ_TYPE_EDGE_BOTH);


Is it always the case? I don't think so... Also, acpi_set_irq is define 
after this patch. The code should never use code defined later.



+
+if ( !uart->regs )
+{
+printk("pl011: Unable to map the UART memory\n");
+return -ENOMEM;
+}
+
+uart->vuart.base_addr = addr;
+uart->vuart.size = size;
+uart->vuart.data_off = DR;
+uart->vuart.status_off = FR;
+uart->vuart.status = 0;
+
+/* Register with generic serial driver. */
+serial_register_uart(SERHND_DTUART, &pl011_driver, uart);


I don't really like this. Maybe we should define a different serial 
handler, or redefine it to SERHND_ARM



+
+return 0;
+}
+
+void __init acpi_uart_init(void)
+{


This function is not part of the PL011. In this case, you are breaking 
the design.


I believe that most of the SPCR parsing should be generic, so maybe you 
could extend the DEVICE interface to handle the ACPI case.



+struct acpi_table_spcr *spcr=NULL;
+
+printk("ACPI UART Init\n");
+acpi_get_table(ACPI_SIG_SPCR, 0,(struct acpi_table_header **)&spcr);
+
+switch(spcr->interface_type) {
+case ACPI_SPCR_TYPPE_PL011:
+acpi_pl011_uart_init(spcr);
+break;
+/* Not implemented yet */
+case ACPI_SPCR_TYPE_16550:
+case ACPI_SPCR_TYPE_16550_SUB:
+default:
+printk("iinvalid uart type\n");


invalid


+}
+}
+
+#endif
+
  /*
   * Local variables:
   * mode: C
diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
index 87bc6b3..6aad200 100644
--- a/xen/include/acpi/actbl2.h
+++ b/xen/include/acpi/actbl2.h
@@ -815,6 +815,12 @@ struct acpi_table_spcr {

  #define ACPI_SPCR_DO_NOT_DISABLE(1)

+/* UART Interface type */
+#define ACPI_SPCR_TYPE_16550 0
+#define ACPI_SPCR_TYPE_16550_SUB 1
+#define ACPI_SPCR_TYPPE_PL011 3
+
+
  
/***
   *
   * SPMI - Server Platform Management Interface table
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 9f4451b..99e53d4 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -167,6 +167,7 @@ void ns16550_init(int index, struct ns16550_defaults 
*defaults);
  void ehci_dbgp_init(void);

  void __init dt_uart_init(void);
+void __init acpi_uart_init(void);

  struct physdev_dbgp_op;
  int dbgp_op(const struct physdev_dbgp_op *);


Regards,


--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 12/35] ARM64: Initialization of cpu_logical_map(0)

[Julien Grall]

Hi Parth,

On 04/02/2015 14:01, parth.di...@linaro.org wrote:

From: Naresh Bhat 

Initialization of cpu_logical_map(0) before acpi_boot_init()


Perhaps, merging with the previous patch?

Regards,


Signed-off-by: Hanjun Guo 
Signed-off-by: Naresh Bhat 
---
  xen/arch/arm/setup.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 3531d47..569b2da 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -47,6 +47,7 @@
  #include 
  #include 
  #include 
+#include 

  struct bootinfo __initdata bootinfo;

@@ -749,6 +750,10 @@ void __init start_xen(unsigned long boot_phys_offset,

  #if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
  acpi_boot_table_init();
+
+/* Get the boot CPU's MPIDR before cpu logical map is built */
+cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
+
  acpi_boot_init();
  #endif




--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 19/35] ACPI / GICv2: Add GIC specific ACPI boot support

[Julien Grall]

Hi Parth,

On 04/02/2015 14:02, parth.di...@linaro.org wrote:

From: Naresh Bhat 

ACPI on Xen hypervisor uses MADT table for proper GIC initialization.
It needs to parse GIC related subtables, collect CPU interface and distributor
addresses and call driver initialization function (which is hardware
abstraction agnostic). In a similar way, FDT initialize GICv1/2.


No need to spec about GICv1, we don't support it on Xen.


NOTE: This commit allow to initialize GICv1/2 only.


Ditto.



Signed-off-by: Tomasz Nowicki 
Signed-off-by: Graeme Gregory 
Signed-off-by: Hanjun Guo 
Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 

Conflicts:

xen/arch/arm/irq.c


This may have come via a conflicted merge.


---
  xen/arch/arm/gic-v2.c  | 271 +
  xen/arch/arm/setup.c   |   3 +-
  xen/include/asm-arm/acpi.h |   2 +
  3 files changed, 275 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..cb1d205 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -777,6 +777,277 @@ DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
  .init = gicv2_init,
  DT_DEVICE_END

+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+
+#include 
+#include 
+#include 
+#include 


Please no include in the middle of the file.


+
+/*
+ * Hard code here, we can not get memory size from MADT (but FDT does),
+ * this size can be inferred from GICv2 spec
+ */
+
+#define ACPI_GIC_DIST_MEM_SIZE   0x0001 // (SZ_64K)
+#define ACPI_GIC_CPU_IF_MEM_SIZE 0x2000 // (SZ_8K)


Why don't you use the proper define (SZ_64K/SZ_8k) rather than 
hardcoding it?



+
+static DEFINE_PER_CPU(u64, gic_percpu_cpu_base);
+static cpumask_t gic_acpi_cpu_mask;
+static u64 dist_phy_base;
+
+static int __init
+gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+struct acpi_madt_generic_interrupt *processor;
+unsigned int cpu;
+
+processor = (struct acpi_madt_generic_interrupt *)header;
+
+if (BAD_MADT_ENTRY(processor, end))

if ( ... )


+return -EINVAL;
+for_each_possible_cpu(cpu) {


for_each_possible( ... )
{

Please checking the coding style within this patch. I won't tell more 
foo ( ... )

{

in this patch.


+/*
+ * FIXME: This condition is failing.
+ * In Xen we first want to bring/initialize the GIC in hypervisor with 
single CPU
+ * if (processor->mpidr == cpu_logical_map(cpu))
+ */
+goto find;
+}


Looking at the code in this function, this whole loop doesn't seem 
useful. It make the code more complicate to read. Why don't you validate 
directly the GIC addresses in this function?


This is what Linux does and it's divide by 5 the produced code.


+
+printk("\nUnable to find CPU corresponding to GIC CPU entry [mpdir 
%lx]\n",
+(long)processor->mpidr);
+
+return 0;
+
+find:
+/* Read from APIC table and fill up the GIC variables */
+gicv2.dbase = processor->redist_base_address;
+gicv2.cbase = processor->base_address;
+gicv2.hbase = processor->gich_base_address;
+gicv2.vbase = processor->gicv_base_address;
+gicv2_info.maintenance_irq = processor->vgic_maintenance_interrupt;
+if( processor->flags & ACPI_MADT_ENABLED )
+{
+if( processor->flags & ACPI_MADT_VGIC )
+acpi_set_irq(gicv2_info.maintenance_irq, 
DT_IRQ_TYPE_EDGE_BOTH);
+else
+acpi_set_irq(gicv2_info.maintenance_irq, 
DT_IRQ_TYPE_LEVEL_MASK);
+}
+
+/*
+ * Do not validate CPU i/f base, we can still use "Local Interrupt
+ * Controller Address" from MADT header instead.
+ */
+per_cpu(gic_percpu_cpu_base, cpu) = processor->base_address;
+cpumask_set_cpu(cpu, &gic_acpi_cpu_mask);
+
+return 0;
+}
+
+static int __init
+gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+struct acpi_madt_generic_distributor *dist;
+
+dist = (struct acpi_madt_generic_distributor *)header;
+
+if (BAD_MADT_ENTRY(dist, end))
+return -EINVAL;
+
+dist_phy_base = dist->base_address;
+
+return 0;
+}
+
+static int gic_acpi_validate_init(u64 madt_cpu_addr)
+{
+void __iomem *cpu_base, *dist_base;
+u64 gic_cpu_base = 0;
+unsigned int cpu;
+
+/* Process all GICC entries delivered by MADT */
+if (!cpumask_empty(&gic_acpi_cpu_mask)) {
+/*
+ * If MADT contains at least one GICC entry, it must be BSP
+ * dedicated.
+ */
+if (!cpumask_test_cpu(0, &gic_acpi_cpu_mask)) {
+printk("GICC entries exist but unable to find BSP GICC 
"
+  

Re: [Xen-devel] [PATCH RFC 16/35] ARM64 / ACPI: Parse GTDT to initialize timer

[Julien Grall]

Hi Parth,

On 04/02/2015 14:02, parth.di...@linaro.org wrote:

From: Naresh Bhat 

Parse GTDT (Generic Timer Descriptor Table) to initialize timer.
Using the information presented by GTDT to initialize the arch
timer (not momery-mapped).


memory-mapped


Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
---
  xen/arch/arm/setup.c   |  6 +
  xen/arch/arm/time.c| 66 ++
  xen/include/xen/time.h |  1 +
  3 files changed, 73 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 569b2da..af9f429 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -775,7 +775,12 @@ void __init start_xen(unsigned long boot_phys_offset,
  smp_init_cpus();
  cpus = smp_get_max_cpus();

+/* Comment for now take it after GIC initialization */
+#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
+   init_xen_acpi_time();
+#else
  init_xen_time();
+#endif


This is clearly wrong. A same Xen binary should run on both ACPI and DT 
when ACPI is enabled.


Also, I would take care of the different between ACPI and DT in 
init_xen_time, rather than ifdefining here. It will make the code more 
cleaner.



  gic_init();

@@ -789,6 +794,7 @@ void __init start_xen(unsigned long boot_phys_offset,
  xsm_dt_init();

  init_maintenance_interrupt();
+


Spurious change.


  init_timer_interrupt();

  timer_init();
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 0add494..0d4c26d 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -29,6 +29,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -239,6 +240,71 @@ struct tm wallclock_time(uint64_t *ns)
  return (struct tm) { 0 };
  }

+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)


#ifdef CONFIG_ACPI


+#define ACPI_GTDT_INTR_MASK 0x3
+
+static int GTDT_INTRL_TAB[] ={ DT_IRQ_TYPE_LEVEL_HIGH, DT_IRQ_TYPE_EDGE_RISING,
+  DT_IRQ_TYPE_LEVEL_LOW ,DT_IRQ_TYPE_EDGE_FALLING};
+
+/* Initialize per-processor generic timer */
+static int __init arch_timer_acpi_init(struct acpi_table_header *table)
+{
+int res;
+int type;
+struct acpi_table_gtdt *gtdt;
+
+gtdt = (struct acpi_table_gtdt *)table;
+
+/* Initialize all the generic timer IRQ variable from GTDT table */
+
+type = GTDT_INTRL_TAB[gtdt->non_secure_el1_flags & ACPI_GTDT_INTR_MASK];
+acpi_set_irq(gtdt->non_secure_el1_interrupt, type);
+timer_irq[TIMER_PHYS_NONSECURE_PPI] = gtdt->non_secure_el1_interrupt;
+
+type = GTDT_INTRL_TAB[gtdt->secure_el1_flags & ACPI_GTDT_INTR_MASK];
+acpi_set_irq(gtdt->secure_el1_interrupt, type);
+timer_irq[TIMER_PHYS_SECURE_PPI] = gtdt->secure_el1_interrupt;
+
+type = GTDT_INTRL_TAB[gtdt->non_secure_el2_flags & ACPI_GTDT_INTR_MASK];
+acpi_set_irq(gtdt->non_secure_el2_interrupt, type);
+timer_irq[TIMER_HYP_PPI] = gtdt->non_secure_el2_interrupt;
+
+type = GTDT_INTRL_TAB[gtdt->virtual_timer_flags & ACPI_GTDT_INTR_MASK];
+acpi_set_irq(gtdt->virtual_timer_interrupt, type);
+timer_irq[TIMER_VIRT_PPI] = gtdt->virtual_timer_interrupt;
+
+printk("Generic Timer IRQ from ACPI GTDT: phys=%u hyp=%u virt=%u\n",
+   timer_irq[TIMER_PHYS_NONSECURE_PPI],
+   timer_irq[TIMER_HYP_PPI],
+   timer_irq[TIMER_VIRT_PPI]);
+
+res = platform_init_time();


The platform code is DT-centrict. Although, most of the code below is 
similar to the Timer DT initialization. Please factor it.



+if ( res )
+printk("Timer: Cannot initialize platform timer");
+
+/* Check that this CPU supports the Generic Timer interface */
+if ( !cpu_has_gentimer )
+printk("CPU does not support the Generic Timer v1 interface");
+
+cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
+
+boot_count = READ_SYSREG64(CNTPCT_EL0);
+
+printk("Using generic timer at %lu KHz\n", cpu_khz);
+
+return 0;
+}
+
+int __init init_xen_acpi_time(void)
+{
+   /* Initialize all the generic timers presented in GTDT */
+   acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init);
+   return 0;
+}
+
+#endif
+
  /*
   * Local variables:
   * mode: C
diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
index 709501f..4598a0c 100644
--- a/xen/include/xen/time.h
+++ b/xen/include/xen/time.h
@@ -11,6 +11,7 @@
  #include 
  #include 

+extern int init_xen_acpi_time(void);


This is ARM specific, please move the prototype in asm-arm/time.h.


  extern int init_xen_time(void);
  extern void cstate_restore_tsc(void);




Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 06/35] ACPI: Add Generic Interrupt and Distributor struct

[Julien Grall]

Hi Parth,

On 04/02/2015 14:01, parth.di...@linaro.org wrote:

From: Naresh Bhat 

Add Generic Interrupt and Distributor (ACPI 5.0) structure.

Signed-off-by: Naresh Bhat 
---
  xen/include/acpi/actbl1.h | 29 -
  1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
index 9311e3a..dd6dc27 100644
--- a/xen/include/acpi/actbl1.h
+++ b/xen/include/acpi/actbl1.h
@@ -639,7 +639,9 @@ enum acpi_madt_type {
ACPI_MADT_TYPE_INTERRUPT_SOURCE = 8,
ACPI_MADT_TYPE_LOCAL_X2APIC = 9,
ACPI_MADT_TYPE_LOCAL_X2APIC_NMI = 10,
-   ACPI_MADT_TYPE_RESERVED = 11/* 11 and greater are reserved */
+   ACPI_MADT_TYPE_GENERIC_INTERRUPT = 11,
+   ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR = 12,
+   ACPI_MADT_TYPE_RESERVED = 13/* 13 and greater are reserved */
  };

  /*
@@ -760,6 +762,31 @@ struct acpi_madt_local_x2apic_nmi {
u8 reserved[3];
  };

+/* 11: Generic Interrupt (ACPI 5.0) */
+
+struct acpi_madt_generic_interrupt {
+struct acpi_subtable_header header;
+u16 reserved;   /* reserved - must be zero */
+u32 gic_id;
+u32 uid;
+u32 flags;
+u32 parking_version;
+u32 performance_interrupt;
+u64 parked_address;
+u64 base_address;
+};
+
+/* 12: Generic Distributor (ACPI 5.0) */
+
+struct acpi_madt_generic_distributor {
+struct acpi_subtable_header header;
+u16 reserved;   /* reserved - must be zero */
+u32 gic_id;
+u64 base_address;
+u32 global_irq_base;
+u32 reserved2;  /* reserved - must be zero */
+};
+


This file is using tablutation rather than space for indent


  /*
   * Common flags fields for MADT subtables
   */



--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 11/35] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Julien Grall]

Hi Parth,

On 04/02/2015 14:01, parth.di...@linaro.org wrote:

From: Naresh Bhat 

MADT contains the information for MPIDR which is essential for
SMP initialization, parse the GIC cpu interface structures to
get the MPIDR value and map it to cpu_logical_map(), and add
enabled cpu with valid MPIDR into cpu_possible_map and
cpu_present_map.

Signed-off-by: Hanjun Guo 
Signed-off-by: Tomasz Nowicki 
Signed-off-by: Naresh Bhat 
---
  xen/arch/arm/arm64/acpi/arm-core.c | 139 +
  xen/include/asm-arm/acpi.h |   2 +
  xen/include/xen/acpi.h |   5 ++
  3 files changed, 146 insertions(+)

diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c
index 2b7e2ef..84b0032 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -26,7 +26,10 @@
  #include 
  #include 
  #include 
+#include 
+#include 

+#include 
  #include 

  /*
@@ -49,10 +52,141 @@ int acpi_psci_present;
  /* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
  int acpi_psci_use_hvc;

+/* available_cpus means enabled cpu in MADT */
+static int available_cpus;
+


Why adding available_cpus here, and total_cpus a bit below?


  enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;

  struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */

+/* arch-optional setting to enable display of offline cpus >= nr_cpu_ids */
+unsigned int total_cpus = 0;


Set but never used, neither exported...


+/*
+ * acpi_register_gic_cpu_interface - register a gic cpu interface and
+ * generates a logic cpu number
+ * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
+ * @enabled: this cpu is enabled or not
+ *
+ * Returns the logic cpu number which maps to the gic cpu interface
+ */
+static int acpi_register_gic_cpu_interface(u64 mpidr, u8 enabled)
+{
+int cpu;
+
+if ( mpidr == INVALID_HWID )
+{
+printk("Skip invalid cpu hardware ID\n");
+return -EINVAL;
+}
+
+total_cpus++;
+if ( !enabled )
+return -EINVAL;
+
+if ( available_cpus >=  NR_CPUS )
+{
+printk("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
+NR_CPUS, total_cpus, (long long unsigned 
int)mpidr);


Why the (long long unsigned int) cast? Please use PRIx64.


+return -EINVAL;
+}
+
+/* If it is the first CPU, no need to check duplicate MPIDRs */
+if ( !available_cpus )
+goto skip_mpidr_check;


I don't think it's necessary, for_each_present_cpu should not contain 
the first CPU...



+
+/*
+* Duplicate MPIDRs are a recipe for disaster. Scan
+* all initialized entries and check for
+* duplicates. If any is found just ignore the CPU.
+*/
+for_each_present_cpu(cpu)
+{
+if ( cpu_logical_map(cpu) == mpidr )
+{
+printk("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
+(long long unsigned int)mpidr);


Ditto for the cast.


+return -EINVAL;
+}
+}
+
+skip_mpidr_check:
+available_cpus++;
+
+/* allocate a logic cpu id for the new comer */
+if ( cpu_logical_map(0) == mpidr )
+{
+/*
+ * boot_cpu_init() already hold bit 0 in cpu_present_mask
+ * for BSP, no need to allocte again.


allocate


+ */
+cpu = 0;
+}
+else
+cpu = cpumask_next_zero(-1, &cpu_present_map);
+
+/* map the logic cpu id to cpu MPIDR */
+cpu_logical_map(cpu) = mpidr;
+
+set_cpu_possible(cpu, true);
+set_cpu_present(cpu, true);
+
+return cpu;
+}
+
+static int __init
+acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
+   const unsigned long end)
+{
+struct acpi_madt_generic_interrupt *processor;
+
+processor = (struct acpi_madt_generic_interrupt *)header;
+
+if ( BAD_MADT_ENTRY(processor, end) )
+return -EINVAL;
+
+acpi_table_print_madt_entry(header);
+
+acpi_register_gic_cpu_interface(processor->mpidr,
+processor->flags & ACPI_MADT_ENABLED);
+
+return 0;
+}
+
+/*
+ * Parse GIC cpu interface related entries in MADT
+ * returns 0 on success, < 0 on error
+ */
+static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
+{
+int count;
+
+/*
+ * do a partial walk of MADT to determine how many CPUs
+ * we have including disabled CPUs, and get information
+ * we need for SMP init
+ */
+count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
+
+if ( !count )
+{
+printk("No GIC CPU interface entries present\n");
+return -ENODEV;
+}
+else if ( count < 0 )
+{
+printk("Error parsing GIC CPU interface entry\n");
+return count;
+}
+
+/* Make boot-up look pretty */
+printk("%d CPUs available, %d CPUs total\n", available_cpus

Re: [Xen-devel] [PATCH RFC 04/35] ACPI / ACPICA: Introduce ARM Boot Architecture Flags in FADT

[Julien Grall]

Hi Parth,

On 04/02/2015 14:01, parth.di...@linaro.org wrote:

From: Naresh Bhat 

 The Power State Coordination Interface (PSCI) defines an API that
 can be used to coordinate power control amongst the various supervisory
 systems concurrently running on a device. ACPI support for this
 technology would require the addition of two flags: PSCI_COMPLIANT and
 PSCI_USE_HVC. When set, the former signals to the OS that the hardware
 is PSCI compliant. The latter selects the appropriate conduit for PSCI
 calls by toggling between Hypervisor Calls (HVC) and Secure Monitor
 Calls (SMC).

 An ARM Boot Architecture Flags structure to support new ARM hardware
 was introduced in FADT in ACPI 5.1, add the code accordingly to
 implement that in ACPICA core.

 Since ACPI 5.1 doesn't support self defined PSCI function IDs,
 which means that only PSCI 0.2+ is supported in ACPI.

 Signed-off-by: Hanjun Guo 
 Signed-off-by: Naresh Bhat 
---
  xen/include/acpi/actbl.h | 12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/xen/include/acpi/actbl.h b/xen/include/acpi/actbl.h
index 856945d..34e8673 100644
--- a/xen/include/acpi/actbl.h
+++ b/xen/include/acpi/actbl.h
@@ -244,7 +244,8 @@ struct acpi_table_fadt {
u32 flags;  /* Miscellaneous flag bits (see below for 
individual flags) */
struct acpi_generic_address reset_register; /* 64-bit address of 
the Reset register */
u8 reset_value; /* Value to write to the reset_register port to 
reset the system */
-   u8 reserved4[3];/* Reserved, must be zero */
+u16 arm_boot_flags; /* ARM Boot Architecture Flags (see below for 
individual flags) */
+u8 minor_version;   /* Minor version of this FADT structure */


The indentation is wrong. Beware that Xen is using space rather than tab 
for the indentation.



u64 Xfacs;  /* 64-bit physical address of FACS */
u64 Xdsdt;  /* 64-bit physical address of DSDT */
struct acpi_generic_address xpm1a_event_block;  /* 64-bit Extended 
Power Mgt 1a Event Reg Blk address */
@@ -259,7 +260,7 @@ struct acpi_table_fadt {
struct acpi_generic_address sleep_status;   /* 64-bit Sleep Status 
register */
  };

-/* Masks for FADT Boot Architecture Flags (boot_flags) */
+/* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) [Vx]=Introduced 
in this FADT revision */


What does "this FADT revision" means? Please be more specific by giving 
the version.




  #define ACPI_FADT_LEGACY_DEVICES(1)   /* 00: [V2] System has LPC or 
ISA bus devices */
  #define ACPI_FADT_8042  (1<<1)  /* 01: [V3] System has an 
8042 controller on port 60/64 */
@@ -270,6 +271,11 @@ struct acpi_table_fadt {

  #define FADT2_REVISION_ID   3

+/* Masks for FADT ARM Boot Architecture Flags (arm_boot_flags) */
+
+#define ACPI_FADT_PSCI_COMPLIANT(1)/* 00: PSCI 0.2+ is implemented 
*/
+#define ACPI_FADT_PSCI_USE_HVC  (1<<1) /* 01: HVC must be used instead 
of SMC as the PSCI conduit */
+
  /* Masks for FADT flags */

  #define ACPI_FADT_WBINVD(1)   /* 00: [V1] The wbinvd 
instruction works properly */
@@ -345,7 +351,7 @@ enum acpi_prefered_pm_profiles {
   * FADT V5  size: 0x10C
   */
  #define ACPI_FADT_V1_SIZE   (u32) (ACPI_FADT_OFFSET (flags) + 4)
-#define ACPI_FADT_V2_SIZE   (u32) (ACPI_FADT_OFFSET (reserved4[0]) + 3)
+#define ACPI_FADT_V2_SIZE   (u32) (ACPI_FADT_OFFSET (arm_boot_flags) + 3)
  #define ACPI_FADT_V3_SIZE   (u32) (ACPI_FADT_OFFSET (sleep_control))
  #define ACPI_FADT_V5_SIZE   (u32) (sizeof (struct acpi_table_fadt))


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 10/35] asm / arm: Introduce cputype.h

[Julien Grall]

Hi Parth,

On 04/02/2015 14:01, parth.di...@linaro.org wrote:

From: Naresh Bhat 

Introduce cputype.h file for arm


Most of the defines introduced already exists in asm-arm/processor.h

If you really want a separate file, which I don't think it's necessary, 
please drop the defines in asm-arm/processor.h




Signed-off-by: Naresh Bhat 
---
  xen/include/asm-arm/cputype.h | 83 +++
  1 file changed, 83 insertions(+)
  create mode 100644 xen/include/asm-arm/cputype.h

diff --git a/xen/include/asm-arm/cputype.h b/xen/include/asm-arm/cputype.h
new file mode 100644
index 000..0b454cc
--- /dev/null
+++ b/xen/include/asm-arm/cputype.h
@@ -0,0 +1,83 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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 __ASM_CPUTYPE_H
+#define __ASM_CPUTYPE_H
+
+#include 
+
+#define INVALID_HWIDULONG_MAX
+
+#define MPIDR_HWID_BITMASK  0xff00ff
+
+#define MPIDR_LEVEL_BITS_SHIFT  3
+#define MPIDR_LEVEL_MASK((1 << MPIDR_LEVEL_BITS) - 1)
+
+#define MPIDR_LEVEL_SHIFT(level) \
+(((1 << level) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
+
+#define MPIDR_AFFINITY_LEVEL(mpidr, level) \
+((mpidr >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
+
+#define read_cpuid(reg) ({  \
+u64 __val;  \
+asm("mrs%0, " #reg : "=r" (__val)); \
+__val;  \
+})


This is ARM64 specific, this will never work on ARM32.



+#define ARM_CPU_IMP_ARM 0x41
+#define ARM_CPU_IMP_APM 0x50
+
+#define ARM_CPU_PART_AEM_V8 0xD0F0
+#define ARM_CPU_PART_FOUNDATION 0xD000
+#define ARM_CPU_PART_CORTEX_A57 0xD070
+
+#define APM_CPU_PART_POTENZA0x


Why thoses define?


+#ifndef __ASSEMBLY__
+
+/*
+ * The CPU ID never changes at run time, so we might as well tell the
+ * compiler that it's constant.  Use this function to read the CPU ID
+ * rather than directly reading processor_id or read_cpuid() directly.
+ */
+static inline u32 __attribute_const__ read_cpuid_id(void)
+{
+return read_cpuid(MIDR_EL1);
+}
+
+static inline u64 __attribute_const__ read_cpuid_mpidr(void)
+{
+return read_cpuid(MPIDR_EL1);
+}
+
+static inline unsigned int __attribute_const__ read_cpuid_implementor(void)
+{
+return (read_cpuid_id() & 0xFF00) >> 24;
+}
+
+static inline unsigned int __attribute_const__ read_cpuid_part_number(void)
+{
+return (read_cpuid_id() & 0xFFF0);
+}
+
+static inline u32 __attribute_const__ read_cpuid_cachetype(void)
+{
+return read_cpuid(CTR_EL0);
+}


Rather than introducing helpers which will only work for ARM64, please 
use READ_SYSREG(...). See usage in arch/arm/smpboot.c


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 09/35] Add cpumask_next_zero set_cpu_present and possible

[Julien Grall]

Hi Parth,

On 04/02/2015 14:01, parth.di...@linaro.org wrote:

From: Naresh Bhat 

Introduce and use cpumask_next_zero, set_cpu_present and set_cpu_possible.


Why don't you use cpu_possible_map, cpu_present_map?


Signed-off-by: Naresh Bhat 
---
  xen/common/cpu.c  | 18 ++
  xen/include/xen/cpumask.h | 40 
  2 files changed, 58 insertions(+)

diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 630881e..da399c9 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -216,3 +216,21 @@ void enable_nonboot_cpus(void)

  cpumask_clear(&frozen_cpus);
  }
+
+static DECLARE_BITMAP(cpu_present_bits, NR_CPUS) __read_mostly;
+static DECLARE_BITMAP(cpu_possible_bits, NR_CPUS) __read_mostly;
+void set_cpu_possible(unsigned int cpu, bool possible)
+{
+if ( possible )
+ cpumask_set_cpu(cpu, to_cpumask(cpu_possible_bits));
+else
+cpumask_clear_cpu(cpu, to_cpumask(cpu_possible_bits));
+}
+
+void set_cpu_present(unsigned int cpu, bool present)
+{
+if ( present )
+cpumask_set_cpu(cpu, to_cpumask(cpu_present_bits));
+else
+cpumask_clear_cpu(cpu, to_cpumask(cpu_present_bits));
+}


What's the purpose of declaring two bitmaps but never use them?


diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h
index 850b4a2..209483e 100644
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -78,6 +78,7 @@
  #include 
  #include 
  #include 
+#include 


Please don't include stdbool.h and use bool_t instead (defined in types.h)



  typedef struct cpumask{ DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;

@@ -295,6 +296,22 @@ static inline int cpulist_scnprintf(char *buf, int len,
  }

  /*
+ * cpumask_next_zero - get the next unset cpu in a cpumask
+ * @n: the cpu prior to the place to search (ie. return will be > @n)
+ * @srcp: the cpumask pointer
+ *
+ * Returns >= nr_cpu_ids if no further cpus unset.
+ */
+static inline unsigned int cpumask_next_zero(int n, const cpumask_t *srcp)
+{
+/* -1 is a legal arg here. */
+if (n != -1)
+cpumask_check(n);
+
+return find_next_zero_bit(srcp->bits, nr_cpu_ids, n+1);
+}
+
+/*
   * cpumask_var_t: struct cpumask for stack usage.
   *
   * Oh, the wicked games we play!  In order to make kernel coding a
@@ -440,6 +457,29 @@ extern cpumask_t cpu_present_map;
  #define for_each_online_cpu(cpu)   for_each_cpu(cpu, &cpu_online_map)
  #define for_each_present_cpu(cpu)  for_each_cpu(cpu, &cpu_present_map)

+/* Wrappers for arch boot code to manipulate normally-constant masks */
+void set_cpu_possible(unsigned int cpu, bool possible);
+void set_cpu_present(unsigned int cpu, bool present);
+
+/*
+ * to_cpumask - convert an NR_CPUS bitmap to a struct cpumask *
+ * @bitmap: the bitmap
+ *
+ * There are a few places where cpumask_var_t isn't appropriate and
+ * static cpumasks must be used (eg. very early boot), yet we don't
+ * expose the definition of 'struct cpumask'.
+ *
+ * This does the conversion, and can be used as a constant initializer.
+ */
+#define to_cpumask(bitmap)  \
+((struct cpumask *)(1 ? (bitmap)\
+: (void *)sizeof(__check_is_bitmap(bitmap
+
+static inline int __check_is_bitmap(const unsigned long *bitmap)
+{
+return 1;
+}
+
  /* Copy to/from cpumap provided by control tools. */
  struct xenctl_bitmap;
  int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *, const cpumask_t *);



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 05/35] ARM64 / ACPI: Parse FADT table to get PSCI flags

[Julien Grall]

Hi Parth,

On 04/02/2015 14:01, parth.di...@linaro.org wrote:

From: Naresh Bhat 

There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
the former signals to the OS that the hardware is PSCI compliant.
The latter selects the appropriate conduit for PSCI calls by
toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
(SMC).

FADT table contains such information, parse FADT to get the flags
for furture usage. At the same time, only ACPI 5.1 or higher verison
supports PSCI, and FADT Major.Minor version was introduced in ACPI
5.1, so we will check the version and only parse FADT table with
version >= 5.1.

If firmware provides ACPI tables with ACPI version less than 5.1,
OS will be messed up with those information, so disable ACPI if we
get an FADT table with version less that 5.1.

Signed-off-by: Hanjun Guo 
Signed-off-by: Naresh Bhat 
---
  xen/arch/arm/arm64/acpi/arm-core.c | 54 +++---
  xen/arch/arm/setup.c   |  1 +
  xen/include/asm-arm/acpi.h |  2 ++
  3 files changed, 54 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c
index 50a83d6..2b7e2ef 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -25,6 +25,7 @@
  #if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
  #include 
  #include 
+#include 

  #include 

@@ -42,6 +43,12 @@ EXPORT_SYMBOL(acpi_disabled);
  int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */
  EXPORT_SYMBOL(acpi_pci_disabled);

+/* 1 to indicate PSCI is implemented */
+int acpi_psci_present;


bool


+
+/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
+int acpi_psci_use_hvc;


bool


+
  enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;

  struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
@@ -58,7 +65,7 @@ EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
   * failure: return =< 0
   */
  //int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int 
polarity)
-unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low)
+unsigned int acpi_register_gsi(u32 gsi, int edge_level, int active_high_low)


Spurious change.


  {
  return -1;
  }
@@ -69,6 +76,33 @@ void acpi_unregister_gsi(u32 gsi)
  }
  EXPORT_SYMBOL_GPL(acpi_unregister_gsi);

+static int __init acpi_parse_fadt(struct acpi_table_header *table)
+{
+   struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
+
+   /*
+* Revision in table header is the FADT Major version,
+* and there is a minor version of FADT which was introduced
+* by ACPI 5.1, we only deal with ACPI 5.1 or higher version
+* to get arm boot flags, or we will disable ACPI.
+*/
+   if ( table->revision < 5 || fadt->minor_version < 1 ) {
+   printk("FADT version is %d.%d, no PSCI support, should be 5.1 or 
higher\n",
+   table->revision, fadt->minor_version);
+   acpi_psci_present = 0;
+   disable_acpi();
+   return -EINVAL;
+   }
+
+   if ( acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT )
+   acpi_psci_present = 1;


You never use this function, so either something is wrong in this 
series, or I may have miss a patch... Does SMP boot is supported with 
ACPI on Xen? If so, how do you do it? All the PSCI code is based on the 
device tree. So by any chance, does Xen still use the DT?



+
+   if ( acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC )
+   acpi_psci_use_hvc = 1;


This flags should never be enabled when for SMP bring up in the 
hypervisor. If it's the case, we should print an error.



+
+   return 0;
+}
+
  /*
   * acpi_boot_table_init() called from setup_arch(), always.
   *  1. find RSDP and get its address, and then find XSDT
@@ -81,12 +115,12 @@ int __init acpi_boot_table_init(void)
  {
  int error;
  /* If acpi_disabled, bail out */
-if (acpi_disabled)
+if ( acpi_disabled )


This coding style change should belong to the patch which add the code 
(if I'm not mistaken patch #3).



  return 1;

  /* Initialize the ACPI boot-time table parser. */
  error = acpi_table_init();
-if (error)
+if ( error )


Ditto.


  {
  disable_acpi();
  return error;
@@ -94,4 +128,18 @@ int __init acpi_boot_table_init(void)

  return 0;
  }
+
+int __init acpi_boot_init(void)
+{
+int err = 0;
+/* If acpi_disabled, bail out */
+if (acpi_disabled)


if ( acpi_disabled )


+return -ENODEV;
+
+err = acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
+if ( err )
+printk("Can't find FADT\n");
+
+return err;
+}
  #endif
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7ae126b..3531d47 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -749,6 +749,7 @@ void __init start_xen(unsigned lo

Re: [Xen-devel] [PATCH RFC 03/35] xen: arm64: ACPI: Add basic ACPI initialization

[Julien Grall]

Hi Parth,

On 04/02/2015 14:01, parth.di...@linaro.org wrote:

From: Naresh Bhat 

This patch introduce arm-core.c and its related header file

- asm/acpi.h for arch specific variables and functions needed by
   ACPI driver core;
- arm-core.c for ARM64 related ACPI implementation for ACPI driver
   core;

acpi_boot_table_init() will be called in setup_arch()
to get the RSDP and all the table pointers. with this patch,
we can get ACPI boot-time tables from firmware on ARM64.

Signed-off-by: Naresh Bhat 
---
  xen/arch/arm/arm64/Makefile|  1 +
  xen/arch/arm/arm64/acpi/Makefile   |  1 +
  xen/arch/arm/arm64/acpi/arm-core.c | 97 ++
  xen/arch/arm/setup.c   | 14 +-
  xen/include/xen/acpi.h | 11 +
  5 files changed, 123 insertions(+), 1 deletion(-)
  create mode 100644 xen/arch/arm/arm64/acpi/Makefile
  create mode 100644 xen/arch/arm/arm64/acpi/arm-core.c

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index c7243f5..49d135f 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,4 +1,5 @@
  subdir-y += lib
+subdir-y += acpi


It would be more logic to include this directory only when HAS_ACPI is 
defined.


It would be smth like:

subdir-$(HAS_ACPI) += acpi

[...]


diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c


I think "arm" is pointless in the filename. Maybe core.c would be a 
better name?



new file mode 100644
index 000..50a83d6
--- /dev/null
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -0,0 +1,97 @@


[..]


+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)


Compiling the directory only when HAS_ACPI is enabled would avoid a 
pointless #ifdef here.



+#include 
+#include 
+
+#include 


You should be consistent here, the acpi.h headers is in asm so generic 
to all ARM architecture but the ACPI code actually reside in an ARM64 
directory.


Even though ACPI is only ARM64, this code doesn't seem ARM64 specific. 
So I would move the directory in arch/arm/



+
+/*
+ * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
+ * variable is still required by the ACPI core
+ */
+u32 acpi_rsdt_forced;


I didn't find any usage for this in Xen.


+int acpi_noirq;/* skip ACPI IRQ initialization */


This is set but never used.


+int acpi_strict;


I didn't find any usage for this in Xen.


+int acpi_disabled;
+EXPORT_SYMBOL(acpi_disabled);
+
+int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */
+EXPORT_SYMBOL(acpi_pci_disabled);


This is set but never used.


+enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;


Why do you define acpi_irq_model to ACPI_IRQ_MODEL_PLATFORM here and in 
patch #15, change to ACPI_IRQ_MODEL_PLATFORM?


Furthermore, you set it, but never use it.


+
+struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */


I didn't find any usage in Xen.


+
+int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
+{
+*irq = -1;
+return 0;
+}
+EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);


This function is never used. I found a prototype defined in the headers 
(xen/acpi.h) few years ago but not implemented on x86.


I suspect that we forgot to drop the prototype at some point. Can you 
send a patch to remove it?



+
+/*
+ * success: return IRQ number (>0)
+ * failure: return =< 0
+ */
+//int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
+unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low)
+{
+return -1;
+}
+EXPORT_SYMBOL_GPL(acpi_register_gsi);
+
+void acpi_unregister_gsi(u32 gsi)
+{
+}
+EXPORT_SYMBOL_GPL(acpi_unregister_gsi);


Ditto for these 2 functions.


+/*
+ * acpi_boot_table_init() called from setup_arch(), always.
+ *  1. find RSDP and get its address, and then find XSDT
+ *  2. extract all tables and checksums them all
+ *
+ * We can parse ACPI boot-time tables such as FADT, MADT after
+ * this function is called.
+ */
+int __init acpi_boot_table_init(void)
+{
+int error;
+/* If acpi_disabled, bail out */
+if (acpi_disabled)
+return 1;
+
+/* Initialize the ACPI boot-time table parser. */
+error = acpi_table_init();
+if (error)
+{
+disable_acpi();
+return error;
+}
+
+return 0;
+}
+#endif
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 3991d64..7ae126b 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -45,6 +45,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 

  struct bootinfo __initdata bootinfo;

@@ -737,7 +739,18 @@ void __init start_xen(unsigned long boot_phys_offset,

  setup_mm(fdt_paddr, fdt_size);

+system_state = SYS_STATE_boot;
+


Hmmm why? Is it because of the memory allocator in ACPI? If so, you 
should justify a such change and drop the other system_state = 
SYS_STATE_boot within this function.



  vm_init();
+
+/*
+ * Parse the AC

[Xen-devel] [xen-4.3-testing test] 34153: regressions - FAIL

[xen . org]

flight 34153 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34153/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install  fail like 33687

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install  fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-armhf-armhf-xl-sedf  5 xen-boot fail   never pass
 test-armhf-armhf-xl-credit2   5 xen-boot fail   never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-armhf-armhf-xl-midway5 xen-boot fail   never pass
 test-armhf-armhf-xl-sedf-pin  5 xen-boot fail   never pass
 test-armhf-armhf-xl   5 xen-boot fail   never pass
 test-armhf-armhf-libvirt  5 xen-boot fail   never pass
 test-armhf-armhf-xl-multivcpu  5 xen-boot fail  never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/checkfail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass

version targeted for testing:
 xen  ef73de2a84a3042c3481c9a521e8e0c756b793f2
baseline version:
 xen  f70c066bb55ed967a8e98bf30a50cf0a7a6155f9


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Dan Carpenter 
  Daniel De Graaf 
  Ian Campbell 
  Jan Beulich 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Tim Deegan 


jobs:
 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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd

Re: [Xen-devel] [PATCH RFC 19/35] ACPI / GICv2: Add GIC specific ACPI boot support

[Parth Dixit]

On 4 February 2015 at 20:13, G Gregory  wrote:
> On 4 February 2015 at 14:02,   wrote:
>> From: Naresh Bhat 
>>
>> ACPI on Xen hypervisor uses MADT table for proper GIC initialization.
>> It needs to parse GIC related subtables, collect CPU interface and 
>> distributor
>> addresses and call driver initialization function (which is hardware
>> abstraction agnostic). In a similar way, FDT initialize GICv1/2.
>>
>> NOTE: This commit allow to initialize GICv1/2 only.
>>
>> Signed-off-by: Tomasz Nowicki 
>> Signed-off-by: Graeme Gregory 
>
> I do not recognise any of the code here and I'm pretty sure I have not
> worked on any of it. I am unsure what the rules on Signed-off-by: is
> but I think this one is wrong.
>
> Graeme
I will remove it. I inherited this patch from naresh with your
signoff , so i did not removed it. Thanks for alerting me.
Policy is to not remove the previous signoff's in a patch and add
signoff only in case
some logical change is made to the patch.

Parth
>> Signed-off-by: Hanjun Guo 
>> Signed-off-by: Naresh Bhat 
>> Signed-off-by: Parth Dixit 
>>
>> Conflicts:
>>
>> xen/arch/arm/irq.c
>> ---
>>  xen/arch/arm/gic-v2.c  | 271 
>> +
>>  xen/arch/arm/setup.c   |   3 +-
>>  xen/include/asm-arm/acpi.h |   2 +
>>  3 files changed, 275 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> index faad1ff..cb1d205 100644
>> --- a/xen/arch/arm/gic-v2.c
>> +++ b/xen/arch/arm/gic-v2.c
>> @@ -777,6 +777,277 @@ DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
>>  .init = gicv2_init,
>>  DT_DEVICE_END
>>
>> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/*
>> + * Hard code here, we can not get memory size from MADT (but FDT does),
>> + * this size can be inferred from GICv2 spec
>> + */
>> +
>> +#define ACPI_GIC_DIST_MEM_SIZE   0x0001 // (SZ_64K)
>> +#define ACPI_GIC_CPU_IF_MEM_SIZE 0x2000 // (SZ_8K)
>> +
>> +static DEFINE_PER_CPU(u64, gic_percpu_cpu_base);
>> +static cpumask_t gic_acpi_cpu_mask;
>> +static u64 dist_phy_base;
>> +
>> +static int __init
>> +gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
>> +const unsigned long end)
>> +{
>> +struct acpi_madt_generic_interrupt *processor;
>> +unsigned int cpu;
>> +
>> +processor = (struct acpi_madt_generic_interrupt *)header;
>> +
>> +if (BAD_MADT_ENTRY(processor, end))
>> +return -EINVAL;
>> +for_each_possible_cpu(cpu) {
>> +/*
>> + * FIXME: This condition is failing.
>> + * In Xen we first want to bring/initialize the GIC in hypervisor 
>> with single CPU
>> + * if (processor->mpidr == cpu_logical_map(cpu))
>> + */
>> +goto find;
>> +}
>> +
>> +printk("\nUnable to find CPU corresponding to GIC CPU entry [mpdir 
>> %lx]\n",
>> +(long)processor->mpidr);
>> +
>> +return 0;
>> +
>> +find:
>> +/* Read from APIC table and fill up the GIC variables */
>> +gicv2.dbase = processor->redist_base_address;
>> +gicv2.cbase = processor->base_address;
>> +gicv2.hbase = processor->gich_base_address;
>> +gicv2.vbase = processor->gicv_base_address;
>> +gicv2_info.maintenance_irq = processor->vgic_maintenance_interrupt;
>> +if( processor->flags & ACPI_MADT_ENABLED )
>> +{
>> +if( processor->flags & ACPI_MADT_VGIC )
>> +acpi_set_irq(gicv2_info.maintenance_irq, 
>> DT_IRQ_TYPE_EDGE_BOTH);
>> +else
>> +acpi_set_irq(gicv2_info.maintenance_irq, 
>> DT_IRQ_TYPE_LEVEL_MASK);
>> +}
>> +
>> +/*
>> + * Do not validate CPU i/f base, we can still use "Local Interrupt
>> + * Controller Address" from MADT header instead.
>> + */
>> +per_cpu(gic_percpu_cpu_base, cpu) = processor->base_address;
>> +cpumask_set_cpu(cpu, &gic_acpi_cpu_mask);
>> +
>> +return 0;
>> +}
>> +
>> +static int __init
>> +gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
>> +const unsigned long end)
>> +{
>> +struct acpi_madt_generic_distributor *dist;
>> +
>> +dist = (struct acpi_madt_generic_distributor *)header;
>> +
>> +if (BAD_MADT_ENTRY(dist, end))
>> +return -EINVAL;
>> +
>> +dist_phy_base = dist->base_address;
>> +
>> +return 0;
>> +}
>> +
>> +static int gic_acpi_validate_init(u64 madt_cpu_addr)
>> +{
>> +void __iomem *cpu_base, *dist_base;
>> +u64 gic_cpu_base = 0;
>> +unsigned int cpu;
>> +
>> +/* Process all GICC entries delivered by MADT */
>> +if (!cpumask_empty(&gic_acpi_cpu_mask)) {
>> +/*
>> + * If MADT contains at least one GICC entry, it must be BSP
>> +

[Xen-devel] [Patch v4 01/23] ACPICA: Resources: Provide common part for struct acpi_resource_address structures.

[Jiang Liu]

From: Lv Zheng 

struct acpi_resource_address and struct acpi_resource_extended_address64 share 
substracts
just at different offsets. To unify the parsing functions, OSPMs like Linux
need a new ACPI_ADDRESS64_ATTRIBUTE as their substructs, so they can
extract the shared data.

This patch also synchronizes the structure changes to the Linux kernel.
The usages are searched by matching the following keywords:
1. acpi_resource_address
2. acpi_resource_extended_address
3. ACPI_RESOURCE_TYPE_ADDRESS
4. ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS
And we found and fixed the usages in the following files:
 arch/ia64/kernel/acpi-ext.c
 arch/ia64/pci/pci.c
 arch/x86/pci/acpi.c
 arch/x86/pci/mmconfig-shared.c
 drivers/xen/xen-acpi-memhotplug.c
 drivers/acpi/acpi_memhotplug.c
 drivers/acpi/pci_root.c
 drivers/acpi/resource.c
 drivers/char/hpet.c
 drivers/pnp/pnpacpi/rsparser.c
 drivers/hv/vmbus_drv.c

Build tests are passed with defconfig/allnoconfig/allyesconfig and
defconfig+CONFIG_ACPI=n.

Original-by: Thomas Gleixner 
Original-by: Jiang Liu 
Signed-off-by: Lv Zheng 
Signed-off-by: Jiang Liu 
---
 arch/ia64/kernel/acpi-ext.c   |6 ++--
 arch/ia64/pci/pci.c   |   14 -
 arch/x86/pci/acpi.c   |   26 
 arch/x86/pci/mmconfig-shared.c|6 ++--
 drivers/acpi/acpi_memhotplug.c|8 ++---
 drivers/acpi/acpica/rsaddr.c  |9 +++---
 drivers/acpi/acpica/rsdumpinfo.c  |   59 +++--
 drivers/acpi/acpica/rsxface.c |   10 +++
 drivers/acpi/pci_root.c   |6 ++--
 drivers/acpi/resource.c   |   24 +++
 drivers/char/hpet.c   |4 +--
 drivers/hv/vmbus_drv.c|4 +--
 drivers/pnp/pnpacpi/rsparser.c|   16 +-
 drivers/xen/xen-acpi-memhotplug.c |8 ++---
 include/acpi/acrestyp.h   |   40 +++--
 15 files changed, 125 insertions(+), 115 deletions(-)

diff --git a/arch/ia64/kernel/acpi-ext.c b/arch/ia64/kernel/acpi-ext.c
index 8b9318d311a0..bd09bf74f187 100644
--- a/arch/ia64/kernel/acpi-ext.c
+++ b/arch/ia64/kernel/acpi-ext.c
@@ -69,10 +69,10 @@ static acpi_status find_csr_space(struct acpi_resource 
*resource, void *data)
status = acpi_resource_to_address64(resource, &addr);
if (ACPI_SUCCESS(status) &&
addr.resource_type == ACPI_MEMORY_RANGE &&
-   addr.address_length &&
+   addr.address.address_length &&
addr.producer_consumer == ACPI_CONSUMER) {
-   space->base = addr.minimum;
-   space->length = addr.address_length;
+   space->base = addr.address.minimum;
+   space->length = addr.address.address_length;
return AE_CTRL_TERMINATE;
}
return AE_OK;   /* keep looking */
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 900cc93e5409..48cc65705db4 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -188,12 +188,12 @@ static u64 add_io_space(struct pci_root_info *info,
 
name = (char *)(iospace + 1);
 
-   min = addr->minimum;
-   max = min + addr->address_length - 1;
+   min = addr->address.minimum;
+   max = min + addr->address.address_length - 1;
if (addr->info.io.translation_type == ACPI_SPARSE_TRANSLATION)
sparse = 1;
 
-   space_nr = new_space(addr->translation_offset, sparse);
+   space_nr = new_space(addr->address.translation_offset, sparse);
if (space_nr == ~0)
goto free_resource;
 
@@ -247,7 +247,7 @@ static acpi_status resource_to_window(struct acpi_resource 
*resource,
if (ACPI_SUCCESS(status) &&
(addr->resource_type == ACPI_MEMORY_RANGE ||
 addr->resource_type == ACPI_IO_RANGE) &&
-   addr->address_length &&
+   addr->address.address_length &&
addr->producer_consumer == ACPI_PRODUCER)
return AE_OK;
 
@@ -284,7 +284,7 @@ static acpi_status add_window(struct acpi_resource *res, 
void *data)
if (addr.resource_type == ACPI_MEMORY_RANGE) {
flags = IORESOURCE_MEM;
root = &iomem_resource;
-   offset = addr.translation_offset;
+   offset = addr.address.translation_offset;
} else if (addr.resource_type == ACPI_IO_RANGE) {
flags = IORESOURCE_IO;
root = &ioport_resource;
@@ -297,8 +297,8 @@ static acpi_status add_window(struct acpi_resource *res, 
void *data)
resource = &info->res[info->res_num];
resource->name = info->name;
resource->flags = flags;
-   resource->start = addr.minimum + offset;
-   resource->end = resource->start + addr.address_length - 1;
+   resource->start = addr.address.minimum + offset;
+   resource->end = resource->start + addr.address.address_length - 1;
info->res_offset[info->res_num] = offset;
 
if (insert_resource(root, resource)) {
diff --git 

[Xen-devel] [xen-4.4-testing test] 34151: tolerable FAIL - PUSHED

[xen . org]

flight 34151 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34151/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 34091

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-sedf 10 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   10 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2   5 xen-boot fail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/checkfail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass

version targeted for testing:
 xen  52e190cacf95046c99a52947aa12d7c0a2225b4d
baseline version:
 xen  cc05e029d1ba7772ca3fd45bbcee081f527089f5


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Dan Carpenter 
  Daniel De Graaf 
  Ian Campbell 
  Jan Beulich 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Tim Deegan 


jobs:
 build-amd64-xend pass
 build-i386-xend  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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-amd64

Re: [Xen-devel] [Xen-users] Xen memory allocation for dom0 and domU

[Jintack Lim]

On Wed, Feb 4, 2015 at 9:55 PM, Jintack Lim  wrote:
> On Wed, Feb 4, 2015 at 11:41 AM, Ian Campbell  wrote:
>>
>> Patch for all this below. Jan, I don't think there is any (possibly
>> historical on x86_32) x86 option we should be trying to be consistent
>> with.
>
> Thanks, Ian.
> Your patch works well!
>

Will this patch be pushed to the upstream?

I was not able to find this patch in here.
 http://xenbits.xen.org/gitweb/?p=xen.git;a=summary
Could you tell me where is the patch now?

> Jintack


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

Re: [Xen-devel] apic-v reduce network performance in my test case

[Liuqiming (John)]

On 2015/2/5 10:57, Liuqiming (John) wrote:

sorry for late replay

On 2015/2/3 23:32, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 03, 2015 at 10:24:08AM +0800, Liuqiming (John) wrote:
> > On 2015/2/2 22:59, Konrad Rzeszutek Wilk wrote:
> >> On Mon, Feb 02, 2015 at 09:58:57PM +0800, Liuqiming (John) wrote:
> >>> Hi Jan,
> >>> Thanks for the reply.
> >>>
> >>> On 2015/2/2 18:12, Jan Beulich wrote:
> >>> On 31.01.15 at 11:29,  wrote:
> > Recently I met an odd performance problem: when I turn
> on APIC
> > Virtualization feature (apicv=1), the network performance of a
> windows
> > guest become worse.
> >
> > My test case like this: host only have one windows 2008
> R2 HVM
> > guest running,and this guest has a SR-IOV VF network passthrough
> to it.
> > Guest using this network access a NAS device. No fontend or
> backend of
> > network and storage, all data transfered through network.
> >
> > The xentrace data shows: the mainly difference between
> apicv and
> > non-apicv, is the way guest write apic registers, and
> > EXIT_REASON_MSR_WRITE vmexit cost much more time than
> > EXIT_REASON_APIC_WRITE, but when using WRMSR, the PAUSE vmexit
> is much
> > less than using APIC-v.
> 
>  There being heavier use of the pause VMEXIT doesn't by itself say
>  anything, I'm afraid. It may suggest that you have a C-state exit
>  latency problem - try lowering the maximum C-state allowed, or
>  disabling use of C-states altogether.
> >>> Sorry, I forgot to mention  my test scenario:
> >>> Its a video test suite,I am not sure what the logic inside the
> tools exactly (not opensource tool).
> >>> The basic flow is:
> >>>1) test suite start several thread to read video file from
> disk (from NAS through network in my case)
> >>>2) decode these video data as a frame one by one
> >>>3) if  any frame delay more than 40ms, then mark as lost
> >>>
> >>> test result:
> >>>  apicv=1,  there can be 15 thread running at the same time
> without lost frame
> >>>  apicv=0,  there can be 22 thread running at the same time
> without lost frame
> >>>
> >>> so when I'm saying apicv reduce the performance, I got the
> conclusion from the test result not from what xentrace shows.
> 
> > In commit 7f2e992b824ec62a2818e64390ac2ccfbd74e6b7
> > "VMX/Viridian: suppress MSR-based APIC suggestion when having
> APIC-V",
> > msr based apic is disabled when apic-v is on, I wonder can they
> co-exist
> > in some way? seems for windows guest msr-based apic has better
> performance.
> 
>  The whole purpose is to avoid the costly MSR access exits. Why
>  would you want to reintroduce that overhead?
> 
>  Jan
> 
> >>> I agree to avoid the MSR access vmexit by using apicv, I just do
> not know what's the side effect.
> >>> Because from the test result,  apicv replacing  msr-based access
> brings performance reduction.
> >>
> >> It sounds like it brings latency disruption, not neccessarily
> performance reduction.
> >>
> >> What happens if you run with the cpufreq turned to performance, or
> as Jan suggested -
> >> with disabling C-states?
> >>
> > I have tried disable C-states in BIOS, the test result is still the
> same.
> > There is no frontend-backend device in my test, dom0 is not
> involved, so you mean cpufreq in DomU, right?
>
> I meant on Xen (cpufreq=performance). But if you disable C-states then
> that should
> not matter.
>
> > I have no idea how to change cpufreq of a windows os but I will
> figure out and try.
>
> That should not be needed.
>
> But back to your problem. When you say you have 'frame delay' - is it
> because
> of the NAS storage not getting the I/Os fast enough?
>
The  NAS storage should not be the bottleneck, it's a ramdisk connected
with 10G network card.
Besides, I'am using the same test environment, the only difference is
whether apicv=1 or not.

> What are you using as network device? Is it an SR-IOV device or an
> emulated
> device (e1000, ne2k, rtl81..?)?
The vm using Intel Corporation 82599 Ethernet Controller Virtual
Function passthrough network and has the corresponding driver installed.
> >>
> >>> ___
> >>> Xen-devel mailing list
> >>> Xen-devel@lists.xen.org
> >>> http://lists.xen.org/xen-devel
> >>
> >> .
> >>
> >
When  tracing the performance problem, I found whether apicv is on
change the result.
And after investigating the code, turns out CPUID4A_MSR_BASED_APIC
presents or not is the key factor.





sorry, forget cc the list



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

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

[xen . org]

flight 34146 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34146/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 
33480
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 33480
 test-amd64-amd64-xl-win7-amd64  7 windows-install fail REGR. vs. 33480
 test-amd64-i386-xl-win7-amd64  7 windows-install  fail REGR. vs. 33480
 test-amd64-i386-xl-winxpsp3   7 windows-install   fail REGR. vs. 33480
 test-amd64-amd64-xl-winxpsp3  7 windows-install   fail REGR. vs. 33480
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install  fail REGR. vs. 33480
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 33480
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install fail REGR. vs. 33480
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 33480
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-installfail REGR. vs. 33480
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-installfail REGR. vs. 33480
 test-amd64-i386-freebsd10-amd64  8 guest-startfail REGR. vs. 33480
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 
33480
 test-amd64-i386-rhel6hvm-amd  7 redhat-installfail REGR. vs. 33480
 test-amd64-i386-freebsd10-i386  8 guest-start fail REGR. vs. 33480
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail REGR. vs. 33480
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install fail REGR. vs. 33480
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 33480
 test-amd64-i386-rhel6hvm-intel  7 redhat-install  fail REGR. vs. 33480

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33480

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-armhf-armhf-xl-sedf 10 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-midway   10 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-armhf-armhf-xl-credit2   5 xen-boot fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass

version targeted for testing:
 qemuud5fbb4c9ed52d97aebe5994d8a857c74c0d95a92
baseline version:
 qemuu1e42c353469cb58ca4f3b450eea4211af7d0b147


People who touched revisions under test:
  Alex Suykov 
  Alexander Graf 
  Amit Shah 
  Andreas Färber 
  Aurelien Jarno 
  Avi Kivity 
  Bastian Koppelmann 
  Ben Taylor 
  Benjamin Herrenschmidt 
  Bharata B Rao 
  Blue Swirl 
  Christian Borntraeger 
  Christophe Lyon 
  Cornelia Huck 
  Dinar Valeev 
  Don Koch 
  Ed Swierk 
  Eduardo Habkost 
  Eduardo Otubo 
  Fabrice Bellard 
  Fam Zheng 
  Felix Janda 
  Gerd Hoffmann 
  Gonglei 
  Guan Xuetao 
  Igor Mammedov 
  Jan Kiszka 
  Jeff Cody 
  Jiri Slaby 
  Juan Quintela 
  Kevin Wolf 
  Marc-André Lureau 
  Mark Cave-Ayland 
  Max Filippov 
  Max Reitz 
  Michael S. Tsirkin 
  Paolo Bonzini 
  Paul Brook 
  Paul Durrant 
  Peter Maydell 
  Richard Henderson 
  Richard Sandiford 
  Riku Voipio 
  Stefan Weil 
  Stefano Stabellini 
  Wei Huang 


jobs:
 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-pvops   

Re: [Xen-devel] [Xen-users] Xen memory allocation for dom0 and domU

[Jintack Lim]

On Wed, Feb 4, 2015 at 11:41 AM, Ian Campbell  wrote:
>
> Patch for all this below. Jan, I don't think there is any (possibly
> historical on x86_32) x86 option we should be trying to be consistent
> with.

Thanks, Ian.
Your patch works well!

Jintack


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

Re: [Xen-devel] [v2][PATCH] libxl: add one machine property to support IGD GFX passthrough

[Chen, Tiejun]

On 2015/2/4 18:41, Ian Campbell wrote:

On Wed, 2015-02-04 at 09:34 +0800, Chen, Tiejun wrote:



   "-machine xxx,igd-passthru=on", to enable/disable that feature.
   And we also remove that old option, "-gfx_passthru", just from
   the case of LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN since actually
   no any qemu stream version really need or use that.

 ^up ?

What happens if you pass this new option to an older version of qemu
upstream? I suppose it doesn't fail any worse than passing -gfx_passthru
would have done.


Neither '-gfx_passthru' nor 'igd-passthrou' exists in any version of
qemu upstream. As I mentioned previously, just now we're starting to
support this in qemu upstream :)

But you known, on Xen side we have two qemu versions,
qemu-xen-traditional and qemu-xen. Although '-gfx_passthru' is adopted
in both two versions, just qemu-xen-traditional supports IGD passthrough
completely. For qemu-xen, we just have this term definition but without
that IGD passthrough feature support actually.


I'm afraid I don't follow, you seem to be simultaneously saying that
qemu-xen both does and does not support -gfx_passthru, which cannot be
right. I think from the following paragraph that what you mean is that
upstream qemu-xen has no support for any kind of -gfx_passthru command
line option in any form in any existing version, including the git tree.
Is that correct?


Yes.



(for the purposes of this conversation qemu-traditional is not of
interest)


Yes.




And now we're trying to support IGD passthrough in qemu stream. This
mean we should set 'device_model_version="qemu-xen", right? Then libxl
still pass '-gfx_passthru' to qemu upstream. But when I post other
stuffs to qemu upstream community to support IGD passthrough. Gerd
thought "-machine xxx,igd-passthru=on" is better than '-gfx_passthru'.
So finally you see this change in Xen/tools/libxl.



I have one more general concern, which is that hardcoding igd-passthru
here may make it harder to support gfx_passthru of other cards in the
future.


Actually gfx_passthrou is introduced to just work for IGD passthrough
since something specific to IGD is tricky, so we have to need such a
flag to handle this precisely, like its fixed at 00:02.0, and expose
some ISA bridge PCI config info and even host bridge PCI config info.

So I don't thing other cards need this.


If one type VGA device needs these sorts of workaround it is not
inconceivable that some other one will also need workarounds in the
future.



Indeed this is not something workaround, and I think in any type of VGA 
devices, we'd like to diminish this sort of thing gradually, right?


This mightn't come true in real world :)


Even if you don't consider non-IGD, what about the possibility of a
future IGD device which needs different (or additional, or fewer)
workarounds?


As far as I know we're trying to drop off those dependencies on ISA 
bridge and host bridge in our IGD's roadmap. Because in any pass through 
cases, theoretically we should access those resources dedicated to that 
device.





Somehow something in the stack needs to either detect or be told which
kind of card to passthrough. Automatic detection would be preferable,
but maybe being told by the user is the only possibility.


Based on the above explanation, something should be done before we
detect to construct that real card , so its difficulty to achieve this
goal currently.



Is there any way, given gfx_passthru as a boolean that libxl can
automatically figure out that IGD passthru is what is actually desired
-- e.g. by scanning the set of PCI devices given to the guest perhaps?


Sorry I don't understand what you mean here.


"gfx_passthru" is a generically named option, but it is being
implemented in an IGD specific way. We need to consider the possibility
of other graphics devices needing special handling in the future and
plan accordingly such that we can try and maintain our API guarantees
when this happens.


Agreed.



I think there are three ways to achieve that:

   * Make the libxl/xl option something which is not generic e.g.
 igd_passthru=1
   * Add a second option to allow the user to configure the kind of
 graphics device being passed thru (e.g. gfx_passthru=1,
 passthru_device="igd"), or combine the two by making the
 gfx_passthru option a string instead of a boolean.


It makes more sense but this mean we're going to change that existing 
rule in qemu-traditional. But here I guess we shouldn't consider that case.



   * Make libxl detect the type of graphics device somehow and
 therefore automatically determine when gfx_passthru=1 =>
 igd-passthru


This way confounds me all. Can libxl detect the graphics device *before* 
we intend to pass a parameter to active qemu?





  Currently, we have to set
something as follows,

gfx_passthru=1
pci=["00:02.0"]

This always works for qemu-xen-traditional.

But you should k

Re: [Xen-devel] [PATCH 3/3] mini-os: sort objects in binary archives

[Samuel Thibault]

Olaf Hering, le Tue 03 Feb 2015 12:45:37 +0100, a écrit :
> When building stubdom the mini-os objects are also linked into the
> binary. Unfortunately the linker will place them in the order found in
> the archive. Since this order is random the resulting stubdom binary
> differs when it was built from identical sources but on different
> build hosts. To help with creating a reproducible binary the elements
> in an archive must simply be sorted before passing them to $(AR).
> 
> Signed-off-by: Olaf Hering 
> Cc: Stefano Stabellini 
> Cc: Samuel Thibault 

Provided that the missing parenthesis gets fixed,

Acked-by: Samuel Thibault 

> ---
>  extras/mini-os/Makefile  | 4 ++--
>  extras/mini-os/arch/x86/Makefile | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
> index 6d6537e..fad016c 100644
> --- a/extras/mini-os/Makefile
> +++ b/extras/mini-os/Makefile
> @@ -148,9 +148,9 @@ arch_lib:
>  
>  ifeq ($(CONFIG_LWIP),y)
>  # lwIP library
> -LWC  := $(shell find $(LWIPDIR)/src -type f -name '*.c')
> +LWC  := $(sort $(shell find $(LWIPDIR)/src -type f -name '*.c'))
>  LWC  := $(filter-out %6.c %ip6_addr.c %ethernetif.c, $(LWC))
> -LWO  := $(patsubst %.c,%.o,$(LWC))
> +LWO  := $(patsubst %.c,%.o,$(LWC)
>  LWO  += $(OBJ_DIR)/lwip-arch.o
>  ifeq ($(CONFIG_NETFRONT),y)
>  LWO += $(OBJ_DIR)/lwip-net.o
> diff --git a/extras/mini-os/arch/x86/Makefile 
> b/extras/mini-os/arch/x86/Makefile
> index 1073e36..dc55291 100644
> --- a/extras/mini-os/arch/x86/Makefile
> +++ b/extras/mini-os/arch/x86/Makefile
> @@ -14,7 +14,7 @@ include ../../minios.mk
>  
>  # Sources here are all *.c *.S without $(XEN_TARGET_ARCH).S
>  # This is handled in $(HEAD_ARCH_OBJ)
> -ARCH_SRCS := $(wildcard *.c)
> +ARCH_SRCS := $(sort $(wildcard *.c))
>  
>  # The objects built from the sources.
>  ARCH_OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(ARCH_SRCS))
> 

-- 
Samuel
 > Subject: pb fvwm95-2 comment l'installer le compiler???
 > Merci d'avance
 je te conseille d'être un peu plus précis dans l'exposé de ton pb...
 -+- EJ in guide du linuxien pervers :"Les modéros sont sympas !" -+-

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

Re: [Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Don Slutz]

On 02/04/15 12:01, Jan Beulich wrote:
> The former gets enforced by our debug builds, the latter appears to be
> not uncommon for certain distros' Python packages. Newer glibc warns on
> uses of _FORTIFY_SOURCE without optimization being enabled, which with
> -Werror causes the build to fail.
> 
> Determine Python's intended flags to be passed to the C compiler via
> "python-config --cflags", and replace -O0 by -O1 when a non-zero value
> gets set for _FORTIFY_SOURCE.
> 
> Signed-off-by: Jan Beulich 
> 

Well, this does not fix debug=y builds for me:

...
make -C python install
make[3]: Entering directory `/home/don/xen-master/tools/python'
CC="gcc" CFLAGS="  -O1 -fno-omit-frame-pointer -m64 -g
-fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
-Wdeclaration-after-statement -Wno-unused-but-set-variable
-Wno-unused-local-typedefs   -O0 -g3 -D__XEN_TOOLS__ -MMD -MF .install.d
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls
  " python setup.py install \
--prefix="/usr" --root="/home/don/xen-master/dist/install" --force
running install
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/xen
copying xen/__init__.py -> build/lib.linux-x86_64-2.7/xen
creating build/lib.linux-x86_64-2.7/xen/lowlevel
copying xen/lowlevel/__init__.py -> build/lib.linux-x86_64-2.7/xen/lowlevel
running build_ext
building 'xc' extension
creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/xen
creating build/temp.linux-x86_64-2.7/xen/lowlevel
creating build/temp.linux-x86_64-2.7/xen/lowlevel/xc
gcc -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fwrapv -O1 -fno-omit-frame-pointer -m64 -g
-fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
-Wdeclaration-after-statement -Wno-unused-but-set-variable
-Wno-unused-local-typedefs -O0 -g3 -D__XEN_TOOLS__ -MMD -MF .install.d
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls
-fPIC -I../../tools/include -I../../tools/libxc/include
-Ixen/lowlevel/xc -I/usr/include/python2.7 -c xen/lowlevel/xc/xc.c -o
build/temp.linux-x86_64-2.7/xen/lowlevel/xc/xc.o -fno-strict-aliasing
-Werror
In file included from /usr/include/limits.h:27:0,
 from
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/limits.h:169,
 from
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/syslimits.h:7,
 from
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/limits.h:34,
 from /usr/include/python2.7/Python.h:19,
 from xen/lowlevel/xc/xc.c:7:
/usr/include/features.h:314:4: error: #warning _FORTIFY_SOURCE requires
compiling with optimization (-O) [-Werror=cpp]
cc1: all warnings being treated as errors
error: command 'gcc' failed with exit status 1
make[3]: *** [install] Error 1
make[3]: Leaving directory `/home/don/xen-master/tools/python'
make[2]: *** [subdir-install-python] Error 2
make[2]: Leaving directory `/home/don/xen-master/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/home/don/xen-master/tools'
make: *** [install-tools] Error 2


Using this change:

dcs-xen-54:~/xen-master>git show | cat
commit 3cda306a162e55d73c25efc14840e7afeec8d3d3
Author: Don Slutz 
Date:   Wed Feb 4 17:57:00 2015 -0500

tools/Rules.mk: Drop -O0 for debug=y

This is a partial revert of

commit 1166ecf781b1016eaa61f8d5ba4fb1fde9d599b6
Author: Euan Harris 
Date:   Mon Dec 1 14:21:05 2014 +

tools/Rules.mk: Don't optimize debug builds; add macro debugging
information

Signed-off-by: Don Slutz 

diff --git a/tools/Rules.mk b/tools/Rules.mk
index 74cf37e..8bf603d 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -56,7 +56,7 @@ SHLIB_libxenvchan  = -Wl,-rpath-link=$(XEN_LIBVCHAN)

 ifeq ($(debug),y)
 # Disable optimizations and enable debugging information for macros
-CFLAGS += -O0 -g3
+CFLAGS += -g3
 endif

 LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)


I can now build with "debug=y" on Fedora 17.

   -Don Slutz




> --- a/tools/pygrub/Makefile
> +++ b/tools/pygrub/Makefile
> @@ -2,15 +2,24 @@
>  XEN_ROOT = $(CURDIR)/../..
>  include $(XEN_ROOT)/tools/Rules.mk
>  
> +py_cflags := $(shell $(PYTHON)-config --cflags)
> +PY_CFLAGS = $(if $(strip $(py_cflags)),,\
> + $(error '$(PYTHON)-config --cflags' produced no output))\
> +$(if $(filter -D_FORTIFY_SOURCE=%,\
> +  $(filter-out -D_FORTIFY_SOURCE=0,\
> +   $(py_cflags))),\
> + $(patsubst -O0,-O1,$(CFLAGS)),\
> + $(CFLAGS)) $(APPEND_LDFLAGS)
> +
>  .PHONY: all
>  all: build
>  .PHONY: build
>  build:
> - CC="$(CC)" CFLAGS="$(CFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) setup.py build
> + CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build
>  
>  .PHONY: install
>  install: all
> - CC="$(CC)" CFLAGS="$(CFLAGS) $(APPEND_

Re: [Xen-devel] [PATCH] x86/hvm: Fix HVM guest regression introduced by c58ba78c84

[Don Slutz]

On 02/04/15 08:02, Andrew Cooper wrote:
> On 04/02/15 13:00, Jan Beulich wrote:
> On 04.02.15 at 13:56,  wrote:
>>> Something between d0b2caa..c58ba78 has broken HVM guests to point at
>>> which HVMloader doesn't reliably function.
>> And no crash (with register state dumped) or any other hint as to
>> what's going wrong?
> 
> PV guests are all fine, and mixed PV/HVM tests have the PV side complete
> successfully.
> 

With the info provided, it looks a lot like I have found:

(copied here, dropped duplication):


 Forwarded Message 
Subject: Re: [Qemu-devel] [PATCH v5 2/2] Xen: Use the ioreq-server API
when available
Date: Wed, 28 Jan 2015 19:57:42 -0500
From: Don Slutz 
To: Don Slutz , Paul Durrant
, qemu-de...@nongnu.org, Stefano Stabellini

CC: Peter Maydell , Olaf Hering
, Alexey Kardashevskiy , Stefan Weil
, Michael Tokarev , Alexander Graf
, Gerd Hoffmann , Stefan Hajnoczi
, Paolo Bonzini 



On 01/28/15 19:05, Don Slutz wrote:
> On 01/28/15 14:32, Don Slutz wrote:
>> On 12/05/14 05:50, Paul Durrant wrote:
>>> The ioreq-server API added to Xen 4.5 offers better security than
>>> the existing Xen/QEMU interface because the shared pages that are
>>> used to pass emulation request/results back and forth are removed
>>> from the guest's memory space before any requests are serviced.
>>> This prevents the guest from mapping these pages (they are in a
>>> well known location) and attempting to attack QEMU by synthesizing
>>> its own request structures. Hence, this patch modifies configure
>>> to detect whether the API is available, and adds the necessary
>>> code to use the API if it is.
>>
>> This patch (which is now on xenbits qemu staging) is causing me
>> issues.
>>
>
> I have found the key.
>
> The following will reproduce my issue:
>
> 1) xl create -p 
> 2) read one of HVM_PARAM_IOREQ_PFN, HVM_PARAM_BUFIOREQ_PFN, or
>HVM_PARAM_BUFIOREQ_EVTCHN
> 3) xl unpause new guest
>
> The guest will hang in hvmloader.
>

...

Using QEMU upstream master (or xenbits qemu staging), you do not have a
default ioreq server.  And so hvm_select_ioreq_server() returns NULL for
hvmloader's iorequest to:

CPU4  0 (+   0)  HANDLE_PIO [ port = 0x0cfe size = 2 dir = 1 ]

(I added this xentrace to figure out what is happening, and I have
a lot of data about it, if any one wants it.)

To get a guest hang instead of calling hvm_complete_assist_req()
for some of hvmloader's pci_read() calls, you can do the following:


1) xl create -p 
2) read one of HVM_PARAM_IOREQ_PFN, HVM_PARAM_BUFIOREQ_PFN, or
   HVM_PARAM_BUFIOREQ_EVTCHN
3) xl unpause new guest

The guest will hang in hvmloader.

The read of HVM_PARAM_IOREQ_PFN will cause a default ioreq server to
be created and directed to the QEMU upsteam that is not a default
ioreq server.  This read also creates the extra event channels that
I see.

I see that hvmop_create_ioreq_server() prevents you from creating
an is_default ioreq_server, so QEMU is not able to do.

Not sure where we go from here.

   -Don Slutz


Using the debug key e, you can see extra unbound event channels.


I had proposed the 1 line fix:

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index bad410e..7ac4b45 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -993,7 +993,7 @@ static int hvm_create_ioreq_server(struct domain *d,
domid_t domid,
 spin_lock(&d->arch.hvm_domain.ioreq_server.lock);

 rc = -EEXIST;
-if ( is_default && d->arch.hvm_domain.default_ioreq_server != NULL )
+if ( is_default && !list_empty(&d->arch.hvm_domain.ioreq_server.list) )
 goto fail2;

 rc = hvm_ioreq_server_init(s, d, domid, is_default, handle_bufioreq,


But no idea if this is right or way off base.

-Don Slutz



> ~Andrew
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

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

Re: [Xen-devel] Stubdom breakage in 4.5

[Don Slutz]

On 02/03/15 09:00, Paul Durrant wrote:
>> -Original Message-
>> From: Ian Campbell
>> Sent: 03 February 2015 13:48
>> To: Paul Durrant
>> Cc: Wei Liu; xen-devel@lists.xen.org; Ian Jackson; Jan Beulich; Andrew
>> Cooper; Stefano Stabellini
>> Subject: Re: Stubdom breakage in 4.5
>>
>> On Tue, 2015-02-03 at 13:42 +, Paul Durrant wrote:
 -Original Message-
 From: Wei Liu [mailto:wei.l...@citrix.com]
 Sent: 03 February 2015 12:22
 To: xen-devel@lists.xen.org
 Cc: Wei Liu; Ian Campbell; Ian Jackson; Paul Durrant; Jan Beulich; Andrew
 Cooper; Stefano Stabellini
 Subject: Stubdom breakage in 4.5

 Hi all

 I recently found out that stubdom in 4.5 is broken.


>> Either way, this regression certainly needs fixing in 4.5 as well as
>> unstable/4.6. It's my understanding that the stuff Don is doing is (at
>> least partially) addressing the latter?
>>
> 
> No, I don't think the stuff Don is doing will help this. He has need to steer 
> his emulation requests, which are new and distinct. The case here is that you 
> need an emulator for existent types of IOREQ to be present before the guest 
> gets going and the toolstack is not ensuring this, so yes, forcibly creating 
> the default emulator during domain build would solve that problem. However it 
> does introduce another problem...
> Upstream QEMU now no longer hooks into Xen as the default emulator and 
> therefore will not get emulation requests for the TPM probe done by 
> hvmloader; those are now completed by Xen but would end up wedging the VM if 
> Xen thought that a default emulator would eventually turn up. So, forcible 
> creation of the default emulator would still need to be something that could 
> be turned off if the latest upstream QEMU were in use.
> 

Most of what I have posted does not apply.  The only possible one that
comes to mind is about using QEMU master (of the newer 4.6 QEMU) with
4.5 which I am assuming is not the case here (for reference it is
about creating a default_ioreq_server to the QEMU that did call
hvm_ioreq_server_enable() 1st, and then a 2nd time as the default one.
(Message-ID: <54caef19.1030...@terremark.com>; Subject: Re: [Qemu-devel]
[PATCH v5 2/2] Xen: Use the ioreq-server API when available)).

   -Don Slutz

>> Paul, can you take care of fixing, or ensuring someone else is fixing,
>> the issue, please.
>>
> 
> I'm happy to fix once the best course of action is agreed.
> 
>   Paul
> 
> 
>> Ian.
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

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

[Xen-devel] [linux-next test] 34141: regressions - FAIL

[xen . org]

flight 34141 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34141/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot  fail REGR. vs. 33881
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot   fail REGR. vs. 33881
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot   fail REGR. vs. 33881
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot fail REGR. vs. 33881
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot  fail REGR. vs. 33881
 test-amd64-i386-freebsd10-amd64  5 xen-boot   fail REGR. vs. 33881
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot  fail REGR. vs. 33881
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot  fail REGR. vs. 33881
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install fail REGR. vs. 33881

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-multivcpu 16 guest-stop  fail blocked in 33881
 test-amd64-i386-freebsd10-i386  7 freebsd-install  fail like 33881
 test-amd64-amd64-xl-sedf  5 xen-boot  fail REGR. vs. 33881
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33881

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-sedf 10 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   10 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-armhf-armhf-xl-credit2   5 xen-boot fail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass

version targeted for testing:
 linuxb50cadffd155708cbd890d0ee6cc309c51af0f7d
baseline version:
 linuxc59c961ca511dc7ee2f4f7e9c224d16f5c76ca6e

jobs:
 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
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 fail
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 tes

Re: [Xen-devel] Stubdom breakage in 4.5

[Don Slutz]

On 02/04/15 07:58, Paul Durrant wrote:
>> -Original Message-
>> From: Ian Campbell
>> Sent: 04 February 2015 12:30
>> To: Paul Durrant
>> Cc: Wei Liu; xen-devel@lists.xen.org; Ian Jackson; Jan Beulich; Andrew
>> Cooper; Stefano Stabellini
>> Subject: Re: Stubdom breakage in 4.5
>>
>> On Tue, 2015-02-03 at 14:11 +, Paul Durrant wrote:
>>> How about this as a slightly hacky solution that I think may work in both
>> cases?
>>>
>>> If Xen finds no emulator at all for an HVM guest then it waits around
>>> for at least one to show up before processing an emulation request.
>>> Until one does it stalls the vcpu in question indefinitely, but on the
>>> first emulator attach (i.e. ioreq server creations) then the IO will
>>> always be processed, even if it doesn't match the ioreq server.
>>
>> It sounds plausible to me and seems like it would probably be
>> backportable.
>>
> 
> Actually I think it may be even simpler, although I've not tried it. If 
> hvm_domain_initialise() pauses the domain and the first 
> hvm_ioreq_server_enable() unpauses it, I'm hoping that may be enough.
> 

You do need to keep the PVH case in mind here.

   -Don Slutz


>> Longer term I think we still need to fix the domain creation interlock
>> for launching multiple qemu's, ioreq servers and any other type of
>> service thing we might launch (whether in a stub dom or not), at which
>> point we may be able to remove the above workaround too.
>>
> 
> Yes. Once the toolstack is aware it can keep the domain paused until all 
> emulators report readiness.
> 
>   Paul
> 
>> Ian.
>>
>>
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

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

Re: [Xen-devel] [edk2] [PATCH v3 21/27] Ovmf/Xen: add ARM and AArch64 support to XenBusDxe

[Jordan Justen]

On 2015-02-03 11:20:06, Ard Biesheuvel wrote:
> This patch adds support to XenBusDxe for executing on ARM and AArch64
> machines (the former only when built with GCC).
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  OvmfPkg/XenBusDxe/AtomicsGcc.c  | 44 
> +
>  OvmfPkg/XenBusDxe/XenBusDxe.inf |  3 +++
>  2 files changed, 47 insertions(+)
>  create mode 100644 OvmfPkg/XenBusDxe/AtomicsGcc.c
> 
> diff --git a/OvmfPkg/XenBusDxe/AtomicsGcc.c b/OvmfPkg/XenBusDxe/AtomicsGcc.c
> new file mode 100644
> index ..a0bdcbf67440
> --- /dev/null
> +++ b/OvmfPkg/XenBusDxe/AtomicsGcc.c
> @@ -0,0 +1,44 @@
> +/** @file
> +  Arch-independent implementations of XenBusDxe atomics using GCC __builtins
> +
> +  Copyright (C) 2014, Linaro Ltd.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +UINT16
> +EFIAPI
> +InternalSyncCompareExchange16 (
> +  IN  volatile UINT16   *Value,
> +  IN  UINT16CompareValue,
> +  IN  UINT16ExchangeValue

Can you instead get InterlockedCompareExchange16 added to
BaseSynchronizationLib?

http://permalink.gmane.org/gmane.comp.bios.tianocore.devel/10470

-Jordan

> +  )
> +{
> +  return __sync_val_compare_and_swap_2 (Value, CompareValue, ExchangeValue);
> +}
> +
> +INT32
> +EFIAPI
> +TestAndClearBit (
> +  IN INT32Bit,
> +  IN volatile VOID*Address
> +  )
> +{
> +  //
> +  // Calculate the effective address relative to 'Address' based on the
> +  // higher order bits of 'Bit'. Use signed shift instead of division to
> +  // ensure we round towards -Inf, and end up with a positive shift in 'Bit',
> +  // even if 'Bit' itself is negative.
> +  //
> +  Address += (Bit >> 5) * sizeof(INT32);
> +  Bit &= 31;
> +
> +  return (__sync_fetch_and_and_4 (Address, ~(1U << Bit)) & (1U << Bit)) != 0;
> +}
> diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
> index 31553ac5a64a..949ec0a0c732 100644
> --- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
> +++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
> @@ -54,6 +54,9 @@
>X64/InterlockedCompareExchange16.nasm
>X64/TestAndClearBit.nasm
>  
> +[Sources.AARCH64, Sources.ARM]
> +  AtomicsGcc.c | GCC
> +
>  [LibraryClasses]
>UefiDriverEntryPoint
>UefiBootServicesTableLib
> -- 
> 1.8.3.2
> 
> 
> --
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> ___
> edk2-devel mailing list
> edk2-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

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

Re: [Xen-devel] [Qemu-devel] [PATCH] vl.c: fixed QEMU crash if no display was selected in command line

[Marcel Apfelbaum]

On 02/04/2015 10:40 PM, Don Slutz wrote:

A proper fix for this is the thread:

I suspected I don't have the whole picture, good to know it is fixed!

Thanks!
Marcel



Subject: [PATCH v2 0/3] fix qemu crash about vnc
Date: Fri, 30 Jan 2015 10:14:33 +0800
Message-ID: <1422584076-5728-1-git-send-email-arei.gong...@huawei.com>

This also has a bug:

https://bugs.launchpad.net/qemu/+bug/1414222


Xen expects this to be working.

-Don Slutz


[...]

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

Re: [Xen-devel] [Qemu-devel] [PATCH] vl.c: fixed QEMU crash if no display was selected in command line

[Don Slutz]

A proper fix for this is the thread:

Subject: [PATCH v2 0/3] fix qemu crash about vnc
Date: Fri, 30 Jan 2015 10:14:33 +0800
Message-ID: <1422584076-5728-1-git-send-email-arei.gong...@huawei.com>

This also has a bug:

https://bugs.launchpad.net/qemu/+bug/1414222


Xen expects this to be working.

   -Don Slutz


On 02/04/15 06:25, Marcel Apfelbaum wrote:
> Commit 4db14629c3 (vnc: switch to QemuOpts, allow multiple servers)
> converted vnc option to QemuOpts.
> However, the default vnc display had ...,to=99,... between parameters
> that is not covered by the QemuOpts.
> Remove it because is not longer used and solves the crash.
> 
> Signed-off-by: Marcel Apfelbaum 
> ---
> This issue is bugging me some time now. Please let me know if
> I got it wrong.
> 
>  vl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/vl.c b/vl.c
> index 983259b..c8f33d2 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3970,7 +3970,7 @@ int main(int argc, char **argv, char **envp)
>  #elif defined(CONFIG_SDL) || defined(CONFIG_COCOA)
>  display_type = DT_SDL;
>  #elif defined(CONFIG_VNC)
> -vnc_parse_func("localhost:0,to=99,id=default");
> +vnc_parse_func("localhost:0,id=default");
>  show_vnc_port = 1;
>  #else
>  display_type = DT_NONE;
> 

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

[Xen-devel] [xen-unstable test] 34137: tolerable FAIL - PUSHED

[xen . org]

flight 34137 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34137/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf  5 xen-boot  fail REGR. vs. 34087
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 34087

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-sedf 10 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-midway   10 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-armhf-armhf-xl-credit2   5 xen-boot fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass

version targeted for testing:
 xen  a1b4af132077de694054d757fea4573d482c8b3a
baseline version:
 xen  d0b2caa80fccafbb131b28b7b8488001d82ab4bf


People who touched revisions under test:
  Andrew Cooper 
  David Scott 
  Ian Campbell 
  Ian Jackson 
  Stefano Stabellini 
  Tiejun Chen 
  Wei Liu 


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pa

Re: [Xen-devel] [PATCH RFC 10/35] asm / arm: Introduce cputype.h

[Stefano Stabellini]

On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat 
> 
> Introduce cputype.h file for arm
> 
> Signed-off-by: Naresh Bhat 
> ---
>  xen/include/asm-arm/cputype.h | 83 
> +++
>  1 file changed, 83 insertions(+)
>  create mode 100644 xen/include/asm-arm/cputype.h
> 
> diff --git a/xen/include/asm-arm/cputype.h b/xen/include/asm-arm/cputype.h
> new file mode 100644
> index 000..0b454cc
> --- /dev/null
> +++ b/xen/include/asm-arm/cputype.h
> @@ -0,0 +1,83 @@
> +/*
> + * Copyright (C) 2012 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * 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 __ASM_CPUTYPE_H
> +#define __ASM_CPUTYPE_H
> +
> +#include 
> +
> +#define INVALID_HWIDULONG_MAX
> +
> +#define MPIDR_HWID_BITMASK  0xff00ff
> +
> +#define MPIDR_LEVEL_BITS_SHIFT  3
> +#define MPIDR_LEVEL_MASK((1 << MPIDR_LEVEL_BITS) - 1)
> +
> +#define MPIDR_LEVEL_SHIFT(level) \
> +(((1 << level) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
> +
> +#define MPIDR_AFFINITY_LEVEL(mpidr, level) \
> +((mpidr >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)

You shouldn't duplicate the definitions in processor.h.
If you want to move them to this file, then please remove them from
processor.h.


> +#define read_cpuid(reg) ({  \
> +u64 __val;  \
> +asm("mrs%0, " #reg : "=r" (__val)); \
> +__val;  \
> +})
> +
> +#define ARM_CPU_IMP_ARM 0x41
> +#define ARM_CPU_IMP_APM 0x50
> +
> +#define ARM_CPU_PART_AEM_V8 0xD0F0
> +#define ARM_CPU_PART_FOUNDATION 0xD000
> +#define ARM_CPU_PART_CORTEX_A57 0xD070
> +
> +#define APM_CPU_PART_POTENZA0x
> +
> +#ifndef __ASSEMBLY__
> +
> +/*
> + * The CPU ID never changes at run time, so we might as well tell the
> + * compiler that it's constant.  Use this function to read the CPU ID
> + * rather than directly reading processor_id or read_cpuid() directly.
> + */
> +static inline u32 __attribute_const__ read_cpuid_id(void)
> +{
> +return read_cpuid(MIDR_EL1);
> +}
> +
> +static inline u64 __attribute_const__ read_cpuid_mpidr(void)
> +{
> +return read_cpuid(MPIDR_EL1);
> +}
> +
> +static inline unsigned int __attribute_const__ read_cpuid_implementor(void)
> +{
> +return (read_cpuid_id() & 0xFF00) >> 24;
> +}
> +
> +static inline unsigned int __attribute_const__ read_cpuid_part_number(void)
> +{
> +return (read_cpuid_id() & 0xFFF0);
> +}
> +
> +static inline u32 __attribute_const__ read_cpuid_cachetype(void)
> +{
> +return read_cpuid(CTR_EL0);
> +}

We already read mpidr and midr in identify_cpu. Isn't that enough?
Can't you just reuse the info in struct cpuinfo_arm?


> +#endif /* __ASSEMBLY__ */
> +
> +#endif
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH RFC 09/35] Add cpumask_next_zero set_cpu_present and possible

[Stefano Stabellini]

On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat 
> 
> Introduce and use cpumask_next_zero, set_cpu_present and set_cpu_possible.
> 
> Signed-off-by: Naresh Bhat 
> ---
>  xen/common/cpu.c  | 18 ++
>  xen/include/xen/cpumask.h | 40 
>  2 files changed, 58 insertions(+)
> 
> diff --git a/xen/common/cpu.c b/xen/common/cpu.c
> index 630881e..da399c9 100644
> --- a/xen/common/cpu.c
> +++ b/xen/common/cpu.c
> @@ -216,3 +216,21 @@ void enable_nonboot_cpus(void)
>  
>  cpumask_clear(&frozen_cpus);
>  }
> +
> +static DECLARE_BITMAP(cpu_present_bits, NR_CPUS) __read_mostly;

We already have cpu_present_map on both x86 and ARM.
Does it make sense to use that instead?


> +static DECLARE_BITMAP(cpu_possible_bits, NR_CPUS) __read_mostly;

ARM already has cpu_possible_map. x86 seems to be able to cope with
having ACPI without this map.

If you want to introduce it, you should explain why x86 needs this map.


> +void set_cpu_possible(unsigned int cpu, bool possible)
> +{
> +if ( possible )
> + cpumask_set_cpu(cpu, to_cpumask(cpu_possible_bits));
> +else
> +cpumask_clear_cpu(cpu, to_cpumask(cpu_possible_bits));
> +}
> +
> +void set_cpu_present(unsigned int cpu, bool present)
> +{
> +if ( present )
> +cpumask_set_cpu(cpu, to_cpumask(cpu_present_bits));
> +else
> +cpumask_clear_cpu(cpu, to_cpumask(cpu_present_bits));
> +}
> diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h
> index 850b4a2..209483e 100644
> --- a/xen/include/xen/cpumask.h
> +++ b/xen/include/xen/cpumask.h
> @@ -78,6 +78,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  typedef struct cpumask{ DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;
>  
> @@ -295,6 +296,22 @@ static inline int cpulist_scnprintf(char *buf, int len,
>  }
>  
>  /*
> + * cpumask_next_zero - get the next unset cpu in a cpumask
> + * @n: the cpu prior to the place to search (ie. return will be > @n)
> + * @srcp: the cpumask pointer
> + *
> + * Returns >= nr_cpu_ids if no further cpus unset.
> + */
> +static inline unsigned int cpumask_next_zero(int n, const cpumask_t *srcp)
> +{
> +/* -1 is a legal arg here. */
> +if (n != -1)
> +cpumask_check(n);
> +
> +return find_next_zero_bit(srcp->bits, nr_cpu_ids, n+1);

   return min_t(int, nr_cpu_ids, find_next_zero_bit(srcp->bits, nr_cpu_ids, 
n + 1));


> +}
> +
> +/*
>   * cpumask_var_t: struct cpumask for stack usage.
>   *
>   * Oh, the wicked games we play!  In order to make kernel coding a
> @@ -440,6 +457,29 @@ extern cpumask_t cpu_present_map;
>  #define for_each_online_cpu(cpu)   for_each_cpu(cpu, &cpu_online_map)
>  #define for_each_present_cpu(cpu)  for_each_cpu(cpu, &cpu_present_map)
>  
> +/* Wrappers for arch boot code to manipulate normally-constant masks */
> +void set_cpu_possible(unsigned int cpu, bool possible);
> +void set_cpu_present(unsigned int cpu, bool present);
> +
> +/*
> + * to_cpumask - convert an NR_CPUS bitmap to a struct cpumask *
> + * @bitmap: the bitmap
> + *
> + * There are a few places where cpumask_var_t isn't appropriate and
> + * static cpumasks must be used (eg. very early boot), yet we don't
> + * expose the definition of 'struct cpumask'.
> + *
> + * This does the conversion, and can be used as a constant initializer.
> + */
> +#define to_cpumask(bitmap)  \
> +((struct cpumask *)(1 ? (bitmap)\

it doesn't make sense to me

> +: (void *)sizeof(__check_is_bitmap(bitmap
> +
> +static inline int __check_is_bitmap(const unsigned long *bitmap)
> +{
> +return 1;
> +}

What is the purpose of this?


>  /* Copy to/from cpumap provided by control tools. */
>  struct xenctl_bitmap;
>  int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *, const cpumask_t *);
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [qemu-mainline bisection] complete test-amd64-i386-rhel6hvm-intel

[Don Slutz]

This looks like:

https://bugs.launchpad.net/qemu/+bug/1414222

Patch "fix qemu crash about vnc" is still pending.
   -Don Slutz


On 01/31/15 23:25, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-rhel6hvm-intel
> test redhat-install
> 
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://git.qemu.org/qemu.git
> Tree: xen git://xenbits.xen.org/xen.git
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  qemuu git://git.qemu.org/qemu.git
>   Bug introduced:  b3a4755a67a52aa7297eb8927b482d09dabdefec
>   Bug not present: a805ca54015bd123e2bc2454ec59619d0ed106c2
> 
> 
>   commit b3a4755a67a52aa7297eb8927b482d09dabdefec
>   Merge: a805ca5 4478aa7
>   Author: Peter Maydell 
>   Date:   Thu Jan 22 12:14:19 2015 +
>   
>   Merge remote-tracking branch 'remotes/kraxel/tags/pull-vnc-20150122-1' 
> into staging
>   
>   vnc: add support for multiple vnc displays
>   
>   # gpg: Signature made Thu 22 Jan 2015 11:00:54 GMT using RSA key ID 
> D3E87138
>   # gpg: Good signature from "Gerd Hoffmann (work) "
>   # gpg: aka "Gerd Hoffmann "
>   # gpg: aka "Gerd Hoffmann (private) "
>   
>   * remotes/kraxel/tags/pull-vnc-20150122-1:
> monitor: add vnc websockets
> monitor: add query-vnc-servers command
> vnc: factor out qmp_query_client_list
> vnc: track & limit connections
> vnc: update docs/multiseat.txt
> vnc: allow binding servers to qemu consoles
> vnc: switch to QemuOpts, allow multiple servers
> vnc: add display id to acl names
> vnc: remove unused DisplayState parameter, add id instead.
> vnc: remove vnc_display global
>   
>   Signed-off-by: Peter Maydell 
>   
>   commit 4478aa768ccefcc5b234c23d035435fd71b932f6
>   Author: Gerd Hoffmann 
>   Date:   Wed Dec 10 09:49:39 2014 +0100
>   
>   monitor: add vnc websockets
>   
>   Add websockets bool to VncBasicInfo, report websocket server sockets,
>   flag websocket client connections.
>   
>   Signed-off-by: Gerd Hoffmann 
>   
>   commit df887684603a4b3b0c623090a6b419dc70f22c32
>   Author: Gerd Hoffmann 
>   Date:   Wed Dec 17 15:49:44 2014 +0100
>   
>   monitor: add query-vnc-servers command
>   
>   Add new query vnc qmp command, for the lack of better ideas just name it
>   "query-vnc-servers".  Changes over query-vnc:
>   
>* It returns a list of vnc servers, so multiple vnc server instances
>  are covered.
>* Each vnc server returns a list of server sockets.  Followup patch
>  will use that to also report websockets.  In case we add support for
>  multiple server sockets server sockets (to better support ipv4+ipv6
>  dualstack) we can add them to the list too.
>   
>   Signed-off-by: Gerd Hoffmann 
>   
>   commit 2d29a4368c3c00a5cf200f29b3dfd32bc4fb2c31
>   Author: Gerd Hoffmann 
>   Date:   Tue Dec 9 15:27:39 2014 +0100
>   
>   vnc: factor out qmp_query_client_list
>   
>   so we can reuse it for the new vnc query command.
>   
>   Signed-off-by: Gerd Hoffmann 
>   
>   commit e5f34cdd2da54f28d90889a3afd15fad2d6105ff
>   Author: Gerd Hoffmann 
>   Date:   Thu Oct 2 12:09:34 2014 +0200
>   
>   vnc: track & limit connections
>   
>   Also track the number of connections in "connecting" and "shared" state
>   (in addition to the "exclusive" state).  Apply a configurable limit to
>   these connections.
>   
>   The logic to apply the limit to connections in "shared" state is pretty
>   simple:  When the limit is reached no new connections are allowed.
>   
>   The logic to apply the limit to connections in "connecting" state (this
>   is the state you are in *before* successful authentication) is
>   slightly different:  A new connect kicks out the oldest client which is
>   still in "connecting" state.  This avoids a easy DoS by unauthenticated
>   users by simply opening connections until the limit is reached.
>   
>   Cc: Dr. David Alan Gilbert 
>   Signed-off-by: Gerd Hoffmann 
>   
>   commit 86fdcf23f4a9d8473844734907555b3a93ed686c
>   Author: Gerd Hoffmann 
>   Date:   Thu Oct 2 15:53:37 2014 +0200
>   
>   vnc: update docs/multiseat.txt
>   
>   vnc joins the party ;)
>   Also some s/head/seat/ to clarify.
>   
>   Signed-off-by: Gerd Hoffmann 
>   
>   commit 1d0d59fe291967533f974e82213656d479475a1e
>   Author: Gerd Hoffmann 
>   Date:   Thu Sep 18 12:54:49 2014 +0200
>   
>   vnc: allow binding servers to qemu consoles
>   
>   This patch adds a display= parameter to the vnc options.  This allows to
>   bind a vnc server instance to a specific display, 

Re: [Xen-devel] [PATCH RFC 07/35] ACPI / ACPICA: Add new features for MADT which introduced by ACPI 5.1

[Stefano Stabellini]

On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat 
> 
> Add new features for MADT which introduced by ACPI 5.1:
> -comment on the GIC ID field of the GIC structure which is replaced
>  by CPU Interface Number.
> -add new fields: Redistributor Base Address, GICV, GICH, and MPIDR.
> -add new structures for GIC MSI frame and GICR.
> -add flag definition for GICC flags.
> 
> Signed-off-by: Tomasz Nowicki 
> Signed-off-by: Hanjun Guo 
> Signed-off-by: Naresh Bhat 

I see.  I think you can safely merge this patch with the previous one.


>  xen/include/acpi/actbl1.h | 38 ++
>  1 file changed, 34 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
> index dd6dc27..d16670d 100644
> --- a/xen/include/acpi/actbl1.h
> +++ b/xen/include/acpi/actbl1.h
> @@ -641,7 +641,9 @@ enum acpi_madt_type {
>   ACPI_MADT_TYPE_LOCAL_X2APIC_NMI = 10,
>   ACPI_MADT_TYPE_GENERIC_INTERRUPT = 11,
>   ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR = 12,
> - ACPI_MADT_TYPE_RESERVED = 13/* 13 and greater are reserved */
> + ACPI_MADT_TYPE_GIC_MSI_FRAME = 13,
> + ACPI_MADT_TYPE_GIC_REDISTRIBUTOR = 14,
> + ACPI_MADT_TYPE_RESERVED = 15/* 15 and greater are reserved */
>  };
>  
>  /*
> @@ -762,18 +764,23 @@ struct acpi_madt_local_x2apic_nmi {
>   u8 reserved[3];
>  };
>  
> -/* 11: Generic Interrupt (ACPI 5.0) */
> +/* 11: Generic Interrupt (ACPI 5.1) */
>  
>  struct acpi_madt_generic_interrupt {
>  struct acpi_subtable_header header;
>  u16 reserved;   /* reserved - must be zero */
> -u32 gic_id;
> +u32 gic_id;  /* it was renamed to cpu interface number in 
> ACPI 5.1 */
>  u32 uid;
>  u32 flags;
>  u32 parking_version;
>  u32 performance_interrupt;
>  u64 parked_address;
>  u64 base_address;
> +u64 gicv_base_address;
> +u64 gich_base_address;
> +u32 vgic_maintenance_interrupt;
> +u64 redist_base_address;
> +u64 mpidr;
>  };
>  
>  /* 12: Generic Distributor (ACPI 5.0) */
> @@ -787,14 +794,37 @@ struct acpi_madt_generic_distributor {
>  u32 reserved2;  /* reserved - must be zero */
>  };
>  
> +/* 13: GIC MSI Frame (ACPI 5.1) */
> +
> +struct acpi_madt_gic_msi_frame {
> +   struct acpi_subtable_header header;
> +   u16 reserved;   /* reserved - must be zero */
> +   u32 gic_msi_frame_id;
> +   u64 base_address;
> +};
> +
> +/* 14: GIC Redistributor (ACPI 5.1) */
> +
> +struct acpi_madt_gic_redistributor {
> +   struct acpi_subtable_header header;
> +   u16 reserved;   /* reserved - must be zero */
> +   u64 base_address;
> +   u32 region_size;
> +};
> +
>  /*
>   * Common flags fields for MADT subtables
>   */
>  
> -/* MADT Local APIC flags (lapic_flags) */
> +/* MADT Local APIC flags (lapic_flags) and GICC flags */
>  
>  #define ACPI_MADT_ENABLED   (1)  /* 00: Processor is usable if 
> set */
>  
> +/* MADT GICC flags only */
> +
> +#define ACPI_MADT_PERF_INT_MODE (1<<1) /* 01: Performance Interrupt 
> Mode */
> +#define ACPI_MADT_VGIC  (1<<2) /* 02: VGIC Maintenance 
> interrupt mode */
> +
>  /* MADT MPS INTI flags (inti_flags) */
>  
>  #define ACPI_MADT_POLARITY_MASK (3)  /* 00-01: Polarity of APIC I/O 
> input signals */
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH RFC 06/35] ACPI: Add Generic Interrupt and Distributor struct

[Stefano Stabellini]

On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat 
> 
> Add Generic Interrupt and Distributor (ACPI 5.0) structure.
> 
> Signed-off-by: Naresh Bhat 
> ---
>  xen/include/acpi/actbl1.h | 29 -
>  1 file changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
> index 9311e3a..dd6dc27 100644
> --- a/xen/include/acpi/actbl1.h
> +++ b/xen/include/acpi/actbl1.h
> @@ -639,7 +639,9 @@ enum acpi_madt_type {
>   ACPI_MADT_TYPE_INTERRUPT_SOURCE = 8,
>   ACPI_MADT_TYPE_LOCAL_X2APIC = 9,
>   ACPI_MADT_TYPE_LOCAL_X2APIC_NMI = 10,
> - ACPI_MADT_TYPE_RESERVED = 11/* 11 and greater are reserved */
> + ACPI_MADT_TYPE_GENERIC_INTERRUPT = 11,
> + ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR = 12,
> + ACPI_MADT_TYPE_RESERVED = 13/* 13 and greater are reserved */

You might as well define the GICv2m and GICR types


>  };
>  
>  /*
> @@ -760,6 +762,31 @@ struct acpi_madt_local_x2apic_nmi {
>   u8 reserved[3];
>  };
>  
> +/* 11: Generic Interrupt (ACPI 5.0) */

Why not use the 5.1 struct?


> +struct acpi_madt_generic_interrupt {

acpi_madt_gicc?


> +struct acpi_subtable_header header;
> +u16 reserved;   /* reserved - must be zero */
> +u32 gic_id;
> +u32 uid;
> +u32 flags;
> +u32 parking_version;
> +u32 performance_interrupt;
> +u64 parked_address;
> +u64 base_address;
> +};
> +
> +/* 12: Generic Distributor (ACPI 5.0) */

Why not use the most recent version here too?


> +struct acpi_madt_generic_distributor {

acpi_madt_gicd?


> +struct acpi_subtable_header header;
> +u16 reserved;   /* reserved - must be zero */
> +u32 gic_id;
> +u64 base_address;
> +u32 global_irq_base;
> +u32 reserved2;  /* reserved - must be zero */
> +};
> +
>  /*
>   * Common flags fields for MADT subtables
>   */
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH RFC 05/35] ARM64 / ACPI: Parse FADT table to get PSCI flags

[Stefano Stabellini]

On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat 
> 
> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> the former signals to the OS that the hardware is PSCI compliant.
> The latter selects the appropriate conduit for PSCI calls by
> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
> (SMC).
> 
> FADT table contains such information, parse FADT to get the flags
> for furture usage. At the same time, only ACPI 5.1 or higher verison
> supports PSCI, and FADT Major.Minor version was introduced in ACPI
> 5.1, so we will check the version and only parse FADT table with
> version >= 5.1.
> 
> If firmware provides ACPI tables with ACPI version less than 5.1,
> OS will be messed up with those information, so disable ACPI if we
> get an FADT table with version less that 5.1.
> 
> Signed-off-by: Hanjun Guo 
> Signed-off-by: Naresh Bhat 
> ---
>  xen/arch/arm/arm64/acpi/arm-core.c | 54 
> +++---
>  xen/arch/arm/setup.c   |  1 +
>  xen/include/asm-arm/acpi.h |  2 ++
>  3 files changed, 54 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
> b/xen/arch/arm/arm64/acpi/arm-core.c
> index 50a83d6..2b7e2ef 100644
> --- a/xen/arch/arm/arm64/acpi/arm-core.c
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -25,6 +25,7 @@
>  #if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -42,6 +43,12 @@ EXPORT_SYMBOL(acpi_disabled);
>  int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization 
> */
>  EXPORT_SYMBOL(acpi_pci_disabled);
>  
> +/* 1 to indicate PSCI is implemented */
> +int acpi_psci_present;
> +
> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
> +int acpi_psci_use_hvc;

Can they be static?
Also it might be better to define an enum with values: PSCI_ABSENT, PSCI_HVC, 
PSCI_SMC.


>  enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
>  
>  struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
> @@ -58,7 +65,7 @@ EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
>   * failure: return =< 0
>   */
>  //int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int 
> polarity)
> -unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low)
> +unsigned int acpi_register_gsi(u32 gsi, int edge_level, int active_high_low)
>  {
>  return -1;
>  }
> @@ -69,6 +76,33 @@ void acpi_unregister_gsi(u32 gsi)
>  }
>  EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
>  
> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
> +{
> +   struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> +
> +   /*
> +* Revision in table header is the FADT Major version,
> +* and there is a minor version of FADT which was introduced
> +* by ACPI 5.1, we only deal with ACPI 5.1 or higher version
> +* to get arm boot flags, or we will disable ACPI.
> +*/
> +   if ( table->revision < 5 || fadt->minor_version < 1 ) {
> +   printk("FADT version is %d.%d, no PSCI support, should be 5.1 
> or higher\n",
> +   table->revision, fadt->minor_version);
> +   acpi_psci_present = 0;
> +   disable_acpi();
> +   return -EINVAL;
> +   }
> +
> +   if ( acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT )
> +   acpi_psci_present = 1;
> +
> +   if ( acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC )
> +   acpi_psci_use_hvc = 1;
> +
> +   return 0;
> +}
> +
>  /*
>   * acpi_boot_table_init() called from setup_arch(), always.
>   *  1. find RSDP and get its address, and then find XSDT
> @@ -81,12 +115,12 @@ int __init acpi_boot_table_init(void)
>  {
>  int error;
>  /* If acpi_disabled, bail out */
> -if (acpi_disabled)
> +if ( acpi_disabled )
>  return 1;
>  
>  /* Initialize the ACPI boot-time table parser. */
>  error = acpi_table_init();
> -if (error)
> +if ( error )
>  {
>  disable_acpi();
>  return error;
> @@ -94,4 +128,18 @@ int __init acpi_boot_table_init(void)
>  
>  return 0;
>  }
> +
> +int __init acpi_boot_init(void)
> +{
> +int err = 0;
> +/* If acpi_disabled, bail out */
> +if (acpi_disabled)
> +return -ENODEV;
> +
> +err = acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
> +if ( err )
> +printk("Can't find FADT\n");
> +
> +return err;
> +}
>  #endif
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 7ae126b..3531d47 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -749,6 +749,7 @@ void __init start_xen(unsigned long boot_phys_offset,
>  
>  #if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
>  acpi_boot_table_init();
> +acpi_boot_init();
>  #endif
>  
>  dt_unflatten_host_device_tree();
> diff --git a/xen/include/asm-arm/acpi.h b/xen/inc

Re: [Xen-devel] [PATCH RFC 04/35] ACPI / ACPICA: Introduce ARM Boot Architecture Flags in FADT

[Stefano Stabellini]

On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat 
> 
> The Power State Coordination Interface (PSCI) defines an API that
> can be used to coordinate power control amongst the various supervisory
> systems concurrently running on a device. ACPI support for this
> technology would require the addition of two flags: PSCI_COMPLIANT and
> PSCI_USE_HVC. When set, the former signals to the OS that the hardware
> is PSCI compliant. The latter selects the appropriate conduit for PSCI
> calls by toggling between Hypervisor Calls (HVC) and Secure Monitor
> Calls (SMC).
> 
> An ARM Boot Architecture Flags structure to support new ARM hardware
> was introduced in FADT in ACPI 5.1, add the code accordingly to
> implement that in ACPICA core.
> 
> Since ACPI 5.1 doesn't support self defined PSCI function IDs,
> which means that only PSCI 0.2+ is supported in ACPI.
> 
> Signed-off-by: Hanjun Guo 
> Signed-off-by: Naresh Bhat 
> ---
>  xen/include/acpi/actbl.h | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/include/acpi/actbl.h b/xen/include/acpi/actbl.h
> index 856945d..34e8673 100644
> --- a/xen/include/acpi/actbl.h
> +++ b/xen/include/acpi/actbl.h
> @@ -244,7 +244,8 @@ struct acpi_table_fadt {
>   u32 flags;  /* Miscellaneous flag bits (see below for 
> individual flags) */
>   struct acpi_generic_address reset_register; /* 64-bit address of 
> the Reset register */
>   u8 reset_value; /* Value to write to the reset_register port to 
> reset the system */
> - u8 reserved4[3];/* Reserved, must be zero */
> +u16 arm_boot_flags; /* ARM Boot Architecture Flags (see below 
> for individual flags) */
> +u8 minor_version;   /* Minor version of this FADT structure */

indentation


>   u64 Xfacs;  /* 64-bit physical address of FACS */
>   u64 Xdsdt;  /* 64-bit physical address of DSDT */
>   struct acpi_generic_address xpm1a_event_block;  /* 64-bit Extended 
> Power Mgt 1a Event Reg Blk address */
> @@ -259,7 +260,7 @@ struct acpi_table_fadt {
>   struct acpi_generic_address sleep_status;   /* 64-bit Sleep Status 
> register */
>  };
>  
> -/* Masks for FADT Boot Architecture Flags (boot_flags) */
> +/* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) [Vx]=Introduced 
> in this FADT revision */
>  
>  #define ACPI_FADT_LEGACY_DEVICES(1)  /* 00: [V2] System has LPC or 
> ISA bus devices */
>  #define ACPI_FADT_8042  (1<<1)   /* 01: [V3] System has an 8042 
> controller on port 60/64 */
> @@ -270,6 +271,11 @@ struct acpi_table_fadt {
>  
>  #define FADT2_REVISION_ID   3
>  
> +/* Masks for FADT ARM Boot Architecture Flags (arm_boot_flags) */
> +
> +#define ACPI_FADT_PSCI_COMPLIANT(1)/* 00: PSCI 0.2+ is 
> implemented */
> +#define ACPI_FADT_PSCI_USE_HVC  (1<<1) /* 01: HVC must be used 
> instead of SMC as the PSCI conduit */
> +
>  /* Masks for FADT flags */
>  
>  #define ACPI_FADT_WBINVD(1)  /* 00: [V1] The wbinvd 
> instruction works properly */
> @@ -345,7 +351,7 @@ enum acpi_prefered_pm_profiles {
>   * FADT V5  size: 0x10C
>   */
>  #define ACPI_FADT_V1_SIZE   (u32) (ACPI_FADT_OFFSET (flags) + 4)
> -#define ACPI_FADT_V2_SIZE   (u32) (ACPI_FADT_OFFSET (reserved4[0]) + 3)
> +#define ACPI_FADT_V2_SIZE   (u32) (ACPI_FADT_OFFSET (arm_boot_flags) + 3)
>  #define ACPI_FADT_V3_SIZE   (u32) (ACPI_FADT_OFFSET (sleep_control))
>  #define ACPI_FADT_V5_SIZE   (u32) (sizeof (struct acpi_table_fadt))
>  
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH RFC 03/35] xen: arm64: ACPI: Add basic ACPI initialization

[Stefano Stabellini]

On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat 
> 
> This patch introduce arm-core.c and its related header file
> 
> - asm/acpi.h for arch specific variables and functions needed by
>   ACPI driver core;
> - arm-core.c for ARM64 related ACPI implementation for ACPI driver
>   core;
> 
> acpi_boot_table_init() will be called in setup_arch()
> to get the RSDP and all the table pointers. with this patch,
> we can get ACPI boot-time tables from firmware on ARM64.
> 
> Signed-off-by: Naresh Bhat 
> ---
>  xen/arch/arm/arm64/Makefile|  1 +
>  xen/arch/arm/arm64/acpi/Makefile   |  1 +
>  xen/arch/arm/arm64/acpi/arm-core.c | 97 
> ++
>  xen/arch/arm/setup.c   | 14 +-
>  xen/include/xen/acpi.h | 11 +
>  5 files changed, 123 insertions(+), 1 deletion(-)
>  create mode 100644 xen/arch/arm/arm64/acpi/Makefile
>  create mode 100644 xen/arch/arm/arm64/acpi/arm-core.c
> 
> diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
> index c7243f5..49d135f 100644
> --- a/xen/arch/arm/arm64/Makefile
> +++ b/xen/arch/arm/arm64/Makefile
> @@ -1,4 +1,5 @@
>  subdir-y += lib
> +subdir-y += acpi
>  
>  obj-y += entry.o
>  
> diff --git a/xen/arch/arm/arm64/acpi/Makefile 
> b/xen/arch/arm/arm64/acpi/Makefile
> new file mode 100644
> index 000..07e3c44
> --- /dev/null
> +++ b/xen/arch/arm/arm64/acpi/Makefile
> @@ -0,0 +1 @@
> +obj-y  += arm-core.o
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
> b/xen/arch/arm/arm64/acpi/arm-core.c
> new file mode 100644
> index 000..50a83d6
> --- /dev/null
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -0,0 +1,97 @@
> +/*
> + *  ARM64 Specific Low-Level ACPI Boot Support
> + *
> + *  Copyright (C) 2014, Naresh Bhat 
> + *
> + * ~~
> + *
> + *  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, write to the Free Software
> + *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + *
> + * ~~
> + */
> +
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> +#include 
> +#include 
> +
> +#include 
> +
> +/*
> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> + * variable is still required by the ACPI core
> + */
> +u32 acpi_rsdt_forced;
> +
> +int acpi_noirq;/* skip ACPI IRQ initialization */
> +int acpi_strict;
> +int acpi_disabled;
> +EXPORT_SYMBOL(acpi_disabled);
> +
> +int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization 
> */
> +EXPORT_SYMBOL(acpi_pci_disabled);

As I wrote in the previous email, all these options need a comment that
explain what they mean.

The EXPORT_SYMBOL are unnecessary.


> +enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
> +
> +struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
> +
> +int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
> +{
> +*irq = -1;
> +return 0;
> +}
> +EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
> +
> +/*
> + * success: return IRQ number (>0)
> + * failure: return =< 0
> + */
> +//int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int 
> polarity)
> +unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low)
> +{
> +return -1;
> +}
> +EXPORT_SYMBOL_GPL(acpi_register_gsi);
> +
> +void acpi_unregister_gsi(u32 gsi)
> +{
> +}
> +EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
> +
> +/*
> + * acpi_boot_table_init() called from setup_arch(), always.
> + *  1. find RSDP and get its address, and then find XSDT
> + *  2. extract all tables and checksums them all
> + *
> + * We can parse ACPI boot-time tables such as FADT, MADT after
> + * this function is called.
> + */
> +int __init acpi_boot_table_init(void)
> +{
> +int error;
> +/* If acpi_disabled, bail out */
> +if (acpi_disabled)
> +return 1;
> +
> +/* Initialize the ACPI boot-time table parser. */
> +error = acpi_table_init();
> +if (error)
> +{
> +disable_acpi();
> +return error;
> +}
> +
> +return 0;
> +}
> +#endif
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 3991d64..7ae126b 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -45,6 +45,8 @@
>  #include 
>  #include 
>

Re: [Xen-devel] [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers

[Julien Grall]

Hi Parth,

On 04/02/2015 14:01, parth.di...@linaro.org wrote:

From: Naresh Bhat 

xen hypervisor will use ACPI for initialisation in the same manner that
current x86/x86_64 ones do. Add the calls to initialise the ACPI tables
and load devices using the xen/drivers/acpi subsytem.


All changes in this patch are mostly unrelated, and most of them 
requires an explanation why we need to it.


I would split this patch in small chunk.

See below for others comment.


Signed-off-by: Naresh Bhat 
---
  xen/common/sysctl.c   |   2 +
  xen/drivers/acpi/osl.c|   6 ++
  xen/drivers/acpi/utilities/utglobal.c |   1 +
  xen/include/asm-arm/acpi.h| 106 ++
  xen/include/asm-arm/arm64/page.h  |   2 +
  5 files changed, 117 insertions(+)
  create mode 100644 xen/include/asm-arm/acpi.h

diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 0cb6ee1..a700a16 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -170,6 +170,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
  op->u.availheap.avail_bytes <<= PAGE_SHIFT;
  break;

+#ifdef CONFIG_X86
  #ifdef HAS_ACPI


#if defined(CONFIG_X86) && defined(HAS_ACPI) ?

Also, this change seems to be related to the patch #1.

I would make sense to create a separate patch which will disable the 
compilation of pmstate and adding this #ifdef.



  case XEN_SYSCTL_get_pmstat:
  ret = do_get_pm_info(&op->u.get_pmstat);
@@ -181,6 +182,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
  copyback = 1;
  break;
  #endif
+#endif

  case XEN_SYSCTL_page_offline_op:
  {
diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index 93c983c..73da9d9 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -96,7 +96,11 @@ acpi_os_map_memory(acpi_physical_address phys, acpi_size 
size)
return __va(phys);
return __vmap(&pfn, PFN_UP(offs + size), 1, 1, 
PAGE_HYPERVISOR_NOCACHE) + offs;
}
+#ifdef CONFIG_X86
return __acpi_map_table(phys, size);
+#else
+   return __va(phys);


I remembered to have a discussion about this change with Naresh few 
month ago.


__va should only be used when the memory is direct-mapped to Xen (i.e 
accessible directly). On ARM64, this only the case for the RAM. Can you 
confirm that ACPI will always reside to the RAM?


Futhermore, the code of this function seems x86-specific. The low 1MB 
may not be mapped on ARM64.


I would move the whole function (acpi_os_map_memory) per-architecture.


+#endif
  }




  void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
@@ -105,6 +109,7 @@ void acpi_os_unmap_memory(void __iomem * virt, acpi_size 
size)
vunmap((void *)((unsigned long)virt & PAGE_MASK));
  }

+#ifdef CONFIG_X86
  acpi_status acpi_os_read_port(acpi_io_address port, u32 * value, u32 width)
  {
u32 dummy;
@@ -140,6 +145,7 @@ acpi_status acpi_os_write_port(acpi_io_address port, u32 
value, u32 width)

return AE_OK;
  }
+#endif


Why only x86? Linux seems to define it also for ARM64.


  acpi_status
  acpi_os_read_memory(acpi_physical_address phys_addr, u32 * value, u32 width)
diff --git a/xen/drivers/acpi/utilities/utglobal.c 
b/xen/drivers/acpi/utilities/utglobal.c
index 7dbc964..65c918e 100644
--- a/xen/drivers/acpi/utilities/utglobal.c
+++ b/xen/drivers/acpi/utilities/utglobal.c
@@ -43,6 +43,7 @@

  #define DEFINE_ACPI_GLOBALS

+#include 


Why it's necessary?


  #include 
  #include 
  #include 
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
new file mode 100644
index 000..f6284b5
--- /dev/null
+++ b/xen/include/asm-arm/acpi.h
@@ -0,0 +1,106 @@
+/*
+ *  Copyright (C) 2014, Naresh Bhat 
+ *
+ * ~~
+ *
+ *  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, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * ~~
+ */
+
+#ifndef _ASM_ARM64_ACPI_H
+#define _ASM_ARM64_ACPI_H
+
+#include 
+
+#define COMPILER_DEPENDENT_INT64   long long
+#define COMPILER_DEPENDENT_UINT64  unsigned long long
+
+#define MAX_LOCAL_APIC 256
+#define MAX_IO_APICS 64
+
+/*
+ * Calling conventions:
+ *
+ * ACP

Re: [Xen-devel] [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers

[Stefano Stabellini]

On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat 
> 
> xen hypervisor will use ACPI for initialisation in the same manner that
> current x86/x86_64 ones do. Add the calls to initialise the ACPI tables
> and load devices using the xen/drivers/acpi subsytem.
> 
> Signed-off-by: Naresh Bhat 
> ---
>  xen/common/sysctl.c   |   2 +
>  xen/drivers/acpi/osl.c|   6 ++
>  xen/drivers/acpi/utilities/utglobal.c |   1 +
>  xen/include/asm-arm/acpi.h| 106 
> ++
>  xen/include/asm-arm/arm64/page.h  |   2 +
>  5 files changed, 117 insertions(+)
>  create mode 100644 xen/include/asm-arm/acpi.h
> 
> diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
> index 0cb6ee1..a700a16 100644
> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -170,6 +170,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
> u_sysctl)
>  op->u.availheap.avail_bytes <<= PAGE_SHIFT;
>  break;
>  
> +#ifdef CONFIG_X86

Could you please explain in the commit message why you are ifdef'ing
the following?


>  #ifdef HAS_ACPI
>  case XEN_SYSCTL_get_pmstat:
>  ret = do_get_pm_info(&op->u.get_pmstat);
> @@ -181,6 +182,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
> u_sysctl)
>  copyback = 1;
>  break;
>  #endif
> +#endif
>  
>  case XEN_SYSCTL_page_offline_op:
>  {
> diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
> index 93c983c..73da9d9 100644
> --- a/xen/drivers/acpi/osl.c
> +++ b/xen/drivers/acpi/osl.c
> @@ -96,7 +96,11 @@ acpi_os_map_memory(acpi_physical_address phys, acpi_size 
> size)
>   return __va(phys);
>   return __vmap(&pfn, PFN_UP(offs + size), 1, 1, 
> PAGE_HYPERVISOR_NOCACHE) + offs;
>   }
> +#ifdef CONFIG_X86
>   return __acpi_map_table(phys, size);

same here: please explain


> +#else
> + return __va(phys);
> +#endif
>  }
>  
>  void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
> @@ -105,6 +109,7 @@ void acpi_os_unmap_memory(void __iomem * virt, acpi_size 
> size)
>   vunmap((void *)((unsigned long)virt & PAGE_MASK));
>  }
>  
> +#ifdef CONFIG_X86

same here: please explain


>  acpi_status acpi_os_read_port(acpi_io_address port, u32 * value, u32 width)
>  {
>   u32 dummy;
> @@ -140,6 +145,7 @@ acpi_status acpi_os_write_port(acpi_io_address port, u32 
> value, u32 width)
>  
>   return AE_OK;
>  }
> +#endif
>  
>  acpi_status
>  acpi_os_read_memory(acpi_physical_address phys_addr, u32 * value, u32 width)
> diff --git a/xen/drivers/acpi/utilities/utglobal.c 
> b/xen/drivers/acpi/utilities/utglobal.c
> index 7dbc964..65c918e 100644
> --- a/xen/drivers/acpi/utilities/utglobal.c
> +++ b/xen/drivers/acpi/utilities/utglobal.c
> @@ -43,6 +43,7 @@
>  
>  #define DEFINE_ACPI_GLOBALS
>  
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> new file mode 100644
> index 000..f6284b5
> --- /dev/null
> +++ b/xen/include/asm-arm/acpi.h

The addition of this new file should be moved to the next patch.


> @@ -0,0 +1,106 @@
> +/*
> + *  Copyright (C) 2014, Naresh Bhat 
> + *
> + * ~~
> + *
> + *  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, write to the Free Software
> + *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + *
> + * ~~
> + */
> +
> +#ifndef _ASM_ARM64_ACPI_H
> +#define _ASM_ARM64_ACPI_H
> +
> +#include 
> +
> +#define COMPILER_DEPENDENT_INT64   long long
> +#define COMPILER_DEPENDENT_UINT64  unsigned long long
> +
> +#define MAX_LOCAL_APIC 256
> +#define MAX_IO_APICS 64
> +
> +/*
> + * Calling conventions:
> + *
> + * ACPI_SYSTEM_XFACE- Interfaces to host OS (handlers, threads)
> + * ACPI_EXTERNAL_XFACE  - External ACPI interfaces
> + * ACPI_INTERNAL_XFACE  - Internal ACPI interfaces
> + * ACPI_INTERNAL_VAR_XFACE  - Internal variable-parameter list interfaces
> + */
> +#define ACPI_SYSTEM_XFACE
> +#define ACPI_EXTERNAL_XFACE
> +#define ACPI_INTERNAL_XFACE
> +#define ACPI_INTERNAL_VAR_XFACE
> +
> +/* Asm macros */
> +#define ACPI_ASM_MACROS
> +#define BREAKPOINT3
> +#define ACPI_DISABLE_IRQS() local_irq_disable()
> +#defi

[Xen-devel] [qemu-upstream-unstable test] 34131: regressions - FAIL

[xen . org]

flight 34131 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34131/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-i386 11 guest-localmigrate  fail REGR. vs. 33488
 test-amd64-i386-freebsd10-amd64 11 guest-localmigrate fail REGR. vs. 33488
 test-amd64-i386-xl-win7-amd64 10 guest-localmigrate   fail REGR. vs. 33488
 test-amd64-amd64-xl-winxpsp3 10 guest-localmigratefail REGR. vs. 33488
 test-amd64-amd64-xl-win7-amd64 10 guest-localmigrate  fail REGR. vs. 33488
 test-amd64-i386-xl-winxpsp3-vcpus1 10 guest-localmigrate  fail REGR. vs. 33488
 test-amd64-i386-xl-winxpsp3  10 guest-localmigratefail REGR. vs. 33488

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 guest-localmigrate fail REGR. vs. 
33488
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 guest-localmigrate fail REGR. vs. 
33488
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 guest-localmigrate fail REGR. vs. 33488
 test-amd64-i386-xl-qemuu-win7-amd64 10 guest-localmigrate fail REGR. vs. 33488
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 10 guest-localmigrate fail REGR. vs. 
33488
 test-amd64-i386-xl-qemuu-winxpsp3 10 guest-localmigrate   fail REGR. vs. 33488
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 guest-localmigrate fail REGR. vs. 33488
 test-amd64-amd64-xl-qemuu-win7-amd64 10 guest-localmigrate fail REGR. vs. 33488
 test-amd64-amd64-xl-qemuu-winxpsp3 10 guest-localmigrate  fail REGR. vs. 33488

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-armhf-armhf-xl-midway   10 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf 10 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-armhf-armhf-xl-credit2   5 xen-boot fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass

version targeted for testing:
 qemuube11dc1e9172f91e798a8f831b30c14b479e08e8
baseline version:
 qemuu0d37748342e29854db7c9f6c47d7f58c6cfba6b2


People who touched revisions under test:
  Don Slutz 
  Paul Durrant 
  Stefano Stabellini 


jobs:
 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-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64fail
 test-amd64-i386-xl-qemuu-debianhvm-amd64 fail
 test-amd64-i386-freebsd10-amd64  fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  

[Xen-devel] [PATCH] xen/arm: Call context_saved() with interrupts enabled during context switch

[Denis Drozdov]

From: denys drozdov 

This is a requirement of the scheduler interface, violating this
causes for example with the RT scheduler:

(XEN) Assertion 'local_irq_is_enabled()' failed at spinlock.c:137
(XEN) [ Xen-4.5.0  arm32  debug=y  Not tainted ]
(XEN) CPU:0
(XEN) PC: 0022a074 _spin_lock_irq+0x18/0x94

(XEN) Xen call trace:
(XEN)[<0022a074>] _spin_lock_irq+0x18/0x94 (PC)
(XEN)[<002256b8>] rt_context_saved+0x3c/0x144 (LR)
(XEN)[<002256b8>] rt_context_saved+0x3c/0x144
(XEN)[<00228ed8>] context_saved+0x4c/0x80
(XEN)[<002524b4>] schedule_tail+0x148/0x2f0
(XEN)[<00252668>] continue_new_vcpu+0xc/0x70
(XEN)[<00252a18>] context_switch+0x74/0x7c


Signed-off-by: denys drozdov 
Acked-by: Ian Campbell 
Reviewed-by: Dario Faggioli 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/domain.c |7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7221bc8..1626376 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -64,7 +64,7 @@ static void ctxt_switch_from(struct vcpu *p)
  * mode. Therefore we don't need to save the context of an idle VCPU.
  */
 if ( is_idle_vcpu(p) )
-goto end_context;
+return;
 
 p2m_save_state(p);
 
@@ -138,9 +138,6 @@ static void ctxt_switch_from(struct vcpu *p)
 gic_save_state(p);
 
 isb();
-
-end_context:
-context_saved(p);
 }
 
 static void ctxt_switch_to(struct vcpu *n)
@@ -246,6 +243,8 @@ static void schedule_tail(struct vcpu *prev)
 
 local_irq_enable();
 
+context_saved(prev);
+
 if ( prev != current )
 update_runstate_area(current);
 
-- 
1.7.9.5


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

Re: [Xen-devel] [PATCH RFC 01/35] xen: acpi: Build numa and pmstate x86 only

[Julien Grall]

Hi Parth,

On 04/02/2015 14:01, parth.di...@linaro.org wrote:

From: Naresh Bhat 

Configure and build numa, pmstate for x86 architecture only.


Can you explain why you need to disable them?

I.e this code is contains some x86 dependencies and both feature are not 
supported on ARM right now.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH OSSTEST v6 9/9] mfi-common, make-flight: create XSM test jobs

[Wei Liu]

On Wed, Feb 04, 2015 at 04:47:51PM +, Ian Jackson wrote:
> Wei Liu writes ("[PATCH OSSTEST v6 9/9] mfi-common, make-flight: create XSM 
> test jobs"):
> > Duplicate Debian PV and HVM test jobs for XSM testing.
> 
> This looks pretty good.  I have one minor comment:
> 
> > +  xsm_suffix=""
> > +  for rv in $@ ; do
> > +  case $rv in
> > +  enable_xsm=true) xsm_suffix="-xsm";;
> > +  esac
> > +  done
> 
> You could write this as
> 
>case " $* " in
>*" enable_xsm=true "*) xsm_suffix="-xsm";;
>esac
> 
> since we don't cope with runvar settings with spaces in anyway.
> 
> (If we did you'd have to write   "$@"   not just  $@   .)
> 
> Ian.

Here is the updated version:

---8<---
>From 5b40b06a62ef51ad511e36bf6eb12f3e9e88a647 Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Mon, 2 Feb 2015 19:57:13 +
Subject: [PATCH OSSTEST v6] mfi-common, make-flight: create XSM test jobs
Cc: ian.campb...@citrix.com, ian.jack...@eu.citrix.com

Duplicate Debian PV and HVM test jobs for XSM testing.

Signed-off-by: Wei Liu 
Cc: Ian Campbell 
Cc: Ian Jackson 
---
Changes in v6:
1. Skip generating xsm job for different platforms.
2. Use "xsms".
3. Reformat some long lines.
---
 make-flight | 53 +++--
 mfi-common  | 10 --
 2 files changed, 47 insertions(+), 16 deletions(-)

diff --git a/make-flight b/make-flight
index 0cb9b98..8ac3a87 100755
--- a/make-flight
+++ b/make-flight
@@ -207,27 +207,36 @@ do_hvm_win7_x64_tests () {
 do_hvm_debian_test_one () {
   testname=$1
   bios=$2
+  xsm=$3
+
   job_create_test test-$xenarch$kern-$dom0arch-xl$qemuu_suffix-$testname-amd64\
 test-debianhvm xl $xenarch $dom0arch $qemuu_runvar \
+enable_xsm=$xsm \
 debianhvm_image=debian-7.2.0-amd64-CD-1.iso \
 bios=$bios \
 all_hostflags=$most_hostflags,hvm
 }
 
 do_hvm_debian_tests() {
+  xsms=$(xenbranch_xsm_variants)
+
   if [ $xenarch != amd64 ]; then
 return
   fi
 
   # QEMU upstream supports ovmf and seabios
   if [ "x$qemuu_suffix" == "x-qemuu" ]; then
-do_hvm_debian_test_one ovmf ovmf
-do_hvm_debian_test_one debianhvm seabios
+do_hvm_debian_test_one ovmf ovmf false
+for xsm in $xsms ; do
+  do_hvm_debian_test_one debianhvm seabios $xsm
+done
   fi
 
   # QEMU traditional supports rombios
   if [ "x$qemuu_suffix" == "x-qemut" ]; then
-do_hvm_debian_test_one debianhvm rombios
+for xsm in $xsms ; do
+  do_hvm_debian_test_one debianhvm rombios $xsm
+done
   fi
 }
 
@@ -299,19 +308,35 @@ do_passthrough_tests () {
 }
 
 do_pv_debian_tests () {
-  # Basic PV Linux test with xl
-  for platform in '' `getplatforms $xenarch` ; do
-suffix=${platform:+-$platform}
-hostflags=${most_hostflags}${platform:+,platform-$platform}
-
-job_create_test test-$xenarch$kern-$dom0arch-xl$suffix test-debian xl \
-$xenarch $dom0arch   \
-$debian_runvars all_hostflags=$hostflags
+  xsms=$(xenbranch_xsm_variants)
+
+  for xsm in $xsms ; do
+# Basic PV Linux test with xl
+for platform in '' `getplatforms $xenarch` ; do
+
+  # xsm test is not platform specific
+  if [ x$xsm = xtrue -a x$platform != x ]; then
+  continue
+  fi
+
+  suffix=${platform:+-$platform}
+  hostflags=${most_hostflags}${platform:+,platform-$platform}
+
+  job_create_test test-$xenarch$kern-$dom0arch-xl$suffix   \
+  test-debian xl   \
+  $xenarch $dom0arch   \
+  enable_xsm=$xsm  \
+  $debian_runvars all_hostflags=$hostflags
+done
   done
 
-  job_create_test test-$xenarch$kern-$dom0arch-libvirt test-debian libvirt \
-$xenarch $dom0arch   \
-$debian_runvars all_hostflags=$most_hostflags
+  for xsm in $xsms ; do
+job_create_test test-$xenarch$kern-$dom0arch-libvirt \
+test-debian libvirt  \
+$xenarch $dom0arch   \
+enable_xsm=$xsm  \
+$debian_runvars all_hostflags=$most_hostflags
+  done
 }
 
 test_matrix_do_one () {
diff --git a/mfi-common b/mfi-common
index ee4e635..a0603a2 100644
--- a/mfi-common
+++ b/mfi-common
@@ -271,8 +271,14 @@ job_create_test () {
   local xenarch=$1; shift
   local dom0arch=$1; shift
 
-  xenbuildjob="${bfi}build-$xenarch"
-  buildjob="${bfi}build-$dom0arch"
+  xsm_suffix=""
+  case " $* " in
+*" enable_xsm=true "*) xsm_suffix="-xsm";
+  esac
+
+  job="$job$xsm_suffix"
+  xenbuildjob="${bfi}build-$xenarch$xsm_suffix"
+  buildjob="${bfi}build-$dom0arch$xsm_suffix"
   tsbuildjob=
 
   case "$xenbranch:$toolstack" in
-- 
1.9.1


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

[Xen-devel] [PATCH] tools: work around collision of -O0 and -D_FORTIFY_SOURCE

[Jan Beulich]

The former gets enforced by our debug builds, the latter appears to be
not uncommon for certain distros' Python packages. Newer glibc warns on
uses of _FORTIFY_SOURCE without optimization being enabled, which with
-Werror causes the build to fail.

Determine Python's intended flags to be passed to the C compiler via
"python-config --cflags", and replace -O0 by -O1 when a non-zero value
gets set for _FORTIFY_SOURCE.

Signed-off-by: Jan Beulich 

--- a/tools/pygrub/Makefile
+++ b/tools/pygrub/Makefile
@@ -2,15 +2,24 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+py_cflags := $(shell $(PYTHON)-config --cflags)
+PY_CFLAGS = $(if $(strip $(py_cflags)),,\
+ $(error '$(PYTHON)-config --cflags' produced no output))\
+$(if $(filter -D_FORTIFY_SOURCE=%,\
+  $(filter-out -D_FORTIFY_SOURCE=0,\
+   $(py_cflags))),\
+ $(patsubst -O0,-O1,$(CFLAGS)),\
+ $(CFLAGS)) $(APPEND_LDFLAGS)
+
 .PHONY: all
 all: build
 .PHONY: build
 build:
-   CC="$(CC)" CFLAGS="$(CFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) setup.py build
+   CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build
 
 .PHONY: install
 install: all
-   CC="$(CC)" CFLAGS="$(CFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) setup.py 
install \
+   CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py install \
$(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" \
--install-scripts=$(LIBEXEC_BIN) --force
set -e; if [ $(BINDIR) != $(LIBEXEC_BIN) -a \
--- a/tools/python/Makefile
+++ b/tools/python/Makefile
@@ -4,6 +4,15 @@ include $(XEN_ROOT)/tools/Rules.mk
 .PHONY: all
 all: build
 
+py_cflags := $(shell $(PYTHON)-config --cflags)
+PY_CFLAGS = $(if $(strip $(py_cflags)),,\
+ $(error '$(PYTHON)-config --cflags' produced no output))\
+$(if $(filter -D_FORTIFY_SOURCE=%,\
+  $(filter-out -D_FORTIFY_SOURCE=0,\
+   $(py_cflags))),\
+ $(patsubst -O0,-O1,$(CFLAGS)),\
+ $(CFLAGS)) $(LDFLAGS) $(APPEND_LDFLAGS)
+
 .PHONY: build
 build: genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \
$(XEN_ROOT)/tools/libxl/idl.py
@@ -11,11 +20,11 @@ build: genwrap.py $(XEN_ROOT)/tools/libx
$(XEN_ROOT)/tools/libxl/libxl_types.idl \
xen/lowlevel/xl/_pyxl_types.h \
xen/lowlevel/xl/_pyxl_types.c
-   CC="$(CC)" CFLAGS="$(CFLAGS) $(LDFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) 
setup.py build
+   CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build
 
 .PHONY: install
 install:
-   CC="$(CC)" CFLAGS="$(CFLAGS) $(LDFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) 
setup.py install \
+   CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py install \
$(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" --force
 
 .PHONY: test



tools: work around collision of -O0 and -D_FORTIFY_SOURCE

The former gets enforced by our debug builds, the latter appears to be
not uncommon for certain distros' Python packages. Newer glibc warns on
uses of _FORTIFY_SOURCE without optimization being enabled, which with
-Werror causes the build to fail.

Determine Python's intended flags to be passed to the C compiler via
"python-config --cflags", and replace -O0 by -O1 when a non-zero value
gets set for _FORTIFY_SOURCE.

Signed-off-by: Jan Beulich 

--- a/tools/pygrub/Makefile
+++ b/tools/pygrub/Makefile
@@ -2,15 +2,24 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+py_cflags := $(shell $(PYTHON)-config --cflags)
+PY_CFLAGS = $(if $(strip $(py_cflags)),,\
+ $(error '$(PYTHON)-config --cflags' produced no output))\
+$(if $(filter -D_FORTIFY_SOURCE=%,\
+  $(filter-out -D_FORTIFY_SOURCE=0,\
+   $(py_cflags))),\
+ $(patsubst -O0,-O1,$(CFLAGS)),\
+ $(CFLAGS)) $(APPEND_LDFLAGS)
+
 .PHONY: all
 all: build
 .PHONY: build
 build:
-   CC="$(CC)" CFLAGS="$(CFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) setup.py build
+   CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build
 
 .PHONY: install
 install: all
-   CC="$(CC)" CFLAGS="$(CFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) setup.py 
install \
+   CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py install \
$(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" \
--install-scripts=$(LIBEXEC_BIN) --force
set -e; if [ $(BINDIR) != $(LIBEXEC_BIN) -a \
--- a/tools/python/Makefile
+++ b/tools/python/Makefile
@@ -4,6 +4,15 @@ include $(XEN_ROOT)/tools/Rules.mk
 .PHONY: all
 all: build
 
+py_cflags := $(shell $(PYTHON)-config --cflags)
+PY_CFLAGS = $(if $(strip $(py_cflags)),,\
+ $(error '$(PYTHON)-config --cflags' produced no output))\
+$(if $(filter -D_FORTIFY_SOURCE=%,\
+  $(filter-out -D_FORTIFY_SOURCE=0,\
+ 

[Xen-devel] [CALL-FOR-AGENDA] Monthly Xen.org Technical Call (2015-02-11)

[Ian Campbell]

The next Xen technical call should be at:
Wed 11 Feb 17:00:00 GMT 2015
date -d @1423674000

However I'm going to be at a conference next week in GMT+8, so I'm not
available to chair. If there is something which needs urgent
discussion then I can try and find a standin, otherwise I suggest we
skip this month.


See http://lists.xen.org/archives/html/xen-devel/2015-01/msg00414.html
for more information on the call.

Please let me know (CC-ing the list) any topics which you would like to
discuss. It might be useful to include:

  * References to any relevant/recent mailing list threads;
  * Other people who you think should be involved in the discussion (and
CC them);

If you would like to attend then please let me know so I can send you the
dial in details.

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

Re: [Xen-devel] [Xen-users] Xen memory allocation for dom0 and domU

[Jan Beulich]

>>> On 04.02.15 at 17:41,  wrote:
> I originally used to think that domheap allocations would fall back to
> the xenheap if the domheap was exhausted, but I think I was mistaken in
> that.

That's an arch choice actually - there are two variants of the Xen
heap allocation function.

> Patch for all this below. Jan, I don't think there is any (possibly
> historical on x86_32) x86 option we should be trying to be consistent
> with.

On x86-32 it was always fixed 16M. On x86-64 we had a
"xenheap_megabytes=" option before the sharing of the pools
got introduced.

Jan


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

Re: [Xen-devel] [PATCH OSSTEST v6 9/9] mfi-common, make-flight: create XSM test jobs

[Ian Jackson]

Wei Liu writes ("[PATCH OSSTEST v6 9/9] mfi-common, make-flight: create XSM 
test jobs"):
> Duplicate Debian PV and HVM test jobs for XSM testing.

This looks pretty good.  I have one minor comment:

> +  xsm_suffix=""
> +  for rv in $@ ; do
> +  case $rv in
> +  enable_xsm=true) xsm_suffix="-xsm";;
> +  esac
> +  done

You could write this as

   case " $* " in
   *" enable_xsm=true "*) xsm_suffix="-xsm";;
   esac

since we don't cope with runvar settings with spaces in anyway.

(If we did you'd have to write   "$@"   not just  $@   .)

Ian.

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

[Xen-devel] question about memory allocation for driver domain

[Oleksandr Tyshchenko]

Hi, all.

We have begun to use the driver domain on OMAP5 platform.
To make driver domain running on OMAP5 platform we need to have it
memory 1 to 1 mapped because of lacking SMMU support on this platform.
To satisfy this requirement we have done temporally solution which
works but not entirely completed and looks not good from Xen
perspective. The main question in memory allocator in Xen.

We did next steps:
1. toolstack:
- allow to allocate 128/256/512 Mb memory chunks
- add ability to set rambase_pfn via cfg file

2. hypervisor:
- alloc driver domain memory 1 to 1
  - mark domain with id 1 as privileged
  - update memory allocation logic for such domain
  - allocate memory in the same way as for domain 0

But we have encountered with one thing related to memory allocation algorithm.
Let me describe what I mean.
Our requirements is to allocate one specified chunk if it is present in domheap.
We have this "spec_mfn" which are a "rambase_pfn" for driver domain we
want to map 1 to 1. We can get it from extent_list. So, we need to
alloc chunk which would be correspond to "spec_mfn".
In other world we need to allocate known chunk of memory. But if I
understood correctly that the existing allocator doesn't allow us to
do that directly.

There are some thoughts how to do that. But, at first, we need to
choose right direction:
1. Add the separate memory allocator which allow us to alloc specified
chunk if it is present. And use it in case when we need to allocate
memory for driver domain 1:1 only. We can pass bool variable via cfg
file to show what we want (1:1 or not).
2. Don't add separate allocator. Modify existing allocator to add
ability to alloc specified chunk.
3. Don't add and modify anything. Let the allocator to work as usual.
Return mfn of allocating chunk and correct the default rambase_pfn in
toolstack.
What we actually have in the moment but do that manually. We see what
the mfn we got and corrected "rambase_pfn" property in cfg file.

Could someone explain me what is a right way?
All suggestions welcomed!

-- 

Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com

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

Re: [Xen-devel] [PATCH v3 21/27] Ovmf/Xen: add ARM and AArch64 support to XenBusDxe

[Stefano Stabellini]

On Tue, 3 Feb 2015, Ard Biesheuvel wrote:
> This patch adds support to XenBusDxe for executing on ARM and AArch64
> machines (the former only when built with GCC).

Wouldn't it be simpler to just provide an asm implementation of them?
Similarly to OvmfPkg/XenBusDxe/X64/TestAndClearBit.nasm and
OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.nasm?

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  OvmfPkg/XenBusDxe/AtomicsGcc.c  | 44 
> +
>  OvmfPkg/XenBusDxe/XenBusDxe.inf |  3 +++
>  2 files changed, 47 insertions(+)
>  create mode 100644 OvmfPkg/XenBusDxe/AtomicsGcc.c
> 
> diff --git a/OvmfPkg/XenBusDxe/AtomicsGcc.c b/OvmfPkg/XenBusDxe/AtomicsGcc.c
> new file mode 100644
> index ..a0bdcbf67440
> --- /dev/null
> +++ b/OvmfPkg/XenBusDxe/AtomicsGcc.c
> @@ -0,0 +1,44 @@
> +/** @file
> +  Arch-independent implementations of XenBusDxe atomics using GCC __builtins
> +
> +  Copyright (C) 2014, Linaro Ltd.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +UINT16
> +EFIAPI
> +InternalSyncCompareExchange16 (
> +  IN  volatile UINT16   *Value,
> +  IN  UINT16CompareValue,
> +  IN  UINT16ExchangeValue
> +  )
> +{
> +  return __sync_val_compare_and_swap_2 (Value, CompareValue, ExchangeValue);
> +}
> +
> +INT32
> +EFIAPI
> +TestAndClearBit (
> +  IN INT32Bit,
> +  IN volatile VOID*Address
> +  )
> +{
> +  //
> +  // Calculate the effective address relative to 'Address' based on the
> +  // higher order bits of 'Bit'. Use signed shift instead of division to
> +  // ensure we round towards -Inf, and end up with a positive shift in 'Bit',
> +  // even if 'Bit' itself is negative.
> +  //
> +  Address += (Bit >> 5) * sizeof(INT32);
> +  Bit &= 31;
> +
> +  return (__sync_fetch_and_and_4 (Address, ~(1U << Bit)) & (1U << Bit)) != 0;
> +}
> diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
> index 31553ac5a64a..949ec0a0c732 100644
> --- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
> +++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
> @@ -54,6 +54,9 @@
>X64/InterlockedCompareExchange16.nasm
>X64/TestAndClearBit.nasm
>  
> +[Sources.AARCH64, Sources.ARM]
> +  AtomicsGcc.c | GCC
> +
>  [LibraryClasses]
>UefiDriverEntryPoint
>UefiBootServicesTableLib
> -- 
> 1.8.3.2
> 

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

Re: [Xen-devel] [PATCH] xen/arm: Fix rtds scheduler for arm

[Julien Grall]

Hello,

On 04/02/2015 15:13, Ian Campbell wrote:

On Mon, 2015-02-02 at 20:03 +0200, Denis Drozdov wrote:

From: denys drozdov 

Make Credit2 and RT schedulers to run on arm platform
context_saved should be deferred on ARM after IRQs enabled


A better subject+message would be:

 xen/arm: Call context_saved() with interrupts enabled during context 
switch

 This is a requirement of the scheduler interface, violating this
 causes for example with the RT scheduler:
 


Signed-off-by: denys drozdov 


Acked-by: Ian Campbell 


The commit message suggested by Ian looks more clear to me. With this 
change:


Reviewed-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] Fix building error

[Olaf Hering]

On Wed, Feb 04, Jan Beulich wrote:

> I also checked Python, and they also seem to have been enabling
> _FORTIFY_SOURCE forever. Consequently, with the previously suggested
> patches not having found acceptance, how about

I'm sure python just carries the CFLAGS used for its build, so that
other python related code can use the very same CFLAGS. IMO that is
valid. Since the whole distro is built with those CFLAGS via
RPM_OPT_FLAGS it will end up also in python.

I wonder, is it just SUSE and Fedora that use _FORTIFY_SOURCE in global
CFLAGS?

Olaf

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

Re: [Xen-devel] [Xen-users] Xen memory allocation for dom0 and domU

[Ian Campbell]

On Wed, 2015-02-04 at 14:55 +, Ian Campbell wrote:
> On Wed, 2015-02-04 at 09:45 -0500, Jintack Lim wrote:
> > > Don't forget that Xen itself will consume some RAM, according to your
> > > numbers it's something between 256M and 350M on this system (that's more
> > > than my gut feeling expects, but not way out).
> > >
> > 
> > Yes, it seems Xen is consuming 289M.
> > Is it expected?
> 
> It's a bit more than my gut feeling would have said we used, but not so
> large I think it indicates something is very wrong.

It's the xenheap, which is 1/8 of the total RAM (at least 128M and
capped at 1GB), so in your case ~256M less whatever allocations made
from it during boot.

xenheap is Xen's "malloc heap" (always mapped), as opposed to the dom
heap which is where domain memory comes from and is demand mapped. The
domheap is what xl info calls "free memory" and what you need to
allocate in order to start a guest.

I originally used to think that domheap allocations would fall back to
the xenheap if the domheap was exhausted, but I think I was mistaken in
that.

This is only an issue on arm32 because on arm64 all of RAM is always
mapped and there is no separate domheap (on Seattle from your other mail
I think what you are seeing is the large frametable from the 16GB of
RAM)

I think that 1/8 RAM (min 128M) is probably too large. Something like
1/32 (min 32M) perhaps? On a 2GB system that would be 64M. 32-bit x86
used to manage with 12M FWIW.

I also think this should be controllable by the user.

Patch for all this below. Jan, I don't think there is any (possibly
historical on x86_32) x86 option we should be trying to be consistent
with.

Ian.


8<-

>From f41ab97bcefc74f0f7be76c91bb00e5bd32b7677 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Wed, 4 Feb 2015 16:36:36 +
Subject: [PATCH] xen: arm32: reduce default size of the xenheap

... and make it tunable via the command line.

1/8 of RAM is 128M on a 1GB system and 256M on a 2GB system etc,
which is a lot. 1/32 of RAM seems more reasonable. Also drop the
minimum to 32M.

Leave the maximum at 1GB.

Signed-off-by: Ian Campbell 
---
 docs/misc/xen-command-line.markdown |8 
 xen/arch/arm/setup.c|   25 ++---
 2 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index bc316be..dac82ef 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -237,6 +237,14 @@ and not running softirqs. Reduce this if softirqs are not 
being run frequently
 enough. Setting this to a high value may cause boot failure, particularly if
 the NMI watchdog is also enabled.
 
+### xenheap\_size (arm32)
+> `= `
+
+> Default: `1/32 RAM`
+
+Amount of RAM to set aside for the Xenheap. By default 1/32 of the RAM
+up to a maximum of 1GB and with a minimum of 32M.
+
 ### clocksource
 > `= pit | hpet | acpi`
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index a916ca6..5be1637 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -50,6 +50,11 @@ struct bootinfo __initdata bootinfo;
 
 struct cpuinfo_arm __read_mostly boot_cpu_data;
 
+#ifdef CONFIG_ARM_32
+static unsigned long opt_xenheap_size __initdata;
+size_param("xenheap_size", opt_xenheap_size);
+#endif
+
 static __used void init_done(void)
 {
 free_init_memory();
@@ -501,16 +506,21 @@ static void __init setup_mm(unsigned long dtb_paddr, 
size_t dtb_size)
  *
  *  - must be 32 MiB aligned
  *  - must not include Xen itself or the boot modules
- *  - must be at most 1GB or 1/8 the total RAM in the system if less
- *  - must be at least 128M
+ *  - must be at most 1GB or 1/32 the total RAM in the system if less
+ *  - must be at least 32M
  *
  * We try to allocate the largest xenheap possible within these
  * constraints.
  */
 heap_pages = ram_pages;
-xenheap_pages = (heap_pages/8 + 0x1fffUL) & ~0x1fffUL;
-xenheap_pages = max(xenheap_pages, 128UL<<(20-PAGE_SHIFT));
-xenheap_pages = min(xenheap_pages, 1UL<<(30-PAGE_SHIFT));
+if ( opt_xenheap_size )
+xenheap_pages = opt_xenheap_size >> PAGE_SHIFT;
+else
+{
+xenheap_pages = (heap_pages/32 + 0x1fffUL) & ~0x1fffUL;
+xenheap_pages = max(xenheap_pages, 32UL<<(20-PAGE_SHIFT));
+xenheap_pages = min(xenheap_pages, 1UL<<(30-PAGE_SHIFT));
+}
 
 do
 {
@@ -528,8 +538,9 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
 
 domheap_pages = heap_pages - xenheap_pages;
 
-printk("Xen heap: %"PRIpaddr"-%"PRIpaddr" (%lu pages)\n",
-e - (pfn_to_paddr(xenheap_pages)), e, xenheap_pages);
+printk("Xen heap: %"PRIpaddr"-%"PRIpaddr" (%lu pages%s)\n",
+   e - (pfn_to_paddr(xenheap_pages)), e, xenheap_pages,
+   opt_xenheap_size ? ", from command-line" : "");
 printk("Dom heap: %lu pages\n", domheap_pages);
 
 se

Re: [Xen-devel] [PATCH RFC 00/35] Add ACPI support for arm64 on Xen

[Julien Grall]

Hi Parth,

On 04/02/2015 14:01, parth.di...@linaro.org wrote:

From: Parth Dixit 
This patch series adds ACPI support for arm64.


Thank you for sending the ACPI patch series. I will give a look at it 
before the connect, so we could talk about it next week.



Xen reads static tables described by ACPI standard (5.1) from uefi
and configures timer, gic and uart. ACPI tables are modified to
enable PSCI, HVC and xen specific information (grant table and
event channel interrupts) and mapped into dom0 address space.
A skeleton device tree is created to pass memory
(which cannot be passed using ACPI) and rsdp pointer to DOM0.
DOM0 parses dynamic ACPI tables and configure other peripherals.

- patches 1-19 add ACPI support for xen/uefi interface
- patches 20-35 add ACPI support for xen/dom0 interface
Last patch "xen: arm64: Add ACPI support" enables the support for ACPI
so that individual patches do not affect working xen code base.

Instructions for reproducing the setup and working code base can be found
in the following repositories
wiki : https://wiki.linaro.org/LEG/Engineering/Xen_boot_on_FVP_ACPI_UEFI
linux : 
https://git.linaro.org/people/parth.dixit/xen-acpi-support/leg-kernel.git
xen : https://git.linaro.org/people/parth.dixit/xen-acpi-support/xen.git
uefi : 
https://git.linaro.org/people/parth.dixit/xen-acpi-support/linaro-edk2.git

Few workarounds have been made to get it working, these are as follows
1. Xen assumes that mmio regions are defined in firmware. It reads
this information from uefi tables and map's it to dom0 address space.


FWIW, this is part of the UEFI spec. So it's safe to use it ;).


Right now FVP firmware on which this series has been tested
does not contains all the mmio regions defined in ACPI supplied by
firmware, to overcome this hard coding of mmio regions is done.


What's the status of this bug? IIRC, a bug was filled last December.


2. Linux is checking if mapped pages belong to ram and when this check 
fails(incorrectly)
it maps RAM using ioremap, to overcome this at present this check is
disabled in linux.


Some people were working on dropping/reworking this check. What's the 
status?



3. Device specific interrupt information is defined in DSDT tables in ACPI.
Parsing this table is out of scope for xen so it uses dom0 to parse DSDT table
and enables the interrupt dynamically when they are enabled by dom0.


It's a design choice, not a workaround ;).


4. Grant table region and event channel interrupts are hard coded right now.

5. RSDP ponter is exposed to dom0 by using "rsdp" node, this node is not yet 
defined
in linux and its name may get changed to "linux,acpi-rsdp" or something else.


Ditto.

BTW, when do you plan to send the Linux series? Did they decided about 
the boot protocol?


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] common/xz: add comments for the intentionally missing break statements

[Ian Campbell]

On Wed, 2015-02-04 at 16:08 +, Jan Beulich wrote:
> Signed-off-by: Lasse Collin 
> [Linux commit 84d517f3e56f7d0d305c14a701cee8f7372ebe1e]
> Signed-off-by: Jan Beulich 

Acked-by: IAn Campbell 

> 
> --- a/xen/common/xz/dec_lzma2.c
> +++ b/xen/common/xz/dec_lzma2.c
> @@ -1043,6 +1043,8 @@ XZ_EXTERN enum xz_ret INIT xz_dec_lzma2_
>  
>   s->lzma2.sequence = SEQ_LZMA_PREPARE;
>  
> + /* Fall through */
> +
>   case SEQ_LZMA_PREPARE:
>   if (s->lzma2.compressed < RC_INIT_BYTES)
>   return XZ_DATA_ERROR;
> @@ -1053,6 +1055,8 @@ XZ_EXTERN enum xz_ret INIT xz_dec_lzma2_
>   s->lzma2.compressed -= RC_INIT_BYTES;
>   s->lzma2.sequence = SEQ_LZMA_RUN;
>  
> + /* Fall through */
> +
>   case SEQ_LZMA_RUN:
>   /*
>* Set dictionary limit to indicate how much we want
> 
> 
> 



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

[Xen-devel] [PATCH OSSTEST v6 2/9] ts-xen-build-prep: install checkpolicy

[Wei Liu]

This is used to complie Flask policy.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 
---
 ts-xen-build-prep | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 24a8b25..3684c0a 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -178,7 +178,7 @@ sub prep () {
autoconf automake libtool xsltproc
libxml2-utils libxml2-dev libnl-dev
libdevmapper-dev w3c-dtd-xhtml libxml-xpath-perl
-   ccache nasm));
+   ccache nasm checkpolicy));
 
 target_cmd_root($ho, "chmod -R a+r /usr/share/git-core/templates");
 # workaround for Debian #595728
-- 
1.9.1


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

[Xen-devel] [PATCH OSSTEST v6 9/9] mfi-common, make-flight: create XSM test jobs

[Wei Liu]

Duplicate Debian PV and HVM test jobs for XSM testing.

Signed-off-by: Wei Liu 
Cc: Ian Campbell 
Cc: Ian Jackson 
---
Changes in v6:
1. Skip generating xsm job for different platforms.
2. Use "xsms".
3. Reformat some long lines.
---
 make-flight | 53 +++--
 mfi-common  | 12 ++--
 2 files changed, 49 insertions(+), 16 deletions(-)

diff --git a/make-flight b/make-flight
index 0cb9b98..8ac3a87 100755
--- a/make-flight
+++ b/make-flight
@@ -207,27 +207,36 @@ do_hvm_win7_x64_tests () {
 do_hvm_debian_test_one () {
   testname=$1
   bios=$2
+  xsm=$3
+
   job_create_test test-$xenarch$kern-$dom0arch-xl$qemuu_suffix-$testname-amd64\
 test-debianhvm xl $xenarch $dom0arch $qemuu_runvar \
+enable_xsm=$xsm \
 debianhvm_image=debian-7.2.0-amd64-CD-1.iso \
 bios=$bios \
 all_hostflags=$most_hostflags,hvm
 }
 
 do_hvm_debian_tests() {
+  xsms=$(xenbranch_xsm_variants)
+
   if [ $xenarch != amd64 ]; then
 return
   fi
 
   # QEMU upstream supports ovmf and seabios
   if [ "x$qemuu_suffix" == "x-qemuu" ]; then
-do_hvm_debian_test_one ovmf ovmf
-do_hvm_debian_test_one debianhvm seabios
+do_hvm_debian_test_one ovmf ovmf false
+for xsm in $xsms ; do
+  do_hvm_debian_test_one debianhvm seabios $xsm
+done
   fi
 
   # QEMU traditional supports rombios
   if [ "x$qemuu_suffix" == "x-qemut" ]; then
-do_hvm_debian_test_one debianhvm rombios
+for xsm in $xsms ; do
+  do_hvm_debian_test_one debianhvm rombios $xsm
+done
   fi
 }
 
@@ -299,19 +308,35 @@ do_passthrough_tests () {
 }
 
 do_pv_debian_tests () {
-  # Basic PV Linux test with xl
-  for platform in '' `getplatforms $xenarch` ; do
-suffix=${platform:+-$platform}
-hostflags=${most_hostflags}${platform:+,platform-$platform}
-
-job_create_test test-$xenarch$kern-$dom0arch-xl$suffix test-debian xl \
-$xenarch $dom0arch   \
-$debian_runvars all_hostflags=$hostflags
+  xsms=$(xenbranch_xsm_variants)
+
+  for xsm in $xsms ; do
+# Basic PV Linux test with xl
+for platform in '' `getplatforms $xenarch` ; do
+
+  # xsm test is not platform specific
+  if [ x$xsm = xtrue -a x$platform != x ]; then
+  continue
+  fi
+
+  suffix=${platform:+-$platform}
+  hostflags=${most_hostflags}${platform:+,platform-$platform}
+
+  job_create_test test-$xenarch$kern-$dom0arch-xl$suffix   \
+  test-debian xl   \
+  $xenarch $dom0arch   \
+  enable_xsm=$xsm  \
+  $debian_runvars all_hostflags=$hostflags
+done
   done
 
-  job_create_test test-$xenarch$kern-$dom0arch-libvirt test-debian libvirt \
-$xenarch $dom0arch   \
-$debian_runvars all_hostflags=$most_hostflags
+  for xsm in $xsms ; do
+job_create_test test-$xenarch$kern-$dom0arch-libvirt \
+test-debian libvirt  \
+$xenarch $dom0arch   \
+enable_xsm=$xsm  \
+$debian_runvars all_hostflags=$most_hostflags
+  done
 }
 
 test_matrix_do_one () {
diff --git a/mfi-common b/mfi-common
index ee4e635..b99cc14 100644
--- a/mfi-common
+++ b/mfi-common
@@ -271,8 +271,16 @@ job_create_test () {
   local xenarch=$1; shift
   local dom0arch=$1; shift
 
-  xenbuildjob="${bfi}build-$xenarch"
-  buildjob="${bfi}build-$dom0arch"
+  xsm_suffix=""
+  for rv in $@ ; do
+  case $rv in
+  enable_xsm=true) xsm_suffix="-xsm";;
+  esac
+  done
+
+  job="$job$xsm_suffix"
+  xenbuildjob="${bfi}build-$xenarch$xsm_suffix"
+  buildjob="${bfi}build-$dom0arch$xsm_suffix"
   tsbuildjob=
 
   case "$xenbranch:$toolstack" in
-- 
1.9.1


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

[Xen-devel] [PATCH OSSTEST v6 8/9] make-flight: factor out do_pv_debian_tests

[Wei Liu]

Pure code motion. No effect on job generation.

Signed-off-by: Wei Liu 
Cc: Ian Campbell 
Cc: Ian Jackson 
Acked-by: Ian Campbell 
Acked-by: Ian Jackson 
---
 make-flight | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/make-flight b/make-flight
index 63b14f5..0cb9b98 100755
--- a/make-flight
+++ b/make-flight
@@ -298,8 +298,7 @@ do_passthrough_tests () {
   done
 }
 
-test_matrix_do_one () {
-
+do_pv_debian_tests () {
   # Basic PV Linux test with xl
   for platform in '' `getplatforms $xenarch` ; do
 suffix=${platform:+-$platform}
@@ -313,6 +312,11 @@ test_matrix_do_one () {
   job_create_test test-$xenarch$kern-$dom0arch-libvirt test-debian libvirt \
 $xenarch $dom0arch   \
 $debian_runvars all_hostflags=$most_hostflags
+}
+
+test_matrix_do_one () {
+
+  do_pv_debian_tests
 
   do_multivcpu_tests
   do_sedf_tests
-- 
1.9.1


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

[Xen-devel] [PATCH OSSTEST v6 4/9] mfi-common: create build-$arch-xsm job

[Wei Liu]

Signed-off-by: Wei Liu 
Acked-by: Ian Campbell 
---
Changes in v4:
1. Use "true" and "false" instead of "y" and "n".
2. Rename xenbranch_wants_xsm_tests to xenbranch_xsm_variants.
---
 mfi-common | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/mfi-common b/mfi-common
index 44b6752..ee4e635 100644
--- a/mfi-common
+++ b/mfi-common
@@ -41,6 +41,19 @@ branch_wants_rumpkernel_tests () {
   esac
 }
 
+xenbranch_xsm_variants () {
+# Test XSM from 4.5 onwards
+case "$xenbranch" in
+xen-3.*-testing) echo "false";;
+xen-4.0-testing) echo "false";;
+xen-4.1-testing) echo "false";;
+xen-4.2-testing) echo "false";;
+xen-4.3-testing) echo "false";;
+xen-4.4-testing) echo "false";;
+*) echo "false true";
+esac
+}
+
 create_build_jobs () {
 
   local arch
@@ -141,8 +154,15 @@ create_build_jobs () {
 
 
build_hostflags=share-build-$suite-$arch,arch-$arch,suite-$suite,purpose-build
 
-./cs-job-create $flight build-$arch build\
+for enable_xsm in $(xenbranch_xsm_variants) ; do
+  if [ x$enable_xsm = xtrue ] ; then
+xsm_suffix="-xsm"
+  else
+xsm_suffix=""
+  fi
+  ./cs-job-create $flight build-$arch$xsm_suffix build   \
 arch=$arch enable_xend=$build_defxend enable_ovmf=$enable_ovmf\
+enable_xsm=$enable_xsm   \
 tree_qemu=$TREE_QEMU \
 tree_qemuu=$TREE_QEMU_UPSTREAM   \
 tree_xen=$TREE_XEN   \
@@ -156,6 +176,7 @@ create_build_jobs () {
 revision_qemuu=$REVISION_QEMU_UPSTREAM   \
 revision_seabios=$REVISION_SEABIOS   \
 revision_ovmf=$REVISION_OVMF
+done
 
 if [ $build_extraxend = "true" ] ; then
 ./cs-job-create $flight build-$arch-xend build   \
-- 
1.9.1


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

[Xen-devel] [PATCH OSSTEST v6 6/9] Debian.pm: load flask policy in uboot

[Wei Liu]

Signed-off-by: Wei Liu 
Acked-by: Ian Campbell 
Acked-by: Ian Jackson 
---
 Osstest/Debian.pm | 20 
 1 file changed, 20 insertions(+)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8efc89e..5c5ce7a 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -153,6 +153,24 @@ sub setupboot_uboot () {
my $kern = "vmlinuz-$want_kernver";
my $initrd = "initrd.img-$want_kernver";
 
+   my $flask_commands = "";
+   if ($want_xsm) {
+   my $flaskpolicy = $r{flaskpolicy};
+   $flask_commands = <
+echo Loaded $flaskpolicy to \\\${flask_policy_addr_r} (\\\${filesize})
+
+END
+   }
+
+   my $root= target_guest_lv_name($ho,"root");
+
logm("Xen options: $xenhopt");
 
# Common kernel options
@@ -241,6 +259,8 @@ fdt set /chosen/module\@1 compatible "xen,linux-initrd" 
"xen,multiboot-module"
 fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} 
${size_hex_prefix}\\\${filesize}>
 echo Loaded $initrd to \\\${ramdisk_addr_r} (\\\${filesize})
 
+${flask_commands}
+
 fdt print /chosen
 
 echo Booting \\\${xen_addr_r} - \\\${fdt_addr}
-- 
1.9.1


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

[Xen-devel] [PATCH OSSTEST v6 3/9] ts-xen-build: build with XSM support if requested

[Wei Liu]

Signed-off-by: Wei Liu 
Cc: Ian Jackson 
Cc: Ian Campbell 
Acked-by: Ian Campbell 
Acked-by: Ian Jackson 
---
Changes in v5:
1. Only set XSM_ENABLE when runvar is defined.
2. Fix inconsistent whitespace.

Changes in v4:
1. Use "true" instead of "y"
---
 ts-xen-build | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/ts-xen-build b/ts-xen-build
index 370bfbc..b1f29c6 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -27,6 +27,8 @@ tsreadconfig();
 selectbuildhost(\@ARGV);
 # remaining arguments are passed as targets to "make"
 builddirsprops();
+
+my $enable_xsm = $r{enable_xsm} =~ m/true/ ? 1 : 0;
 
 sub checkout () {
 prepbuilddirs();
@@ -34,6 +36,7 @@ sub checkout () {
 build_clone($ho, 'xen', $builddir, 'xen');
 
 my $debug_build = $r{xen_build_debug} || 'y';
+my $build_xsm = $enable_xsm ? 'y' : 'n';
 
 # Do not set this unless you know what you are doing. This arm
 # option makes the build specific to a particular type of
@@ -52,6 +55,9 @@ sub checkout () {
echo >>.config QEMU_REMOTE='$r{tree_qemu}'
echo >>.config KERNELS=''
 END
+   (nonempty($r{enable_xsm}) ? <>.config XSM_ENABLE='${build_xsm}'
+END
(nonempty($r{revision_qemu}) ? <>.config QEMU_TAG='$r{revision_qemu}'
 END
@@ -120,6 +126,14 @@ END
 buildcmd_stamped_logged(9000, 'build', '',

[Xen-devel] [PATCH OSSTEST v6 1/9] overlay: update overlay/etc/grub.d/20_linux_xen

[Wei Liu]

This file was originally created to work around Debian bug #633127
("/etc/grub/20_linux does not recognise some old Xen kernels").

According to Debian bug tracker [0], #633127 bug is fixed in Wheezy. As
we're now using Wheezy in OSSTest we can safely remove the old overlay
file if there's no further bugs discovered.

However we have another bug #690538 ("grub-common: Please make submenu
creation optional or at least allow users to disable it easily") that
would break OSSTest.  We're now using Wheezy in production. There's no
way to disable submenu in Wheezy. And submenu breaks OSSTest's grub menu
parser.

So update this overlay file to the one in Wheezy's grub-common
1.99-27+deb7u2 and take care of Debian bug #690538 by removing the lines
to generate submenu.

Also work around GRUB bug #43420 ("20_linux_xen doesn't support Xen XSM
policy file") by applying a small patch proposed in [2].

Add a note to reference #633127 and #690538 above grub2 setup function.

0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633127
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690538
2: https://savannah.gnu.org/bugs/?43420

Signed-off-by: Wei Liu 
Cc: Ian Jackson 
Cc: Ian Campbell 
Acked-by: Ian Campbell 
---
 Osstest/Debian.pm   |   5 ++
 overlay/etc/grub.d/20_linux_xen | 117 +++-
 2 files changed, 98 insertions(+), 24 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index e3e1c90..640f195 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -350,6 +350,11 @@ sub setupboot_grub1 ($$$) {
 return $bl;
 }
 
+# Note on running OSSTest on Squeeze with old Xen kernel: check out
+# Debian bug #633127 "/etc/grub/20_linux does not recognise some old
+# Xen kernels"
+# Currently setupboot_grub2 relies on Grub menu not having submenu.
+# Check Debian bug #690538.
 sub setupboot_grub2 ($$$) {
 my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
 my $bl= { };
diff --git a/overlay/etc/grub.d/20_linux_xen b/overlay/etc/grub.d/20_linux_xen
index 99854d2..f5a8b81 100755
--- a/overlay/etc/grub.d/20_linux_xen
+++ b/overlay/etc/grub.d/20_linux_xen
@@ -1,7 +1,7 @@
 #! /bin/sh
 
-# Copied from the identically named file in grub-common 1.98+20100804-14
-# i386.  This version fixes #633127 (and has the patch I proposed there).
+# Copied from the identically named file in grub-common 1.99-27+deb7u2.
+# This version fixed Debian bug #690538 and GRUB bug #43420.
 
 set -e
 
@@ -21,14 +21,14 @@ set -e
 # You should have received a copy of the GNU General Public License
 # along with GRUB.  If not, see .
 
-prefix=/usr
-exec_prefix=${prefix}
-bindir=${exec_prefix}/bin
-libdir=${exec_prefix}/lib
-. ${libdir}/grub/grub-mkconfig_lib
+prefix="/usr"
+exec_prefix="${prefix}"
+datarootdir="${prefix}/share"
+
+. "${datarootdir}/grub/grub-mkconfig_lib"
 
 export TEXTDOMAIN=grub
-export TEXTDOMAINDIR=${prefix}/share/locale
+export TEXTDOMAINDIR="${datarootdir}/locale"
 
 CLASS="--class gnu-linux --class gnu --class os --class xen"
 
@@ -36,7 +36,7 @@ if [ "x${GRUB_DISTRIBUTOR}" = "x" ] ; then
   OS=GNU/Linux
 else
   OS="${GRUB_DISTRIBUTOR} GNU/Linux"
-  CLASS="--class $(echo ${GRUB_DISTRIBUTOR} | tr '[A-Z]' '[a-z]' | cut -d' ' 
-f1) ${CLASS}"
+  CLASS="--class $(echo ${GRUB_DISTRIBUTOR} | tr 'A-Z' 'a-z' | cut -d' ' -f1) 
${CLASS}"
 fi
 
 # loop-AES arranges things so that /dev/loop/X can be our root device, but
@@ -44,6 +44,11 @@ fi
 case ${GRUB_DEVICE} in
   /dev/loop/*|/dev/loop[0-9])
 GRUB_DEVICE=`losetup ${GRUB_DEVICE} | sed -e "s/^[^(]*(\([^)]\+\)).*/\1/"`
+# We can't cope with devices loop-mounted from files here.
+case ${GRUB_DEVICE} in
+  /dev/*) ;;
+  *) exit 0 ;;
+esac
   ;;
 esac
 
@@ -55,6 +60,23 @@ else
   LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
 fi
 
+# Allow overriding GRUB_CMDLINE_LINUX and GRUB_CMDLINE_LINUX_DEFAULT.
+if [ "${GRUB_CMDLINE_LINUX_XEN_REPLACE}" ]; then
+  GRUB_CMDLINE_LINUX="${GRUB_CMDLINE_LINUX_XEN_REPLACE}"
+fi
+if [ "${GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT}" ]; then
+  GRUB_CMDLINE_LINUX_DEFAULT="${GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT}"
+fi
+
+if [ "x`${grub_probe} --device ${GRUB_DEVICE} --target=fs 2>/dev/null || 
true`" = xbtrfs ] \
+|| [ "x`stat -f --printf=%T /`" = xbtrfs ]; then
+  rootsubvol="`make_system_path_relative_to_its_root /`"
+  rootsubvol="${rootsubvol#/}"
+  if [ "x${rootsubvol}" != x ]; then
+GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"
+  fi
+fi
+
 linux_entry ()
 {
   os="$1"
@@ -63,22 +85,43 @@ linux_entry ()
   recovery="$4"
   args="$5"
   xen_args="$6"
-  if ${recovery} ; then
-title="$(gettext_quoted "%s, with Linux %s and XEN %s (recovery mode)")"
+  xsm="$7"
+  # If user wants to enable XSM support, make sure there's
+  # corresponding policy file.
+  if ${xsm} ; then
+  xenpolicy=`echo xenpolicy-$xen_version`
+  if test ! -e "${xen_dirname}/${xenpolicy}" ; then
+ return
+  fi
+  xen_args=`

[Xen-devel] [PATCH OSSTEST v6 0/9] XSM test case for OSSTest

[Wei Liu]

Hi all

This patch series attempts to duplicate some Debian test cases for XSM. This
is version 6 of this series, rebased on top of OSSTest pretest branch.

Tests duplicated for xen-unstable branch:
  build-{i386,amd64,armhf}-xsm
  test-amd64-{i386,amd64}-{xl,libvirt}-xsm
  test-armhf-armhf-{xl,libvirt}-xsm
  test-amd64-{i386,amd64}-xl-qemuu-debianhvm-amd64-xsm
  test-amd64-(i386,amd64}-xl-qemut-debianhvm-amd64-xsm

Changes in v6 can be found in individual patch. Only the last patch needs an
ack.

See below for output of
  ./standalone-generate-dump-flight-runvars > origin # master
  ./standalone-generate-dump-flight-runvars > xsm # this series applied
  diff -ub ../origin xsm  | grep '-xen-unstable' | sed  's/[ \t]*$//' # nothing
  diff -ub ../origin xsm  | grep '+xen-unstable' | sed  's/[ \t]*$//'

+xen-unstable   build-amd64   
enable_xsm  false
+xen-unstable   build-amd64-xsm   arch  
  amd64
+xen-unstable   build-amd64-xsm   
build_lvextend_max  50
+xen-unstable   build-amd64-xsm   
enable_ovmf true
+xen-unstable   build-amd64-xsm   
enable_xend false
+xen-unstable   build-amd64-xsm   
enable_xsm  true
+xen-unstable   build-amd64-xsm   
host_hostflags  
share-build-wheezy-amd64,arch-amd64,suite-wheezy,purpose-build
+xen-unstable   build-amd64-xsm   
revision_ovmf
+xen-unstable   build-amd64-xsm   
revision_qemu
+xen-unstable   build-amd64-xsm   
revision_qemuu  0d37748342e29854db7c9f6c47d7f58c6cfba6b2
+xen-unstable   build-amd64-xsm   
revision_seabios
+xen-unstable   build-amd64-xsm   
revision_xenc58ba78c84eecf4b7ed5e68d744c555112f8ad14
+xen-unstable   build-amd64-xsm   
tree_ovmf
+xen-unstable   build-amd64-xsm   
tree_qemu   git://xenbits.xen.org/staging/qemu-xen-unstable.git
+xen-unstable   build-amd64-xsm   
tree_qemuu  
git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+xen-unstable   build-amd64-xsm   
tree_seabios
+xen-unstable   build-amd64-xsm   
tree_xengit://xenbits.xen.org/xen.git
+xen-unstable   build-armhf   
enable_xsm  false
+xen-unstable   build-armhf-xsm   arch  
  armhf
+xen-unstable   build-armhf-xsm   
build_lvextend_max  50
+xen-unstable   build-armhf-xsm   
enable_ovmf true
+xen-unstable   build-armhf-xsm   
enable_xend false
+xen-unstable   build-armhf-xsm   
enable_xsm  true
+xen-unstable   build-armhf-xsm   
host_hostflags  
share-build-wheezy-armhf,arch-armhf,suite-wheezy,purpose-build
+xen-unstable   build-armhf-xsm   
revision_ovmf
+xen-unstable   build-armhf-xsm   
revision_qemu
+xen-unstable   build-armhf-xsm   
revision_qemuu  0d37748342e29854db7c9f6c47d7f58c6cfba6b2
+xen-unstable   build-armhf-xsm   
revision_seabios
+xen-unstable   build-armhf-xsm   
revision_xenc58ba78c84eecf4b7ed5e68d744c555112f8ad14
+xen-unstable   build-armhf-xsm   
tree_ovmf
+xen-unstable   build-armhf-xsm   
tree_qemu   git://xenbits.xen.org/staging/qemu-xen-unstable.git
+xen-unstable   build-armhf-xsm   
tree_qemuu  
git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+xen-unstable   build-armhf-xsm   
tree_seabios
+xen-unstable   build-armhf-xsm   
tree_xengit://xenbits.xen.org/xen.git
+xen-unstable   build-i386
enable_xsm  false
+xen-unstable   build-i386-xsmarch  
 

[Xen-devel] [PATCH OSSTEST v6 7/9] ts-xen-install: install Xen with XSM support if requested

[Wei Liu]

Signed-off-by: Wei Liu 
Acked-by: Ian Campbell 
---
Changes in v4:
1. Use "true" instead of "y"
---
 ts-xen-install | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ts-xen-install b/ts-xen-install
index 829c3e9..de4324a 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -46,6 +46,8 @@ if (@ARGV and $ARGV[0] eq '--check') {
 
 our $ho;
 
+my $enable_xsm = $r{enable_xsm} =~ m/true/ ? 1 : 0;
+
 my %distpath;
 
 sub packages () {
@@ -171,7 +173,8 @@ sub setupboot () {
 }
 
 my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
-debian_boot_setup($ho, $want_kernver, 0, $xenhopt, \%distpath, \@hooks);
+debian_boot_setup($ho, $want_kernver, $enable_xsm, $xenhopt,
+  \%distpath, \@hooks);
 
 logm("ready to boot Xen");
 }
-- 
1.9.1


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

[Xen-devel] [PATCH OSSTEST v6 5/9] Debian.pm: pass in XSM configuration to bootloader setup routines

[Wei Liu]

Change to Uboot will come in another patch. GRUB 1 is ignored, as
currently OSSTest only has Wheezy which has GRUB 2.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 
---
Changes in v6:
1. Wrap some overly long lines.

Changes in v4:
1. Modify callsite of debian_boot_setup to avoid regression.
---
 Osstest/Debian.pm | 36 +---
 ts-xen-install|  2 +-
 2 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 640f195..8efc89e 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -47,9 +47,9 @@ BEGIN {
 
 #-- manipulation of Debian bootloader setup --
 
-sub debian_boot_setup (;$) {
+sub debian_boot_setup ($;$) {
 # $xenhopt==undef => is actually a guest, do not set up a hypervisor
-my ($ho, $want_kernver, $xenhopt, $distpath, $hooks) = @_;
+my ($ho, $want_kernver, $want_xsm, $xenhopt, $distpath, $hooks) = @_;
 
 target_kernkind_check($ho);
 target_kernkind_console_inittab($ho,$ho,"/");
@@ -74,11 +74,14 @@ sub debian_boot_setup (;$) {
 
 my $bootloader;
 if ( $ho->{Flags}{'need-uboot-bootscr'} ) {
-   $bootloader= setupboot_uboot($ho, $want_kernver, $xenhopt, $kopt);
+$bootloader= setupboot_uboot($ho, $want_kernver,
+ $want_xsm, $xenhopt, $kopt);
 } elsif ($ho->{Suite} =~ m/lenny/) {
-$bootloader= setupboot_grub1($ho, $want_kernver, $xenhopt, $kopt);
+$bootloader= setupboot_grub1($ho, $want_kernver,
+ $want_xsm, $xenhopt, $kopt);
 } else {
-$bootloader= setupboot_grub2($ho, $want_kernver, $xenhopt, $kopt);
+$bootloader= setupboot_grub2($ho, $want_kernver,
+ $want_xsm, $xenhopt, $kopt);
 }
 
 $bootloader->{UpdateConfig}($ho);
@@ -138,8 +141,9 @@ if test -z "\${fdt_addr}" && test -n "\${fdtfile}" ; then
 fi
 END
 }
-sub setupboot_uboot ($$$) {
-my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
+
+sub setupboot_uboot () {
+my ($ho,$want_kernver,$want_xsm,$xenhopt,$xenkopt) = @_;
 my $bl= { };
 
 $bl->{UpdateConfig}= sub {
@@ -270,13 +274,17 @@ END
 return $bl;
 }
 
-sub setupboot_grub1 ($$$) {
-my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
+sub setupboot_grub1 () {
+my ($ho,$want_kernver,$want_xsm,$xenhopt,$xenkopt) = @_;
 my $bl= { };
 
 my $rmenu= "/boot/grub/menu.lst";
 my $lmenu= "$stash/$ho->{Name}--menu.lst.out";
 
+if ($want_xsm) {
+   die "Enabling XSM with GRUB is not supported";
+}
+
 target_editfile_root($ho, $rmenu, sub {
 while (<::EI>) {
 if (m/^## ## Start Default/ ..
@@ -355,8 +363,8 @@ sub setupboot_grub1 ($$$) {
 # Xen kernels"
 # Currently setupboot_grub2 relies on Grub menu not having submenu.
 # Check Debian bug #690538.
-sub setupboot_grub2 ($$$) {
-my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
+sub setupboot_grub2 () {
+my ($ho,$want_kernver,$want_xsm,$xenhopt,$xenkopt) = @_;
 my $bl= { };
 
 my $rmenu= '/boot/grub/grub.cfg';
@@ -383,6 +391,9 @@ sub setupboot_grub2 ($$$) {
 $entry->{KernVer} ne $want_kernver) {
logm("(skipping entry at $entry->{StartLine};".
 " kernel $entry->{KernVer}, not $want_kernver)");
+   } elsif ($want_xsm && !defined $entry->{Xenpolicy}) {
+   logm("(skipping entry at $entry->{StartLine};".
+" XSM policy file not present)");
} else {
# yes!
last;
@@ -415,6 +426,9 @@ sub setupboot_grub2 ($$$) {
 if (m/^\s*module\s*\/(initrd\S+)/) {
 $entry->{Initrd}= $1;
 }
+   if (m/^\s*module\s*\/(xenpolicy\S+)/) {
+$entry->{Xenpolicy}= $1;
+}
 }
 die 'grub 2 bootloader entry not found' unless $entry;
 
diff --git a/ts-xen-install b/ts-xen-install
index 7cfe344..829c3e9 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -171,7 +171,7 @@ sub setupboot () {
 }
 
 my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
-debian_boot_setup($ho, $want_kernver, $xenhopt, \%distpath, \@hooks);
+debian_boot_setup($ho, $want_kernver, 0, $xenhopt, \%distpath, \@hooks);
 
 logm("ready to boot Xen");
 }
-- 
1.9.1


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

Re: [Xen-devel] [PATCH] libvchan: address compiler warnings

[Wei Liu]

On Wed, Feb 04, 2015 at 04:07:48PM +, Jan Beulich wrote:
> Both vchan_wr() and stdout_wr() should be defined with a non-empty
> argument list (i.e. void). Additionally both of them as well as usage()
> should be static to make clear that no other code is referencing them.
> 
> Further, statements should follow declarations.
> 
> Signed-off-by: Jan Beulich 
> 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] xen/arm: Fix rtds scheduler for arm

[Dario Faggioli]

On Wed, 2015-02-04 at 15:13 +, Ian Campbell wrote:
> On Mon, 2015-02-02 at 20:03 +0200, Denis Drozdov wrote:
> > From: denys drozdov 
> > 
> > Make Credit2 and RT schedulers to run on arm platform
> > context_saved should be deferred on ARM after IRQs enabled
> 
> A better subject+message would be:
> 
> xen/arm: Call context_saved() with interrupts enabled during context 
> switch
> 
> This is a requirement of the scheduler interface, violating this
> causes for example with the RT scheduler:
> 
> 
> > Signed-off-by: denys drozdov 
> 
> Acked-by: Ian Campbell 
> 
> However I would like an ack from a scheduler person (e.g. George) before
> it gets applied.
> 
Deferring the call to context_saved() until below both
ctxt_switch_from() and ctxt_switch_to(), for ARM, like the patch is
doing seems ok to me.

As Jan noted already, it basically makes things look exactly as they
look in x86 already and, checking how booth credit2 and RTDS use
the .context_saved hook, all seems fine to me.

So, FWIW:

Reviewed-by: Dario Faggioli 

Regards,
Dario

-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



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

Re: [Xen-devel] [PATCH v2] Fix building error

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] Fix building error"):
> On 04.02.15 at 16:43,  wrote:
> > This is still bad.  What if the user explicitly wants to build without
> > optimisation ?  That's not unusual.  And it's only the combination of
> > -O0 and FORTIFY that fails.  (And it's only on broken platforms that
> > FORTIFY appears by default.)
> 
> Broken platforms? (Of course I ask without having any idea where
> python-config takes that -D_FORTIFY_SOURCE=2 [together with
> everything else it sets] from.)

IMO a platform where the standard Python build tools produce compiler
options incompatible with -O0 is broken.

> Also I think overriding -O here is no worse that Python adding
> -DNDEBUG regardless of us doing a debug build.

What???  I'm just not going there.

> > I guess I would tolerate a patch which spots the combination of
> > _FORTIFY_SOURCE and -O0 and only in that case changes -O1 to -O0.
> 
> But that would have to happen in (I guess) setup.py, unless we want
> to invoke "python-config --cflags" from the Makefile to find out. And
> I don't see myself touching any Python code...

I don't mind some kind of configure check for this particular
brokenness.  python-config --cflags seems like it would be a fine way
to detect it.

Ian.

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

[Xen-devel] [PATCH] common/xz: add comments for the intentionally missing break statements

[Jan Beulich]

Signed-off-by: Lasse Collin 
[Linux commit 84d517f3e56f7d0d305c14a701cee8f7372ebe1e]
Signed-off-by: Jan Beulich 

--- a/xen/common/xz/dec_lzma2.c
+++ b/xen/common/xz/dec_lzma2.c
@@ -1043,6 +1043,8 @@ XZ_EXTERN enum xz_ret INIT xz_dec_lzma2_
 
s->lzma2.sequence = SEQ_LZMA_PREPARE;
 
+   /* Fall through */
+
case SEQ_LZMA_PREPARE:
if (s->lzma2.compressed < RC_INIT_BYTES)
return XZ_DATA_ERROR;
@@ -1053,6 +1055,8 @@ XZ_EXTERN enum xz_ret INIT xz_dec_lzma2_
s->lzma2.compressed -= RC_INIT_BYTES;
s->lzma2.sequence = SEQ_LZMA_RUN;
 
+   /* Fall through */
+
case SEQ_LZMA_RUN:
/*
 * Set dictionary limit to indicate how much we want



common/xz: add comments for the intentionally missing break statements

Signed-off-by: Lasse Collin 
[Linux commit 84d517f3e56f7d0d305c14a701cee8f7372ebe1e]
Signed-off-by: Jan Beulich 

--- a/xen/common/xz/dec_lzma2.c
+++ b/xen/common/xz/dec_lzma2.c
@@ -1043,6 +1043,8 @@ XZ_EXTERN enum xz_ret INIT xz_dec_lzma2_
 
s->lzma2.sequence = SEQ_LZMA_PREPARE;
 
+   /* Fall through */
+
case SEQ_LZMA_PREPARE:
if (s->lzma2.compressed < RC_INIT_BYTES)
return XZ_DATA_ERROR;
@@ -1053,6 +1055,8 @@ XZ_EXTERN enum xz_ret INIT xz_dec_lzma2_
s->lzma2.compressed -= RC_INIT_BYTES;
s->lzma2.sequence = SEQ_LZMA_RUN;
 
+   /* Fall through */
+
case SEQ_LZMA_RUN:
/*
 * Set dictionary limit to indicate how much we want
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] libvchan: address compiler warnings

[Jan Beulich]

Both vchan_wr() and stdout_wr() should be defined with a non-empty
argument list (i.e. void). Additionally both of them as well as usage()
should be static to make clear that no other code is referencing them.

Further, statements should follow declarations.

Signed-off-by: Jan Beulich 

--- a/tools/libvchan/node-select.c
+++ b/tools/libvchan/node-select.c
@@ -39,7 +39,7 @@
 
 #include 
 
-void usage(char** argv)
+static void usage(char** argv)
 {
fprintf(stderr, "usage:\n"
"\t%s [client|server] domainid nodepath [rbufsiz wbufsiz]\n",
@@ -54,10 +54,12 @@ int insiz = 0;
 int outsiz = 0;
 struct libxenvchan *ctrl = 0;
 
-void vchan_wr() {
+static void vchan_wr(void) {
+   int ret;
+
if (!insiz)
return;
-   int ret = libxenvchan_write(ctrl, inbuf, insiz);
+   ret = libxenvchan_write(ctrl, inbuf, insiz);
if (ret < 0) {
fprintf(stderr, "vchan write failed\n");
exit(1);
@@ -68,10 +70,12 @@ void vchan_wr() {
}
 }
 
-void stdout_wr() {
+static void stdout_wr(void) {
+   int ret;
+
if (!outsiz)
return;
-   int ret = write(1, outbuf, outsiz);
+   ret = write(1, outbuf, outsiz);
if (ret < 0 && errno != EAGAIN)
exit(1);
if (ret > 0) {



libvchan: address compiler warnings

Both vchan_wr() and stdout_wr() should be defined with a non-empty
argument list (i.e. void). Additionally both of them as well as usage()
should be static to make clear that no other code is referencing them.

Further, statements should follow declarations.

Signed-off-by: Jan Beulich 

--- a/tools/libvchan/node-select.c
+++ b/tools/libvchan/node-select.c
@@ -39,7 +39,7 @@
 
 #include 
 
-void usage(char** argv)
+static void usage(char** argv)
 {
fprintf(stderr, "usage:\n"
"\t%s [client|server] domainid nodepath [rbufsiz wbufsiz]\n",
@@ -54,10 +54,12 @@ int insiz = 0;
 int outsiz = 0;
 struct libxenvchan *ctrl = 0;
 
-void vchan_wr() {
+static void vchan_wr(void) {
+   int ret;
+
if (!insiz)
return;
-   int ret = libxenvchan_write(ctrl, inbuf, insiz);
+   ret = libxenvchan_write(ctrl, inbuf, insiz);
if (ret < 0) {
fprintf(stderr, "vchan write failed\n");
exit(1);
@@ -68,10 +70,12 @@ void vchan_wr() {
}
 }
 
-void stdout_wr() {
+static void stdout_wr(void) {
+   int ret;
+
if (!outsiz)
return;
-   int ret = write(1, outbuf, outsiz);
+   ret = write(1, outbuf, outsiz);
if (ret < 0 && errno != EAGAIN)
exit(1);
if (ret > 0) {
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] Fix building error

[Jan Beulich]

>>> On 04.02.15 at 16:43,  wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] Fix building error"):
>> On 15.01.15 at 12:26,  wrote:
>> > Assuming that the underlying bug is intractible I think the right
>> > answer is for an affected developer to do one of the following, as a
>> > workaround: either, manually override Fortify when requesting a debug
>> > build (by setting EXTRA_CFLAGS_XEN_TOOLS), or manually override the
>> > -O0 setting.
> ...
>> Having run into this just now too, and seeing that the previous
>> discussion didn't really lead anywhere, I wonder what should be
>> done about this. I check as far back as I reasonably could, and
>> glibc apparently never supported _FORTIFY_SOURCE without
>> optimization. The change in behavior at some point simply was
>> that rather than disabling this silently, they now warn about it
>> (which of course is fatal for a build with -Werror). I also checked
>> Python, and they also seem to have been enabling
>> _FORTIFY_SOURCE forever. Consequently, with the previously
>> suggested patches not having found acceptance, how about
> ...
>> +PY_CFLAGS = $(patsubst -O0,-O1,$(CFLAGS)) $(APPEND_LDFLAGS)
> 
> This is still bad.  What if the user explicitly wants to build without
> optimisation ?  That's not unusual.  And it's only the combination of
> -O0 and FORTIFY that fails.  (And it's only on broken platforms that
> FORTIFY appears by default.)

Broken platforms? (Of course I ask without having any idea where
python-config takes that -D_FORTIFY_SOURCE=2 [together with
everything else it sets] from.)

Also I think overriding -O here is no worse that Python adding
-DNDEBUG regardless of us doing a debug build. (Besides they
actually do pass -O2 too, just that our additions override this.)

> I guess I would tolerate a patch which spots the combination of
> _FORTIFY_SOURCE and -O0 and only in that case changes -O1 to -O0.

But that would have to happen in (I guess) setup.py, unless we want
to invoke "python-config --cflags" from the Makefile to find out. And
I don't see myself touching any Python code...

Jan


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

Re: [Xen-devel] [OSSTEST PATCH] mg-debian-installer-update: produce deterministic output

[Ian Campbell]

On Wed, 2015-02-04 at 15:40 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [OSSTEST PATCH] 
> mg-debian-installer-update: produce deterministic output"):
> > On Mon, 2015-01-12 at 12:27 +, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [Xen-devel] [OSSTEST PATCH] 
> > > mg-debian-installer-update: produce deterministic output"):
> > > > We might like to consider something along these lines for the future:
> > > 
> > > A reasonable idea (although I wonder if it should be configurable).
> > 
> > I did consider just inserting a $CURL_OPTS which could be set to include
> > pragma no-cache from the command line. I mostly didn't because I was too
> > lazy to think about the correct shell quoting at the time...
> 
> I have pushed this.  I edited a comment which talked about
> "transparent proxies" (why is a lie) to refer to "intercepting
> proxies" (which is not).
> 
> A "transparent proxy" is (as defined in the RFCs) one which refrains
> from making certain changes to requests explicitly proxied through it.
> 
> A proxy which operates without awareness on the client side by
> intercepting TCP streams at routers is an "intercepting proxy".

Ack.



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

Re: [Xen-devel] [PATCH v2] Fix building error

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] Fix building error"):
> On 15.01.15 at 12:26,  wrote:
> > Assuming that the underlying bug is intractible I think the right
> > answer is for an affected developer to do one of the following, as a
> > workaround: either, manually override Fortify when requesting a debug
> > build (by setting EXTRA_CFLAGS_XEN_TOOLS), or manually override the
> > -O0 setting.
...
> Having run into this just now too, and seeing that the previous
> discussion didn't really lead anywhere, I wonder what should be
> done about this. I check as far back as I reasonably could, and
> glibc apparently never supported _FORTIFY_SOURCE without
> optimization. The change in behavior at some point simply was
> that rather than disabling this silently, they now warn about it
> (which of course is fatal for a build with -Werror). I also checked
> Python, and they also seem to have been enabling
> _FORTIFY_SOURCE forever. Consequently, with the previously
> suggested patches not having found acceptance, how about
...
> +PY_CFLAGS = $(patsubst -O0,-O1,$(CFLAGS)) $(APPEND_LDFLAGS)

This is still bad.  What if the user explicitly wants to build without
optimisation ?  That's not unusual.  And it's only the combination of
-O0 and FORTIFY that fails.  (And it's only on broken platforms that
FORTIFY appears by default.)

I guess I would tolerate a patch which spots the combination of
_FORTIFY_SOURCE and -O0 and only in that case changes -O1 to -O0.

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH] mg-debian-installer-update: produce deterministic output

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] [OSSTEST PATCH] 
mg-debian-installer-update: produce deterministic output"):
> On Mon, 2015-01-12 at 12:27 +, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [OSSTEST PATCH] 
> > mg-debian-installer-update: produce deterministic output"):
> > > We might like to consider something along these lines for the future:
> > 
> > A reasonable idea (although I wonder if it should be configurable).
> 
> I did consider just inserting a $CURL_OPTS which could be set to include
> pragma no-cache from the command line. I mostly didn't because I was too
> lazy to think about the correct shell quoting at the time...

I have pushed this.  I edited a comment which talked about
"transparent proxies" (why is a lie) to refer to "intercepting
proxies" (which is not).

A "transparent proxy" is (as defined in the RFCs) one which refrains
from making certain changes to requests explicitly proxied through it.

A proxy which operates without awareness on the client side by
intercepting TCP streams at routers is an "intercepting proxy".

Ian.

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

Re: [Xen-devel] [PATCH v2] Fix building error

[Jan Beulich]

>>> On 15.01.15 at 12:26,  wrote:
> Wen Congyang writes ("[PATCH v2] Fix building error"):
>>  ifeq ($(debug),y)
>>  # Disable optimizations and enable debugging information for macros
>>  CFLAGS += -O0 -g3
>> +# _FORTIFY_SOURCE requires compiling with optimization
>> +CFLAGS += -Wp,-U_FORTIFY_SOURCE
> 
> I'm not entirely convinced about this.  I have two kinds of concern:
> 
> One is practical, which is that ATM AIUI a debug build, while not
> intended for production use, is not any less secure.  (Leaving aside
> the ability of guests to perform a DoS with copious debugging output.)
> 
> The other is that we seem to be entering into a battle of escalation
> between various Makefiles.  Specifically, this seems to be a
> workaround for a bug in some other Makefiles we are using: the bug
> being that these other Makefiles can't cope with -O0.  And
> unconditionally squashing the other Makefiles' options seems like a
> big hammer.
> 
> The fact that Fortify doesn't support -O0 is a property of Fortify
> which ought to be encoded in Fortify (or the places where it is
> enabled).
> 
> Assuming that the underlying bug is intractible I think the right
> answer is for an affected developer to do one of the following, as a
> workaround: either, manually override Fortify when requesting a debug
> build (by setting EXTRA_CFLAGS_XEN_TOOLS), or manually override the
> -O0 setting.
> 
> To make this easier to do without editing tools/Rules.mk I would
> support a patch to Rules.mk which has it honour a variable containing
> a debug-specific set of CFLAGS.

Having run into this just now too, and seeing that the previous
discussion didn't really lead anywhere, I wonder what should be
done about this. I check as far back as I reasonably could, and
glibc apparently never supported _FORTIFY_SOURCE without
optimization. The change in behavior at some point simply was
that rather than disabling this silently, they now warn about it
(which of course is fatal for a build with -Werror). I also checked
Python, and they also seem to have been enabling
_FORTIFY_SOURCE forever. Consequently, with the previously
suggested patches not having found acceptance, how about

--- unstable.orig/tools/pygrub/Makefile
+++ unstable/tools/pygrub/Makefile
@@ -2,15 +2,17 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+PY_CFLAGS = $(patsubst -O0,-O1,$(CFLAGS)) $(APPEND_LDFLAGS)
+
 .PHONY: all
 all: build
 .PHONY: build
 build:
-   CC="$(CC)" CFLAGS="$(CFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) setup.py build
+   CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build
 
 .PHONY: install
 install: all
-   CC="$(CC)" CFLAGS="$(CFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) setup.py 
install \
+   CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py install \
$(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" \
--install-scripts=$(LIBEXEC_BIN) --force
set -e; if [ $(BINDIR) != $(LIBEXEC_BIN) -a \
--- unstable.orig/tools/python/Makefile
+++ unstable/tools/python/Makefile
@@ -4,6 +4,8 @@ include $(XEN_ROOT)/tools/Rules.mk
 .PHONY: all
 all: build
 
+PY_CFLAGS = $(patsubst -O0,-O1,$(CFLAGS)) $(LDFLAGS) $(APPEND_LDFLAGS)
+
 .PHONY: build
 build: genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \
$(XEN_ROOT)/tools/libxl/idl.py
@@ -11,11 +13,11 @@ build: genwrap.py $(XEN_ROOT)/tools/libx
$(XEN_ROOT)/tools/libxl/libxl_types.idl \
xen/lowlevel/xl/_pyxl_types.h \
xen/lowlevel/xl/_pyxl_types.c
-   CC="$(CC)" CFLAGS="$(CFLAGS) $(LDFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) 
setup.py build
+   CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build
 
 .PHONY: install
 install:
-   CC="$(CC)" CFLAGS="$(CFLAGS) $(LDFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) 
setup.py install \
+   CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py install \
$(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" --force
 
 .PHONY: test

Jan


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

Re: [Xen-devel] [linux-3.14 bisection] complete test-amd64-amd64-xl-qemut-winxpsp3

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] [linux-3.14 bisection] complete 
test-amd64-amd64-xl-qemut-winxpsp3"):
> On Wed, 2015-02-04 at 15:19 +, Stefano Stabellini wrote:
> > Is it possible that the bisector is confused?
> 
> It was bisecting over b91261aa8a..4d7313cd7cbe, which doesn't include
> the above.
> 
> IOW I think this bisect started before 98047ad0dcb5 appears in 3.14.y.

Yes:

 2 February [linux-3.14 bisection] complete 
test-amd64-amd64-xl-qemut-winxpsp3
 4 February [linux-3.14 test] 34092: tolerable FAIL - PUSHED

Ian.

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

Re: [Xen-devel] [qemu-upstream-unstable bisection] complete test-amd64-i386-freebsd10-i386

[Paul Durrant]

> -Original Message-
> From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com]
> Sent: 04 February 2015 15:12
> To: Ian Jackson
> Cc: xen-de...@lists.xensource.com; Stefano Stabellini; Paul Durrant; Ian
> Campbell
> Subject: Re: [qemu-upstream-unstable bisection] complete test-amd64-i386-
> freebsd10-i386
> 
> Paul,
> 
> do you have an estimate on when it is going to be fixed?
> 
> If it is not soon, I would prefer to revert the patch for now to unbreak
> tests.
> 

I'll hopefully have something in the next day or so. I'm working on the stubdom 
problem at the moment.

  Paul

> Cheers,
> 
> Stefano
> 
> On Mon, 2 Feb 2015, xen.org wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job test-amd64-i386-freebsd10-i386
> > test guest-localmigrate
> >
> > Tree: linux git://xenbits.xen.org/linux-pvops.git
> > Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> > Tree: xen git://xenbits.xen.org/xen.git
> >
> > *** Found and reproduced problem changeset ***
> >
> >   Bug is in tree:  qemuu git://xenbits.xen.org/staging/qemu-upstream-
> unstable.git
> >   Bug introduced:  7665d6ba98e20fb05c420de947c1750fd47e5c07
> >   Bug not present: 9026dca821a61b72983778e3dcd92cfc34b02e8b
> >
> >
> >   commit 7665d6ba98e20fb05c420de947c1750fd47e5c07
> >   Author: Paul Durrant 
> >   Date:   Tue Jan 20 11:06:19 2015 +
> >
> >   Xen: Use the ioreq-server API when available
> >
> >   The ioreq-server API added to Xen 4.5 offers better security than
> >   the existing Xen/QEMU interface because the shared pages that are
> >   used to pass emulation request/results back and forth are removed
> >   from the guest's memory space before any requests are serviced.
> >   This prevents the guest from mapping these pages (they are in a
> >   well known location) and attempting to attack QEMU by synthesizing
> >   its own request structures. Hence, this patch modifies configure
> >   to detect whether the API is available, and adds the necessary
> >   code to use the API if it is.
> >
> >   upstream-commit-id: 3996e85c1822e05c50250f8d2d1e57b6bea1229d
> >
> >   Signed-off-by: Paul Durrant 
> >   Signed-off-by: Stefano Stabellini 
> >   Acked-by: Stefano Stabellini 
> >
> >
> > For bisection revision-tuple graph see:
> >http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-
> upstream-unstable.test-amd64-i386-freebsd10-i386.guest-localmigrate.html
> > Revision IDs in each graph node refer, respectively, to the Trees above.
> >
> > 
> > Searching for failure / basis pass:
> >  34011 fail [host=grain-weevil] / 33488 [host=scape-moth] 32024
> [host=scape-moth] 31848 ok.
> > Failure / basis pass flights: 34011 / 31848
> > (tree in latest but not in basispass: ovmf)
> > (tree with no url: seabios)
> > Tree: linux git://xenbits.xen.org/linux-pvops.git
> > Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> > Tree: xen git://xenbits.xen.org/xen.git
> > Latest c3b70f0bbb6a883f4afa639286043d3f71fbbddf
> c530a75c1e6a472b0eb9558310b518f0dfcd8860
> b0d42741f8e9a00854c3b3faca1da84bfc69bf22
> be11dc1e9172f91e798a8f831b30c14b479e08e8
> 7106c691a6332cffab4037186d1caa3012ae051e
> > Basis pass d7892a4c389d54bccb9bce8e65eb053a33bbe290
> c530a75c1e6a472b0eb9558310b518f0dfcd8860
> b0d42741f8e9a00854c3b3faca1da84bfc69bf22
> a230ec3101ddda868252c036ea960af2b2d6cd5a
> 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
> > Generating revisions with ./adhoc-revtuple-generator
> git://xenbits.xen.org/linux-
> pvops.git#d7892a4c389d54bccb9bce8e65eb053a33bbe290-
> c3b70f0bbb6a883f4afa639286043d3f71fbbddf
> git://xenbits.xen.org/osstest/linux-
> firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-
> c530a75c1e6a472b0eb9558310b518f0dfcd8860
> git://xenbits.xen.org/staging/qemu-xen-
> unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-
> b0d42741f8e9a00854c3b3faca1da84bfc69bf22
> git://xenbits.xen.org/staging/qemu-upstream-
> unstable.git#a230ec3101ddda868252c036ea960af2b2d6cd5a-
> be11dc1e9172f91e798a8f831b30c14b479e08e8
> git://xenbits.xen.org/xen.git#6913fa31fa898f45ecc3b00e2397b8ebc75c8df4-
> 7106c691a6332cffab4037186d1caa3012ae051e
> > + exec
> > + sh -xe
> > + cd /export/home/osstest/repos/linux-pvops
> > + git remote set-url origin
> git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
> > + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> > + exec
> > + sh -xe
> > + cd /export/home/osstest/repos/qemu-upstream-unstable
> > + git remote set-url origin
> git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-
> upstream-unstable.git
> > + git fetch -p origin +refs/heads/*:refs/r

Re: [Xen-devel] [linux-3.14 bisection] complete test-amd64-amd64-xl-qemut-winxpsp3

[Ian Campbell]

On Wed, 2015-02-04 at 15:19 +, Stefano Stabellini wrote:
> On Mon, 2 Feb 2015, xen.org wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job test-amd64-amd64-xl-qemut-winxpsp3
> > test xen-boot
> > 
> > Tree: linux 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> > Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> > Tree: xen git://xenbits.xen.org/xen.git
> > 
> > *** Found and reproduced problem changeset ***
> 
> Actually stable/linux-3.14.y already contains the revert of
> 3394691d34fc9baaaff3637b858b9911cd2b327d, commit id
> 98047ad0dcb515a19dec0d9179ef3f7c0c0f3cee.
> 
> Is it possible that the bisector is confused?

It was bisecting over b91261aa8a..4d7313cd7cbe, which doesn't include
the above.

IOW I think this bisect started before 98047ad0dcb5 appears in 3.14.y.

Ian.


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

[Xen-devel] [OSSTest PATCH v2 1/2] ts-cpupools: new test script

[Dario Faggioli]

for smoke testing cpupools a bit. It tries to partition
a live host in two cpupools, trying out the following 3
schedulers for the new cpupool (one after the other):
 credit, credit2 and RTDS.

It also tries to migrating a domain to the new cpupool
and then back to Pool-0.

Signed-off-by: Dario Faggioli 
Acked-by: Juergen Gross 
---
 ts-cpupools |  124 +++
 1 file changed, 124 insertions(+)
 create mode 100755 ts-cpupools

diff --git a/ts-cpupools b/ts-cpupools
new file mode 100755
index 000..fe612e1
--- /dev/null
+++ b/ts-cpupools
@@ -0,0 +1,124 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2014 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 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 Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost,$gn)= @ARGV;
+$whhost ||= 'host';
+$gn ||= 'debian';
+
+our ($ho,$gho) = ts_get_host_guest($whhost,$gn);
+#our $ho= selecthost(@ARGV);
+
+our $default_cpupool= "Pool-0";
+our @schedulers= ("credit","credit2","rtds");
+our @cpulist;
+our $nr_cpus;
+
+sub check () {
+  my $out;
+
+  # Figure out the number of pCPUs of the host. We need to know
+  # that in order to decide with what pCPUs we want to create
+  # cpupools
+  my $xlinfo= target_cmd_output_root($ho, "xl info");
+  $xlinfo =~ /nr_cpus\s*:\s([0-9]*)/;
+  $nr_cpus= $1;
+  logm("Found $nr_cpus pCPUs");
+  die "Too few pCPUs to test cpupools: $nr_cpus" if $nr_cpus < 2;
+
+  # We want only 1 cpupool to exist
+  my $cppinfo= target_cmd_output_root($ho, "xl cpupool-list");
+  my $nr_cpupools= $cppinfo =~ tr/\n//;
+  logm("Found $nr_cpupools cpupools");
+  die "There already is more than one cpu pool!" if $nr_cpupools > 1;
+  die "Non-default cpupool configuration detected" if $cppinfo =~ 
/^$default_cpupool\b/;
+
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
+}
+
+# List of the odd pCPUs
+sub prep_cpulist () {
+  if (! defined @cpulist) {
+foreach my $cpu (0..$nr_cpus) {
+  next unless $cpu % 2;
+  push @cpulist, $cpu;
+}
+  }
+}
+
+sub prep ($) {
+  my ($sched)= @_;
+
+  # Remove the pCPUs from in $cpulist from the default cpupool
+  my $cpustr= "[";
+  foreach my $cpu (@cpulist) {
+target_cmd_root($ho,"xl cpupool-cpu-remove $default_cpupool $cpu");
+$cpustr.= "\"$cpu\", ";
+  }
+  $cpustr.= "]";
+
+  logm("Creating config file for cpupool-osstest-$sched with cpus=$cpustr");
+  
target_putfilecontents_stash($ho,100,<<"END","/etc/xen/cpupool-osstest-$sched");
+name = "cpupool-osstest-$sched"
+sched=\"$sched\"
+cpus=$cpustr
+END
+}
+
+check();
+prep_cpulist();
+foreach my $sched (@schedulers) {
+  my $out;
+
+  prep("$sched");
+
+  # For each cpupool:
+  #  * create it
+  #  * rename it
+  #  * move a domain in it
+  #  * move back a domain out of it
+  #  * add back the pcpus from it to the default pool
+  #  * destroy it
+  target_cmd_root($ho, "xl cpupool-create /etc/xen/cpupool-osstest-$sched");
+  target_cmd_output_root($ho, "xl cpupool-rename cpupool-osstest-$sched 
cpupool-test");
+  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+
+  target_cmd_root($ho, "xl cpupool-migrate $gho->{Name} cpupool-test");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+  $out= target_cmd_output_root($ho, "xl vcpu-list"); logm("$out");
+
+  target_cmd_root($ho, "xl cpupool-migrate $gho->{Name} Pool-0");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+
+  foreach my $cpu (@cpulist) {
+target_cmd_root($ho,"xl cpupool-cpu-remove cpupool-test $cpu");
+target_cmd_root($ho,"xl cpupool-cpu-add $default_cpupool $cpu");
+  }
+  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
+
+  target_cmd_root($ho, "xl cpupool-destroy cpupool-test");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+}
+


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

[Xen-devel] [OSSTest PATCH v2 2/2] Testing cpupools: recipe for it and job definition

[Dario Faggioli]

Signed-off-by: Dario Faggioli 
---
Changes from v1:
 * added invocation to ts-guest-stop in the recipe to kill
   leak-check complaints (which went unnoticed during v1
   testing, sorry)
 * moved the test before the "ARM cutoff", and remove the
   per-arch filtering, so that the test can run on ARM
   hardware too
---
 make-flight |   12 
 sg-run-job  |7 +++
 2 files changed, 19 insertions(+)

diff --git a/make-flight b/make-flight
index 63b14f5..4d2e4bf 100755
--- a/make-flight
+++ b/make-flight
@@ -283,6 +283,16 @@ do_multivcpu_tests () {
 $debian_runvars all_hostflags=$most_hostflags
 }
 
+do_cpupools_tests () {
+  if [ $xenarch != $dom0arch ]; then
+return
+  fi
+
+  job_create_test test-$xenarch$kern-$dom0arch-xl-cpupools\
+test-cpupools xl $xenarch $dom0arch   \
+$debian_runvars all_hostflags=$most_hostflags
+}
+
 do_passthrough_tests () {
   if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
 return
@@ -318,6 +328,8 @@ test_matrix_do_one () {
   do_sedf_tests
   do_credit2_tests
 
+  do_cpupools_tests
+
   # No further arm tests at the moment
   if [ $dom0arch = armhf ]; then
   return
diff --git a/sg-run-job b/sg-run-job
index 2cf810a..fae5af0 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -272,6 +272,13 @@ proc run-job/test-debianhvm {} {
 test-guest debianhvm
 }
 
+proc need-hosts/test-cpupools {} { return host }
+proc run-job/test-cpupools {} {
+install-guest-debian
+run-ts . = ts-cpupools
+run-ts . = ts-guest-stop + host debian
+}
+
 proc need-hosts/test-pair {} { return {src_host dst_host} }
 proc run-job/test-pair {} {
 run-ts . =  ts-debian-install  dst_host


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

[Xen-devel] [OSSTest PATCH v2 0/2] Test case for cpupools

[Dario Faggioli]

We aren't doing any cpupools smoke testing as of now. So, do some. :-)

As suggested by Juergen, I adjusted things such that we are now generating test
jobs for ARM too. In fact, here is the list of jobs, and for each jobs the
runvars, being introduced by this series:

dariof@hoopak:~/osstest.git$ diff -Nru runvars.orig runvars.patched 
--- runvars.orig2015-02-04 15:15:35.214928000 +
+++ runvars.patched 2015-02-04 15:11:30.529748000 +
@@ -0,0 +1,18 @@
+test-amd64-amd64-xl-cpupools  all_hostflags   
arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test 
+test-amd64-amd64-xl-cpupools  archamd64
   
+test-amd64-amd64-xl-cpupools  buildjob
build-amd64 
+test-amd64-amd64-xl-cpupools  debian_arch amd64
   
+test-amd64-amd64-xl-cpupools  debian_kernkind pvops
   
+test-amd64-amd64-xl-cpupools  kernbuildjob
build-amd64-pvops   
+test-amd64-amd64-xl-cpupools  kernkindpvops
   
+test-amd64-amd64-xl-cpupools  toolstack   xl   
   
+test-amd64-amd64-xl-cpupools  xenbuildjob 
build-amd64 
+test-armhf-armhf-xl-cpupools  all_hostflags   
arch-armhf,arch-xen-armhf,suite-wheezy,purpose-test 
+test-armhf-armhf-xl-cpupools  archarmhf
   
+test-armhf-armhf-xl-cpupools  buildjob
build-armhf 
+test-armhf-armhf-xl-cpupools  debian_arch armhf
   
+test-armhf-armhf-xl-cpupools  debian_kernkind pvops
   
+test-armhf-armhf-xl-cpupools  kernbuildjob
build-armhf-pvops   
+test-armhf-armhf-xl-cpupools  kernkindpvops
   
+test-armhf-armhf-xl-cpupools  toolstack   xl   
   
+test-armhf-armhf-xl-cpupools  xenbuildjob 
build-armhf 

Regards,
Dario
---
Dario Faggioli (2):
  ts-cpupools: new test script
  Testing cpupools: recipe for it and job definition


 make-flight |   12 ++
 sg-run-job  |7 +++
 ts-cpupools |  124 +++
 3 files changed, 143 insertions(+)
 create mode 100755 ts-cpupools

--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

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

Re: [Xen-devel] [linux-3.14 bisection] complete test-amd64-amd64-xl-qemut-winxpsp3

[Stefano Stabellini]

On Mon, 2 Feb 2015, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-amd64-xl-qemut-winxpsp3
> test xen-boot
> 
> Tree: linux 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen git://xenbits.xen.org/xen.git
> 
> *** Found and reproduced problem changeset ***

Actually stable/linux-3.14.y already contains the revert of
3394691d34fc9baaaff3637b858b9911cd2b327d, commit id
98047ad0dcb515a19dec0d9179ef3f7c0c0f3cee.

Is it possible that the bisector is confused?



>   Bug is in tree:  linux 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>   Bug introduced:  3394691d34fc9baaaff3637b858b9911cd2b327d
>   Bug not present: f4862f0e93b9095e8e75d1f8663cec197d34fb58
> 
> 
>   commit 3394691d34fc9baaaff3637b858b9911cd2b327d
>   Author: Stefano Stabellini 
>   Date:   Fri Nov 21 16:56:12 2014 +
>   
>   swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single
>   
>   commit 2c3fc8d26dd09b9d7069687eead849ee81c78e46 upstream.
>   
>   Need to pass the pointer within the swiotlb internal buffer to the
>   swiotlb library, that in the case of xen_unmap_single is dev_addr, not
>   paddr.
>   
>   Signed-off-by: Stefano Stabellini 
>   Acked-by: Konrad Rzeszutek Wilk 
>   Signed-off-by: Greg Kroah-Hartman 
> 
> 
> For bisection revision-tuple graph see:
>
> http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.linux-3.14.test-amd64-amd64-xl-qemut-winxpsp3.xen-boot.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
> 
> 
> Searching for failure / basis pass:
>  33918 fail [host=field-cricket] / 33341 ok.
> Failure / basis pass flights: 33918 / 33341
> (tree with no url: seabios)
> Tree: linux 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen git://xenbits.xen.org/xen.git
> Latest 4d7313cd7cbe56ccb511eca23ef5bba7f10ffcb8 
> c530a75c1e6a472b0eb9558310b518f0dfcd8860 
> b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
> 0d37748342e29854db7c9f6c47d7f58c6cfba6b2 
> 7106c691a6332cffab4037186d1caa3012ae051e
> Basis pass c3b70f0bbb6a883f4afa639286043d3f71fbbddf 
> c530a75c1e6a472b0eb9558310b518f0dfcd8860 
> b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
> 1ebb75b1fee779621b63e84fefa7b07354c43a99 
> 36174af3fbeb1b662c0eadbfa193e77f68cc955b
> Generating revisions with ./adhoc-revtuple-generator  
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#c3b70f0bbb6a883f4afa639286043d3f71fbbddf-4d7313cd7cbe56ccb511eca23ef5bba7f10ffcb8
>  
> git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
>  
> git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22
>  
> git://xenbits.xen.org/staging/qemu-upstream-unstable.git#1ebb75b1fee779621b63e84fefa7b07354c43a99-0d37748342e29854db7c9f6c47d7f58c6cfba6b2
>  
> git://xenbits.xen.org/xen.git#36174af3fbeb1b662c0eadbfa193e77f68cc955b-7106c691a6332cffab4037186d1caa3012ae051e
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/linux-stable
> + git remote set-url origin 
> git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> >From 
> >git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable
>26bc420b..e36f014 master -> origin/master
>  * [new tag] v3.19-rc7  -> v3.19-rc7
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/qemu-upstream-unstable
> + git remote set-url origin 
> git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/xen
> + git remote set-url origin 
> git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> >From git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen
>1a010ca..a1b4af1  staging-> origin/staging
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/linux-stable
> + git remote set-url origin 
> git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/qemu-upstream-unstable
> + git remote set-url origin 
> git:/

Re: [Xen-devel] [PATCH] xen/arm: Fix rtds scheduler for arm

[Ian Campbell]

On Mon, 2015-02-02 at 20:03 +0200, Denis Drozdov wrote:
> From: denys drozdov 
> 
> Make Credit2 and RT schedulers to run on arm platform
> context_saved should be deferred on ARM after IRQs enabled

A better subject+message would be:

xen/arm: Call context_saved() with interrupts enabled during context 
switch

This is a requirement of the scheduler interface, violating this
causes for example with the RT scheduler:


> Signed-off-by: denys drozdov 

Acked-by: Ian Campbell 

However I would like an ack from a scheduler person (e.g. George) before
it gets applied.

> ---
>  xen/arch/arm/domain.c |7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 7221bc8..1626376 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -64,7 +64,7 @@ static void ctxt_switch_from(struct vcpu *p)
>   * mode. Therefore we don't need to save the context of an idle VCPU.
>   */
>  if ( is_idle_vcpu(p) )
> -goto end_context;
> +return;
>  
>  p2m_save_state(p);
>  
> @@ -138,9 +138,6 @@ static void ctxt_switch_from(struct vcpu *p)
>  gic_save_state(p);
>  
>  isb();
> -
> -end_context:
> -context_saved(p);
>  }
>  
>  static void ctxt_switch_to(struct vcpu *n)
> @@ -246,6 +243,8 @@ static void schedule_tail(struct vcpu *prev)
>  
>  local_irq_enable();
>  
> +context_saved(prev);
> +
>  if ( prev != current )
>  update_runstate_area(current);
>  



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

Re: [Xen-devel] [qemu-upstream-unstable bisection] complete test-amd64-i386-freebsd10-i386

[Stefano Stabellini]

Paul,

do you have an estimate on when it is going to be fixed?

If it is not soon, I would prefer to revert the patch for now to unbreak
tests.

Cheers,

Stefano

On Mon, 2 Feb 2015, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-freebsd10-i386
> test guest-localmigrate
> 
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen git://xenbits.xen.org/xen.git
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  qemuu 
> git://xenbits.xen.org/staging/qemu-upstream-unstable.git
>   Bug introduced:  7665d6ba98e20fb05c420de947c1750fd47e5c07
>   Bug not present: 9026dca821a61b72983778e3dcd92cfc34b02e8b
> 
> 
>   commit 7665d6ba98e20fb05c420de947c1750fd47e5c07
>   Author: Paul Durrant 
>   Date:   Tue Jan 20 11:06:19 2015 +
>   
>   Xen: Use the ioreq-server API when available
>   
>   The ioreq-server API added to Xen 4.5 offers better security than
>   the existing Xen/QEMU interface because the shared pages that are
>   used to pass emulation request/results back and forth are removed
>   from the guest's memory space before any requests are serviced.
>   This prevents the guest from mapping these pages (they are in a
>   well known location) and attempting to attack QEMU by synthesizing
>   its own request structures. Hence, this patch modifies configure
>   to detect whether the API is available, and adds the necessary
>   code to use the API if it is.
>   
>   upstream-commit-id: 3996e85c1822e05c50250f8d2d1e57b6bea1229d
>   
>   Signed-off-by: Paul Durrant 
>   Signed-off-by: Stefano Stabellini 
>   Acked-by: Stefano Stabellini 
> 
> 
> For bisection revision-tuple graph see:
>
> http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-upstream-unstable.test-amd64-i386-freebsd10-i386.guest-localmigrate.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
> 
> 
> Searching for failure / basis pass:
>  34011 fail [host=grain-weevil] / 33488 [host=scape-moth] 32024 
> [host=scape-moth] 31848 ok.
> Failure / basis pass flights: 34011 / 31848
> (tree in latest but not in basispass: ovmf)
> (tree with no url: seabios)
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen git://xenbits.xen.org/xen.git
> Latest c3b70f0bbb6a883f4afa639286043d3f71fbbddf 
> c530a75c1e6a472b0eb9558310b518f0dfcd8860 
> b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
> be11dc1e9172f91e798a8f831b30c14b479e08e8 
> 7106c691a6332cffab4037186d1caa3012ae051e
> Basis pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 
> c530a75c1e6a472b0eb9558310b518f0dfcd8860 
> b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
> a230ec3101ddda868252c036ea960af2b2d6cd5a 
> 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
> Generating revisions with ./adhoc-revtuple-generator  
> git://xenbits.xen.org/linux-pvops.git#d7892a4c389d54bccb9bce8e65eb053a33bbe290-c3b70f0bbb6a883f4afa639286043d3f71fbbddf
>  
> git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
>  
> git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22
>  
> git://xenbits.xen.org/staging/qemu-upstream-unstable.git#a230ec3101ddda868252c036ea960af2b2d6cd5a-be11dc1e9172f91e798a8f831b30c14b479e08e8
>  
> git://xenbits.xen.org/xen.git#6913fa31fa898f45ecc3b00e2397b8ebc75c8df4-7106c691a6332cffab4037186d1caa3012ae051e
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/linux-pvops
> + git remote set-url origin 
> git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/qemu-upstream-unstable
> + git remote set-url origin 
> git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/xen
> + git remote set-url origin 
> git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/linux-pvops
> + git remote set-url origin 
> git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/qemu-upstream-unstable
> + git remote set-url origin 
> gi

Re: [Xen-devel] Xen's Linux kernel config options V2

[Stefano Stabellini]

On Wed, 4 Feb 2015, Ian Campbell wrote:
> On Wed, 2015-02-04 at 14:57 +, Stefano Stabellini wrote:
> > On Wed, 4 Feb 2015, David Vrabel wrote:
> > > On 16/12/14 16:21, Juergen Gross wrote:
> > > > Hi,
> > > > 
> > > > This is a design proposal for a rework of the config options on the
> > > > Linux kernel which are related to Xen.
> > > > 
> > > > The need to do so arose from the fact that it is currently not
> > > > possible to build the Xen frontend drivers for a non-pvops kernel,
> > > > e.g. to run them in a HVM-domain. There are more drawbacks in the
> > > > current config options to which I'll come later.
> > > > 
> > > > Option  Selects Depends
> > > > --
> > > > XEN
> > > >   XEN_PV(x86)   XEN_HAVE_PVMMU
> > > > PARAVIRT
> > > > PARAVIRT_CLOCK
> > > >   XEN_PVH(x86)  XEN_PVHVM
> > > > PARAVIRT  
> > > > PARAVIRT_CLOCK
> > > >   XEN_PVHVM PARAVIRT
> > > > PARAVIRT_CLOCK
> > 
> > PARAVIRT_CLOCK and PARAVIRT are x86 specific.
> 
> Does PARAVIRT_CLOCK include the pvclock_read_wallclock stuff? Eventually
> we are going to want that functionality on ARM too, although it's not
> clear to me that bundling pv-wallclock and pv-cyclecounter in
> arch/x86/kernel/pvclock.c under the same config option is most correct.
 
Agreed.  Also that patch series never went upstream unfortunately.

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

Re: [Xen-devel] [PATCH] xen/arm: Fix rtds scheduler for arm

[Ian Campbell]

On Wed, 2015-02-04 at 15:04 +, Stefano Stabellini wrote:
> On Mon, 2 Feb 2015, Julien Grall wrote:
> > On 02/02/15 12:16, Ian Campbell wrote:
> > > On Mon, 2015-02-02 at 11:40 +, Jan Beulich wrote:
> > > On 02.02.15 at 12:14,  wrote:
> > >>> On Mon, 2015-02-02 at 12:49 +0200, Denys Drozdov wrote:
> >  The issue observed on credit2 scheduler is similar to the rt scheduler
> >  on arm platform. The root cause is that interrupts are disabled in the
> >  beginning of arm context_switch, thus spin_lock_irq is failing in
> >  ASSERT(local_irq_is_enabled()). I propose to change both credit2 and
> >  rt scheduler to run on arm platform as well and re-run the regression
> >  with scheduler patches.
> > >>>
> > >>> I'd like to hear from the scheduler and other $arch folks regarding
> > >>> whether we think the rtds and credit2 schedulers are wrong or whether it
> > >>> is actually the ARM arch code which needs fixing before considering any
> > >>> change.
> > >>
> > >> The aspect to be understood first is why ARM needs IRQs disabled
> > >> past __context_switch() into schedule_tail() (and there until after
> > >> ctxt_switch_from() and ctxt_switch_to()). If that's indeed necessary,
> > >> there's no question that the schedulers need to be adjusted to
> > >> accommodate for this.
> > > 
> > > I don't think it's *necessary*, but we do seem to have ended up with the
> > > context switch having that requirement today (and relying on it in
> > > several places in switch from/to (mostly to).
> > 
> > > I'm pretty sure we could rework things more along the lines of how x86
> > > does it if needed, but it would be a non-trivial refactoring I think.
> > 
> > We have some part of the code which may inject an interrupt during
> > context switch.
> > For instance the timer may inject an IRQ as long as it has not been
> > disabled. Same when the timer is restored.
> > 
> > The former may result to inject an interrupt to the wrong vCPU.
> 
> Also the gic save and restore functions need to be run with interrupt
> disabled.

I am aware that today all sorts of things rely on interrupts being
disabled during context switch on ARM.

My point was that we *could*, if required, rework things to not rely on
this.

Ian.


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

Re: [Xen-devel] [PATCH] xen/arm: Fix rtds scheduler for arm

[Stefano Stabellini]

On Mon, 2 Feb 2015, Julien Grall wrote:
> On 02/02/15 12:16, Ian Campbell wrote:
> > On Mon, 2015-02-02 at 11:40 +, Jan Beulich wrote:
> > On 02.02.15 at 12:14,  wrote:
> >>> On Mon, 2015-02-02 at 12:49 +0200, Denys Drozdov wrote:
>  The issue observed on credit2 scheduler is similar to the rt scheduler
>  on arm platform. The root cause is that interrupts are disabled in the
>  beginning of arm context_switch, thus spin_lock_irq is failing in
>  ASSERT(local_irq_is_enabled()). I propose to change both credit2 and
>  rt scheduler to run on arm platform as well and re-run the regression
>  with scheduler patches.
> >>>
> >>> I'd like to hear from the scheduler and other $arch folks regarding
> >>> whether we think the rtds and credit2 schedulers are wrong or whether it
> >>> is actually the ARM arch code which needs fixing before considering any
> >>> change.
> >>
> >> The aspect to be understood first is why ARM needs IRQs disabled
> >> past __context_switch() into schedule_tail() (and there until after
> >> ctxt_switch_from() and ctxt_switch_to()). If that's indeed necessary,
> >> there's no question that the schedulers need to be adjusted to
> >> accommodate for this.
> > 
> > I don't think it's *necessary*, but we do seem to have ended up with the
> > context switch having that requirement today (and relying on it in
> > several places in switch from/to (mostly to).
> 
> > I'm pretty sure we could rework things more along the lines of how x86
> > does it if needed, but it would be a non-trivial refactoring I think.
> 
> We have some part of the code which may inject an interrupt during
> context switch.
> For instance the timer may inject an IRQ as long as it has not been
> disabled. Same when the timer is restored.
> 
> The former may result to inject an interrupt to the wrong vCPU.

Also the gic save and restore functions need to be run with interrupt
disabled.

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

Re: [Xen-devel] Xen's Linux kernel config options V2

[Ian Campbell]

On Wed, 2015-02-04 at 14:57 +, Stefano Stabellini wrote:
> On Wed, 4 Feb 2015, David Vrabel wrote:
> > On 16/12/14 16:21, Juergen Gross wrote:
> > > Hi,
> > > 
> > > This is a design proposal for a rework of the config options on the
> > > Linux kernel which are related to Xen.
> > > 
> > > The need to do so arose from the fact that it is currently not
> > > possible to build the Xen frontend drivers for a non-pvops kernel,
> > > e.g. to run them in a HVM-domain. There are more drawbacks in the
> > > current config options to which I'll come later.
> > > 
> > > Option  Selects Depends
> > > --
> > > XEN
> > >   XEN_PV(x86)   XEN_HAVE_PVMMU
> > > PARAVIRT
> > > PARAVIRT_CLOCK
> > >   XEN_PVH(x86)  XEN_PVHVM
> > > PARAVIRT  
> > > PARAVIRT_CLOCK
> > >   XEN_PVHVM PARAVIRT
> > > PARAVIRT_CLOCK
> 
> PARAVIRT_CLOCK and PARAVIRT are x86 specific.

Does PARAVIRT_CLOCK include the pvclock_read_wallclock stuff? Eventually
we are going to want that functionality on ARM too, although it's not
clear to me that bundling pv-wallclock and pv-cyclecounter in
arch/x86/kernel/pvclock.c under the same config option is most correct.

Ian.


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