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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-libvirt-xsm 12 guest-start  fail REGR. vs. 111403
 test-armhf-armhf-xl-vhd  10 debian-di-installfail REGR. vs. 111403
 test-armhf-armhf-libvirt 12 guest-start  fail REGR. vs. 111403
 test-armhf-armhf-libvirt-xsm 12 guest-start  fail REGR. vs. 111403
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 111403

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 111379
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 111403
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111403
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 111403
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu6b06e3e49eb8c91cc286c16d6bf3181ac296f33d
baseline version:
 qemuu2185c93ba80f81bfa27ce6f259c7f2ef4f08b668

Last test of basis   111403  2017-07-05 10:31:25 Z5 days
Failing since111475  2017-07-06 11:14:43 Z4 days6 attempts
Testing same since   111648  2017-07-10 19:48:23 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Anoob Soman 
  Anthony Liguori 
  Anthony PERARD 
  Christian Borntraeger 
  Cornelia Huck 
  Daniel P. Berrange 
  Dong Jia Shi 
  Emilio G. Cota 
  Eric Blake 
  Fam Zheng 
  Halil Pasic 
  Hervé Poussineau 
  Jason Wang 
  Jiang Biao 
  Kevin Wolf 
  Paolo Bonzini 
  Peter Maydell 
  Pranith Kumar 
  QingFeng Hao 
  Richard Henderson 
  Ross Lagerwall 
  Sergio Andres Gomez Del Real 
  Stefano Stabellini 
  Thomas Huth 
  Viktor Mihajlovski 
  Vladimir Sementsov-Ogievskiy 
  Wu Xiang 
  Yang Zhong 

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

Re: [Xen-devel] [PATCH v3 3/4] xen/mapcache: introduce xen_replace_cache_entry()

[Paul Durrant]

> -Original Message-
> From: Igor Druzhinin
> Sent: 11 July 2017 00:40
> To: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org
> Cc: Igor Druzhinin ; sstabell...@kernel.org;
> Anthony Perard ; Paul Durrant
> ; pbonz...@redhat.com
> Subject: [PATCH v3 3/4] xen/mapcache: introduce
> xen_replace_cache_entry()
> 
> This new call is trying to update a requested map cache entry
> according to the changes in the physmap. The call is searching
> for the entry, unmaps it and maps again at the same place using
> a new guest address. If the mapping is dummy this call will
> make it real.
> 
> This function makes use of a new xenforeignmemory_map2() call
> with an extended interface that was recently introduced in
> libxenforeignmemory [1].
> 
> [1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg113007.html
> 
> Signed-off-by: Igor Druzhinin 

LGTM

Reviewed-by: Paul Durrant 

> ---
>  configure | 18 +
>  hw/i386/xen/xen-mapcache.c| 85
> +++
>  include/hw/xen/xen_common.h   | 14 +++
>  include/sysemu/xen-mapcache.h | 11 +-
>  4 files changed, 119 insertions(+), 9 deletions(-)
> 
> diff --git a/configure b/configure
> index c571ad1..ad6156b 100755
> --- a/configure
> +++ b/configure
> @@ -2021,6 +2021,24 @@ EOF
>  # Xen unstable
>  elif
>  cat > $TMPC < +#undef XC_WANT_COMPAT_MAP_FOREIGN_API
> +#include 
> +int main(void) {
> +  xenforeignmemory_handle *xfmem;
> +
> +  xfmem = xenforeignmemory_open(0, 0);
> +  xenforeignmemory_map2(xfmem, 0, 0, 0, 0, 0, 0, 0);
> +
> +  return 0;
> +}
> +EOF
> +compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs"
> +  then
> +  xen_stable_libs="-lxendevicemodel $xen_stable_libs"
> +  xen_ctrl_version=41000
> +  xen=yes
> +elif
> +cat > $TMPC <  #undef XC_WANT_COMPAT_DEVICEMODEL_API
>  #define __XEN_TOOLS__
>  #include 
> diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
> index 39cb511..8bc63e0 100644
> --- a/hw/i386/xen/xen-mapcache.c
> +++ b/hw/i386/xen/xen-mapcache.c
> @@ -151,6 +151,7 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f,
> void *opaque)
>  }
> 
>  static void xen_remap_bucket(MapCacheEntry *entry,
> + void *vaddr,
>   hwaddr size,
>   hwaddr address_index,
>   bool dummy)
> @@ -167,7 +168,9 @@ static void xen_remap_bucket(MapCacheEntry
> *entry,
>  err = g_malloc0(nb_pfn * sizeof (int));
> 
>  if (entry->vaddr_base != NULL) {
> -ram_block_notify_remove(entry->vaddr_base, entry->size);
> +if (!(entry->flags & XEN_MAPCACHE_ENTRY_DUMMY)) {
> +ram_block_notify_remove(entry->vaddr_base, entry->size);
> +}
>  if (munmap(entry->vaddr_base, entry->size) != 0) {
>  perror("unmap fails");
>  exit(-1);
> @@ -181,11 +184,11 @@ static void xen_remap_bucket(MapCacheEntry
> *entry,
>  }
> 
>  if (!dummy) {
> -vaddr_base = xenforeignmemory_map(xen_fmem, xen_domid,
> -   PROT_READ | PROT_WRITE,
> +vaddr_base = xenforeignmemory_map2(xen_fmem, xen_domid,
> vaddr,
> +   PROT_READ | PROT_WRITE, 0,
> nb_pfn, pfns, err);
>  if (vaddr_base == NULL) {
> -perror("xenforeignmemory_map");
> +perror("xenforeignmemory_map2");
>  exit(-1);
>  }
>  } else {
> @@ -193,7 +196,7 @@ static void xen_remap_bucket(MapCacheEntry
> *entry,
>   * We create dummy mappings where we are unable to create a foreign
>   * mapping immediately due to certain circumstances (i.e. on resume
> now)
>   */
> -vaddr_base = mmap(NULL, size, PROT_READ | PROT_WRITE,
> +vaddr_base = mmap(vaddr, size, PROT_READ | PROT_WRITE,
>MAP_ANON | MAP_SHARED, -1, 0);
>  if (vaddr_base == NULL) {
>  perror("mmap");
> @@ -201,6 +204,10 @@ static void xen_remap_bucket(MapCacheEntry
> *entry,
>  }
>  }
> 
> +if (!(entry->flags & XEN_MAPCACHE_ENTRY_DUMMY)) {
> +ram_block_notify_add(vaddr_base, size);
> +}
> +
>  entry->vaddr_base = vaddr_base;
>  entry->paddr_index = address_index;
>  entry->size = size;
> @@ -213,7 +220,6 @@ static void xen_remap_bucket(MapCacheEntry
> *entry,
>  entry->flags &= ~(XEN_MAPCACHE_ENTRY_DUMMY);
>  }
> 
> -ram_block_notify_add(entry->vaddr_base, entry->size);
>  bitmap_zero(entry->valid_mapping, nb_pfn);
>  for (i = 0; i < nb_pfn; i++) {
>  if (!err[i]) {
> @@ -286,14 +292,14 @@ tryagain:
>  if (!entry) {
>  entry = g_malloc0(sizeof (MapCacheEntry));
>  pentry->next = entry;
> -xen_remap_bucket(entry, cache_size, address_index, dummy);
> +xen_remap_bucket(ent

Re: [Xen-devel] [PATCH v3 4/4] xen: don't use xenstore to save/restore physmap anymore

[Paul Durrant]

> -Original Message-
> From: Igor Druzhinin
> Sent: 11 July 2017 00:40
> To: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org
> Cc: Igor Druzhinin ; sstabell...@kernel.org;
> Anthony Perard ; Paul Durrant
> ; pbonz...@redhat.com
> Subject: [PATCH v3 4/4] xen: don't use xenstore to save/restore physmap
> anymore
> 
> If we have a system with xenforeignmemory_map2() implemented
> we don't need to save/restore physmap on suspend/restore
> anymore. In case we resume a VM without physmap - try to
> recreate the physmap during memory region restore phase and
> remap map cache entries accordingly. The old code is left
> for compatibility reasons.
> 
> Signed-off-by: Igor Druzhinin 

Reviewed-by: Paul Durrant 

> ---
>  hw/i386/xen/xen-hvm.c   | 48
> ++---
>  hw/i386/xen/xen-mapcache.c  |  4 
>  include/hw/xen/xen_common.h |  1 +
>  3 files changed, 42 insertions(+), 11 deletions(-)
> 
> diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
> index d259cf7..d24ca47 100644
> --- a/hw/i386/xen/xen-hvm.c
> +++ b/hw/i386/xen/xen-hvm.c
> @@ -289,6 +289,7 @@ static XenPhysmap *get_physmapping(XenIOState
> *state,
>  return NULL;
>  }
> 
> +#ifdef XEN_COMPAT_PHYSMAP
>  static hwaddr xen_phys_offset_to_gaddr(hwaddr start_addr,
> ram_addr_t size, void 
> *opaque)
>  {
> @@ -334,6 +335,12 @@ static int xen_save_physmap(XenIOState *state,
> XenPhysmap *physmap)
>  }
>  return 0;
>  }
> +#else
> +static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap)
> +{
> +return 0;
> +}
> +#endif
> 
>  static int xen_add_to_physmap(XenIOState *state,
>hwaddr start_addr,
> @@ -368,6 +375,26 @@ go_physmap:
>  DPRINTF("mapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx"\n",
>  start_addr, start_addr + size);
> 
> +mr_name = memory_region_name(mr);
> +
> +physmap = g_malloc(sizeof (XenPhysmap));
> +
> +physmap->start_addr = start_addr;
> +physmap->size = size;
> +physmap->name = mr_name;
> +physmap->phys_offset = phys_offset;
> +
> +QLIST_INSERT_HEAD(&state->physmap, physmap, list);
> +
> +if (runstate_check(RUN_STATE_INMIGRATE)) {
> +/* Now when we have a physmap entry we can replace a dummy
> mapping with
> + * a real one of guest foreign memory. */
> +uint8_t *p = xen_replace_cache_entry(phys_offset, start_addr, size);
> +assert(p && p == memory_region_get_ram_ptr(mr));
> +
> +return 0;
> +}
> +
>  pfn = phys_offset >> TARGET_PAGE_BITS;
>  start_gpfn = start_addr >> TARGET_PAGE_BITS;
>  for (i = 0; i < size >> TARGET_PAGE_BITS; i++) {
> @@ -382,17 +409,6 @@ go_physmap:
>  }
>  }
> 
> -mr_name = memory_region_name(mr);
> -
> -physmap = g_malloc(sizeof (XenPhysmap));
> -
> -physmap->start_addr = start_addr;
> -physmap->size = size;
> -physmap->name = mr_name;
> -physmap->phys_offset = phys_offset;
> -
> -QLIST_INSERT_HEAD(&state->physmap, physmap, list);
> -
>  xc_domain_pin_memory_cacheattr(xen_xc, xen_domid,
> start_addr >> TARGET_PAGE_BITS,
> (start_addr + size - 1) >> 
> TARGET_PAGE_BITS,
> @@ -1158,6 +1174,7 @@ static void xen_exit_notifier(Notifier *n, void
> *data)
>  xs_daemon_close(state->xenstore);
>  }
> 
> +#ifdef XEN_COMPAT_PHYSMAP
>  static void xen_read_physmap(XenIOState *state)
>  {
>  XenPhysmap *physmap = NULL;
> @@ -1205,6 +1222,11 @@ static void xen_read_physmap(XenIOState
> *state)
>  }
>  free(entries);
>  }
> +#else
> +static void xen_read_physmap(XenIOState *state)
> +{
> +}
> +#endif
> 
>  static void xen_wakeup_notifier(Notifier *notifier, void *data)
>  {
> @@ -1331,7 +1353,11 @@ void xen_hvm_init(PCMachineState *pcms,
> MemoryRegion **ram_memory)
>  state->bufioreq_local_port = rc;
> 
>  /* Init RAM management */
> +#ifdef XEN_COMPAT_PHYSMAP
>  xen_map_cache_init(xen_phys_offset_to_gaddr, state);
> +#else
> +xen_map_cache_init(NULL, state);
> +#endif
>  xen_ram_init(pcms, ram_size, ram_memory);
> 
>  qemu_add_vm_change_state_handler(xen_hvm_change_state_handler,
> state);
> diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
> index 8bc63e0..84cc4a2 100644
> --- a/hw/i386/xen/xen-mapcache.c
> +++ b/hw/i386/xen/xen-mapcache.c
> @@ -239,7 +239,9 @@ static uint8_t *xen_map_cache_unlocked(hwaddr
> phys_addr, hwaddr size,
>  hwaddr address_offset;
>  hwaddr cache_size = size;
>  hwaddr test_bit_size;
> +#ifdef XEN_COMPAT_PHYSMAP
>  bool translated = false;
> +#endif
>  bool dummy = false;
> 
>  tryagain:
> @@ -307,11 +309,13 @@ tryagain:
>  test_bit_size >> XC_PAGE_SHIFT,
>  entry->valid_mapping)) {
>  mapcache->last_entry = NULL;
> +#ifdef XEN_COMPAT_PHYSMAP
>  if (!translated && mapcache->phys_offset_to_gad

Re: [Xen-devel] [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

[Arnd Bergmann]

On Tue, Jul 11, 2017 at 6:58 AM, Brian Gerst  wrote:
> On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky  wrote:
>> On 7/8/2017 7:57 AM, Brian Gerst wrote:
>>> On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky 
>>
>> I originally had a check for SME here in a previous version of the
>> patch.  Thomas Gleixner recommended removing the check so that the code
>> path was always exercised regardless of the state of SME in order to
>> better detect issues:
>>
>> http://marc.info/?l=linux-kernel&m=149803067811436&w=2
>
> Looking a bit closer, this shortcut doesn't set the caching
> attributes.  So it's probably best to get rid of it anyways.  Also
> note, there is a corresponding check in iounmap().

Could that cause regressions if a driver relies on (write-through)
cacheable access to the VGA frame buffer RAM or an read-only
cached access to an option ROM but now gets uncached access?

I also tried to find out whether we can stop mapping the ISA MMIO
area into the linear mapping, but at least the VGA code uses
VGA_MAP_MEM() to get access to the same pointers. I'm pretty
sure this got copied incorrectly into most other architectures, but
it is definitely still used on x86 with vga16fb/vgacon/mdacon.

On the plus side, I see that removing this code path will end up
restoring MMIOTRACE support for the ISA MMIO range that was
apparently removed by accident in commit d61fc44853f4
("x86: mmiotrace, preview 2") in linux-2.6.27.

  Arnd

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 3a3d62d2e66d7bec1b97f51c26eac5326e30ad94
baseline version:
 ovmf c82fc2b555285306904c9c1ed6524a85bee8841a

Last test of basis71676  2017-07-10 06:24:48 Z1 days
Testing same since71678  2017-07-11 06:23:46 Z0 days1 attempts


People who touched revisions under test:
  Bret Barkelew 
  Hao Wu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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


Push not applicable.


commit 3a3d62d2e66d7bec1b97f51c26eac5326e30ad94
Author: Hao Wu 
Date:   Tue Jun 20 10:51:53 2017 +0800

MdeModulePkg/PartitionDxe: Add impl of Partition Information Protocol

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bret Barkelew 
Signed-off-by: Hao Wu 
Reviewed-by: Ruiyu Ni 

commit bce72b5837a58348295b34b562a55499371ba8de
Author: Hao Wu 
Date:   Mon Jun 19 16:23:33 2017 +0800

MdePkg: Add EFI Partition Information Protocol definitions

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

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

Re: [Xen-devel] [RFC PATCH v2 03/25] x86: NUMA: Rename and sanitize some common functions

[Vijay Kilari]

Hi Jan,

 Sorry for late reply.

On Fri, Jun 30, 2017 at 7:35 PM, Jan Beulich  wrote:
  03/28/17 5:54 PM >>>
>> --- a/xen/arch/x86/numa.c
>> +++ b/xen/arch/x86/numa.c
>> @@ -53,15 +53,15 @@ int srat_disabled(void)
>>  /*
>>   * Given a shift value, try to populate memnodemap[]
>>   * Returns :
>> - * 1 if OK
>> - * 0 if memnodmap[] too small (of shift too small)
>> - * -1 if node overlap or lost ram (shift too big)
>> + * 0 if OK
>> + * -EINVAL if memnodmap[] too small (of shift too small)
>> + * OR if node overlap or lost ram (shift too big)
>
> It may not matter too much, but you're making things actually worse to
> the caller, as it now can't distinguish the two failure modes anymore.
> Also, if you already touch it, please also correct the apparent typo
> ("of" quite likely meant to be "or"). But what I consider most problematic
> is that you convert ...

OK. I propose to return different error values for two failure modes.
-ENOMEM for "if memnodmap[] too small" and
-EINVAL for if node overlap or lost ram

But In any case it does not matter much and can drop this change.

> ... what is an error case so far to a success one.
>
>> @@ -116,10 +116,10 @@ static int __init 
>> allocate_cachealigned_memnodemap(void)
>>   * The LSB of all start and end addresses in the node map is the value of 
>> the
>>   * maximum possible shift.
>>   */
>> -static int __init extract_lsb_from_nodes(const struct node *nodes,
>> - int numnodes)
>> +static unsigned int __init extract_lsb_from_nodes(const struct node *nodes,
>> +  int numnodes)
>
> Why would you convert the return type to unsigned, but not also that of the
> bogusly signed parameter?

Because memnode_shift type is changed from int to unsigned int.
The return type is changed.

I will change int parameter to unsigned int.
Apart from that I see that variable 'i' in extract_lsb_from_nodes() is int.
This needs to changed to unsigned int.

>
>> @@ -143,27 +143,27 @@ static int __init extract_lsb_from_nodes(const struct 
>> node *nodes,
>>  return i;
>>  }
>>
>> -int __init compute_hash_shift(struct node *nodes, int numnodes,
>> -  nodeid_t *nodeids)
>> +int __init compute_memnode_shift(struct node *nodes, int numnodes,
>> + nodeid_t *nodeids, unsigned int *shift)
>
> I'm not in favor of returning the shift count via pointer when it can easily
> be returned by value.

OK.

>
>>  {
>> -int shift;
>> +*shift = extract_lsb_from_nodes(nodes, numnodes);
>>
>> -shift = extract_lsb_from_nodes(nodes, numnodes);
>>  if ( memnodemapsize <= ARRAY_SIZE(_memnodemap) )
>>  memnodemap = _memnodemap;
>>  else if ( allocate_cachealigned_memnodemap() )
>> -return -1;
>> -printk(KERN_DEBUG "NUMA: Using %d for the hash shift.\n", shift);
>> +return -ENOMEM;
>> +
>> +printk(KERN_DEBUG "NUMA: Using %u for the hash shift.\n", *shift);
>>
>> -if ( populate_memnodemap(nodes, numnodes, shift, nodeids) != 1 )
>> +if ( populate_memnodemap(nodes, numnodes, *shift, nodeids) )
>>  {
>>  printk(KERN_INFO "Your memory is not aligned you need to "
>> "rebuild your hypervisor with a bigger NODEMAPSIZE "
>> -   "shift=%d\n", shift);
>> -return -1;
>> +   "shift=%u\n", *shift);
>> +return -EINVAL;
>
> So you make populate_memnodemap() return proper error values, but then discard
> it and uniformly use -EINVAL here. If you mean the function to simply return a
> success/failure indicator, make it return bool. Otherwise use the error value
> it return (even if right now it can only ever be -EINVAL).

OK. I will drop this change and keep compute_hash_shift() return -1 or
shift value.

Regards
Vijay

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

[Xen-devel] [linux-3.18 test] 111655: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 111628 pass in 
111614
 test-armhf-armhf-xl-credit2   6 xen-install  fail in 111628 pass in 111655
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail in 111628 pass in 111655
 test-armhf-armhf-examine  7 reboot   fail in 111628 pass in 111655
 test-amd64-amd64-pygrub 10 debian-di-install fail in 111628 pass in 111655
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 111644 pass in 
111523
 test-amd64-amd64-xl-rtds 10 debian-install fail pass in 111523
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
111628
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail pass in 111644
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail pass in 
111644

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   4 host-install(4) broken in 111628 blocked in 110441
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 110441
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 111523 
blocked in 110441
 test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111523 
blocked in 110441
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 111614 blocked in 
110441
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 111614 
like 110441
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 111628 
like 110441
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110441
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 110441
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110441
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110441
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   n

[Xen-devel] [distros-debian-snapshot test] 71679: tolerable trouble: blocked/broken/fail/pass

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-armhf-daily-netboot-pygrub  1 build-check(1)  blocked n/a
 build-arm64-pvops 2 hosts-allocate   broken like 71633
 build-arm64   2 hosts-allocate   broken like 71633
 build-arm64   3 capture-logs broken like 71633
 build-arm64-pvops 3 capture-logs broken like 71633
 test-amd64-i386-i386-daily-netboot-pvgrub 11 guest-start fail blocked in 71633
 test-amd64-amd64-amd64-daily-netboot-pvgrub 11 guest-start fail blocked in 
71633
 test-amd64-amd64-i386-daily-netboot-pygrub 11 guest-start fail blocked in 71633
 test-amd64-amd64-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 
71633
 test-armhf-armhf-armhf-daily-netboot-pygrub 10 debian-di-install fail like 
71633
 test-amd64-i386-i386-weekly-netinst-pygrub 10 debian-di-install fail like 71633
 test-amd64-i386-i386-current-netinst-pygrub 10 debian-di-install fail like 
71633
 test-amd64-amd64-i386-current-netinst-pygrub 10 debian-di-install fail like 
71633
 test-amd64-i386-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 
71633
 test-amd64-i386-amd64-current-netinst-pygrub 10 debian-di-install fail like 
71633
 test-amd64-amd64-i386-weekly-netinst-pygrub 10 debian-di-install fail like 
71633
 test-amd64-amd64-amd64-current-netinst-pygrub 10 debian-di-install fail like 
71633

baseline version:
 flight   71633

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   pass
 test-arm64-arm64-armhf-daily-netboot-pygrub  blocked 
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   fail
 test-amd64-amd64-amd64-current-netinst-pygrubfail
 test-amd64-i386-amd64-current-netinst-pygrub fail
 test-amd64-amd64-i386-current-netinst-pygrub fail
 test-amd64-i386-i386-current-netinst-pygrub  fail
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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

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

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


Push not applicable.


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 9750503a116be3c246b249b1e7d7d9c51aae2a03
baseline version:
 ovmf 3a3d62d2e66d7bec1b97f51c26eac5326e30ad94

Last test of basis   111656  2017-07-11 00:48:19 Z0 days
Testing same since   111665  2017-07-11 06:05:53 Z0 days1 attempts


People who touched revisions under test:
  Bi, Dandan 
  Dandan Bi 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

[Brian Gerst]

On Tue, Jul 11, 2017 at 4:35 AM, Arnd Bergmann  wrote:
> On Tue, Jul 11, 2017 at 6:58 AM, Brian Gerst  wrote:
>> On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky  
>> wrote:
>>> On 7/8/2017 7:57 AM, Brian Gerst wrote:
 On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky 
>>>
>>> I originally had a check for SME here in a previous version of the
>>> patch.  Thomas Gleixner recommended removing the check so that the code
>>> path was always exercised regardless of the state of SME in order to
>>> better detect issues:
>>>
>>> http://marc.info/?l=linux-kernel&m=149803067811436&w=2
>>
>> Looking a bit closer, this shortcut doesn't set the caching
>> attributes.  So it's probably best to get rid of it anyways.  Also
>> note, there is a corresponding check in iounmap().

Perhaps the iounmap() check should be kept for now for safety, since
some drivers (vga16fb for example) call iounmap() blindly even if the
mapping wasn't returned from ioremap().  Maybe add a warning when an
ISA address is passed to iounmap().

> Could that cause regressions if a driver relies on (write-through)
> cacheable access to the VGA frame buffer RAM or an read-only
> cached access to an option ROM but now gets uncached access?

Yes there could be some surprises in drivers use the normal ioremap()
call which is uncached but were expecting the default write-through
mapping.

> I also tried to find out whether we can stop mapping the ISA MMIO
> area into the linear mapping, but at least the VGA code uses
> VGA_MAP_MEM() to get access to the same pointers. I'm pretty
> sure this got copied incorrectly into most other architectures, but
> it is definitely still used on x86 with vga16fb/vgacon/mdacon.

Changing VGA_MAP_MEM() to use ioremap_wt() would take care of that.
Although, looking at the mdacon/vgacon, they don't have support for
unmapping the frame buffer if they are built modular.

--
Brian Gerst

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-intel  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-xl-credit2  15 guest-saverestorefail REGR. vs. 110515
 test-amd64-amd64-xl-multivcpu 15 guest-saverestore   fail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 21 guest-start/debian  fail REGR. vs. 110515
 test-amd64-amd64-pair21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-i386-libvirt-pair 21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-i386-libvirt  16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-xl-xsm   16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-xl  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-xl-xsm  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-i386-libvirt-xsm  16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-pair 21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-amd  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-libvirt 16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-amd64-libvirt-xsm 16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-xl   16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-libvirt-vhd 10 debian-di-installfail REGR. vs. 110515

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110515
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 110515
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 110515
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 110515
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 110515
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never

Re: [Xen-devel] [Qemu-devel] [PATCH v3 0/4] xen: don't save/restore the physmap on VM save/restore

[no-reply]

Hi,

This series failed build test on s390x host. Please find the details below.

Type: series
Subject: [Qemu-devel] [PATCH v3 0/4] xen: don't save/restore the physmap on VM 
save/restore
Message-id: 1499726403-10129-1-git-send-email-igor.druzhi...@citrix.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit that has the patches applied on top of "base"
# branch
set -e
echo "=== ENV ==="
env
echo "=== PACKAGES ==="
rpm -qa
echo "=== TEST BEGIN ==="
CC=$HOME/bin/cc
INSTALL=$PWD/install
BUILD=$PWD/build
echo -n "Using CC: "
realpath $CC
mkdir -p $BUILD $INSTALL
SRC=$PWD
cd $BUILD
$SRC/configure --cc=$CC --prefix=$INSTALL
make -j4
# XXX: we need reliable clean up
# make check -j4 V=1
make install
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
893068b xen: don't use xenstore to save/restore physmap anymore
bab7b78 xen/mapcache: introduce xen_replace_cache_entry()
b1ed857 xen/mapcache: add an ability to create dummy mappings
f0688e9 xen: move physmap saving into a separate function

=== OUTPUT BEGIN ===
=== ENV ===
XDG_SESSION_ID=146112
SHELL=/bin/sh
USER=fam
PATCHEW=/home/fam/patchew/patchew-cli -s http://patchew.org --nodebug
PATH=/usr/bin:/bin
PWD=/var/tmp/patchew-tester-tmp-_hhpulql/src
LANG=en_US.UTF-8
HOME=/home/fam
SHLVL=2
LOGNAME=fam
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1012/bus
XDG_RUNTIME_DIR=/run/user/1012
_=/usr/bin/env
=== PACKAGES ===
gpg-pubkey-873529b8-54e386ff
xz-libs-5.2.2-2.fc24.s390x
libxshmfence-1.2-3.fc24.s390x
giflib-4.1.6-15.fc24.s390x
trousers-lib-0.3.13-6.fc24.s390x
ncurses-base-6.0-6.20160709.fc25.noarch
gmp-6.1.1-1.fc25.s390x
libidn-1.33-1.fc25.s390x
slang-2.3.0-7.fc25.s390x
libsemanage-2.5-8.fc25.s390x
pkgconfig-0.29.1-1.fc25.s390x
alsa-lib-1.1.1-2.fc25.s390x
yum-metadata-parser-1.1.4-17.fc25.s390x
python3-slip-dbus-0.6.4-4.fc25.noarch
python2-cssselect-0.9.2-1.fc25.noarch
python-fedora-0.8.0-2.fc25.noarch
createrepo_c-libs-0.10.0-6.fc25.s390x
initscripts-9.69-1.fc25.s390x
wget-1.18-2.fc25.s390x
dhcp-client-4.3.5-1.fc25.s390x
parted-3.2-21.fc25.s390x
flex-2.6.0-3.fc25.s390x
colord-libs-1.3.4-1.fc25.s390x
python-osbs-client-0.33-3.fc25.noarch
perl-Pod-Simple-3.35-1.fc25.noarch
python2-simplejson-3.10.0-1.fc25.s390x
brltty-5.4-2.fc25.s390x
librados2-10.2.4-2.fc25.s390x
tcp_wrappers-7.6-83.fc25.s390x
libcephfs_jni1-10.2.4-2.fc25.s390x
nettle-devel-3.3-1.fc25.s390x
bzip2-devel-1.0.6-21.fc25.s390x
libuuid-2.28.2-2.fc25.s390x
pango-1.40.4-1.fc25.s390x
python3-dnf-1.1.10-6.fc25.noarch
cryptsetup-libs-1.7.4-1.fc25.s390x
texlive-kpathsea-doc-svn41139-33.fc25.1.noarch
netpbm-10.77.00-3.fc25.s390x
openssh-7.4p1-4.fc25.s390x
texlive-kpathsea-bin-svn40473-33.20160520.fc25.1.s390x
texlive-graphics-svn41015-33.fc25.1.noarch
texlive-dvipdfmx-def-svn40328-33.fc25.1.noarch
texlive-mfware-svn40768-33.fc25.1.noarch
texlive-texlive-scripts-svn41433-33.fc25.1.noarch
texlive-euro-svn22191.1.1-33.fc25.1.noarch
texlive-etex-svn37057.0-33.fc25.1.noarch
texlive-iftex-svn29654.0.2-33.fc25.1.noarch
texlive-palatino-svn31835.0-33.fc25.1.noarch
texlive-texlive-docindex-svn41430-33.fc25.1.noarch
texlive-xunicode-svn30466.0.981-33.fc25.1.noarch
texlive-koma-script-svn41508-33.fc25.1.noarch
texlive-pst-grad-svn15878.1.06-33.fc25.1.noarch
texlive-pst-blur-svn15878.2.0-33.fc25.1.noarch
texlive-jknapltx-svn19440.0-33.fc25.1.noarch
netpbm-progs-10.77.00-3.fc25.s390x
texinfo-6.1-4.fc25.s390x
openssl-devel-1.0.2k-1.fc25.s390x
python2-sssdconfig-1.15.2-1.fc25.noarch
gdk-pixbuf2-2.36.6-1.fc25.s390x
mesa-libEGL-13.0.4-3.fc25.s390x
pcre-cpp-8.40-6.fc25.s390x
pcre-utf16-8.40-6.fc25.s390x
glusterfs-extra-xlators-3.10.1-1.fc25.s390x
mesa-libGL-devel-13.0.4-3.fc25.s390x
nss-devel-3.29.3-1.1.fc25.s390x
libaio-0.3.110-6.fc24.s390x
libfontenc-1.1.3-3.fc24.s390x
lzo-2.08-8.fc24.s390x
isl-0.14-5.fc24.s390x
libXau-1.0.8-6.fc24.s390x
linux-atm-libs-2.5.1-14.fc24.s390x
libXext-1.3.3-4.fc24.s390x
libXxf86vm-1.1.4-3.fc24.s390x
bison-3.0.4-4.fc24.s390x
perl-srpm-macros-1-20.fc25.noarch
gawk-4.1.3-8.fc25.s390x
libwayland-client-1.12.0-1.fc25.s390x
perl-Exporter-5.72-366.fc25.noarch
perl-version-0.99.17-1.fc25.s390x
fftw-libs-double-3.3.5-3.fc25.s390x
libssh2-1.8.0-1.fc25.s390x
ModemManager-glib-1.6.4-1.fc25.s390x
newt-python3-0.52.19-2.fc25.s390x
python-munch-2.0.4-3.fc25.noarch
python-bugzilla-1.2.2-4.fc25.noarch
libedit-3.1-16.20160618cvs.fc25.s390x
python-pycurl-7.43.0-4.fc25.s390x
createrepo_c-0.10.0-6.fc25.s390x
device-mapper-multipath-libs-0.4.9-83.fc25.s390x
yum-3.4.3-510.fc25.noarch
dhcp-common-4.3.5-1.fc25.noarch
dracut-config-rescue-044-78.fc25.s390x
teamd-1.26-1.fc25.s390x
mozjs17-17.0.0-16.fc25.s390x
libselinux-2.5-13.fc25.s390x
libgo-devel-6.3.1-1.fc25.s390x
NetworkManager-libnm-1.4.4-3.fc25.s390x
python2-pyparsing-2.1.10-1.fc25.noarch
cairo-gobject-1.14.8-1.fc25.s390x
ethtool-4.8-1.fc25.s390x
xorg-x11-proto-devel-7.7-20.fc25.noarch
brlapi-0.6.5-2.fc25.s390x
librados-devel-10.2.4-2.fc2

[Xen-devel] [ovmf test] 111676: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 111665
 build-i386-xsm6 xen-buildfail REGR. vs. 111665
 build-amd64   6 xen-buildfail REGR. vs. 111665
 build-i3866 xen-buildfail REGR. vs. 111665

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf c6ab9aecb71bcdb78cc1e13ba3f5a74bc895d4db
baseline version:
 ovmf 9750503a116be3c246b249b1e7d7d9c51aae2a03

Last test of basis   111665  2017-07-11 06:05:53 Z0 days
Testing same since   111676  2017-07-11 12:16:50 Z0 days1 attempts


People who touched revisions under test:
  Brijesh Singh 
  Jordan Justen 
  Laszlo Ersek 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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

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

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

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


Not pushing.

(No revision log; it would be 354 lines long.)

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

Re: [Xen-devel] [Qemu-devel] [PATCH v3 0/4] xen: don't save/restore the physmap on VM save/restore

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Message-id: 1499726403-10129-1-git-send-email-igor.druzhi...@citrix.com
Type: series
Subject: [Qemu-devel] [PATCH v3 0/4] xen: don't save/restore the physmap on VM 
save/restore

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
893068b xen: don't use xenstore to save/restore physmap anymore
bab7b78 xen/mapcache: introduce xen_replace_cache_entry()
b1ed857 xen/mapcache: add an ability to create dummy mappings
f0688e9 xen: move physmap saving into a separate function

=== OUTPUT BEGIN ===
Checking PATCH 1/4: xen: move physmap saving into a separate function...
Checking PATCH 2/4: xen/mapcache: add an ability to create dummy mappings...
Checking PATCH 3/4: xen/mapcache: introduce xen_replace_cache_entry()...
ERROR: space required before the open parenthesis '('
#180: FILE: hw/i386/xen/xen-mapcache.c:541:
+if(!test_bits(address_offset >> XC_PAGE_SHIFT,

total: 1 errors, 0 warnings, 205 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 4/4: xen: don't use xenstore to save/restore physmap anymore...
ERROR: space prohibited between function name and open parenthesis '('
#48: FILE: hw/i386/xen/xen-hvm.c:380:
+physmap = g_malloc(sizeof (XenPhysmap));

total: 1 errors, 0 warnings, 120 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH 00/15] RFC: SGX virtualization design and draft patches

[Andrew Cooper]

On 09/07/17 09:03, Kai Huang wrote:

Hi all,

This series is RFC Xen SGX virtualization support design and RFC draft patches.


Thankyou very much for this design doc.


2. SGX Virtualization Design

2.1 High Level Toolstack Changes:

2.1.1 New 'epc' parameter

EPC is limited resource. In order to use EPC efficiently among all domains,
when creating guest, administrator should be able to specify domain's virtual
EPC size. And admin
alao should be able to get all domain's virtual EPC size.

For this purpose, a new 'epc = ' parameter is added to XL configuration
file. This parameter specifies guest's virtual EPC size. The EPC base address
will be calculated by toolstack internally, according to guest's memory size,
MMIO size, etc. 'epc' is MB in unit and any 1MB aligned value will be accepted.


How will this interact with multi-package servers?  Even though its fine 
to implement the single-package support first, the design should be 
extensible to the multi-package case.


First of all, what are the implications of multi-package SGX?

(Somewhere) you mention changes to scheduling.  I presume this is 
because a guest with EPC mappings in EPT must be scheduled on the same 
package, or ENCLU[EENTER] will fail.  I presume also that each package 
will have separate, unrelated private keys?


I presume there is no sensible way (even on native) for a single logical 
process to use multiple different enclaves?  By extension, does it make 
sense to try and offer parts of multiple enclaves to a single VM?



2.1.3 Notify domain's virtual EPC base and size to Xen

Xen needs to know guest's EPC base and size in order to populate EPC pages for
it. Toolstack notifies EPC base and size to Xen via XEN_DOMCTL_set_cpuid.


I am currently in the process of reworking the Xen/Toolstack interface 
when it comes to CPUID handling.  The latest design is available here: 
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg00378.html 
but the end result will be the toolstack expressing its CPUID policy in 
terms of the architectural layout.


Therefore, I would expect that, however the setting is represented in 
the configuration file, xl/libxl would configure it with the hypervisor 
by setting CPUID.0x12[2] with the appropriate base and size.



2.1.4 Launch Control Support (?)

Xen Launch Control Support is about to support running multiple domains with
each running its own LE signed by different owners (if HW allows, explained
below). As explained in 1.4 SGX Launch Control, EINIT for LE (Launch Enclave)
only succeeds when SHA256(SIGSTRUCT.modulus) matches IA32_SGXLEPUBKEYHASHn,
and EINIT for other enclaves will derive EINITTOKEN key according to
IA32_SGXLEPUBKEYHASHn. Therefore, to support this, guest's virtual
IA32_SGXLEPUBKEYHASHn must be updated to phyiscal MSRs before EINIT (which
also means the physical IA32_SGXLEPUBKEYHASHn need to be *unlocked* in BIOS
before booting to OS).

For physical machine, it is BIOS's writer's decision that whether BIOS would
provide interface for user to specify customerized IA32_SGXLEPUBKEYHASHn (it
is default to digest of Intel's signing key after reset). In reality, OS's SGX
driver may require BIOS to make MSRs *unlocked* and actively write the hash
value to MSRs in order to run EINIT successfully, as in this case, the driver
will not depend on BIOS's capability (whether it allows user to customerize
IA32_SGXLEPUBKEYHASHn value).

The problem is for Xen, do we need a new parameter, such as 'lehash='
to specify the default value of guset's virtual IA32_SGXLEPUBKEYHASHn? And do
we need a new parameter, such as 'lewr' to specify whether guest's virtual MSRs
are locked or not before handling to guest's OS?

I tends to not introduce 'lehash', as it seems SGX driver would actively update
the MSRs. And new parameter would add additional changes for upper layer
software (such as openstack). And 'lewr' is not needed either as Xen can always
*unlock* the MSRs to guest.

Please give comments?

Currently in my RFC patches above two parameters are not implemented.
Xen hypervisor will always *unlock* the MSRs. Whether there is 'lehash'
parameter or not doesn't impact Xen hypervisor's emulation of
IA32_SGXLEPUBKEYHASHn. See below Xen hypervisor changes for details.


Reading around, am I correct with the following?

1) Some processors have no launch control.  There is no restriction on 
which enclaves can boot.


2) Some Skylake client processors claim to have launch control, but the 
MSRs are unavailable (is this an erratum?).  These are limited to 
booting enclaves matching the Intel public key.


3) Launch control may be locked by the BIOS.  There may be a custom 
hash, or it might be the Intel default.  Xen can't adjust it at all, but 
can support running any number of VMs with matching enclaves.


4) Launch control may be unlocked by the BIOS.  In this case, Xen can 
context switch a hash per domain, and run all enclaves.


The eventual plans for CPUID and MSR levelling should allow all of

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 9750503a116be3c246b249b1e7d7d9c51aae2a03
baseline version:
 ovmf 3a3d62d2e66d7bec1b97f51c26eac5326e30ad94

Last test of basis71678  2017-07-11 06:23:46 Z0 days
Testing same since71680  2017-07-11 12:19:35 Z0 days1 attempts


People who touched revisions under test:
  Bi, Dandan 
  Dandan Bi 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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


Push not applicable.


commit 9750503a116be3c246b249b1e7d7d9c51aae2a03
Author: Bi, Dandan 
Date:   Mon Jul 10 14:11:26 2017 +0800

MdeModulePkg/XhciDxe: Make comments align with function

Cc: Ruiyu Ni 
Cc: Hao Wu 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Hao Wu 

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

Re: [Xen-devel] [PATCH] x86/monitor: Notify monitor if an emulation fails.

[Petre Ovidiu PIRCALABU]

On Lu, 2017-07-10 at 12:30 -0600, Tamas K Lengyel wrote:
> On Mon, Jul 10, 2017 at 11:07 AM, Petre Pircalabu
>  wrote:
> >
> > If case of a vm_event with the emulate_flags set, if the
> > instruction
> > cannot be emulated, the monitor should be notified instead of
> > directly
> > injecting a hw exception.
> > This behavior can be used to re-execute an instruction not
> > supported by
> > the emulator using the real processor (e.g. altp2m) instead of just
> > crashing.
> >
> > Signed-off-by: Petre Pircalabu 
> > ---
> >  tools/libxc/include/xenctrl.h |  2 ++
> >  tools/libxc/xc_monitor.c  | 14 ++
> >  xen/arch/x86/hvm/emulate.c|  5 -
> >  xen/arch/x86/hvm/monitor.c| 19 +++
> >  xen/arch/x86/monitor.c| 12 
> >  xen/include/asm-x86/domain.h  |  1 +
> >  xen/include/asm-x86/hvm/monitor.h |  1 +
> >  xen/include/asm-x86/monitor.h |  3 ++-
> >  xen/include/public/domctl.h   |  1 +
> >  xen/include/public/vm_event.h |  2 ++
> >  10 files changed, 58 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/libxc/include/xenctrl.h
> > b/tools/libxc/include/xenctrl.h
> > index c51bb3b..8deb5ac 100644
> > --- a/tools/libxc/include/xenctrl.h
> > +++ b/tools/libxc/include/xenctrl.h
> > @@ -2029,6 +2029,8 @@ int xc_monitor_debug_exceptions(xc_interface
> > *xch, domid_t domain_id,
> >  int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool
> > enable);
> >  int xc_monitor_privileged_call(xc_interface *xch, domid_t
> > domain_id,
> > bool enable);
> > +int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t
> > domain_id,
> > + bool enable);
> >  /**
> >   * This function enables / disables emulation for each REP for a
> >   * REP-compatible instruction.
> > diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
> > index b44ce93..8e72c6c 100644
> > --- a/tools/libxc/xc_monitor.c
> > +++ b/tools/libxc/xc_monitor.c
> > @@ -216,6 +216,20 @@ int xc_monitor_privileged_call(xc_interface
> > *xch, domid_t domain_id,
> >  return do_domctl(xch, &domctl);
> >  }
> >
> > +int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t
> > domain_id,
> > + bool enable)
> > +{
> > +DECLARE_DOMCTL;
> > +
> > +domctl.cmd = XEN_DOMCTL_monitor_op;
> > +domctl.domain = domain_id;
> > +domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
> > +:
> > XEN_DOMCTL_MONITOR_OP_DISABLE;
> > +domctl.u.monitor_op.event =
> > XEN_DOMCTL_MONITOR_EVENT_EMUL_UNHANDLEABLE;
> > +
> > +return do_domctl(xch, &domctl);
> > +}
> > +
> >  /*
> >   * Local variables:
> >   * mode: C
> > diff --git a/xen/arch/x86/hvm/emulate.c
> > b/xen/arch/x86/hvm/emulate.c
> > index e97aa69..083a38a 100644
> > --- a/xen/arch/x86/hvm/emulate.c
> > +++ b/xen/arch/x86/hvm/emulate.c
> > @@ -14,12 +14,14 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -2101,7 +2103,8 @@ void hvm_emulate_one_vm_event(enum emul_kind
> > kind, unsigned int trapnr,
> >  return;
> >  case X86EMUL_UNHANDLEABLE:
> >  hvm_dump_emulation_state(XENLOG_G_DEBUG, "Mem event",
> > &ctx);
> > -hvm_inject_hw_exception(trapnr, errcode);
> > +if ( (kind != EMUL_KIND_NORMAL) ||
> > !hvm_monitor_emul_unhandleable() )
> Why is there this check for !EMUL_KIND_NORMAL?
>
> Tamas
>
> 
> This email was scanned by Bitdefender

Hi Tamas,

I have checked with Razvan and this condition is no longer necessary.
I will remove it and send a v2.

Many thanks,
Petre


This email was scanned by Bitdefender
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2] x86/monitor: Notify monitor if an emulation fails.

[Petre Pircalabu]

If case of a vm_event with the emulate_flags set, if the instruction
cannot be emulated, the monitor should be notified instead of directly
injecting a hw exception.
This behavior can be used to re-execute an instruction not supported by
the emulator using the real processor (e.g. altp2m) instead of just
crashing.

Signed-off-by: Petre Pircalabu 

---
Changed since v1:
  * Removed the emulation kind check when calling hvm_inject_hw_exception
---
 tools/libxc/include/xenctrl.h  |   2 +
 tools/libxc/xc_monitor.c   |  14 ++
 ...itor-Notify-monitor-if-an-emulation-fails.patch | 212 +
 xen/arch/x86/hvm/emulate.c |   5 +-
 xen/arch/x86/hvm/monitor.c |  19 ++
 xen/arch/x86/monitor.c |  12 ++
 xen/include/asm-x86/domain.h   |   1 +
 xen/include/asm-x86/hvm/monitor.h  |   1 +
 xen/include/asm-x86/monitor.h  |   3 +-
 xen/include/public/domctl.h|   1 +
 xen/include/public/vm_event.h  |   2 +
 11 files changed, 270 insertions(+), 2 deletions(-)
 create mode 100644 
tools/tests/xen-access/0001-x86-monitor-Notify-monitor-if-an-emulation-fails.patch

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c51bb3b..8deb5ac 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2029,6 +2029,8 @@ int xc_monitor_debug_exceptions(xc_interface *xch, 
domid_t domain_id,
 int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
 int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
bool enable);
+int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t domain_id,
+ bool enable);
 /**
  * This function enables / disables emulation for each REP for a
  * REP-compatible instruction.
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index b44ce93..8e72c6c 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -216,6 +216,20 @@ int xc_monitor_privileged_call(xc_interface *xch, domid_t 
domain_id,
 return do_domctl(xch, &domctl);
 }
 
+int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t domain_id,
+ bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_EMUL_UNHANDLEABLE;
+
+return do_domctl(xch, &domctl);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git 
a/tools/tests/xen-access/0001-x86-monitor-Notify-monitor-if-an-emulation-fails.patch
 
b/tools/tests/xen-access/0001-x86-monitor-Notify-monitor-if-an-emulation-fails.patch
new file mode 100644
index 000..7a0d091
--- /dev/null
+++ 
b/tools/tests/xen-access/0001-x86-monitor-Notify-monitor-if-an-emulation-fails.patch
@@ -0,0 +1,212 @@
+From 97b3e9c22c7c6a0e49bde4e1bb6866a02ad43007 Mon Sep 17 00:00:00 2001
+From: Petre Pircalabu 
+Date: Thu, 29 Jun 2017 20:40:46 +0300
+Subject: [PATCH] x86/monitor: Notify monitor if an emulation fails.
+
+If case of a vm_event with the emulate_flags set, if the instruction
+cannot be emulated, the monitor should be notified instead of directly
+injecting a hw exception.
+This behavior can be used to re-execute an instruction not supported by
+the emulator using the real processor (e.g. altp2m) instead of just
+crashing.
+
+Signed-off-by: Petre Pircalabu 
+---
+ tools/libxc/include/xenctrl.h |  2 ++
+ tools/libxc/xc_monitor.c  | 14 ++
+ xen/arch/x86/hvm/emulate.c|  5 -
+ xen/arch/x86/hvm/monitor.c| 19 +++
+ xen/arch/x86/monitor.c| 12 
+ xen/include/asm-x86/domain.h  |  1 +
+ xen/include/asm-x86/hvm/monitor.h |  1 +
+ xen/include/asm-x86/monitor.h |  3 ++-
+ xen/include/public/domctl.h   |  1 +
+ xen/include/public/vm_event.h |  2 ++
+ 10 files changed, 58 insertions(+), 2 deletions(-)
+
+diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
+index c51bb3b..8deb5ac 100644
+--- a/tools/libxc/include/xenctrl.h
 b/tools/libxc/include/xenctrl.h
+@@ -2029,6 +2029,8 @@ int xc_monitor_debug_exceptions(xc_interface *xch, 
domid_t domain_id,
+ int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
+ int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
+bool enable);
++int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t domain_id,
++ bool enable);
+ /**
+  * This function enables / disables emulation for each REP for a
+  * REP-compatible instruction.
+diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
+ind

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111604
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 111604
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111604
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass

version targeted for testing:
 libvirt  405c0f07f5c444c52bd6cc95476753c7c8b2ffe2
baseline version:
 libvirt  840c97b0a0a707094b430b025ab7c23d70370f11

Last test of basis   111604  2017-07-09 13:48:37 Z2 days
Testing same since   111662  2017-07-11 04:25:02 Z0 days1 attempts


People who touched revisions under test:
  Cole Robinson 
  Francesc Guasch 
  Julio Faracco 
  Martin Kletzander 
  Peter Krempa 
  Pino Toscano 
  Scott Garfinkle 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



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

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

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

Test harness code can be found at
http://xe

Re: [Xen-devel] [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

[Tom Lendacky]

On 7/10/2017 11:58 PM, Brian Gerst wrote:

On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky  wrote:

On 7/8/2017 7:57 AM, Brian Gerst wrote:


On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky 
wrote:


Currently there is a check if the address being mapped is in the ISA
range (is_ISA_range()), and if it is, then phys_to_virt() is used to
perform the mapping. When SME is active, the default is to add pagetable
mappings with the encryption bit set unless specifically overridden. The
resulting pagetable mapping from phys_to_virt() will result in a mapping
that has the encryption bit set. With SME, the use of ioremap() is
intended to generate pagetable mappings that do not have the encryption
bit set through the use of the PAGE_KERNEL_IO protection value.

Rather than special case the SME scenario, remove the ISA range check and
usage of phys_to_virt() and have ISA range mappings continue through the
remaining ioremap() path.

Signed-off-by: Tom Lendacky 
---
   arch/x86/mm/ioremap.c |7 +--
   1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 4c1b5fd..bfc3e2d 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -13,6 +13,7 @@
   #include 
   #include 
   #include 
+#include 

   #include 
   #include 
@@ -106,12 +107,6 @@ static void __iomem
*__ioremap_caller(resource_size_t phys_addr,
  }

  /*
-* Don't remap the low PCI/ISA area, it's always mapped..
-*/
-   if (is_ISA_range(phys_addr, last_addr))
-   return (__force void __iomem *)phys_to_virt(phys_addr);
-
-   /*
   * Don't allow anybody to remap normal RAM that we're using..
   */
  pfn  = phys_addr >> PAGE_SHIFT;



Removing this also affects 32-bit, which is more likely to access
legacy devices in this range.  Put in a check for SME instead



I originally had a check for SME here in a previous version of the
patch.  Thomas Gleixner recommended removing the check so that the code
path was always exercised regardless of the state of SME in order to
better detect issues:

http://marc.info/?l=linux-kernel&m=149803067811436&w=2

Thanks,
Tom


Looking a bit closer, this shortcut doesn't set the caching
attributes.  So it's probably best to get rid of it anyways.  Also
note, there is a corresponding check in iounmap().


Good catch.  I'll update the patch to include the removal of the ISA
checks in the iounmap() path as well.

Thanks,
Tom



--
Brian Gerst



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

Re: [Xen-devel] [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

[Tom Lendacky]

On 7/11/2017 12:07 AM, Brian Gerst wrote:

On Mon, Jul 10, 2017 at 3:41 PM, Tom Lendacky  wrote:

On 7/8/2017 7:50 AM, Brian Gerst wrote:


On Fri, Jul 7, 2017 at 9:38 AM, Tom Lendacky 
wrote:


Update the CPU features to include identifying and reporting on the
Secure Memory Encryption (SME) feature.  SME is identified by CPUID
0x801f, but requires BIOS support to enable it (set bit 23 of
MSR_K8_SYSCFG).  Only show the SME feature as available if reported by
CPUID and enabled by BIOS.

Reviewed-by: Borislav Petkov 
Signed-off-by: Tom Lendacky 
---
   arch/x86/include/asm/cpufeatures.h |1 +
   arch/x86/include/asm/msr-index.h   |2 ++
   arch/x86/kernel/cpu/amd.c  |   13 +
   arch/x86/kernel/cpu/scattered.c|1 +
   4 files changed, 17 insertions(+)

diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index 2701e5f..2b692df 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -196,6 +196,7 @@

   #define X86_FEATURE_HW_PSTATE  ( 7*32+ 8) /* AMD HW-PState */
   #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD
ProcFeedbackInterface */
+#define X86_FEATURE_SME( 7*32+10) /* AMD Secure Memory
Encryption */



Given that this feature is available only in long mode, this should be
added to disabled-features.h as disabled for 32-bit builds.



I can add that.  If the series needs a re-spin then I'll include this
change in the series, otherwise I can send a follow-on patch to handle
the feature for 32-bit builds if that works.





   #define X86_FEATURE_INTEL_PPIN ( 7*32+14) /* Intel Processor Inventory
Number */
   #define X86_FEATURE_INTEL_PT   ( 7*32+15) /* Intel Processor Trace */
diff --git a/arch/x86/include/asm/msr-index.h
b/arch/x86/include/asm/msr-index.h
index 18b1623..460ac01 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -352,6 +352,8 @@
   #define MSR_K8_TOP_MEM10xc001001a
   #define MSR_K8_TOP_MEM20xc001001d
   #define MSR_K8_SYSCFG  0xc0010010
+#define MSR_K8_SYSCFG_MEM_ENCRYPT_BIT  23
+#define MSR_K8_SYSCFG_MEM_ENCRYPT
BIT_ULL(MSR_K8_SYSCFG_MEM_ENCRYPT_BIT)
   #define MSR_K8_INT_PENDING_MSG 0xc0010055
   /* C1E active bits in int pending message */
   #define K8_INTP_C1E_ACTIVE_MASK0x1800
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index bb5abe8..c47ceee 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -611,6 +611,19 @@ static void early_init_amd(struct cpuinfo_x86 *c)
   */
  if (cpu_has_amd_erratum(c, amd_erratum_400))
  set_cpu_bug(c, X86_BUG_AMD_E400);
+
+   /*
+* BIOS support is required for SME. If BIOS has not enabled SME
+* then don't advertise the feature (set in scattered.c)
+*/
+   if (cpu_has(c, X86_FEATURE_SME)) {
+   u64 msr;
+
+   /* Check if SME is enabled */
+   rdmsrl(MSR_K8_SYSCFG, msr);
+   if (!(msr & MSR_K8_SYSCFG_MEM_ENCRYPT))
+   clear_cpu_cap(c, X86_FEATURE_SME);
+   }



This should be conditional on CONFIG_X86_64.



If I make the scattered feature support conditional on CONFIG_X86_64
(based on comment below) then cpu_has() will always be false unless
CONFIG_X86_64 is enabled. So this won't need to be wrapped by the
#ifdef.


If you change it to use cpu_feature_enabled(), gcc will see that it is
disabled and eliminate the dead code at compile time.




   }

   static void init_amd_k8(struct cpuinfo_x86 *c)
diff --git a/arch/x86/kernel/cpu/scattered.c
b/arch/x86/kernel/cpu/scattered.c
index 23c2350..05459ad 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -31,6 +31,7 @@ struct cpuid_bit {
  { X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
  { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
  { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
+   { X86_FEATURE_SME,  CPUID_EAX,  0, 0x801f, 0 },



This should also be conditional.  We don't want to set this feature on
32-bit, even if the processor has support.



Can do.  See comment above about re-spin vs. follow-on patch.

Thanks,
Tom


A followup patch will be OK if there is no code that will get confused
by the SME bit being present but not active.


The feature bit is mainly there for /proc/cpuinfo. The code uses
sme_active() in order to determine how to behave. Under CONFIG_X86_32,
sme_active() is always 0.

Based on the comment related to patch 7 (ioremap() of ISA range) I may
need to re-spin the patchset.  I'll include this change following
the recommendation from Boris to use the IS_ENABLED(CONFIG_X86_32) check
to clear the feature bit.

Thanks,
Tom



--
Brian Gerst



___
Xen-devel mailing list
Xen-devel@lists.xe

Re: [Xen-devel] [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

[Tom Lendacky]

On 7/11/2017 12:56 AM, Borislav Petkov wrote:

On Tue, Jul 11, 2017 at 01:07:46AM -0400, Brian Gerst wrote:

If I make the scattered feature support conditional on CONFIG_X86_64
(based on comment below) then cpu_has() will always be false unless
CONFIG_X86_64 is enabled. So this won't need to be wrapped by the
#ifdef.


If you change it to use cpu_feature_enabled(), gcc will see that it is
disabled and eliminate the dead code at compile time.


Just do this:

if (cpu_has(c, X86_FEATURE_SME)) {
   if (IS_ENABLED(CONFIG_X86_32)) {
clear_cpu_cap(c, X86_FEATURE_SME);
   } else {
   u64 msr;

   /* Check if SME is enabled */
  rdmsrl(MSR_K8_SYSCFG, msr);
  if (!(msr & MSR_K8_SYSCFG_MEM_ENCRYPT))
  clear_cpu_cap(c, X86_FEATURE_SME);
   }
}

so that it is explicit that we disable it on 32-bit and we can save us
the ifdeffery elsewhere.


I'll use this method for the change and avoid the #ifdefs.

Thanks,
Tom



Thanks.



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

Re: [Xen-devel] [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

[Brian Gerst]

On Tue, Jul 11, 2017 at 11:02 AM, Tom Lendacky  wrote:
> On 7/10/2017 11:58 PM, Brian Gerst wrote:
>>
>> On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky 
>> wrote:
>>>
>>> On 7/8/2017 7:57 AM, Brian Gerst wrote:


 On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky 
 wrote:
>
>
> Currently there is a check if the address being mapped is in the ISA
> range (is_ISA_range()), and if it is, then phys_to_virt() is used to
> perform the mapping. When SME is active, the default is to add
> pagetable
> mappings with the encryption bit set unless specifically overridden.
> The
> resulting pagetable mapping from phys_to_virt() will result in a
> mapping
> that has the encryption bit set. With SME, the use of ioremap() is
> intended to generate pagetable mappings that do not have the encryption
> bit set through the use of the PAGE_KERNEL_IO protection value.
>
> Rather than special case the SME scenario, remove the ISA range check
> and
> usage of phys_to_virt() and have ISA range mappings continue through
> the
> remaining ioremap() path.
>
> Signed-off-by: Tom Lendacky 
> ---
>arch/x86/mm/ioremap.c |7 +--
>1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 4c1b5fd..bfc3e2d 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -13,6 +13,7 @@
>#include 
>#include 
>#include 
> +#include 
>
>#include 
>#include 
> @@ -106,12 +107,6 @@ static void __iomem
> *__ioremap_caller(resource_size_t phys_addr,
>   }
>
>   /*
> -* Don't remap the low PCI/ISA area, it's always mapped..
> -*/
> -   if (is_ISA_range(phys_addr, last_addr))
> -   return (__force void __iomem *)phys_to_virt(phys_addr);
> -
> -   /*
>* Don't allow anybody to remap normal RAM that we're using..
>*/
>   pfn  = phys_addr >> PAGE_SHIFT;
>

 Removing this also affects 32-bit, which is more likely to access
 legacy devices in this range.  Put in a check for SME instead
>>>
>>>
>>>
>>> I originally had a check for SME here in a previous version of the
>>> patch.  Thomas Gleixner recommended removing the check so that the code
>>> path was always exercised regardless of the state of SME in order to
>>> better detect issues:
>>>
>>> http://marc.info/?l=linux-kernel&m=149803067811436&w=2
>>>
>>> Thanks,
>>> Tom
>>
>>
>> Looking a bit closer, this shortcut doesn't set the caching
>> attributes.  So it's probably best to get rid of it anyways.  Also
>> note, there is a corresponding check in iounmap().
>
>
> Good catch.  I'll update the patch to include the removal of the ISA
> checks in the iounmap() path as well.

I now think it should be kept but also emit a warning, at least for
the short term.  There is bad code out there (vga16fb for example)
that calls iounmap() blindly without calling ioremap() first.  We
don't want to actually follow through with the unmap on the linear
mapping.

--
Brian Gerst

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

[Xen-devel] Call for Comment (by July 14) - NIST Platform Firmware Resiliency Guidelines

[Rich Persaud]

If you are working on EFI, secure boot or measured launch, this document may 
influence future hardware devices.  You can submit comments until this Friday.

https://beta.csrc.nist.gov/News/2017/NIST-Releases-Draft-SP-800-193-for-Public-Comment

---
NIST announces the public comment release of Draft Special Publication 800-193, 
Platform Firmware Resiliency Guidelines. The platform is a collection of 
fundamental hardware and firmware components needed to boot and operate a 
computer system. This document provides technical guidelines and 
recommendations supporting resiliency of platform firmware and data against 
potentially destructive attacks.  These draft guidelines promote resiliency in 
the platform by describing security mechanisms for protecting the platform 
against unauthorized changes, detecting unauthorized changes that occur, and 
secure recovery from attacks. This document is intended to guide implementers, 
including system manufacturers and and component suppliers, on how to use these 
mechanisms to build a strong security foundation into platforms.
---

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

Re: [Xen-devel] [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

[Tom Lendacky]

On 7/11/2017 10:38 AM, Brian Gerst wrote:

On Tue, Jul 11, 2017 at 11:02 AM, Tom Lendacky  wrote:

On 7/10/2017 11:58 PM, Brian Gerst wrote:


On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky 
wrote:


On 7/8/2017 7:57 AM, Brian Gerst wrote:



On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky 
wrote:



Currently there is a check if the address being mapped is in the ISA
range (is_ISA_range()), and if it is, then phys_to_virt() is used to
perform the mapping. When SME is active, the default is to add
pagetable
mappings with the encryption bit set unless specifically overridden.
The
resulting pagetable mapping from phys_to_virt() will result in a
mapping
that has the encryption bit set. With SME, the use of ioremap() is
intended to generate pagetable mappings that do not have the encryption
bit set through the use of the PAGE_KERNEL_IO protection value.

Rather than special case the SME scenario, remove the ISA range check
and
usage of phys_to_virt() and have ISA range mappings continue through
the
remaining ioremap() path.

Signed-off-by: Tom Lendacky 
---
arch/x86/mm/ioremap.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 4c1b5fd..bfc3e2d 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -13,6 +13,7 @@
#include 
#include 
#include 
+#include 

#include 
#include 
@@ -106,12 +107,6 @@ static void __iomem
*__ioremap_caller(resource_size_t phys_addr,
   }

   /*
-* Don't remap the low PCI/ISA area, it's always mapped..
-*/
-   if (is_ISA_range(phys_addr, last_addr))
-   return (__force void __iomem *)phys_to_virt(phys_addr);
-
-   /*
* Don't allow anybody to remap normal RAM that we're using..
*/
   pfn  = phys_addr >> PAGE_SHIFT;



Removing this also affects 32-bit, which is more likely to access
legacy devices in this range.  Put in a check for SME instead




I originally had a check for SME here in a previous version of the
patch.  Thomas Gleixner recommended removing the check so that the code
path was always exercised regardless of the state of SME in order to
better detect issues:

http://marc.info/?l=linux-kernel&m=149803067811436&w=2

Thanks,
Tom



Looking a bit closer, this shortcut doesn't set the caching
attributes.  So it's probably best to get rid of it anyways.  Also
note, there is a corresponding check in iounmap().



Good catch.  I'll update the patch to include the removal of the ISA
checks in the iounmap() path as well.


I now think it should be kept but also emit a warning, at least for
the short term.  There is bad code out there (vga16fb for example)
that calls iounmap() blindly without calling ioremap() first.  We
don't want to actually follow through with the unmap on the linear
mapping.


Yup, was just about to reply to the other email on this. That makes
sense, keep the check but add a warning to it so that it will catch
any misuses of iounmap() and those can then be addressed.

Thanks,
Tom



--
Brian Gerst



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

[Xen-devel] [ovmf test] 111680: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 111665
 build-i386-xsm6 xen-buildfail REGR. vs. 111665
 build-amd64   6 xen-buildfail REGR. vs. 111665
 build-i3866 xen-buildfail REGR. vs. 111665

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf ed6da357a30666cfccfd2539d88e6171710084b7
baseline version:
 ovmf 9750503a116be3c246b249b1e7d7d9c51aae2a03

Last test of basis   111665  2017-07-11 06:05:53 Z0 days
Failing since111676  2017-07-11 12:16:50 Z0 days2 attempts
Testing same since   111680  2017-07-11 13:46:56 Z0 days1 attempts


People who touched revisions under test:
  Brijesh Singh 
  Jordan Justen 
  Laszlo Ersek 
  Liming Gao 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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

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

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

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


Not pushing.

(No revision log; it would be 367 lines long.)

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

[Xen-devel] [PATCH] Livepatch ARM32 fixes thanks to cross-compiler.

[Konrad Rzeszutek Wilk]

Hey,

A long time ago, in a far away galaxy where ARM CubieTrucks
ruled the world a cross compiled livepatch was attempted
to be loaded.

And behold.

It crashed the hypervisor with an alignment error.

This set of three patches tightens the checks around alignment
to make sure that we catch such errand issues.

Please review at your own leisure.

 xen/arch/arm/arm32/livepatch.c | 18 --
 xen/arch/arm/arm64/livepatch.c |  6 +
 xen/arch/x86/livepatch.c   |  6 +
 xen/common/livepatch.c | 55 ++
 xen/common/livepatch_elf.c |  7 ++
 xen/include/xen/elfstructs.h   |  2 ++
 xen/include/xen/livepatch.h|  1 +
 7 files changed, 88 insertions(+), 7 deletions(-)


Konrad Rzeszutek Wilk (3):
  xen/livepatch: Tighten alignment checks.
  livepatch: Include sizes when an mismatch occurs
  xen/livepatch/ARM32: Don't crash on livepatches loaded with wrong 
alignment.


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

[Xen-devel] [PATCH v1 2/3] livepatch: Include sizes when an mismatch occurs

[Konrad Rzeszutek Wilk]

If the .bug.frames.X or .livepatch.funcs sizes are different
than what the hypervisor expects - we fail the payload. To help
in diagnosing this include the expected and the payload
sizes.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/common/livepatch.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 5d53096..c0eb609 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -520,8 +520,8 @@ static int prepare_payload(struct payload *payload,
 ASSERT(sec);
 if ( sec->sec->sh_size % sizeof(*payload->funcs) )
 {
-dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size of 
"ELF_LIVEPATCH_FUNC"!\n",
-elf->name);
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size of "ELF_LIVEPATCH_FUNC"! 
(exp: %zu vs %"PRIuElfWord")\n",
+elf->name, sizeof(*payload->funcs), sec->sec->sh_size);
 return -EINVAL;
 }
 
@@ -648,8 +648,9 @@ static int prepare_payload(struct payload *payload,
 
 if ( sec->sec->sh_size % sizeof(*region->frame[i].bugs) )
 {
-dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size of 
.bug_frames.%u!\n",
-elf->name, i);
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size of .bug_frames.%u! 
(exp: %zu vs %"PRIuElfWord")\n",
+elf->name, i, sizeof(*region->frame[i].bugs),
+sec->sec->sh_size);
 return -EINVAL;
 }
 
-- 
2.9.3


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

[Xen-devel] [PATCH v1 1/3] xen/livepatch: Tighten alignment checks.

[Konrad Rzeszutek Wilk]

The ELF specification mentions nothing about the sh_size being
modulo the sh_addralign. Only that sh_addr MUST be aligned on
sh_addralign if sh_addralign is not zero or one.

We on loading did not take this in-to account so this patch adds
two checks: One on the ELF file itself as it is being parsed, and
then when we copy the payload contents in memory - and check the
aligmnent needs there.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/common/livepatch.c   | 9 +
 xen/common/livepatch_elf.c   | 7 +++
 xen/include/xen/elfstructs.h | 2 ++
 3 files changed, 18 insertions(+)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index ca36161..5d53096 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -406,6 +406,15 @@ static int move_payload(struct payload *payload, struct 
livepatch_elf *elf)
 ASSERT(offset[i] != UINT_MAX);
 
 elf->sec[i].load_addr = buf + offset[i];
+if ( elf->sec[i].sec->sh_addralign > 1 &&
+ ((Elf_Addr)elf->sec[i].load_addr % 
elf->sec[i].sec->sh_addralign) )
+ {
+dprintk(XENLOG_ERR, LIVEPATCH "%s: %s @ %p is not aligned 
(%"PRIuElfWord")\n",
+elf->name, elf->sec[i].name, elf->sec[i].load_addr,
+elf->sec[i].sec->sh_addralign);
+rc = -EINVAL;
+goto out;
+}
 
 /* Don't copy NOBITS - such as BSS. */
 if ( elf->sec[i].sec->sh_type != SHT_NOBITS )
diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
index b69e271..852e9c4 100644
--- a/xen/common/livepatch_elf.c
+++ b/xen/common/livepatch_elf.c
@@ -86,6 +86,13 @@ static int elf_resolve_sections(struct livepatch_elf *elf, 
const void *data)
 delta < sizeof(Elf_Ehdr) ? "at ELF header" : "is past 
end");
 return -EINVAL;
 }
+else if ( sec[i].sec->sh_addralign > 1 &&
+  sec[i].sec->sh_addr % sec[i].sec->sh_addralign )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Section [%u] size 
(%"PRIuElfWord") is not aligned properly (%"PRIuElfWord")\n",
+elf->name, i, sec[i].sec->sh_size, 
sec[i].sec->sh_addralign);
+return -EINVAL;
+}
 else if ( (sec[i].sec->sh_flags & (SHF_WRITE | SHF_ALLOC)) &&
   sec[i].sec->sh_type == SHT_NOBITS &&
   sec[i].sec->sh_size > LIVEPATCH_MAX_SIZE )
diff --git a/xen/include/xen/elfstructs.h b/xen/include/xen/elfstructs.h
index 950e149..edc8862 100644
--- a/xen/include/xen/elfstructs.h
+++ b/xen/include/xen/elfstructs.h
@@ -555,6 +555,7 @@ typedef struct {
 
 #if defined(ELFSIZE) && (ELFSIZE == 32)
 #define PRIxElfAddr"08x"
+#define PRIuElfWord"08u"
 
 #define Elf_Ehdr   Elf32_Ehdr
 #define Elf_Phdr   Elf32_Phdr
@@ -582,6 +583,7 @@ typedef struct {
 #define AuxInfoAux32Info
 #elif defined(ELFSIZE) && (ELFSIZE == 64)
 #define PRIxElfAddrPRIx64
+#define PRIuElfWordPRIu64
 
 #define Elf_Ehdr   Elf64_Ehdr
 #define Elf_Phdr   Elf64_Phdr
-- 
2.9.3


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

[Xen-devel] [PATCH v1 3/3] xen/livepatch/ARM32: Don't crash on livepatches loaded with wrong alignment.

[Konrad Rzeszutek Wilk]

This issue was observed on ARM32 with a cross compiler for the
livepatches. Mainly the livepatches .data section size was not
aligned to the section alignment:

ARM32 native:
Contents of section .rodata:
  68695f66 756e6300 63686563 6b5f666e  hi_func.check_fn
 0010 6300 78656e5f 65787472 615f7665  c...xen_extra_ve
 0020 7273696f 6e00rsion...

ARM32 cross compiler:
Contents of section .rodata:
  68695f66 756e6300 63686563 6b5f666e  hi_func.check_fn
 0010 6300 78656e5f 65787472 615f7665  c...xen_extra_ve
 0020 7273696f 6e00rsion.

And when we loaded it:

native:

(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .text at 00a02000
(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .rodata at 00a04024
(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .altinstructions at 
00a0404c

cross compiler:
(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .text at 00a02000
(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .rodata at 00a04024
(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .altinstructions at 
00a0404a

(See 4a vs 4c)

native readelf:
  [ 4] .rodata   PROGBITS 000164 28 00   A  0   0  4
  [ 5] .altinstructions  PROGBITS 00018c 0c 00   A  0   0  1

cross compiler readelf --sections:
  [ 4] .rodata   PROGBITS 000164 26 00   A  0   0  4
  [ 5] .altinstructions  PROGBITS 00018a 0c 00   A  0   0  1

And as can be seen the .altinstructions have alignment of 1 which from
'man elf' is: "Values of zero and one mean no alignment is required."
which means we can ignore it.

However ignoring this will result in a crash as when we started processing
".rel.altinstructions" for ".altinstructions" with a cross-compiled payload
we would end up poking in an section that was not aligned properly in memory
and crash.

This allows us on ARM32 to erorr out with:

livepatch: xen_hello_world: dest=00a0404a (.altinstructions) is not aligned 
properly!

Furthermore we also observe that the alignment is not correct
for other sections (when cross compiling) as such we add the check
in various other places which allows us to get.
livepatch: xen_bye_world: .livepatch.depends alignment is wrong!

instead of a crash.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/arch/arm/arm32/livepatch.c | 18 --
 xen/arch/arm/arm64/livepatch.c |  6 ++
 xen/arch/x86/livepatch.c   |  6 ++
 xen/common/livepatch.c | 37 -
 xen/include/xen/livepatch.h|  1 +
 5 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 41378a5..ccb9bf8 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -112,6 +112,12 @@ bool arch_livepatch_symbol_deny(const struct livepatch_elf 
*elf,
 return false;
 }
 
+bool arch_livepatch_verify_alignment(const struct livepatch_elf_sec *sec)
+{
+/* Unaligned access on ARM 32 will crash with Data Abort. */
+return (uint32_t)sec->load_addr % sizeof(uint32_t);
+};
+
 static s32 get_addend(unsigned char type, void *dest)
 {
 s32 addend = 0;
@@ -233,7 +239,7 @@ int arch_livepatch_perform(struct livepatch_elf *elf,
 uint32_t val;
 void *dest;
 unsigned char type;
-s32 addend;
+s32 addend = 0;
 
 if ( use_rela )
 {
@@ -251,7 +257,6 @@ int arch_livepatch_perform(struct livepatch_elf *elf,
 symndx = ELF32_R_SYM(r->r_info);
 type = ELF32_R_TYPE(r->r_info);
 dest = base->load_addr + r->r_offset; /* P */
-addend = get_addend(type, dest);
 }
 
 if ( symndx == STN_UNDEF )
@@ -272,6 +277,15 @@ int arch_livepatch_perform(struct livepatch_elf *elf,
 elf->name, symndx);
 return -EINVAL;
 }
+else if ( (uint32_t)dest % sizeof(uint32_t) )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: dest=%p (%s) is not aligned 
properly!\n",
+elf->name, dest, base->name);
+return -EINVAL;
+}
+
+if ( !use_rela )
+addend = get_addend(type, dest);
 
 val = elf->sym[symndx].sym->st_value; /* S */
 
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index 2247b92..7b36210 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -86,6 +86,12 @@ bool arch_livepatch_symbol_deny(const struct livepatch_elf 
*elf,
 return false;
 }
 
+bool arch_livepatch_verify_alignment(const struct livepatch_elf_sec *sec)
+{
+/* Unaligned access on ARM 64 is OK. */
+return false;
+}
+
 enum aarch64_reloc_op {
 RELOC_OP_NONE,
 RELOC_OP_ABS,
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 406eb91..b3cbdac 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/l

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: avoid to use start/stop queue

[Konrad Rzeszutek Wilk]

On Wed, Jul 12, 2017 at 02:20:58AM +0800, Ming Lei wrote:
> This interfaces will be removed soon, so use quiesce and
> unquiesce instead, which should be more safe.

'should be'? That does not sound encouraging?

> 
> The only one usage will be removed in the following
> congestion control patches.
> 
> Cc: Konrad Rzeszutek Wilk 
> Cc: "Roger Pau Monné" 
> Cc: Boris Ostrovsky 
> Cc: Juergen Gross 
> Cc: xen-de...@lists.xenproject.org
> Signed-off-by: Ming Lei 
> ---
>  drivers/block/xen-blkfront.c | 22 --
>  1 file changed, 8 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index c852ed3c01d5..1578befda635 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1187,7 +1187,7 @@ static void xlvbd_release_gendisk(struct blkfront_info 
> *info)
>   return;
>  
>   /* No more blkif_request(). */
> - blk_mq_stop_hw_queues(info->rq);
> + blk_mq_quiesce_queue(info->rq);
>  
>   for (i = 0; i < info->nr_rings; i++) {
>   struct blkfront_ring_info *rinfo = &info->rinfo[i];
> @@ -1216,8 +1216,10 @@ static void xlvbd_release_gendisk(struct blkfront_info 
> *info)
>  /* Already hold rinfo->ring_lock. */
>  static inline void kick_pending_request_queues_locked(struct 
> blkfront_ring_info *rinfo)
>  {
> - if (!RING_FULL(&rinfo->ring))
> + if (!RING_FULL(&rinfo->ring)) {
>   blk_mq_start_stopped_hw_queues(rinfo->dev_info->rq, true);
> + blk_mq_kick_requeue_list(rinfo->dev_info->rq);
> + }
>  }
>  
>  static void kick_pending_request_queues(struct blkfront_ring_info *rinfo)
> @@ -1225,7 +1227,8 @@ static void kick_pending_request_queues(struct 
> blkfront_ring_info *rinfo)
>   unsigned long flags;
>  
>   spin_lock_irqsave(&rinfo->ring_lock, flags);
> - kick_pending_request_queues_locked(rinfo);
> + if (!RING_FULL(&rinfo->ring))
> + blk_mq_run_hw_queues(rinfo->dev_info->rq, true);
>   spin_unlock_irqrestore(&rinfo->ring_lock, flags);
>  }
>  
> @@ -1346,7 +1349,7 @@ static void blkif_free(struct blkfront_info *info, int 
> suspend)
>   BLKIF_STATE_SUSPENDED : BLKIF_STATE_DISCONNECTED;
>   /* No more blkif_request(). */
>   if (info->rq)
> - blk_mq_stop_hw_queues(info->rq);
> + blk_mq_quiesce_queue(info->rq);
>  
>   for (i = 0; i < info->nr_rings; i++)
>   blkif_free_ring(&info->rinfo[i]);
> @@ -2018,22 +2021,13 @@ static int blkif_recover(struct blkfront_info *info)
>   /* Now safe for us to use the shared ring */
>   info->connected = BLKIF_STATE_CONNECTED;
>  
> - for (r_index = 0; r_index < info->nr_rings; r_index++) {
> - struct blkfront_ring_info *rinfo;
> -
> - rinfo = &info->rinfo[r_index];
> - /* Kick any other new requests queued since we resumed */
> - kick_pending_request_queues(rinfo);
> - }
> -
>   list_for_each_entry_safe(req, n, &info->requests, queuelist) {
>   /* Requeue pending requests (flush or discard) */
>   list_del_init(&req->queuelist);
>   BUG_ON(req->nr_phys_segments > segs);
>   blk_mq_requeue_request(req, false);
>   }
> - blk_mq_start_stopped_hw_queues(info->rq, true);
> - blk_mq_kick_requeue_list(info->rq);
> + blk_mq_unquiesce_queue(info->rq);
>  
>   while ((bio = bio_list_pop(&info->bio_list)) != NULL) {
>   /* Traverse the list of pending bios and re-queue them */
> -- 
> 2.9.4
> 

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

[Xen-devel] [ovmf test] 111688: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 111665
 build-i386-xsm6 xen-buildfail REGR. vs. 111665
 build-amd64   6 xen-buildfail REGR. vs. 111665
 build-i3866 xen-buildfail REGR. vs. 111665

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf ed6da357a30666cfccfd2539d88e6171710084b7
baseline version:
 ovmf 9750503a116be3c246b249b1e7d7d9c51aae2a03

Last test of basis   111665  2017-07-11 06:05:53 Z0 days
Failing since111676  2017-07-11 12:16:50 Z0 days3 attempts
Testing same since   111680  2017-07-11 13:46:56 Z0 days2 attempts


People who touched revisions under test:
  Brijesh Singh 
  Jordan Justen 
  Laszlo Ersek 
  Liming Gao 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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

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

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

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


Not pushing.

(No revision log; it would be 367 lines long.)

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-cubietruck  6 xen-install  fail pass in 111645
 test-armhf-armhf-xl-xsm   7 xen-boot   fail pass in 111645
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail pass in 111645
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
pass in 111645

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 111645 
like 111534
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 111645 never 
pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 111645 
never pass
 test-armhf-armhf-xl-xsm 13 migrate-support-check fail in 111645 never pass
 test-armhf-armhf-xl-xsm 14 saverestore-support-check fail in 111645 never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 111506
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 111506
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 111534
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111534
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 111534
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111534
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111534
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 111534
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  

[Xen-devel] [PATCH][xen-next] xen/pvcalls: fix null pointer reference on sock_release call

[Colin King]

From: Colin Ian King 

Currently a sock_release on map->sock will result in a null pointer
deference on map when map is null. Instead, the sock_relase sould
be on sock and not map->sock.

Detected by CoverityScan, CID#1450169 ("Dereference after null check")

Fixes: b535e2b9b78a ("xen/pvcalls: implement connect command")
Signed-off-by: Colin Ian King 
---
 drivers/xen/pvcalls-back.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index d6c4c4aecb41..01b690e1e555 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -424,7 +424,7 @@ static int pvcalls_back_connect(struct xenbus_device *dev,
sock);
if (!map) {
ret = -EFAULT;
-   sock_release(map->sock);
+   sock_release(sock);
}
 
 out:
-- 
2.11.0


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

Re: [Xen-devel] [PATCH v1 1/3] xen/livepatch: Tighten alignment checks.

[Jan Beulich]

>>> Konrad Rzeszutek Wilk  07/11/17 6:53 PM >>>
>--- a/xen/common/livepatch.c
>+++ b/xen/common/livepatch.c
>@@ -406,6 +406,15 @@ static int move_payload(struct payload *payload, struct 
>livepatch_elf *elf)
 >ASSERT(offset[i] != UINT_MAX);
 >
 >elf->sec[i].load_addr = buf + offset[i];
>+if ( elf->sec[i].sec->sh_addralign > 1 &&

I think ruling out just zero here would be sufficient and look more "natural".

>+ ((Elf_Addr)elf->sec[i].load_addr % 
>elf->sec[i].sec->sh_addralign) )

The cast here mkes me wonder what it is that you're checking, or
whether the check isn't being done later than it should be done: I'd
expect all such to happen on the original section header, where no
pointer types exist (and hence such a cast shouldn't be needed).

And then - what about the alignment not being a power of 2? Is that
well defined?

>--- a/xen/common/livepatch_elf.c
>+++ b/xen/common/livepatch_elf.c
>@@ -86,6 +86,13 @@ static int elf_resolve_sections(struct livepatch_elf *elf, 
>const void *data)
 >delta < sizeof(Elf_Ehdr) ? "at ELF header" : "is past 
end");
 >return -EINVAL;
 >}
>+else if ( sec[i].sec->sh_addralign > 1 &&
>+  sec[i].sec->sh_addr % sec[i].sec->sh_addralign )

Ah, here it is - why the second check further up then?

>+{
>+dprintk(XENLOG_ERR, LIVEPATCH "%s: Section [%u] size 
>(%"PRIuElfWord") is not aligned properly (%"PRIuElfWord")\n",
>+elf->name, i, sec[i].sec->sh_size, 
>sec[i].sec->sh_addralign);

What does section size (being logged here) have to do with the check that
failed? I also question the use of decimal values here - generally I find sizes,
offsets, and alignments easier to deal with when they are being presented
as hex numbers.

>--- a/xen/include/xen/elfstructs.h
>+++ b/xen/include/xen/elfstructs.h
>@@ -555,6 +555,7 @@ typedef struct {
 >
 >#if defined(ELFSIZE) && (ELFSIZE == 32)
 >#define PRIxElfAddr   "08x"
>+#define PRIuElfWord   "08u"
 
And leading zeros would cause even more confusion, as they would suggest
(at least to C programmers) the number to be octal.

Jan


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

Re: [Xen-devel] [PATCH v1 2/3] livepatch: Include sizes when an mismatch occurs

[Jan Beulich]

>>> Konrad Rzeszutek Wilk  07/11/17 6:53 PM >>>
>--- a/xen/common/livepatch.c
>+++ b/xen/common/livepatch.c
>@@ -520,8 +520,8 @@ static int prepare_payload(struct payload *payload,
 >ASSERT(sec);
 >if ( sec->sec->sh_size % sizeof(*payload->funcs) )
 >{
>-dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size of 
>"ELF_LIVEPATCH_FUNC"!\n",
>-elf->name);
>+dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size of 
>"ELF_LIVEPATCH_FUNC"! (exp: %zu vs %"PRIuElfWord")\n",
>+elf->name, sizeof(*payload->funcs), sec->sec->sh_size);

What you print as expected value isn't really the only permitted one - the
expectation is the value to be a multiple of it. I wonder if the message
text therefore isn't confusing now. Also, how about embedding the actual
size right in the base message, i.e. something like ''Wrong size NNN of ...
(must be multiple of MMM)"?

Jan


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

Re: [Xen-devel] [PATCH v1 3/3] xen/livepatch/ARM32: Don't crash on livepatches loaded with wrong alignment.

[Jan Beulich]

>>> Konrad Rzeszutek Wilk  07/11/17 6:53 PM >>>
>This issue was observed on ARM32 with a cross compiler for the
>livepatches. Mainly the livepatches .data section size was not
>aligned to the section alignment:
>
>ARM32 native:
>Contents of section .rodata:
 > 68695f66 756e6300 63686563 6b5f666e  hi_func.check_fn
 >0010 6300 78656e5f 65787472 615f7665  c...xen_extra_ve
 >0020 7273696f 6e00rsion...
>
>ARM32 cross compiler:
>Contents of section .rodata:
 > 68695f66 756e6300 63686563 6b5f666e  hi_func.check_fn
 >0010 6300 78656e5f 65787472 615f7665  c...xen_extra_ve
 >0020 7273696f 6e00rsion.
>
>And when we loaded it:
>
>native:
>
>(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .text at 00a02000
>(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .rodata at 00a04024
>(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .altinstructions at 
>00a0404c
>
>cross compiler:
>(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .text at 00a02000
>(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .rodata at 00a04024
>(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .altinstructions at 
>00a0404a
>
>(See 4a vs 4c)
>
>native readelf:
  >[ 4] .rodata   PROGBITS 000164 28 00   A  0   0  
4
  >[ 5] .altinstructions  PROGBITS 00018c 0c 00   A  0   0  
1
>
>cross compiler readelf --sections:
  >[ 4] .rodata   PROGBITS 000164 26 00   A  0   0  
4
  >[ 5] .altinstructions  PROGBITS 00018a 0c 00   A  0   0  
1
>
>And as can be seen the .altinstructions have alignment of 1 which from
>'man elf' is: "Values of zero and one mean no alignment is required."
>which means we can ignore it.
>
>However ignoring this will result in a crash as when we started processing
>".rel.altinstructions" for ".altinstructions" with a cross-compiled payload
>we would end up poking in an section that was not aligned properly in memory
>and crash.

Which section is it that would not be aligned properly in memory?
.altinstructions, with an alignment of 1, can be placed anywhere. You
shouldn't enforce extra alignment. If higher alignment is needed, the
code producing this section emission needs to be fixed.

>This allows us on ARM32 to erorr out with:
>
>livepatch: xen_hello_world: dest=00a0404a (.altinstructions) is not aligned 
>properly!

I therefore doubt this is a correct diagnostic.

What you may want to consider is silently padding sections to a multiple
of their specified alignment.

Jan


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

Re: [Xen-devel] [PATCH 04/15] xen: mm: add ioremap_cache

[Julien Grall]

Hi,

On 07/09/2017 09:10 AM, Kai Huang wrote:

Currently Xen only has non-cacheable version of ioremap. Although EPC is
reported as reserved memory in e820 but it can be mapped as cacheable. This
patch adds ioremap_cache (cacheable version of ioremap).

Signed-off-by: Kai Huang 
---
  xen/arch/x86/mm.c  | 15 +--
  xen/include/xen/vmap.h |  1 +


First of all, this is common code and the "REST" maintainers should have 
been CCed for this include.


But xen/include/xen/vmap.h is common code and going to break ARM. We 
already have an inline implementation of ioremap_nocache. You should 
move the definition in x86 specific headers.


Please make sure to at least build test ARM when touching common code.

Cheers,


  2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 101ab33193..d0b6b3a247 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -6284,9 +6284,10 @@ void *__init arch_vmap_virt_end(void)
  return (void *)fix_to_virt(__end_of_fixed_addresses);
  }
  
-void __iomem *ioremap(paddr_t pa, size_t len)

+static void __iomem *__ioremap(paddr_t pa, size_t len, bool_t cache)
  {
  mfn_t mfn = _mfn(PFN_DOWN(pa));
+unsigned int flags = cache ? PAGE_HYPERVISOR : PAGE_HYPERVISOR_NOCACHE;
  void *va;
  
  WARN_ON(page_is_ram_type(mfn_x(mfn), RAM_TYPE_CONVENTIONAL));

@@ -6299,12 +6300,22 @@ void __iomem *ioremap(paddr_t pa, size_t len)
  unsigned int offs = pa & (PAGE_SIZE - 1);
  unsigned int nr = PFN_UP(offs + len);
  
-va = __vmap(&mfn, nr, 1, 1, PAGE_HYPERVISOR_NOCACHE, VMAP_DEFAULT) + offs;

+va = __vmap(&mfn, nr, 1, 1, flags, VMAP_DEFAULT) + offs;
  }
  
  return (void __force __iomem *)va;

  }
  
+void __iomem *ioremap(paddr_t pa, size_t len)

+{
+return __ioremap(pa, len, false);
+}
+
+void __iomem *ioremap_cache(paddr_t pa, size_t len)
+{
+return __ioremap(pa, len, true);
+}
+
  int create_perdomain_mapping(struct domain *d, unsigned long va,
   unsigned int nr, l1_pgentry_t **pl1tab,
   struct page_info **ppg)
diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h
index 369560e620..f6037e368c 100644
--- a/xen/include/xen/vmap.h
+++ b/xen/include/xen/vmap.h
@@ -24,6 +24,7 @@ void *vzalloc(size_t size);
  void vfree(void *va);
  
  void __iomem *ioremap(paddr_t, size_t);

+void __iomem *ioremap_cache(paddr_t, size_t);
  
  static inline void iounmap(void __iomem *va)

  {



--
Julien Grall

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

Re: [Xen-devel] [PATCH v8 1/7] x86/domctl: generalize the restore of vMCE parameters

[Jan Beulich]

>>> Haozhong Zhang  07/10/17 4:53 AM >>>
>--- a/xen/arch/x86/domctl.c
>+++ b/xen/arch/x86/domctl.c
>@@ -302,6 +302,42 @@ static int update_domain_cpuid_info(struct domain *d,
 >return 0;
 >}
 >
>+static int vcpu_set_vmce(struct vcpu *v,
>+ const struct xen_domctl_ext_vcpucontext *evc)
>+{
>+/*
>+ * Sizes of vMCE parameters used by the current and past versions
>+ * of Xen in descending order. If vMCE parameters are extended,
>+ * remember to add the old size to this array by VMCE_SIZE().
>+ */
>+#define VMCE_SIZE(param) \

I dislike macro (or function) parameter to be named "param" or alike. Please
use names that say what they stand for, e.g. "field" here.

>+(offsetof(typeof(evc->vmce), param) + sizeof(evc->vmce.param))
>+
>+static const unsigned int valid_sizes[] = {
>+sizeof(evc->vmce),
>+VMCE_SIZE(caps),
>+};
>+#undef VMCE_SIZE
>+
>+struct hvm_vmce_vcpu vmce = { };
>+unsigned int evc_vmce_size = evc->size - offsetof(typeof(*evc), mcg_cap);

I'd prefer for this to be put in a min(..., sizeof(evc->vmce)) to cope with
possible future additions of members after the vmce one.

Jan


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

Re: [Xen-devel] [PATCH v8 2/7] x86/vmce: emulate MSR_IA32_MCG_EXT_CTL

[Jan Beulich]

>>> Haozhong Zhang  07/10/17 4:53 AM >>>
>If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then allow guest
>to read/write MSR_IA32_MCG_EXT_CTL.
>
>Signed-off-by: Haozhong Zhang 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v1 3/3] xen/livepatch/ARM32: Don't crash on livepatches loaded with wrong alignment.

[Konrad Rzeszutek Wilk]

On Tue, Jul 11, 2017 at 02:06:09PM -0600, Jan Beulich wrote:
> >>> Konrad Rzeszutek Wilk  07/11/17 6:53 PM >>>
> >This issue was observed on ARM32 with a cross compiler for the
> >livepatches. Mainly the livepatches .data section size was not
> >aligned to the section alignment:
> >
> >ARM32 native:
> >Contents of section .rodata:
>  > 68695f66 756e6300 63686563 6b5f666e  hi_func.check_fn
>  >0010 6300 78656e5f 65787472 615f7665  c...xen_extra_ve
>  >0020 7273696f 6e00rsion...
> >
> >ARM32 cross compiler:
> >Contents of section .rodata:
>  > 68695f66 756e6300 63686563 6b5f666e  hi_func.check_fn
>  >0010 6300 78656e5f 65787472 615f7665  c...xen_extra_ve
>  >0020 7273696f 6e00rsion.
> >
> >And when we loaded it:
> >
> >native:
> >
> >(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .text at 00a02000
> >(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .rodata at 00a04024
> >(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .altinstructions 
> >at 00a0404c
> >
> >cross compiler:
> >(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .text at 00a02000
> >(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .rodata at 00a04024
> >(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .altinstructions 
> >at 00a0404a
> >
> >(See 4a vs 4c)
> >
> >native readelf:
>   >[ 4] .rodata   PROGBITS 000164 28 00   A  0   
> 0  4
>   >[ 5] .altinstructions  PROGBITS 00018c 0c 00   A  0   
> 0  1
> >
> >cross compiler readelf --sections:
>   >[ 4] .rodata   PROGBITS 000164 26 00   A  0   
> 0  4
>   >[ 5] .altinstructions  PROGBITS 00018a 0c 00   A  0   
> 0  1
> >
> >And as can be seen the .altinstructions have alignment of 1 which from
> >'man elf' is: "Values of zero and one mean no alignment is required."
> >which means we can ignore it.
> >
> >However ignoring this will result in a crash as when we started processing
> >".rel.altinstructions" for ".altinstructions" with a cross-compiled payload
> >we would end up poking in an section that was not aligned properly in memory
> >and crash.
> 
> Which section is it that would not be aligned properly in memory?

.altinstructions, thanks to .rodata not being padded properly.

> .altinstructions, with an alignment of 1, can be placed anywhere. You
> shouldn't enforce extra alignment. If higher alignment is needed, the
> code producing this section emission needs to be fixed.

And there is the path to madness :-) We would need to provide an
linker map to make sure that they are with the correct alignment.

Or use the xen.lds on, but we would need to tweak it as the ASSERTS
in it will complain.

> 
> >This allows us on ARM32 to erorr out with:
> >
> >livepatch: xen_hello_world: dest=00a0404a (.altinstructions) is not aligned 
> >properly!
> 
> I therefore doubt this is a correct diagnostic.

It is - if we try to muck around with the .altinstructions we will crash
on ARM32.

> 
> What you may want to consider is silently padding sections to a multiple
> of their specified alignment.

Hm. That hadn't occured to me. Let me try that.

> 
> Jan
> 

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

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

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qcow2
testid xen-boot

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

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  548aa0e3c516d906dae5edb1fc9a1ad2e490120a
  Bug not present: adc311034c356e884d180df25deb046cef3e8c75
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/111696/


  (Revision log too long, omitted.)


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-amd64-xl-qcow2.xen-boot
 --summary-out=tmp/111696.bisection-summary --basis-template=110515 
--blessings=real,real-bisect linux-linus test-amd64-amd64-xl-qcow2 xen-boot
Searching for failure / basis pass:
 111654 fail [host=chardonnay1] / 111580 [host=huxelrebe0] 111529 
[host=nobling0] 111493 [host=nocera1] 111416 [host=rimava1] 111383 
[host=baroque1] 111374 [host=nobling1] 111363 [host=godello0] 111332 
[host=pinot0] 111280 [host=fiano0] 111222 [host=baroque0] 83 [host=pinot1] 
48 [host=italia0] 24 [host=rimava0] 111081 [host=elbling0] 110984 
[host=elbling1] 110950 [host=huxelrebe0] 110908 [host=italia1] 110560 
[host=nobling0] 110547 [host=baroque1] 110536 ok.
Failure / basis pass flights: 111654 / 110536
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 548aa0e3c516d906dae5edb1fc9a1ad2e490120a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
d23afa6399a78ca7d0ed3294119632535828c9d8
Basis pass adc311034c356e884d180df25deb046cef3e8c75 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
695bb5f504ab48c1d546446f104c1b6c0ead126d
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#adc311034c356e884d180df25deb046cef3e8c75-548aa0e3c516d906dae5edb1fc9a1ad2e490120a
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d
 
git://xenbits.xen.org/qemu-xen.git#e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7-414d069b38ab114b89085e44989bf57604ea86d7
 
git://xenbits.xen.org/xen.git#695bb5f504ab48c1d546446f104c1b6c0ead126d-d23afa6399a78ca7d0ed3294119632535828c9d8
adhoc-revtuple-generator: tree discontiguous: linux-2.6
Loaded 2007 nodes in revision graph
Searching for test results:
 110464 [host=baroque0]
 110486 [host=fiano1]
 110515 [host=godello0]
 110547 [host=baroque1]
 110536 pass adc311034c356e884d180df25deb046cef3e8c75 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
695bb5f504ab48c1d546446f104c1b6c0ead126d
 110560 [host=nobling0]
 110908 [host=italia1]
 110950 [host=huxelrebe0]
 110984 [host=elbling1]
 111081 [host=elbling0]
 24 [host=rimava0]
 48 [host=italia0]
 111280 [host=fiano0]
 83 [host=pinot1]
 111222 [host=baroque0]
 111332 [host=pinot0]
 111363 [host=godello0]
 111374 [host=nobling1]
 111383 [host=baroque1]
 111416 [host=rimava1]
 111493 [host=nocera1]
 111529 [host=nobling0]
 111580 [host=huxelrebe0]
 111641 pass adc311034c356e884d180df25deb046cef3e8c75 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
695bb5f504ab48c1d546446f104c1b6c0ead126d
 111611 fail irrelevant
 111635 fail irrelevant
 111642 fail irrelevant
 111646 pass adc311034c356e884d180df25deb046cef3e8c75 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
5bba2b362f7ecde1a1a034c0bb0cc882577d8bce
 111649 pass adc311034c356e884d180df25deb046cef3e8c75 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
5e2af95aeb168d90c5900d35d663691f595fb012
 111650 pass adc311034c356e884d

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: avoid to use start/stop queue

[Roger Pau Monné]

On Wed, Jul 12, 2017 at 02:20:58AM +0800, Ming Lei wrote:
> This interfaces will be removed soon, so use quiesce and
> unquiesce instead, which should be more safe.
> 
> The only one usage will be removed in the following
> congestion control patches.

Would it be better to simply fix blk_mq_{start/stop}_stopped_hw_queues
rather than introducing a new interface?

Roger.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-libvirt-xsm 12 guest-start  fail REGR. vs. 111403
 test-armhf-armhf-xl-vhd  10 debian-di-installfail REGR. vs. 111403
 test-armhf-armhf-libvirt 12 guest-start  fail REGR. vs. 111403
 test-armhf-armhf-libvirt-xsm 12 guest-start  fail REGR. vs. 111403
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 111403

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-startfail pass in 111648

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 111648 like 
111379
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 111648 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 111648 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 111403
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111403
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 111403
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu6b06e3e49eb8c91cc286c16d6bf3181ac296f33d
baseline version:
 qemuu2185c93ba80f81bfa27ce6f259c7f2ef4f08b668

Last test of basis   111403  2017-07-05 10:31:25 Z6 days
Failing since111475  2017-07-06 11:14:43 Z5 days7 attempts
Testing same since   111648  2017-07-10 19:48:23 Z1 days2 attempts


People who touched revisions under test:
  Alistair Francis 
  Anoob Soman 
  Anthony Liguori 
  Anthony PERARD 
  Christian Borntraeger 
  Cornelia Huck 
  Daniel P. Berrange 
  Dong Jia Shi 
  Emilio G. Cota 
  Eric Blake 
  Fam Zheng 
  Halil Pasic 
  Hervé Poussineau 
  Jason Wang 
  Jiang Biao 
  Kevin Wolf 
  Paolo Bonzini 
  Peter Maydell 
  Pranith Kumar 
  QingFeng Hao 
  Richard Henderson 
  Ross Lagerwall 
  Sergio Andres Gomez Del Real 
  Stefano Stabellini 
  Thomas Huth 
  Viktor Mihajlovski 
  Vladimir Sementsov-Ogievskiy 
  Wu Xiang 
  Yang Zhong 

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

[Xen-devel] [seabios test] 111687: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 seabios  dd9bba5b9c1d5175a2757f3fdc9d554b4c8eea3a
baseline version:
 seabios  b3a9f27fb1f63e9b6bf5ca424d31e23bd5b4c2f0

Last test of basis   111330  2017-07-02 17:15:59 Z9 days
Testing same since   111687  2017-07-11 16:46:32 Z0 days1 attempts


People who touched revisions under test:
  Jason Wang 
  Michael S. Tsirkin 

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



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

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

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

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


Pushing revision :

+ branch=seabios
+ revision=dd9bba5b9c1d5175a2757f3fdc9d554b4c8eea3a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push seabios 
dd9bba5b9c1d5175a2757f3fdc9d554b4c8eea3a
+ branch=seabios
+ revision=dd9bba5b9c1d5175a2757f3fdc9d554b4c8eea3a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . 

[Xen-devel] [ovmf test] 111694: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 111665
 build-i386-xsm6 xen-buildfail REGR. vs. 111665
 build-amd64   6 xen-buildfail REGR. vs. 111665
 build-i3866 xen-buildfail REGR. vs. 111665

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf ed6da357a30666cfccfd2539d88e6171710084b7
baseline version:
 ovmf 9750503a116be3c246b249b1e7d7d9c51aae2a03

Last test of basis   111665  2017-07-11 06:05:53 Z0 days
Failing since111676  2017-07-11 12:16:50 Z0 days4 attempts
Testing same since   111680  2017-07-11 13:46:56 Z0 days3 attempts


People who touched revisions under test:
  Brijesh Singh 
  Jordan Justen 
  Laszlo Ersek 
  Liming Gao 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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

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

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

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


Not pushing.

(No revision log; it would be 367 lines long.)

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

[Xen-devel] [linux-3.18 test] 111673: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail in 111655 pass in 111673
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 111655 
pass in 111673
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 111655 
pass in 111673
 test-amd64-amd64-xl-rtds 10 debian-install fail pass in 111523
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail pass in 111523
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail pass in 111614
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 
111655

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 
110441
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 111523 
blocked in 110441
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 111614 blocked in 
110441
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 111614 
like 110441
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 111655 blocked in 
110441
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 111655 
like 110441
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 110441
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110441
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110441
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110441
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail neve

[Xen-devel] Lots of new warnings with gcc-7.1.1

[Linus Torvalds]

[ Very random list of maintainers and mailing lists, at least
partially by number of warnings generated by gcc-7.1.1 that is then
correlated with the get_maintainers script ]

So I upgraded one of my boxes to F26, which upgraded the compiler to gcc-7.1.1

Which in turn means that my nice clean allmodconfig compile is not an
unholy mess of annoying new warnings.

Normally I hate the stupid new warnings, but this time around they are
actually exactly the kinds of warnings you'd want to see and that are
hard for humans to pick out errors: lots of format errors wrt limited
buffer sizes.

At the same time, many of them *are* annoying. We have various limited
buffers that are limited for a good reason, and some of the format
truncation warnings are about numbers in the range {0-MAX_INT], where
we definitely know that we don't need to worry about the really big
ones.

After all, we're using "snprintf()" for a reason - we *want* to
truncate if the buffer is too small.

But a lot of the warnings look reasonable, and at least the warnings
are nice in how they actually explain why the warning is happening.
Example:

  arch/x86/platform/intel-mid/device_libs/platform_max7315.c: In
function ‘max7315_platform_data’:
  arch/x86/platform/intel-mid/device_libs/platform_max7315.c:41:35:
warning: ‘%d’ directive writing between 1 and 11 bytes into a region
of size 9 [-Wformat-overflow=]
 sprintf(base_pin_name, "max7315_%d_base", nr);
 ^~
  arch/x86/platform/intel-mid/device_libs/platform_max7315.c:41:26:
note: directive argument in the range [-2147483647, 2147483647]

Yeah, the compiler is technically correct, but we already made sure we
have at most MAX7315_NUM of those adapters, so no, "nr" is really not
going to be a 10-digit number.

So the warning is kind of bogus.

At the same time, others aren't quite as insane, and in many cases the
warnings might be easy to just fix.

And some actually look valid, although they might still require odd input:

  net/bluetooth/smp.c: In function ‘le_max_key_size_read’:
  net/bluetooth/smp.c:3372:29: warning: ‘snprintf’ output may be
truncated before the last format character [-Wformat-truncation=]
snprintf(buf, sizeof(buf), "%2u\n", SMP_DEV(hdev)->max_key_size);
   ^~~
  net/bluetooth/smp.c:3372:2: note: ‘snprintf’ output between 4 and 5
bytes into a destination of size 4

yeah, "max_key_size" is unsigned char, but if it's larger than 99 it
really does need 5 bytes for "%2u\n" with the terminating NUL
character.

Of course, the "%2d" implies that people expect it to be < 100, but at
the same time it doesn't sound like a bad idea to just make the buffer
be one byte bigger. So..

Anyway, it would be lovely if some of the more affected developers
would take a look at gcc-7.1.1 warnings. Right now I get about three
*thousand* lines of warnings from a "make allmodconfig" build, which
makes them a bit overwhelming.

I do suspect I'll make "-Wformat-truncation" (as opposed to
"-Wformat-overflow") be a "V=1" kind of warning.  But let's see how
many of these we can fix, ok?

  Linus

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

Re: [Xen-devel] [PATCH v3] xen-platform: separate unplugging of NVMe disks

[Stefano Stabellini]

On Mon, 10 Jul 2017, Anthony PERARD wrote:
> Hi Stefano,
> 
> Looks like this patch can be applied.

Thank you for pointing it out to me, because this email has
inexplicably disappeared from my inbox. I have now marked it
appropriately to be committed.

> 
> On Fri, Mar 24, 2017 at 01:40:25PM +, Paul Durrant wrote:
> > Commit 090fa1c8 "add support for unplugging NVMe disks..." extended the
> > existing disk unplug flag to cover NVMe disks as well as IDE and SCSI.
> > 
> > The recent thread on the xen-devel mailing list [1] has highlighted that
> > this is not desirable behaviour: PV frontends should be able to distinguish
> > NVMe disks from other types of disk and should have separate control over
> > whether they are unplugged.
> > 
> > This patch defines a new bit in the unplug mask for this purpose (see Xen
> > commit [2]) and also tidies up the definitions of, and improves the
> > comments regarding, the previously exiting bits in the protocol.
> > 
> > [1] https://lists.xen.org/archives/html/xen-devel/2017-03/msg02924.html
> > [2] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=1096aa02
> > 
> > Signed-off-by: Paul Durrant 
> > Reviewed-by: Stefano Stabellini 
> > --
> > Cc: Anthony Perard 
> > 
> > v3:
> > - Updated to reference Xen documentation patch
> > 
> > v2:
> > - Fix the commit comment
> > ---
> >  hw/i386/xen/xen_platform.c | 47 
> > ++
> >  1 file changed, 35 insertions(+), 12 deletions(-)
> > 
> > diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c
> > index 6010f35..983d532 100644
> > --- a/hw/i386/xen/xen_platform.c
> > +++ b/hw/i386/xen/xen_platform.c
> > @@ -87,10 +87,30 @@ static void log_writeb(PCIXenPlatformState *s, char val)
> >  }
> >  }
> >  
> > -/* Xen Platform, Fixed IOPort */
> > -#define UNPLUG_ALL_DISKS 1
> > -#define UNPLUG_ALL_NICS 2
> > -#define UNPLUG_AUX_IDE_DISKS 4
> > +/*
> > + * Unplug device flags.
> > + *
> > + * The logic got a little confused at some point in the past but this is
> > + * what they do now.
> > + *
> > + * bit 0: Unplug all IDE and SCSI disks.
> > + * bit 1: Unplug all NICs.
> > + * bit 2: Unplug IDE disks except primary master. This is overridden if
> > + *bit 0 is also present in the mask.
> > + * bit 3: Unplug all NVMe disks.
> > + *
> > + */
> > +#define _UNPLUG_IDE_SCSI_DISKS 0
> > +#define UNPLUG_IDE_SCSI_DISKS (1u << _UNPLUG_IDE_SCSI_DISKS)
> > +
> > +#define _UNPLUG_ALL_NICS 1
> > +#define UNPLUG_ALL_NICS (1u << _UNPLUG_ALL_NICS)
> > +
> > +#define _UNPLUG_AUX_IDE_DISKS 2
> > +#define UNPLUG_AUX_IDE_DISKS (1u << _UNPLUG_AUX_IDE_DISKS)
> > +
> > +#define _UNPLUG_NVME_DISKS 3
> > +#define UNPLUG_NVME_DISKS (1u << _UNPLUG_NVME_DISKS)
> >  
> >  static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
> >  {
> > @@ -111,7 +131,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, void 
> > *opaque)
> >  {
> >  uint32_t flags = *(uint32_t *)opaque;
> >  bool aux = (flags & UNPLUG_AUX_IDE_DISKS) &&
> > -!(flags & UNPLUG_ALL_DISKS);
> > +!(flags & UNPLUG_IDE_SCSI_DISKS);
> >  
> >  /* We have to ignore passthrough devices */
> >  if (!strcmp(d->name, "xen-pci-passthrough")) {
> > @@ -124,12 +144,16 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, 
> > void *opaque)
> >  break;
> >  
> >  case PCI_CLASS_STORAGE_SCSI:
> > -case PCI_CLASS_STORAGE_EXPRESS:
> >  if (!aux) {
> >  object_unparent(OBJECT(d));
> >  }
> >  break;
> >  
> > +case PCI_CLASS_STORAGE_EXPRESS:
> > +if (flags & UNPLUG_NVME_DISKS) {
> > +object_unparent(OBJECT(d));
> > +}
> > +
> >  default:
> >  break;
> >  }
> > @@ -147,10 +171,9 @@ static void platform_fixed_ioport_writew(void *opaque, 
> > uint32_t addr, uint32_t v
> >  switch (addr) {
> >  case 0: {
> >  PCIDevice *pci_dev = PCI_DEVICE(s);
> > -/* Unplug devices.  Value is a bitmask of which devices to
> > -   unplug, with bit 0 the disk devices, bit 1 the network
> > -   devices, and bit 2 the non-primary-master IDE devices. */
> > -if (val & (UNPLUG_ALL_DISKS | UNPLUG_AUX_IDE_DISKS)) {
> > +/* Unplug devices. See comment above flag definitions */
> > +if (val & (UNPLUG_IDE_SCSI_DISKS | UNPLUG_AUX_IDE_DISKS |
> > +   UNPLUG_NVME_DISKS)) {
> >  DPRINTF("unplug disks\n");
> >  pci_unplug_disks(pci_dev->bus, val);
> >  }
> > @@ -338,14 +361,14 @@ static void xen_platform_ioport_writeb(void *opaque, 
> > hwaddr addr,
> >   * If VMDP was to control both disk and LAN it would use 4.
> >   * If it controlled just disk or just LAN, it would use 8 
> > below.
> >   */
> > -pci_unplug_disks(pci_dev->bus, UNPLUG_ALL_DISKS);
> > +pci_unplug_disks(pci_dev->bus, UNPLUG_IDE_SCSI_DISKS);
> >  pci_unplug_nics(pci_dev->bus);
> >  }
> >  

[Xen-devel] [seabios baseline-only test] 71681: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71681 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71681/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
71624
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
71624
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
71624

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

version targeted for testing:
 seabios  dd9bba5b9c1d5175a2757f3fdc9d554b4c8eea3a
baseline version:
 seabios  b3a9f27fb1f63e9b6bf5ca424d31e23bd5b4c2f0

Last test of basis71624  2017-07-02 21:19:47 Z9 days
Testing same since71681  2017-07-11 21:47:22 Z0 days1 attempts


People who touched revisions under test:
  Jason Wang 
  Michael S. Tsirkin 

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



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

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

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


Push not applicable.


commit dd9bba5b9c1d5175a2757f3fdc9d554b4c8eea3a
Author: Jason Wang 
Date:   Wed Jul 5 15:49:51 2017 +0800

virtio: IOMMU support

Since we don't enable IOMMU at all, we can then simply enable the
IOMMU support by claiming the support of VIRITO_F_IOMMU_PLATFORM. This
fixes booting failure when iommu_platform is set from qemu cli.

Acked-by: Michael S. Tsirkin 
Signed-off-by: Jason Wang 

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

Re: [Xen-devel] [PATCH 04/15] xen: mm: add ioremap_cache

[Huang, Kai]

Hi Julien,

Thanks for pointing out. I'll move to x86 specific.

I've cc-ed all maintainers reported by ./scripts/get_maintainer.pl, 
looks this script doesn't report all maintainers. Sorry. I'll add ARM 
maintainers next time.


Thanks,
-Kai

On 7/12/2017 8:14 AM, Julien Grall wrote:

Hi,

On 07/09/2017 09:10 AM, Kai Huang wrote:

Currently Xen only has non-cacheable version of ioremap. Although EPC is
reported as reserved memory in e820 but it can be mapped as cacheable. 
This

patch adds ioremap_cache (cacheable version of ioremap).

Signed-off-by: Kai Huang 
---
  xen/arch/x86/mm.c  | 15 +--
  xen/include/xen/vmap.h |  1 +


First of all, this is common code and the "REST" maintainers should have 
been CCed for this include.


But xen/include/xen/vmap.h is common code and going to break ARM. We 
already have an inline implementation of ioremap_nocache. You should 
move the definition in x86 specific headers.


Please make sure to at least build test ARM when touching common code.

Cheers,


  2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 101ab33193..d0b6b3a247 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -6284,9 +6284,10 @@ void *__init arch_vmap_virt_end(void)
  return (void *)fix_to_virt(__end_of_fixed_addresses);
  }
-void __iomem *ioremap(paddr_t pa, size_t len)
+static void __iomem *__ioremap(paddr_t pa, size_t len, bool_t cache)
  {
  mfn_t mfn = _mfn(PFN_DOWN(pa));
+unsigned int flags = cache ? PAGE_HYPERVISOR : 
PAGE_HYPERVISOR_NOCACHE;

  void *va;
  WARN_ON(page_is_ram_type(mfn_x(mfn), RAM_TYPE_CONVENTIONAL));
@@ -6299,12 +6300,22 @@ void __iomem *ioremap(paddr_t pa, size_t len)
  unsigned int offs = pa & (PAGE_SIZE - 1);
  unsigned int nr = PFN_UP(offs + len);
-va = __vmap(&mfn, nr, 1, 1, PAGE_HYPERVISOR_NOCACHE, 
VMAP_DEFAULT) + offs;

+va = __vmap(&mfn, nr, 1, 1, flags, VMAP_DEFAULT) + offs;
  }
  return (void __force __iomem *)va;
  }
+void __iomem *ioremap(paddr_t pa, size_t len)
+{
+return __ioremap(pa, len, false);
+}
+
+void __iomem *ioremap_cache(paddr_t pa, size_t len)
+{
+return __ioremap(pa, len, true);
+}
+
  int create_perdomain_mapping(struct domain *d, unsigned long va,
   unsigned int nr, l1_pgentry_t **pl1tab,
   struct page_info **ppg)
diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h
index 369560e620..f6037e368c 100644
--- a/xen/include/xen/vmap.h
+++ b/xen/include/xen/vmap.h
@@ -24,6 +24,7 @@ void *vzalloc(size_t size);
  void vfree(void *va);
  void __iomem *ioremap(paddr_t, size_t);
+void __iomem *ioremap_cache(paddr_t, size_t);
  static inline void iounmap(void __iomem *va)
  {





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

[Xen-devel] [PATCH v9 3/7] x86/vmce: enable injecting LMCE to guest on Intel host

[Haozhong Zhang]

Inject LMCE to guest if the host MCE is LMCE and the affected vcpu is
known. Otherwise, broadcast MCE to all vcpus on Intel host.

Signed-off-by: Haozhong Zhang 
Reviewed-by: Jan Beulich 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/cpu/mcheck/mcaction.c | 23 ---
 xen/arch/x86/cpu/mcheck/vmce.c | 11 ++-
 xen/arch/x86/cpu/mcheck/vmce.h |  2 +-
 3 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mcaction.c 
b/xen/arch/x86/cpu/mcheck/mcaction.c
index ca17d22bd8..f959bed2cb 100644
--- a/xen/arch/x86/cpu/mcheck/mcaction.c
+++ b/xen/arch/x86/cpu/mcheck/mcaction.c
@@ -44,6 +44,7 @@ mc_memerr_dhandler(struct mca_binfo *binfo,
 unsigned long mfn, gfn;
 uint32_t status;
 int vmce_vcpuid;
+unsigned int mc_vcpuid;
 
 if (!mc_check_addr(bank->mc_status, bank->mc_misc, MC_ADDR_PHYSICAL)) {
 dprintk(XENLOG_WARNING,
@@ -88,18 +89,26 @@ mc_memerr_dhandler(struct mca_binfo *binfo,
 goto vmce_failed;
 }
 
-if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
-global->mc_vcpuid == XEN_MC_VCPUID_INVALID)
+mc_vcpuid = global->mc_vcpuid;
+if (mc_vcpuid == XEN_MC_VCPUID_INVALID ||
+/*
+ * Because MC# may happen asynchronously with the actual
+ * operation that triggers the error, the domain ID as
+ * well as the vCPU ID collected in 'global' at MC# are
+ * not always precise. In that case, fallback to broadcast.
+ */
+global->mc_domid != bank->mc_domid ||
+(boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
+ (!(global->mc_gstatus & MCG_STATUS_LMCE) ||
+  !(d->vcpu[mc_vcpuid]->arch.vmce.mcg_ext_ctl &
+MCG_EXT_CTL_LMCE_EN
 vmce_vcpuid = VMCE_INJECT_BROADCAST;
 else
-vmce_vcpuid = global->mc_vcpuid;
+vmce_vcpuid = mc_vcpuid;
 
 bank->mc_addr = gfn << PAGE_SHIFT |
   (bank->mc_addr & (PAGE_SIZE -1 ));
-/* TODO: support injecting LMCE */
-if (fill_vmsr_data(bank, d,
-   global->mc_gstatus & ~MCG_STATUS_LMCE,
-   vmce_vcpuid == VMCE_INJECT_BROADCAST))
+if (fill_vmsr_data(bank, d, global->mc_gstatus, vmce_vcpuid))
 {
 mce_printk(MCE_QUIET, "Fill vMCE# data for DOM%d "
   "failed\n", bank->mc_domid);
diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index 060e2d0582..e2b3c5b8cc 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -465,14 +465,23 @@ static int vcpu_fill_mc_msrs(struct vcpu *v, uint64_t 
mcg_status,
 }
 
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
-   uint64_t gstatus, bool broadcast)
+   uint64_t gstatus, int vmce_vcpuid)
 {
 struct vcpu *v = d->vcpu[0];
+bool broadcast = (vmce_vcpuid == VMCE_INJECT_BROADCAST);
 int ret, err;
 
 if ( mc_bank->mc_domid == DOMID_INVALID )
 return -EINVAL;
 
+if ( broadcast )
+gstatus &= ~MCG_STATUS_LMCE;
+else if ( gstatus & MCG_STATUS_LMCE )
+{
+ASSERT(vmce_vcpuid >= 0 && vmce_vcpuid < d->max_vcpus);
+v = d->vcpu[vmce_vcpuid];
+}
+
 /*
  * vMCE with the actual error information is injected to vCPU0,
  * and, if broadcast is required, we choose to inject less severe
diff --git a/xen/arch/x86/cpu/mcheck/vmce.h b/xen/arch/x86/cpu/mcheck/vmce.h
index 74f6381460..2797e00275 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.h
+++ b/xen/arch/x86/cpu/mcheck/vmce.h
@@ -17,7 +17,7 @@ int vmce_amd_rdmsr(const struct vcpu *, uint32_t msr, 
uint64_t *val);
 int vmce_amd_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);
 
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
-   uint64_t gstatus, bool broadcast);
+   uint64_t gstatus, int vmce_vcpuid);
 
 #define VMCE_INJECT_BROADCAST (-1)
 int inject_vmce(struct domain *d, int vcpu);
-- 
2.11.0


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

[Xen-devel] [PATCH v9 0/7] Add LMCE support

[Haozhong Zhang]

Changes in v9:
 * Minor updates in patch 1 per Jan's comments.
 * Collect Jan's R-b in patch 2.

Haozhong Zhang (7):
  [M   ] x86/domctl: generalize the restore of vMCE parameters
  [  R ] x86/vmce: emulate MSR_IA32_MCG_EXT_CTL
  [  R ] x86/vmce: enable injecting LMCE to guest on Intel host
  [  RA] x86/vmce, tools/libxl: expose LMCE capability in guest MSR_IA32_MCG_CAP
  [  R ] xen/mce: add support of vLMCE injection to XEN_MC_inject_v2
  [   A] tools/libxc: add support of injecting MC# to specified CPUs
  [   A] tools/xen-mceinj: add support of injecting LMCE

 N: new in this version
 M: modified in this version
 R: got R-b
 A: got A-b

 docs/man/xl.cfg.pod.5.in| 24 +
 tools/libxc/include/xenctrl.h   |  2 ++
 tools/libxc/xc_misc.c   | 52 ++-
 tools/libxc/xc_sr_save_x86_hvm.c|  1 +
 tools/libxl/libxl.h |  7 
 tools/libxl/libxl_dom.c | 15 
 tools/libxl/libxl_types.idl |  1 +
 tools/tests/mce-test/tools/xen-mceinj.c | 50 --
 tools/xl/xl_parse.c | 31 ++--
 xen/arch/x86/cpu/mcheck/mcaction.c  | 23 
 xen/arch/x86/cpu/mcheck/mce.c   | 24 -
 xen/arch/x86/cpu/mcheck/mce.h   |  1 +
 xen/arch/x86/cpu/mcheck/mce_intel.c |  2 +-
 xen/arch/x86/cpu/mcheck/vmce.c  | 64 +++--
 xen/arch/x86/cpu/mcheck/vmce.h  |  2 +-
 xen/arch/x86/domctl.c   | 57 -
 xen/arch/x86/hvm/hvm.c  |  5 +++
 xen/include/asm-x86/mce.h   |  2 ++
 xen/include/public/arch-x86/hvm/save.h  |  1 +
 xen/include/public/arch-x86/xen-mca.h   |  1 +
 xen/include/public/hvm/params.h |  7 +++-
 21 files changed, 336 insertions(+), 36 deletions(-)

-- 
2.11.0


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

[Xen-devel] [PATCH v9 4/7] x86/vmce, tools/libxl: expose LMCE capability in guest MSR_IA32_MCG_CAP

[Haozhong Zhang]

If LMCE is supported by host and ' mca_caps = [ "lmce" ] ' is present
in xl config, the LMCE capability will be exposed in guest MSR_IA32_MCG_CAP.
By default, LMCE is not exposed to guest so as to keep the backwards migration
compatibility.

Signed-off-by: Haozhong Zhang 
Reviewed-by: Jan Beulich  for hypervisor side
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 docs/man/xl.cfg.pod.5.in| 24 
 tools/libxc/xc_sr_save_x86_hvm.c|  1 +
 tools/libxl/libxl.h |  7 +++
 tools/libxl/libxl_dom.c | 15 +++
 tools/libxl/libxl_types.idl |  1 +
 tools/xl/xl_parse.c | 31 +--
 xen/arch/x86/cpu/mcheck/mce.h   |  1 +
 xen/arch/x86/cpu/mcheck/mce_intel.c |  2 +-
 xen/arch/x86/cpu/mcheck/vmce.c  | 19 ++-
 xen/arch/x86/hvm/hvm.c  |  5 +
 xen/include/asm-x86/mce.h   |  1 +
 xen/include/public/hvm/params.h |  7 ++-
 12 files changed, 109 insertions(+), 5 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index ff3203550f..79cb2eaea7 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -2173,6 +2173,30 @@ natively or via hardware backwards compatibility support.
 
 =back
 
+=head3 x86
+
+=over 4
+
+=item B
+
+(HVM only) Enable MCA capabilities besides default ones enabled
+by Xen hypervisor for the HVM domain. "CAP" can be one in the
+following list:
+
+=over 4
+
+=item B<"lmce">
+
+Intel local MCE
+
+=item B
+
+No MCA capabilities in above list are enabled.
+
+=back
+
+=back
+
 =head1 SEE ALSO
 
 =over 4
diff --git a/tools/libxc/xc_sr_save_x86_hvm.c b/tools/libxc/xc_sr_save_x86_hvm.c
index fc5c6ea93e..e17bb59146 100644
--- a/tools/libxc/xc_sr_save_x86_hvm.c
+++ b/tools/libxc/xc_sr_save_x86_hvm.c
@@ -77,6 +77,7 @@ static int write_hvm_params(struct xc_sr_context *ctx)
 HVM_PARAM_IOREQ_SERVER_PFN,
 HVM_PARAM_NR_IOREQ_SERVER_PAGES,
 HVM_PARAM_X87_FIP_WIDTH,
+HVM_PARAM_MCA_CAP,
 };
 
 xc_interface *xch = ctx->xch;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index cf8687aa7e..7cf0f31f68 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -922,6 +922,13 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, const 
libxl_mac *src);
  * If this is defined, the Code and Data Prioritization feature is supported.
  */
 #define LIBXL_HAVE_PSR_CDP 1
+
+/*
+ * LIBXL_HAVE_MCA_CAPS
+ *
+ * If this is defined, setting MCA capabilities for HVM domain is supported.
+ */
+#define LIBXL_HAVE_MCA_CAPS 1
 #endif
 
 /*
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 5d914a59ee..f54fd49a73 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -279,6 +279,17 @@ err:
 libxl_bitmap_dispose(&enlightenments);
 return ERROR_FAIL;
 }
+
+static int hvm_set_mca_capabilities(libxl__gc *gc, uint32_t domid,
+libxl_domain_build_info *const info)
+{
+unsigned long caps = info->u.hvm.mca_caps;
+
+if (!caps)
+return 0;
+
+return xc_hvm_param_set(CTX->xch, domid, HVM_PARAM_MCA_CAP, caps);
+}
 #endif
 
 static void hvm_set_conf_params(xc_interface *handle, uint32_t domid,
@@ -440,6 +451,10 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 rc = hvm_set_viridian_features(gc, domid, info);
 if (rc)
 return rc;
+
+rc = hvm_set_mca_capabilities(gc, domid, info);
+if (rc)
+return rc;
 #endif
 }
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 22044259f3..8a9849c643 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -564,6 +564,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
("serial_list",  libxl_string_list),
("rdm", libxl_rdm_reserve),
("rdm_mem_boundary_memkb", MemKB),
+   ("mca_caps", uint64),
])),
  ("pv", Struct(None, [("kernel", string),
   ("slack_memkb", MemKB),
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 856a304b30..5c2bf17222 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -813,8 +814,9 @@ void parse_config_data(const char *config_source,
 XLU_Config *config;
 XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
*usbctrls, *usbdevs, *p9devs;
-XLU_ConfigList *channels, *ioports, *irqs, *iomem, *viridian, *dtdevs;
-int num_ioports, num_irqs, num_iomem, num_cpus, num_viridian;
+XLU_ConfigList *channels, *ioports, *irqs, *iomem, *viridian, *dtdevs,
+   *mca_ca

[Xen-devel] [PATCH v9 2/7] x86/vmce: emulate MSR_IA32_MCG_EXT_CTL

[Haozhong Zhang]

If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then allow guest
to read/write MSR_IA32_MCG_EXT_CTL.

Signed-off-by: Haozhong Zhang 
Reviewed-by: Jan Beulich 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/cpu/mcheck/vmce.c | 34 +-
 xen/arch/x86/domctl.c  |  2 ++
 xen/include/asm-x86/mce.h  |  1 +
 xen/include/public/arch-x86/hvm/save.h |  1 +
 4 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index 1356f611ab..060e2d0582 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -91,6 +91,7 @@ int vmce_restore_vcpu(struct vcpu *v, const struct 
hvm_vmce_vcpu *ctxt)
 v->arch.vmce.mcg_cap = ctxt->caps;
 v->arch.vmce.bank[0].mci_ctl2 = ctxt->mci_ctl2_bank0;
 v->arch.vmce.bank[1].mci_ctl2 = ctxt->mci_ctl2_bank1;
+v->arch.vmce.mcg_ext_ctl = ctxt->mcg_ext_ctl;
 
 return 0;
 }
@@ -200,6 +201,26 @@ int vmce_rdmsr(uint32_t msr, uint64_t *val)
 mce_printk(MCE_VERBOSE, "MCE: %pv: rd MCG_CTL %#"PRIx64"\n", cur, 
*val);
 break;
 
+case MSR_IA32_MCG_EXT_CTL:
+/*
+ * If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, the LMCE and 
LOCK
+ * bits are always set in guest MSR_IA32_FEATURE_CONTROL by Xen, so it
+ * does not need to check them here.
+ */
+if ( cur->arch.vmce.mcg_cap & MCG_LMCE_P )
+{
+*val = cur->arch.vmce.mcg_ext_ctl;
+mce_printk(MCE_VERBOSE, "MCE: %pv: rd MCG_EXT_CTL %#"PRIx64"\n",
+   cur, *val);
+}
+else
+{
+ret = -1;
+mce_printk(MCE_VERBOSE, "MCE: %pv: rd MCG_EXT_CTL, not 
supported\n",
+   cur);
+}
+break;
+
 default:
 ret = mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0;
 break;
@@ -309,6 +330,16 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
 mce_printk(MCE_VERBOSE, "MCE: %pv: MCG_CAP is r/o\n", cur);
 break;
 
+case MSR_IA32_MCG_EXT_CTL:
+if ( (cur->arch.vmce.mcg_cap & MCG_LMCE_P) &&
+ !(val & ~MCG_EXT_CTL_LMCE_EN) )
+cur->arch.vmce.mcg_ext_ctl = val;
+else
+ret = -1;
+mce_printk(MCE_VERBOSE, "MCE: %pv: wr MCG_EXT_CTL %"PRIx64"%s\n",
+   cur, val, (ret == -1) ? ", not supported" : "");
+break;
+
 default:
 ret = mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : 0;
 break;
@@ -327,7 +358,8 @@ static int vmce_save_vcpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 struct hvm_vmce_vcpu ctxt = {
 .caps = v->arch.vmce.mcg_cap,
 .mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2,
-.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2
+.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2,
+.mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl,
 };
 
 err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 3637d32669..3628af2f70 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -315,6 +315,7 @@ static int vcpu_set_vmce(struct vcpu *v,
 
 static const unsigned int valid_sizes[] = {
 sizeof(evc->vmce),
+VMCE_SIZE(mci_ctl2_bank1),
 VMCE_SIZE(caps),
 };
 #undef VMCE_SIZE
@@ -908,6 +909,7 @@ long arch_do_domctl(
 evc->vmce.caps = v->arch.vmce.mcg_cap;
 evc->vmce.mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2;
 evc->vmce.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2;
+evc->vmce.mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl;
 
 ret = 0;
 vcpu_unpause(v);
diff --git a/xen/include/asm-x86/mce.h b/xen/include/asm-x86/mce.h
index 56ad1f92dd..35f9962638 100644
--- a/xen/include/asm-x86/mce.h
+++ b/xen/include/asm-x86/mce.h
@@ -27,6 +27,7 @@ struct vmce_bank {
 struct vmce {
 uint64_t mcg_cap;
 uint64_t mcg_status;
+uint64_t mcg_ext_ctl;
 spinlock_t lock;
 struct vmce_bank bank[GUEST_MC_BANK_NUM];
 };
diff --git a/xen/include/public/arch-x86/hvm/save.h 
b/xen/include/public/arch-x86/hvm/save.h
index 816973b9c2..fd7bf3fb38 100644
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -610,6 +610,7 @@ struct hvm_vmce_vcpu {
 uint64_t caps;
 uint64_t mci_ctl2_bank0;
 uint64_t mci_ctl2_bank1;
+uint64_t mcg_ext_ctl;
 };
 
 DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
-- 
2.11.0


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

[Xen-devel] [PATCH v9 6/7] tools/libxc: add support of injecting MC# to specified CPUs

[Haozhong Zhang]

Though XEN_MC_inject_v2 allows injecting MC# to specified CPUs, the
current xc_mca_op() does not use this feature and not provide an
interface to callers. This commit add a new xc_mca_op_inject_v2() that
receives a cpumap providing the set of target CPUs.

Signed-off-by: Haozhong Zhang 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/libxc/include/xenctrl.h |  2 ++
 tools/libxc/xc_misc.c | 52 ++-
 2 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c51bb3b448..552a4fd47d 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1809,6 +1809,8 @@ int xc_cpuid_apply_policy(xc_interface *xch,
 void xc_cpuid_to_str(const unsigned int *regs,
  char **strs); /* some strs[] may be NULL if ENOMEM */
 int xc_mca_op(xc_interface *xch, struct xen_mc *mc);
+int xc_mca_op_inject_v2(xc_interface *xch, unsigned int flags,
+xc_cpumap_t cpumap, unsigned int nr_cpus);
 #endif
 
 struct xc_px_val {
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 88084fde30..2303293c6c 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -341,7 +341,57 @@ int xc_mca_op(xc_interface *xch, struct xen_mc *mc)
 xc_hypercall_bounce_post(xch, mc);
 return ret;
 }
-#endif
+
+int xc_mca_op_inject_v2(xc_interface *xch, unsigned int flags,
+xc_cpumap_t cpumap, unsigned int nr_bits)
+{
+int ret = -1;
+struct xen_mc mc_buf, *mc = &mc_buf;
+struct xen_mc_inject_v2 *inject = &mc->u.mc_inject_v2;
+
+DECLARE_HYPERCALL_BOUNCE(cpumap, 0, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+DECLARE_HYPERCALL_BOUNCE(mc, sizeof(*mc), XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
+
+memset(mc, 0, sizeof(*mc));
+
+if ( cpumap )
+{
+if ( !nr_bits )
+{
+errno = EINVAL;
+goto out;
+}
+
+HYPERCALL_BOUNCE_SET_SIZE(cpumap, (nr_bits + 7) / 8);
+if ( xc_hypercall_bounce_pre(xch, cpumap) )
+{
+PERROR("Could not bounce cpumap memory buffer");
+goto out;
+}
+set_xen_guest_handle(inject->cpumap.bitmap, cpumap);
+inject->cpumap.nr_bits = nr_bits;
+}
+
+inject->flags = flags;
+mc->cmd = XEN_MC_inject_v2;
+mc->interface_version = XEN_MCA_INTERFACE_VERSION;
+
+if ( xc_hypercall_bounce_pre(xch, mc) )
+{
+PERROR("Could not bounce xen_mc memory buffer");
+goto out_free_cpumap;
+}
+
+ret = xencall1(xch->xcall, __HYPERVISOR_mca, HYPERCALL_BUFFER_AS_ARG(mc));
+
+xc_hypercall_bounce_post(xch, mc);
+out_free_cpumap:
+if ( cpumap )
+xc_hypercall_bounce_post(xch, cpumap);
+out:
+return ret;
+}
+#endif /* __i386__ || __x86_64__ */
 
 int xc_perfc_reset(xc_interface *xch)
 {
-- 
2.11.0


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

[Xen-devel] [PATCH v9 1/7] x86/domctl: generalize the restore of vMCE parameters

[Haozhong Zhang]

vMCE parameters in struct xen_domctl_ext_vcpucontext were extended in
the past, and is likely to be extended in the future. When migrating a
PV domain from old Xen, XEN_DOMCTL_set_ext_vcpucontext should handle
the differences.

Instead of adding ad-hoc handling code at each extension, we introduce
an array to record sizes of the current and all past versions of vMCE
parameters, and search for the largest one that does not expire the
size of passed-in parameters to determine vMCE parameters that will be
restored. If vMCE parameters are extended in the future, we only need
to adapt the array to reflect the extension.

Signed-off-by: Haozhong Zhang 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

Changes in v9:
 * Rename "param" to "field" in macro VMCE_SIZE().
 * Use min(..., sizeof(evc->vmce)) to get the size of vMCE parameters.
---
 xen/arch/x86/domctl.c | 55 +++
 1 file changed, 38 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 7fa58b49af..3637d32669 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -302,6 +302,43 @@ static int update_domain_cpuid_info(struct domain *d,
 return 0;
 }
 
+static int vcpu_set_vmce(struct vcpu *v,
+ const struct xen_domctl_ext_vcpucontext *evc)
+{
+/*
+ * Sizes of vMCE parameters used by the current and past versions
+ * of Xen in descending order. If vMCE parameters are extended,
+ * remember to add the old size to this array by VMCE_SIZE().
+ */
+#define VMCE_SIZE(field) \
+(offsetof(typeof(evc->vmce), field) + sizeof(evc->vmce.field))
+
+static const unsigned int valid_sizes[] = {
+sizeof(evc->vmce),
+VMCE_SIZE(caps),
+};
+#undef VMCE_SIZE
+
+struct hvm_vmce_vcpu vmce = { };
+unsigned int evc_vmce_size =
+min(evc->size - offsetof(typeof(*evc), mcg_cap), sizeof(evc->vmce));
+unsigned int i = 0;
+
+BUILD_BUG_ON(offsetof(typeof(*evc), mcg_cap) !=
+ offsetof(typeof(*evc), vmce.caps));
+BUILD_BUG_ON(sizeof(evc->mcg_cap) != sizeof(evc->vmce.caps));
+
+while ( i < ARRAY_SIZE(valid_sizes) && evc_vmce_size < valid_sizes[i] )
+++i;
+
+if ( i == ARRAY_SIZE(valid_sizes) )
+return 0;
+
+memcpy(&vmce, &evc->vmce, valid_sizes[i]);
+
+return vmce_restore_vcpu(v, &vmce);
+}
+
 void arch_get_domain_info(const struct domain *d,
   struct xen_domctl_getdomaininfo *info)
 {
@@ -912,23 +949,7 @@ long arch_do_domctl(
 else
 domain_pause(d);
 
-BUILD_BUG_ON(offsetof(struct xen_domctl_ext_vcpucontext,
-  mcg_cap) !=
- offsetof(struct xen_domctl_ext_vcpucontext,
-  vmce.caps));
-BUILD_BUG_ON(sizeof(evc->mcg_cap) != sizeof(evc->vmce.caps));
-if ( evc->size >= offsetof(typeof(*evc), vmce) +
-  sizeof(evc->vmce) )
-ret = vmce_restore_vcpu(v, &evc->vmce);
-else if ( evc->size >= offsetof(typeof(*evc), mcg_cap) +
-   sizeof(evc->mcg_cap) )
-{
-struct hvm_vmce_vcpu vmce = { .caps = evc->mcg_cap };
-
-ret = vmce_restore_vcpu(v, &vmce);
-}
-else
-ret = 0;
+ret = vcpu_set_vmce(v, evc);
 
 domain_unpause(d);
 }
-- 
2.11.0


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

[Xen-devel] [PATCH v9 5/7] xen/mce: add support of vLMCE injection to XEN_MC_inject_v2

[Haozhong Zhang]

Signed-off-by: Haozhong Zhang 
Reviewed-by: Jan Beulich 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/cpu/mcheck/mce.c | 24 +++-
 xen/include/public/arch-x86/xen-mca.h |  1 +
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index ee04fb54ff..30525dd78b 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1485,11 +1485,12 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 {
 const cpumask_t *cpumap;
 cpumask_var_t cmv;
+bool broadcast = op->u.mc_inject_v2.flags & 
XEN_MC_INJECT_CPU_BROADCAST;
 
 if (nr_mce_banks == 0)
 return x86_mcerr("do_mca #MC", -ENODEV);
 
-if ( op->u.mc_inject_v2.flags & XEN_MC_INJECT_CPU_BROADCAST )
+if ( broadcast )
 cpumap = &cpu_online_map;
 else
 {
@@ -1529,6 +1530,27 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 }
 break;
 
+case XEN_MC_INJECT_TYPE_LMCE:
+if ( !lmce_support )
+{
+ret = x86_mcerr("No LMCE support", -EINVAL);
+break;
+}
+if ( broadcast )
+{
+ret = x86_mcerr("Broadcast cannot be used with LMCE", -EINVAL);
+break;
+}
+/* Ensure at most one CPU is specified. */
+if ( nr_cpu_ids > cpumask_next(cpumask_first(cpumap), cpumap) )
+{
+ret = x86_mcerr("More than one CPU specified for LMCE",
+-EINVAL);
+break;
+}
+on_selected_cpus(cpumap, x86_mc_mceinject, NULL, 1);
+break;
+
 default:
 ret = x86_mcerr("Wrong mca type\n", -EINVAL);
 break;
diff --git a/xen/include/public/arch-x86/xen-mca.h 
b/xen/include/public/arch-x86/xen-mca.h
index 7db990723b..dc35267249 100644
--- a/xen/include/public/arch-x86/xen-mca.h
+++ b/xen/include/public/arch-x86/xen-mca.h
@@ -414,6 +414,7 @@ struct xen_mc_mceinject {
 #define XEN_MC_INJECT_TYPE_MASK 0x7
 #define XEN_MC_INJECT_TYPE_MCE  0x0
 #define XEN_MC_INJECT_TYPE_CMCI 0x1
+#define XEN_MC_INJECT_TYPE_LMCE 0x2
 
 #define XEN_MC_INJECT_CPU_BROADCAST 0x8
 
-- 
2.11.0


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

[Xen-devel] [PATCH v9 7/7] tools/xen-mceinj: add support of injecting LMCE

[Haozhong Zhang]

If option '-l' or '--lmce' is specified and the host supports LMCE,
xen-mceinj will inject LMCE to CPU specified by '-c' (or CPU0 if '-c'
is not present).

Signed-off-by: Haozhong Zhang 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/tests/mce-test/tools/xen-mceinj.c | 50 +++--
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/tools/tests/mce-test/tools/xen-mceinj.c 
b/tools/tests/mce-test/tools/xen-mceinj.c
index bae5a46eb5..380e42190c 100644
--- a/tools/tests/mce-test/tools/xen-mceinj.c
+++ b/tools/tests/mce-test/tools/xen-mceinj.c
@@ -56,6 +56,8 @@
 #define MSR_IA32_MC0_MISC0x0403
 #define MSR_IA32_MC0_CTL20x0280
 
+#define MCG_STATUS_LMCE  0x8
+
 struct mce_info {
 const char *description;
 uint8_t mcg_stat;
@@ -113,6 +115,7 @@ static struct mce_info mce_table[] = {
 #define LOGFILE stdout
 
 int dump;
+int lmce;
 struct xen_mc_msrinject msr_inj;
 
 static void Lprintf(const char *fmt, ...)
@@ -212,6 +215,35 @@ static int inject_mce(xc_interface *xc_handle, int cpu_nr)
 return xc_mca_op(xc_handle, &mc);
 }
 
+static int inject_lmce(xc_interface *xc_handle, unsigned int cpu)
+{
+uint8_t *cpumap = NULL;
+size_t cpumap_size, line, shift;
+unsigned int nr_cpus;
+int ret;
+
+nr_cpus = mca_cpuinfo(xc_handle);
+if ( !nr_cpus )
+err(xc_handle, "Failed to get mca_cpuinfo");
+if ( cpu >= nr_cpus )
+err(xc_handle, "-c %u is larger than %u", cpu, nr_cpus - 1);
+
+cpumap_size = (nr_cpus + 7) / 8;
+cpumap = malloc(cpumap_size);
+if ( !cpumap )
+err(xc_handle, "Failed to allocate cpumap\n");
+memset(cpumap, 0, cpumap_size);
+line = cpu / 8;
+shift = cpu % 8;
+memset(cpumap + line, 1 << shift, 1);
+
+ret = xc_mca_op_inject_v2(xc_handle, XEN_MC_INJECT_TYPE_LMCE,
+  cpumap, cpumap_size * 8);
+
+free(cpumap);
+return ret;
+}
+
 static uint64_t bank_addr(int bank, int type)
 {
 uint64_t addr;
@@ -330,8 +362,15 @@ static int inject(xc_interface *xc_handle, struct mce_info 
*mce,
   uint32_t cpu_nr, uint32_t domain, uint64_t gaddr)
 {
 int ret = 0;
+uint8_t mcg_status = mce->mcg_stat;
 
-ret = inject_mcg_status(xc_handle, cpu_nr, mce->mcg_stat, domain);
+if ( lmce )
+{
+if ( mce->cmci )
+err(xc_handle, "No support to inject CMCI as LMCE");
+mcg_status |= MCG_STATUS_LMCE;
+}
+ret = inject_mcg_status(xc_handle, cpu_nr, mcg_status, domain);
 if ( ret )
 err(xc_handle, "Failed to inject MCG_STATUS MSR");
 
@@ -354,6 +393,8 @@ static int inject(xc_interface *xc_handle, struct mce_info 
*mce,
 err(xc_handle, "Failed to inject MSR");
 if ( mce->cmci )
 ret = inject_cmci(xc_handle, cpu_nr);
+else if ( lmce )
+ret = inject_lmce(xc_handle, cpu_nr);
 else
 ret = inject_mce(xc_handle, cpu_nr);
 if ( ret )
@@ -393,6 +434,7 @@ static struct option opts[] = {
 {"dump", 0, 0, 'D'},
 {"help", 0, 0, 'h'},
 {"page", 0, 0, 'p'},
+{"lmce", 0, 0, 'l'},
 {"", 0, 0, '\0'}
 };
 
@@ -409,6 +451,7 @@ static void help(void)
"  -d, --domain=DOMID   target domain, the default is Xen itself\n"
"  -h, --help   print this page\n"
"  -p, --page=ADDR  physical address to report\n"
+   "  -l, --lmce   inject as LMCE (Intel only)\n"
"  -t, --type=ERROR error type\n");
 
 for ( i = 0; i < MCE_TABLE_SIZE; i++ )
@@ -438,7 +481,7 @@ int main(int argc, char *argv[])
 }
 
 while ( 1 ) {
-c = getopt_long(argc, argv, "c:Dd:t:hp:", opts, &opt_index);
+c = getopt_long(argc, argv, "c:Dd:t:hp:l", opts, &opt_index);
 if ( c == -1 )
 break;
 switch ( c ) {
@@ -463,6 +506,9 @@ int main(int argc, char *argv[])
 case 't':
 type = strtol(optarg, NULL, 0);
 break;
+case 'l':
+lmce = 1;
+break;
 case 'h':
 default:
 help();
-- 
2.11.0


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

Re: [Xen-devel] [x86/time] f61a8e12b5: ACPI_Error:Table[DMAR]is_not_invalidated_during_early_boot_stage(#/tbxface-#)

[Dou Liyang]

Hi, Xiaolong

Thank you very much for testing. I have got the reason why the ACPI
error happened and will give a fix patch below.

Also cc ACPI maintainers..

At 07/08/2017 11:48 AM, kernel test robot wrote:

FYI, we noticed the following commit:

commit: f61a8e12b5972879f8decfe059e54c813dc4416b ("x86/time: Initialize interrupt 
mode behind timer init")
url: 
https://github.com/0day-ci/linux/commits/Dou-Liyang/Unify-the-interrupt-delivery-mode-and-do-its-setup-in-advance/20170705-124610


in testcase: will-it-scale
with following parameters:

nr_task: 50%
mode: process
test: writeseek3
cpufreq_governor: performance

test-description: Will It Scale takes a testcase and runs it from 1 through to 
n parallel copies to see if the testcase will scale. It builds both a process 
and threads based test in order to see any differences between the two.
test-url: https://github.com/antonblanchard/will-it-scale


on test machine: 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz with 64G 
memory

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+---+++
|   
| d021c73124 | f61a8e12b5 |
+---+++
| boot_successes
| 0  | 6  |
| boot_failures 
| 2  | 4  |
| invoked_oom-killer:gfp_mask=0x
| 2  ||
| Mem-Info  
| 2  ||
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes  
| 2  ||
| ACPI_Error:Table[DMAR]is_not_invalidated_during_early_boot_stage(#/tbxface-#) 
| 0  | 4  |
| WARNING:at_mm/early_ioremap.c:#check_early_ioremap_leak   
| 0  | 4  |
+---+++



kern  :info  : [0.005000] tsc: Fast TSC calibration using PIT
kern  :info  : [0.006000] tsc: Detected 2194.957 MHz processor
kern  :info  : [0.007000] Calibrating delay loop (skipped), value 
calculated using timer frequency.. 4389.91 BogoMIPS (lpj=2194957)
kern  :info  : [0.008002] pid_max: default: 90112 minimum: 704
kern  :info  : [0.009034] ACPI: Core revision 20170303
kern  :err   : [0.010002] ACPI Error: Table [DMAR] is not invalidated 
during early boot stage (20170303/tbxface-193)


Here is the ACPI error.

The reason:
---

As we know, Linux divides the ACPI table management into two stages:
1) the early stage:
  the mapped ACPI tables is temporary and should be unmapped before the
early stage ends.

2) the late stage.
  the mapped ACPI tables is permanent.

And Linux uses *acpi_permanent_mmap* to distinguish the early stage and
the late stage. the default of *acpi_permanent_mmap* is false and will
be set to true in *acpi_early_init()*, which means that Linux regards
*acpi_early_init()* as the dividing line.

Linux maps the ACPI DMAR table in the late stage, But this patch make 
the mapping earlier in the early stage, so the ACPI error happened.


The solution:
-

There are two solution we can use:

1) After use the DMAR table, we unmap it, which likes following

 acpi_get_table();
 parse the DMAR table and use it...
 acpi_put_table();

2) Invoke the *acpi_early_init()* earlier.

The 1) has influence on the initialization of IOMMU, not work well.
The 2) is suitable, and it also can make the change of interrupt trigger 
type earlier than Linux enter into the final interrupt delivery

mode.

The patch:
--
  it will be added in my next version.


diff --git a/init/main.c b/init/main.c
index df58a41..7a09467 100644
--- a/init/main.c
+++ b/init/main.c
@@ -654,12 +654,12 @@ asmlinkage __visible void __init start_kernel(void)
kmemleak_init();
setup_per_cpu_pageset();
numa_policy_init();
+   acpi_early_init();
if (late_time_init)
late_time_init();
calibrate_delay();
pidmap_init();
anon_vma_init();
-   acpi_early_init();
 #ifdef CONFIG_X86
if (efi_enabled(EFI_RUNTIME_SERVICES))
efi_enter_virtual_mode();

BTY, cc Lee

I try to invoke acpi_early_init() earlier before
timekeeping_init() for accessing ACPI TAD device to set system clock.
Now the testing is OK, but There are a lot of operations between them,
I think we need more investigation.


Thanks,

dou.


kern  :info  : [0.125364] ACPI: 4 ACPI AML tables successfully acquired and 
loaded
kern  :info  : [0.1261

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-intel  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-xl-multivcpu 15 guest-saverestore   fail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 21 guest-start/debian  fail REGR. vs. 110515
 test-amd64-amd64-xl-credit2  15 guest-saverestorefail REGR. vs. 110515
 test-amd64-amd64-pair21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-i386-libvirt-pair 21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-i386-libvirt  16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-xl-xsm   16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-xl  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-xl-xsm  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-libvirt 16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-libvirt-xsm  16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-pair 21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-amd  16 guest-localmigrate   fail REGR. vs. 110515
 test-armhf-armhf-libvirt-xsm  6 xen-install  fail REGR. vs. 110515
 test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail REGR. vs. 110515
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 110515
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-amd64-libvirt-xsm 16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-xl   16 guest-localmigrate   fail REGR. vs. 110515

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 
110515
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 
110515
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 110515
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 110515
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf e508e069a809ba895230ef6ea5c8d43c471d0de4
baseline version:
 ovmf 9750503a116be3c246b249b1e7d7d9c51aae2a03

Last test of basis   111665  2017-07-11 06:05:53 Z0 days
Failing since111676  2017-07-11 12:16:50 Z0 days5 attempts
Testing same since   111704  2017-07-11 22:49:23 Z0 days1 attempts


People who touched revisions under test:
  Brijesh Singh 
  Jordan Justen 
  Laszlo Ersek 
  Liming Gao 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] Lots of new warnings with gcc-7.1.1

[Guenter Roeck]

On 07/11/2017 03:35 PM, Linus Torvalds wrote:

[ Very random list of maintainers and mailing lists, at least
partially by number of warnings generated by gcc-7.1.1 that is then
correlated with the get_maintainers script ]

So I upgraded one of my boxes to F26, which upgraded the compiler to gcc-7.1.1

Which in turn means that my nice clean allmodconfig compile is not an
unholy mess of annoying new warnings.

Normally I hate the stupid new warnings, but this time around they are
actually exactly the kinds of warnings you'd want to see and that are
hard for humans to pick out errors: lots of format errors wrt limited
buffer sizes.

At the same time, many of them *are* annoying. We have various limited
buffers that are limited for a good reason, and some of the format
truncation warnings are about numbers in the range {0-MAX_INT], where
we definitely know that we don't need to worry about the really big
ones.

After all, we're using "snprintf()" for a reason - we *want* to
truncate if the buffer is too small.



The hwmon warnings are all about supporting no more than 9,999 sensors
(applesmc) to 999,999,999 sensors (scpi) of a given type. Easy "fix" would
be to replace snprintf() with scnprintf(), presumably because gcc doesn't
know about scnprintf(). We could also increase the name buffer size.
But is that really worth it just to silence gcc ?

Guenter

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

Re: [Xen-devel] [PATCH 5/25] Xen/doc: Add Xen virtual IOMMU doc

[Lan Tianyu]

On 2017年07月08日 00:08, Julien Grall wrote:
>> Because we now just have onE vIOMMU, all virtual interrupt will be bound
>> to it. If need to support mult-vIOMMU, we can add device-scope
>> field(sbdf array or some thing like that) in the structure and specify
>> what devices should be under one vIOMMU.
> 
> I am not sure to follow the argument here. Even if you have only one
> vIOMMU you need to be able to do the correspondence between the virtual
> MasterID (for PCI it is based on the RID) and the host MasterID.

Hi Julien:
 Sorry for later response.
 MasterID you mentioned here is sbdf, right? Binding between sbdf
and vsbdf(virtual sbdf) should be in the device pass through related
interface(e.g, xc_domain_bind_pt_irq_int() has already done such similar
thing that bind vsbdf with real interrupt of hypervisor.).
 vIOMMU device model can get vsbdf when guest configure vIOMMU entry
and hypervisor can do conversion between sbdf and vsbdf. For interrupt
remapping on virtual VTD, we don't find such requirement so far and got
enough data from IOAPIC/MSI entry and interrupt remapping entry of
virtual VTD. So we don't extend pass through interface.

-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] Lots of new warnings with gcc-7.1.1

[Linus Torvalds]

On Tue, Jul 11, 2017 at 8:10 PM, Guenter Roeck  wrote:
>
> The hwmon warnings are all about supporting no more than 9,999 sensors
> (applesmc) to 999,999,999 sensors (scpi) of a given type.

Yeah, I think that's enough.

> Easy "fix" would be to replace snprintf() with scnprintf(), presumably
> because gcc doesn't know about scnprintf().

If that's the case, I'd prefer just turning off the format-truncation
(but not overflow) warning with '-Wno-format-trunction".

But maybe we can at least start it on a subsystem-by-subsystem basis
after people have verified their own subsusystem?

  Linus

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

Re: [Xen-devel] Lots of new warnings with gcc-7.1.1

[Linus Torvalds]

On Tue, Jul 11, 2017 at 8:17 PM, Linus Torvalds
 wrote:
>
> If that's the case, I'd prefer just turning off the format-truncation
> (but not overflow) warning with '-Wno-format-trunction".

Doing

 KBUILD_CFLAGS  += $(call cc-disable-warning, format-truncation)

in the main Makefile certainly cuts down on the warnings.

We still have some overflow warnings, including the crazy one where
gcc doesn't see that the number of max7315 boards is very limited.

But those could easily be converted to just snprintf() instead, and
then the truncation warning disabling takes care of it. Maybe that's
the right answer.

We also have about a bazillion

warning: ‘*’ in boolean context, suggest ‘&&’ instead

warnings in drivers/ata/libata-core.c, all due to a single macro that
uses a pattern that gcc-7.1.1 doesn't like. The warning looks a bit
debatable, but I suspect the macro could easily be changed too.

Tejun, would you hate just moving the "multiply by 1000" part _into_
that EZ() macro? Something like the attached (UNTESTED!) patch?

  Linus
 drivers/ata/libata-core.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 8453f9a4682f..4c7d5a138495 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3231,19 +3231,19 @@ static const struct ata_timing ata_timing[] = {
 };
 
 #define ENOUGH(v, unit)(((v)-1)/(unit)+1)
-#define EZ(v, unit)((v)?ENOUGH(v, unit):0)
+#define EZ(v, unit)((v)?ENOUGH((v)*1000, unit):0)
 
 static void ata_timing_quantize(const struct ata_timing *t, struct ata_timing 
*q, int T, int UT)
 {
-   q->setup= EZ(t->setup  * 1000,  T);
-   q->act8b= EZ(t->act8b  * 1000,  T);
-   q->rec8b= EZ(t->rec8b  * 1000,  T);
-   q->cyc8b= EZ(t->cyc8b  * 1000,  T);
-   q->active   = EZ(t->active * 1000,  T);
-   q->recover  = EZ(t->recover* 1000,  T);
-   q->dmack_hold   = EZ(t->dmack_hold * 1000,  T);
-   q->cycle= EZ(t->cycle  * 1000,  T);
-   q->udma = EZ(t->udma   * 1000, UT);
+   q->setup= EZ(t->setup,  T);
+   q->act8b= EZ(t->act8b,  T);
+   q->rec8b= EZ(t->rec8b,  T);
+   q->cyc8b= EZ(t->cyc8b,  T);
+   q->active   = EZ(t->active, T);
+   q->recover  = EZ(t->recover,T);
+   q->dmack_hold   = EZ(t->dmack_hold, T);
+   q->cycle= EZ(t->cycle,  T);
+   q->udma = EZ(t->udma,   UT);
 }
 
 void ata_timing_merge(const struct ata_timing *a, const struct ata_timing *b,
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: avoid to use start/stop queue

[Ming Lei]

On Tue, Jul 11, 2017 at 06:41:29PM +, Bart Van Assche wrote:
> On Wed, 2017-07-12 at 02:20 +0800, Ming Lei wrote:
> > This interfaces will be removed soon, so use quiesce and
> > unquiesce instead, which should be more safe.
> > 
> > The only one usage will be removed in the following
> > congestion control patches.
> 
> Hello Ming,
> 
> The title of this patch is misleading since this patch does not touch the 
> calls
> related to queue congestion (blk_mq_stop_hw_queue() and
> blk_mq_start_stopped_hw_queues()). I assume that you meant that this patch 
> avoids
> that the xen-blkfront driver uses blk_mq_(start|stop)_hw_queues() (with 
> queues in
> plural form)? Can you please reflect that in the subject of this and related
> patches?

OK, will do it in V2.

> 
> Additionally, it's probably a good idea that this is not just an interface 
> change
> but that this kind of patches fix a (hard to trigger?) race condition.
> 
> >  static inline void kick_pending_request_queues_locked(struct 
> > blkfront_ring_info *rinfo)
> >  {
> > -   if (!RING_FULL(&rinfo->ring))
> > +   if (!RING_FULL(&rinfo->ring)) {
> > blk_mq_start_stopped_hw_queues(rinfo->dev_info->rq, true);
> > +   blk_mq_kick_requeue_list(rinfo->dev_info->rq);
> > +   }
> >  }
> >  
> >  static void kick_pending_request_queues(struct blkfront_ring_info *rinfo)
> > @@ -1225,7 +1227,8 @@ static void kick_pending_request_queues(struct 
> > blkfront_ring_info *rinfo)
> > unsigned long flags;
> >  
> > spin_lock_irqsave(&rinfo->ring_lock, flags);
> > -   kick_pending_request_queues_locked(rinfo);
> > +   if (!RING_FULL(&rinfo->ring))
> > +   blk_mq_run_hw_queues(rinfo->dev_info->rq, true);
> > spin_unlock_irqrestore(&rinfo->ring_lock, flags);
> >  }
> 
> Why do some kick_pending_request_queues_locked() kick the requeue list and why
> has the above kick_pending_request_queues_locked() call been converted into a
> blk_mq_run_hw_queues() call and thereby ignores the requeue list?

kick_pending_request_queues_locked() is used in req completion path,
which belongs to congestion control, so this patch doesn't touch
kick_pending_request_queues_locked(), which will be switched to
generic congestion control in patch 5.

For kick_pending_request_queues(), this patch replaces
blk_mq_start_stopped_hw_queues() with blk_mq_run_hw_queues()
because run queue is often the real purpose of this function,
especially in non-congestion control path.


Thanks,
Ming

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

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: avoid to use start/stop queue

[Ming Lei]

On Tue, Jul 11, 2017 at 11:24:44PM +0200, Roger Pau Monné wrote:
> On Wed, Jul 12, 2017 at 02:20:58AM +0800, Ming Lei wrote:
> > This interfaces will be removed soon, so use quiesce and
> > unquiesce instead, which should be more safe.
> > 
> > The only one usage will be removed in the following
> > congestion control patches.
> 
> Would it be better to simply fix blk_mq_{start/stop}_stopped_hw_queues
> rather than introducing a new interface?

No, we do not want to expose start/stop state to drivers any more, which
has caused enough trouble already, so these APIs need to be removed, and
quiesce/unquiesce is preferred way for this purpose, as you can see
the work done by Sagi Grimberg:

http://marc.info/?t=14992741596&r=1&w=2


Thanks,
Ming

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

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: avoid to use start/stop queue

[Ming Lei]

On Tue, Jul 11, 2017 at 02:41:05PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 12, 2017 at 02:20:58AM +0800, Ming Lei wrote:
> > This interfaces will be removed soon, so use quiesce and
> > unquiesce instead, which should be more safe.
> 
> 'should be'? That does not sound encouraging?

Sorry for the mistake, and will fix it in V2, definitely quiesce
is the preferred interface, also stop queue may not do what you
want to do as you can see from comment of blk_mq_stop_hw_queues,
and has caused much trouble already.

And I appreciate if you guys may review on this patch itself.

BTW, this patch should have been included in Sagi Grimberg's
patchset of "[PATCH v3 0/8] correct quiescing in several block drivers":

http://marc.info/?t=14992741596&r=1&w=2

Thanks,
Ming

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

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: avoid to use start/stop queue

[Ming Lei]

On Tue, Jul 11, 2017 at 06:41:29PM +, Bart Van Assche wrote:
> On Wed, 2017-07-12 at 02:20 +0800, Ming Lei wrote:
> > This interfaces will be removed soon, so use quiesce and
> > unquiesce instead, which should be more safe.
> > 
> > The only one usage will be removed in the following
> > congestion control patches.
> 
> Hello Ming,
> 
> The title of this patch is misleading since this patch does not touch the 
> calls
> related to queue congestion (blk_mq_stop_hw_queue() and
> blk_mq_start_stopped_hw_queues()). I assume that you meant that this patch 
> avoids
> that the xen-blkfront driver uses blk_mq_(start|stop)_hw_queues() (with 
> queues in
> plural form)? Can you please reflect that in the subject of this and related
> patches?
> 
> Additionally, it's probably a good idea that this is not just an interface 
> change
> but that this kind of patches fix a (hard to trigger?) race condition.
> 
> >  static inline void kick_pending_request_queues_locked(struct 
> > blkfront_ring_info *rinfo)
> >  {
> > -   if (!RING_FULL(&rinfo->ring))
> > +   if (!RING_FULL(&rinfo->ring)) {
> > blk_mq_start_stopped_hw_queues(rinfo->dev_info->rq, true);
> > +   blk_mq_kick_requeue_list(rinfo->dev_info->rq);
> > +   }
> >  }
> >  
> >  static void kick_pending_request_queues(struct blkfront_ring_info *rinfo)
> > @@ -1225,7 +1227,8 @@ static void kick_pending_request_queues(struct 
> > blkfront_ring_info *rinfo)
> > unsigned long flags;
> >  
> > spin_lock_irqsave(&rinfo->ring_lock, flags);
> > -   kick_pending_request_queues_locked(rinfo);
> > +   if (!RING_FULL(&rinfo->ring))
> > +   blk_mq_run_hw_queues(rinfo->dev_info->rq, true);
> > spin_unlock_irqrestore(&rinfo->ring_lock, flags);
> >  }
> 
> Why do some kick_pending_request_queues_locked() kick the requeue list and why
> has the above kick_pending_request_queues_locked() call been converted into a
> blk_mq_run_hw_queues() call and thereby ignores the requeue list?

Looks I forget to reply the question about requeue list.

Actually blk_mq_kick_requeue_list() is only needed run where the
queue is restarted, so this patch moves it after
blk_mq_start_stopped_hw_queues().

In other path, we don't stop queue anymore, so needn't to kick requeue
list.

-- 
Ming

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

[Xen-devel] [PATCH 1/6] xen-blkfront: avoid to use start/stop queue

[Ming Lei]

This interfaces will be removed soon, so use quiesce and
unquiesce instead, which should be more safe.

The only one usage will be removed in the following
congestion control patches.

Cc: Konrad Rzeszutek Wilk 
Cc: "Roger Pau Monné" 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Ming Lei 
---
 drivers/block/xen-blkfront.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index c852ed3c01d5..1578befda635 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1187,7 +1187,7 @@ static void xlvbd_release_gendisk(struct blkfront_info 
*info)
return;
 
/* No more blkif_request(). */
-   blk_mq_stop_hw_queues(info->rq);
+   blk_mq_quiesce_queue(info->rq);
 
for (i = 0; i < info->nr_rings; i++) {
struct blkfront_ring_info *rinfo = &info->rinfo[i];
@@ -1216,8 +1216,10 @@ static void xlvbd_release_gendisk(struct blkfront_info 
*info)
 /* Already hold rinfo->ring_lock. */
 static inline void kick_pending_request_queues_locked(struct 
blkfront_ring_info *rinfo)
 {
-   if (!RING_FULL(&rinfo->ring))
+   if (!RING_FULL(&rinfo->ring)) {
blk_mq_start_stopped_hw_queues(rinfo->dev_info->rq, true);
+   blk_mq_kick_requeue_list(rinfo->dev_info->rq);
+   }
 }
 
 static void kick_pending_request_queues(struct blkfront_ring_info *rinfo)
@@ -1225,7 +1227,8 @@ static void kick_pending_request_queues(struct 
blkfront_ring_info *rinfo)
unsigned long flags;
 
spin_lock_irqsave(&rinfo->ring_lock, flags);
-   kick_pending_request_queues_locked(rinfo);
+   if (!RING_FULL(&rinfo->ring))
+   blk_mq_run_hw_queues(rinfo->dev_info->rq, true);
spin_unlock_irqrestore(&rinfo->ring_lock, flags);
 }
 
@@ -1346,7 +1349,7 @@ static void blkif_free(struct blkfront_info *info, int 
suspend)
BLKIF_STATE_SUSPENDED : BLKIF_STATE_DISCONNECTED;
/* No more blkif_request(). */
if (info->rq)
-   blk_mq_stop_hw_queues(info->rq);
+   blk_mq_quiesce_queue(info->rq);
 
for (i = 0; i < info->nr_rings; i++)
blkif_free_ring(&info->rinfo[i]);
@@ -2018,22 +2021,13 @@ static int blkif_recover(struct blkfront_info *info)
/* Now safe for us to use the shared ring */
info->connected = BLKIF_STATE_CONNECTED;
 
-   for (r_index = 0; r_index < info->nr_rings; r_index++) {
-   struct blkfront_ring_info *rinfo;
-
-   rinfo = &info->rinfo[r_index];
-   /* Kick any other new requests queued since we resumed */
-   kick_pending_request_queues(rinfo);
-   }
-
list_for_each_entry_safe(req, n, &info->requests, queuelist) {
/* Requeue pending requests (flush or discard) */
list_del_init(&req->queuelist);
BUG_ON(req->nr_phys_segments > segs);
blk_mq_requeue_request(req, false);
}
-   blk_mq_start_stopped_hw_queues(info->rq, true);
-   blk_mq_kick_requeue_list(info->rq);
+   blk_mq_unquiesce_queue(info->rq);
 
while ((bio = bio_list_pop(&info->bio_list)) != NULL) {
/* Traverse the list of pending bios and re-queue them */
-- 
2.9.4


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

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: avoid to use start/stop queue

[Bart Van Assche]

On Wed, 2017-07-12 at 02:20 +0800, Ming Lei wrote:
> This interfaces will be removed soon, so use quiesce and
> unquiesce instead, which should be more safe.
> 
> The only one usage will be removed in the following
> congestion control patches.

Hello Ming,

The title of this patch is misleading since this patch does not touch the calls
related to queue congestion (blk_mq_stop_hw_queue() and
blk_mq_start_stopped_hw_queues()). I assume that you meant that this patch 
avoids
that the xen-blkfront driver uses blk_mq_(start|stop)_hw_queues() (with queues 
in
plural form)? Can you please reflect that in the subject of this and related
patches?

Additionally, it's probably a good idea that this is not just an interface 
change
but that this kind of patches fix a (hard to trigger?) race condition.

>  static inline void kick_pending_request_queues_locked(struct 
> blkfront_ring_info *rinfo)
>  {
> - if (!RING_FULL(&rinfo->ring))
> + if (!RING_FULL(&rinfo->ring)) {
>   blk_mq_start_stopped_hw_queues(rinfo->dev_info->rq, true);
> + blk_mq_kick_requeue_list(rinfo->dev_info->rq);
> + }
>  }
>  
>  static void kick_pending_request_queues(struct blkfront_ring_info *rinfo)
> @@ -1225,7 +1227,8 @@ static void kick_pending_request_queues(struct 
> blkfront_ring_info *rinfo)
>   unsigned long flags;
>  
>   spin_lock_irqsave(&rinfo->ring_lock, flags);
> - kick_pending_request_queues_locked(rinfo);
> + if (!RING_FULL(&rinfo->ring))
> + blk_mq_run_hw_queues(rinfo->dev_info->rq, true);
>   spin_unlock_irqrestore(&rinfo->ring_lock, flags);
>  }

Why do some kick_pending_request_queues_locked() kick the requeue list and why
has the above kick_pending_request_queues_locked() call been converted into a
blk_mq_run_hw_queues() call and thereby ignores the requeue list?

Thanks,

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf e508e069a809ba895230ef6ea5c8d43c471d0de4
baseline version:
 ovmf 9750503a116be3c246b249b1e7d7d9c51aae2a03

Last test of basis71680  2017-07-11 12:19:35 Z0 days
Testing same since71682  2017-07-12 03:20:15 Z0 days1 attempts


People who touched revisions under test:
  Brijesh Singh 
  Jordan Justen 
  Laszlo Ersek 
  Liming Gao 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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


Push not applicable.

(No revision log; it would be 391 lines long.)

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

Re: [Xen-devel] Lots of new warnings with gcc-7.1.1

[Marcel Holtmann]

Hi Linus,

> At the same time, others aren't quite as insane, and in many cases the
> warnings might be easy to just fix.
> 
> And some actually look valid, although they might still require odd input:
> 
>  net/bluetooth/smp.c: In function ‘le_max_key_size_read’:
>  net/bluetooth/smp.c:3372:29: warning: ‘snprintf’ output may be
> truncated before the last format character [-Wformat-truncation=]
>snprintf(buf, sizeof(buf), "%2u\n", SMP_DEV(hdev)->max_key_size);
>   ^~~
>  net/bluetooth/smp.c:3372:2: note: ‘snprintf’ output between 4 and 5
> bytes into a destination of size 4
> 
> yeah, "max_key_size" is unsigned char, but if it's larger than 99 it
> really does need 5 bytes for "%2u\n" with the terminating NUL
> character.
> 
> Of course, the "%2d" implies that people expect it to be < 100, but at
> the same time it doesn't sound like a bad idea to just make the buffer
> be one byte bigger. So..

the Bluetooth specification defines that the Maximum Encryption Key Size shall 
be in the range 7 to 16 octets. Which is also reflected in these defines:

#define SMP_MIN_ENC_KEY_SIZE7
#define SMP_MAX_ENC_KEY_SIZE16

So it is buf[4] since we know it never gets larger than 16. So even in this 
case the warning is bogus.

I have no problem in increasing it to buf[5] to shut up the compiler, but that 
is what I would be doing here. I am not fixing an actual bug.

> Anyway, it would be lovely if some of the more affected developers
> would take a look at gcc-7.1.1 warnings. Right now I get about three
> *thousand* lines of warnings from a "make allmodconfig" build, which
> makes them a bit overwhelming.
> 
> I do suspect I'll make "-Wformat-truncation" (as opposed to
> "-Wformat-overflow") be a "V=1" kind of warning.  But let's see how
> many of these we can fix, ok?

I had to use the -Wno-format-trunction in a few projects since gcc was 
completely lost. And since we were using snprintf, I saw no point in trying to 
please gcc with a larger buffer.

Regards

Marcel


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

Re: [Xen-devel] Lots of new warnings with gcc-7.1.1

[Jakub Kicinski]

On Tue, 11 Jul 2017 15:35:15 -0700, Linus Torvalds wrote:
> I do suspect I'll make "-Wformat-truncation" (as opposed to
> "-Wformat-overflow") be a "V=1" kind of warning.  But let's see how
> many of these we can fix, ok?

Somehow related - what's the stand on -Wimplicit-fallthrough?  I run
into the jump tables in jhash.h generating lots of warnings.  Is it OK
to do this?

--->8--

diff --git a/include/linux/jhash.h b/include/linux/jhash.h
index 348c6f47e4cc..f6d6513a4c03 100644
--- a/include/linux/jhash.h
+++ b/include/linux/jhash.h
@@ -85,20 +85,19 @@ static inline u32 jhash(const void *key, u32 length, u32 
initval)
k += 12;
}
/* Last block: affect all 32 bits of (c) */
-   /* All the case statements fall through */
switch (length) {
-   case 12: c += (u32)k[11]<<24;
-   case 11: c += (u32)k[10]<<16;
-   case 10: c += (u32)k[9]<<8;
-   case 9:  c += k[8];
-   case 8:  b += (u32)k[7]<<24;
-   case 7:  b += (u32)k[6]<<16;
-   case 6:  b += (u32)k[5]<<8;
-   case 5:  b += k[4];
-   case 4:  a += (u32)k[3]<<24;
-   case 3:  a += (u32)k[2]<<16;
-   case 2:  a += (u32)k[1]<<8;
-   case 1:  a += k[0];
+   case 12: c += (u32)k[11]<<24;   /* fall through */
+   case 11: c += (u32)k[10]<<16;   /* fall through */
+   case 10: c += (u32)k[9]<<8; /* fall through */
+   case 9:  c += k[8]; /* fall through */
+   case 8:  b += (u32)k[7]<<24;/* fall through */
+   case 7:  b += (u32)k[6]<<16;/* fall through */
+   case 6:  b += (u32)k[5]<<8; /* fall through */
+   case 5:  b += k[4]; /* fall through */
+   case 4:  a += (u32)k[3]<<24;/* fall through */
+   case 3:  a += (u32)k[2]<<16;/* fall through */
+   case 2:  a += (u32)k[1]<<8; /* fall through */
+   case 1:  a += k[0]; /* fall through */
 __jhash_final(a, b, c);
case 0: /* Nothing left to add */
break;
@@ -131,11 +130,11 @@ static inline u32 jhash2(const u32 *k, u32 length, u32 
initval)
k += 3;
}
 
-   /* Handle the last 3 u32's: all the case statements fall through */
+   /* Handle the last 3 u32's */
switch (length) {
-   case 3: c += k[2];
-   case 2: b += k[1];
-   case 1: a += k[0];
+   case 3: c += k[2];  /* fall through */
+   case 2: b += k[1];  /* fall through */
+   case 1: a += k[0];  /* fall through */
__jhash_final(a, b, c);
case 0: /* Nothing left to add */
break;

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

Re: [Xen-devel] [PATCH 5/25] Xen/doc: Add Xen virtual IOMMU doc

[Lan Tianyu]

On 2017年07月08日 00:16, Julien Grall wrote:
> Hi,
> 
> On 06/07/17 07:20, Lan Tianyu wrote:
>> On 2017年07月05日 21:25, Julien Grall wrote:
>>> Furthermore, on ARM we would be able to create the vIOMMU but it would
>>> be unusable. Indeed, IOMMU are only used to protect devices. But you
>>> don't see any way to say "This device is protected by the IOMMU". Did I
>>> miss anything?
>>
>> The "device protection" you mentioned is DMA protection, right?. It's
>> one of IOMMU capabilities. IOMMU also provides interrupt remapping and
>> SVM(Shared virtual memory). I see ARM side also is pushing SVM feature
>> in KVM maillist for native support. Finally, it needs to support SVM in
>> VM and so virtual IOMMU is necessary regardless of full-virtualized or
>> PV IOMMU
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/491614.html
>>
> 
> I don't think SVM is strictly necessary to do DMA protection in the
> guest.

SVM and DMA protection is different features of IOMMU. SVM is to share
same page table(VA->PA) between CPU and GPU or other device in order to
removing overhead to maintain two page table between cpu and device
side. Actually this is also a device feature and more devices will
support SVM besides GPU.

> Not all IOMMUs on ARM are able to use this feature but you may
> still want to allow the guest using the IOMMU. Did I miss anything?

If physical IOMMU doesn't support SVM, vIOMMU device model should not
return SVM capability to tool stack when receive "query capabilities"
cmd. There should be capabilities field in vIOMMU register or ACPI table
for vIOMMU(Not sure ARM side) and SVM capability bit won't be set.
So guest finally won't enable SVM feature.

-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH v2] x86/monitor: Notify monitor if an emulation fails.

[Tamas K Lengyel]

On Tue, Jul 11, 2017 at 8:53 AM, Petre Pircalabu
 wrote:
> If case of a vm_event with the emulate_flags set, if the instruction
> cannot be emulated, the monitor should be notified instead of directly
> injecting a hw exception.
> This behavior can be used to re-execute an instruction not supported by
> the emulator using the real processor (e.g. altp2m) instead of just
> crashing.
>
> Signed-off-by: Petre Pircalabu 
>
> ---
> Changed since v1:
>   * Removed the emulation kind check when calling hvm_inject_hw_exception
> ---
>  tools/libxc/include/xenctrl.h  |   2 +
>  tools/libxc/xc_monitor.c   |  14 ++
>  ...itor-Notify-monitor-if-an-emulation-fails.patch | 212 
> +
>  xen/arch/x86/hvm/emulate.c |   5 +-
>  xen/arch/x86/hvm/monitor.c |  19 ++
>  xen/arch/x86/monitor.c |  12 ++
>  xen/include/asm-x86/domain.h   |   1 +
>  xen/include/asm-x86/hvm/monitor.h  |   1 +
>  xen/include/asm-x86/monitor.h  |   3 +-
>  xen/include/public/domctl.h|   1 +
>  xen/include/public/vm_event.h  |   2 +
>  11 files changed, 270 insertions(+), 2 deletions(-)
>  create mode 100644 
> tools/tests/xen-access/0001-x86-monitor-Notify-monitor-if-an-emulation-fails.patch

I don't think you meant to add this patch file.

Tamas

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

Re: [Xen-devel] [PATCH v1 3/3] xen/livepatch/ARM32: Don't crash on livepatches loaded with wrong alignment.

[Jan Beulich]

>>> Konrad Rzeszutek Wilk  07/11/17 10:34 PM >>>
>On Tue, Jul 11, 2017 at 02:06:09PM -0600, Jan Beulich wrote:
>> >>> Konrad Rzeszutek Wilk  07/11/17 6:53 PM >>>
>> >This issue was observed on ARM32 with a cross compiler for the
>> >livepatches. Mainly the livepatches .data section size was not
>> >aligned to the section alignment:
>> >
>> >ARM32 native:
>> >Contents of section .rodata:
>>  > 68695f66 756e6300 63686563 6b5f666e  hi_func.check_fn
>>  >0010 6300 78656e5f 65787472 615f7665  c...xen_extra_ve
>>  >0020 7273696f 6e00rsion...
>> >
>> >ARM32 cross compiler:
>> >Contents of section .rodata:
>>  > 68695f66 756e6300 63686563 6b5f666e  hi_func.check_fn
>>  >0010 6300 78656e5f 65787472 615f7665  c...xen_extra_ve
>>  >0020 7273696f 6e00rsion.
>> >
>> >And when we loaded it:
>> >
>> >native:
>> >
>> >(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .text at 00a02000
>> >(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .rodata at 
>> >00a04024
>> >(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .altinstructions 
>> >at 00a0404c
>> >
>> >cross compiler:
>> >(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .text at 00a02000
>> >(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .rodata at 
>> >00a04024
>> >(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .altinstructions 
>> >at 00a0404a
>> >
>> >(See 4a vs 4c)
>> >
>> >native readelf:
>>   >[ 4] .rodata   PROGBITS 000164 28 00   A  0   
>> 0  4
>>   >[ 5] .altinstructions  PROGBITS 00018c 0c 00   A  0   
>> 0  1
>> >
>> >cross compiler readelf --sections:
>>   >[ 4] .rodata   PROGBITS 000164 26 00   A  0   
>> 0  4
>>   >[ 5] .altinstructions  PROGBITS 00018a 0c 00   A  0   
>> 0  1
>> >
>> >And as can be seen the .altinstructions have alignment of 1 which from
>> >'man elf' is: "Values of zero and one mean no alignment is required."
>> >which means we can ignore it.
>> >
>> >However ignoring this will result in a crash as when we started processing
>> >".rel.altinstructions" for ".altinstructions" with a cross-compiled payload
>> >we would end up poking in an section that was not aligned properly in memory
>> >and crash.
>> 
>> Which section is it that would not be aligned properly in memory?
>
>.altinstructions, thanks to .rodata not being padded properly.
>
>> .altinstructions, with an alignment of 1, can be placed anywhere. You
>> shouldn't enforce extra alignment. If higher alignment is needed, the
>> code producing this section emission needs to be fixed.
>
>And there is the path to madness :-) We would need to provide an
>linker map to make sure that they are with the correct alignment.

Why? I'd expect it to be the assembler directives creating contributions to
that section to simply lack a .align or alike. And indeed, there's nothing
like that in ARM's alternative.h. Please see commit 01fe4da624 ("x86: force
suitable alignment in sources rather than in linker script") for further
context.

Jan


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

Re: [Xen-devel] RT-Xen on ARM

[Dario Faggioli]

On Fri, 2017-07-07 at 14:29 -0400, Meng Xu wrote:
> On Wed, Jul 5, 2017 at 4:29 AM, Dario Faggioli
>  wrote:
> > 
> The total utilization can help answer if the VCPU parameters are
> feasible or not.
>
I'm just saying that we could keep track of utilization and, if on an
host with N CPUs, we reach more than (N*100)%, we can warn the user
that deadlines will be missed.

This is a simple enough check, and it can live in the hypervisor.

> But I'm thinking there may exist a better (yet optimal) approach to
> answer the question: If all VCPUs on K cores are globally scheduled
> or
> completely partitioned onto each of the K cores, we can use
> Utilization Bound of the EDF scheduling algorithm for checking if the
> VCPU's performance can be safely provided.
> This requires the VCPUs' parameters (which also computes the total
> utilization), which are easy to get.
> 
I know there's math we can use, I'm just saying we don't want that in
Xen.

> Another thing is where this schedulability check should be provided:
> in Xen kernel, in Xen toolstack, or as a separate utility tool?
> In my opinion, a separate utility tool seems to be better than the
> other tool approaches?
> 
Exactly. As said above, you don't put something as complex as that
inside Xen. It can well live in toolstack, IMO, as far as we also add a
(global, non per-domain) for telling whether we want admission or
control not.

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

Re: [Xen-devel] Notes on stubdoms and latency on ARM

[Dario Faggioli]

On Fri, 2017-07-07 at 14:12 -0700, Stefano Stabellini wrote:
> On Fri, 7 Jul 2017, Volodymyr Babchuk wrote:
> > > > 
> > > Since you are using Credit, can you try to disable context switch
> > > rate
> > > limiting?
> >
> > Yep. You are right. In the environment described above (Case 2) I
> > now
> > get much better results:
> > 
> >  real 1.85
> > user 0.00
> > sys 1.85
> 
> From 113 to 1.85 -- WOW!
> 
> Obviously I am no scheduler expert, but shouldn't we advertise a bit
> better a scheduler configuration option that makes things _one
> hundred
> times faster_ ?! 
>
So, to be fair, so far, we've bitten this hard by this only on
artificially constructed test cases, where either some extreme
assumption were made (e.g., that all the vCPUs except one always run at
100% load) or pinning was used in a weird and suboptimal way. And there
are workload where it has been verified that it helps making
performance better (poor SpecVIRT  results without it was the main
motivation having it upstream, and on by default).

That being said, I personally have never liked rate-limiting, it always
looked to me like the wrong solution.

> It's not even mentioned in
> https://wiki.xen.org/wiki/Tuning_Xen_for_Performance!
> 
Well, for sure it should be mentioned here, you're right!

> Also, it is worrying to me that there are cases were, unless the user
> tweaks the configuration, she is going to get 100x worse performance
> out
> of her system.
>
As I said, it's hard to tell in advance whether it will have a good,
bad, or really bad impact on a specific workload.

I'm starting to think, though, that it may be good to switch to having
it off by default, and then document that if the system is going into
trashing because of too frequent context switches, turning it on may
help.

I'll think about it, and see if I'll be able to run some benchmarks
with it on and off.

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

Re: [Xen-devel] [PATCH 04/15] xen: mm: add ioremap_cache

[Jan Beulich]

>>> Julien Grall  07/11/17 10:15 PM >>>
>On 07/09/2017 09:10 AM, Kai Huang wrote:
>> Currently Xen only has non-cacheable version of ioremap. Although EPC is
>> reported as reserved memory in e820 but it can be mapped as cacheable. This
>> patch adds ioremap_cache (cacheable version of ioremap).
>> 
>> Signed-off-by: Kai Huang 
>> ---
>>   xen/arch/x86/mm.c  | 15 +--
>>   xen/include/xen/vmap.h |  1 +
>
>First of all, this is common code and the "REST" maintainers should have 
>been CCed for this include.
>
>But xen/include/xen/vmap.h is common code and going to break ARM. We 
>already have an inline implementation of ioremap_nocache. You should 
>move the definition in x86 specific headers.

Indeed, plus the ARM implementation actually shows how this would better
be done: Have a function allowing more than just true/false to be passed in,
to eventually also allow having ioremap_wc() and alike as wrappers. As long
as it's x86-specific I'd then also suggest calling the new wrapper function
ioremap_wb() (as "cache" may also mean WT).

Jan


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

Re: [Xen-devel] [PATCH v9 1/7] x86/domctl: generalize the restore of vMCE parameters

[Jan Beulich]

>>> Haozhong Zhang  07/12/17 4:05 AM >>>
>+static int vcpu_set_vmce(struct vcpu *v,
>+ const struct xen_domctl_ext_vcpucontext *evc)
>+{
>+/*
>+ * Sizes of vMCE parameters used by the current and past versions
>+ * of Xen in descending order. If vMCE parameters are extended,
>+ * remember to add the old size to this array by VMCE_SIZE().
>+ */
>+#define VMCE_SIZE(field) \
>+(offsetof(typeof(evc->vmce), field) + sizeof(evc->vmce.field))
>+
>+static const unsigned int valid_sizes[] = {
>+sizeof(evc->vmce),
>+VMCE_SIZE(caps),
>+};
>+#undef VMCE_SIZE
>+
>+struct hvm_vmce_vcpu vmce = { };
>+unsigned int evc_vmce_size =
>+min(evc->size - offsetof(typeof(*evc), mcg_cap), sizeof(evc->vmce));

I should have noticed this earlier, and I'll try to remember to adjust this 
while
committing: Instead of mcg_cap we really should be using vmce here, as the
former is there solely for backward compatibility purposes (which this
expression doesn't relate to directly).

Jan


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