[Xen-devel] Can't always start 32 bit domains after 64 bit domains

[Sarah Newman]

Last night on a 288GiB server with less than 64GiB of 32 bit
domUs, we used the standard xendomains script which starts VMs
in alphabetical order.

Some 32 bit domUs at the very end were unable to start. The
error message we received is the following:

xc: error: panic: xc_dom_x86.c:944: arch_setup_meminit: failed to allocate 
0x8 pages: Internal error
xc: error: panic: xc_dom_boot.c:154: xc_dom_boot_mem_init: can't allocate low 
memory for domain: Out of memory
libxl: error: libxl_dom.c:719:libxl__build_pv: xc_dom_boot_mem_init failed: 
Device or resource busy
libxl: error: libxl_create.c:1144:domcreate_rebuild_done: cannot (re-)build 
domain: -3

After shutting down some 64 bit domUs, we could start the remainder
of the 32 bit domUs. Finally we started the rest of the 64 bit
domUs such that everything was booted.

My current understanding is that on a server with more than 168GiB
of memory, I should still be able to around 128GiB of 32-bit PV
domUs, regardless of what order the domUs are started in.

The version of xen we're using is Xen4CentOS 4.6.3-3.

The current workaround plan is to start all the 32-bit domUs
in smallest to largest order, and then all the 64 bit domUs in
smallest to largest order, but we are not 100% confident this will
work long term given it should have worked in the first place.

Is there any other information I can provide to help with duplicating the issue?

Please keep me CC'ed as I am not subscribed to xen-devel right now.

--Sarah

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail REGR. vs. 101909
 test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 101909
 test-amd64-amd64-libvirt 11 guest-start  fail REGR. vs. 101909
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail REGR. vs. 101909
 test-amd64-amd64-libvirt-pair 20 guest-start/debian  fail REGR. vs. 101909
 test-armhf-armhf-xl-vhd   9 debian-di-installfail REGR. vs. 101909
 test-amd64-i386-libvirt-pair 20 guest-start/debian   fail REGR. vs. 101909
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail REGR. vs. 101909
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt  11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt-xsm  11 guest-start  fail REGR. vs. 101909
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install  fail REGR. vs. 101909
 test-armhf-armhf-libvirt 11 guest-start  fail REGR. vs. 101909

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101909
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101909
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 101909
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101909

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuud93b1fb009b64333d324a2fe76fe805f2ac2cda4
baseline version:
 qemuu199a5bde46b0eab898ab1ec591f423000302569f

Last test of basis   101909  2016-11-03 23:21:40 Z   16 days
Failing since101943  2016-11-04 22:40:48 Z   15 days   33 attempts
Testing same since   102436  2016-11-19 22:13:58 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Ankit Kumar 
  ann.zhuangyany...@huawei.com
  Ashijeet Acharya 
  Balbir singh 
  Bharata B Rao 
  Brian Candler 
  Christian Borntraeger 
  Cornelia Huck 
  Cédric Le Goater 
  Daniel Oram 
  Daniel P. Berrange 
  David Gibson 
  Doug Evans 
  Eduardo Habkost 
  Eric Blake 
  Fam Zheng 
  Gautham R. Shenoy 
  Gerd Hoffmann 
  Gonglei 
  Greg Kurz 
  Halil Pasic 
  Igor Mammedov 
  Jason Wang 
  Jeff Cody 
  John Snow 
  Jose Ricardo Ziviani 
  Juan Quintela 
  Julian Brown 
  Kevin Wolf 
  Ladi Prosek 
  Laurent Vivier 
  Li Qiang 
  Marc-André Lureau 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd 14 leak-check/checkfail REGR. vs. 68055

Regressions which are regarded as allowable (not blocking):
 test-xtf-amd64-amd64-1   10 xtf-fep  fail blocked in 68055
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 68055
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   like 68055
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 68055
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   like 68055
 test-xtf-amd64-amd64-2   10 xtf-fep  fail   like 68055
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 68055
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   like 68055
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 68055
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68055

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   6 xen-buildfail   never pass
 build-i386-rumprun6 xen-buildfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  58bd0c7985890e0292212f94a56235228a3445c3
baseline version:
 xen  160e12899212f6f666fe38781fc5911fe9f8ad35

Last test of basis68055  2016-11-17 17:16:59 Z2 days
Testing same since68067  2016-11-19 16:16:36 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  David Vrabel 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail REGR. vs. 101909
 test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 101909
 test-amd64-amd64-libvirt 11 guest-start  fail REGR. vs. 101909
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail REGR. vs. 101909
 test-amd64-amd64-libvirt-pair 20 guest-start/debian  fail REGR. vs. 101909
 test-armhf-armhf-xl-vhd   9 debian-di-installfail REGR. vs. 101909
 test-amd64-i386-libvirt-pair 20 guest-start/debian   fail REGR. vs. 101909
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail REGR. vs. 101909
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt  11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt-xsm  11 guest-start  fail REGR. vs. 101909
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install  fail REGR. vs. 101909
 test-armhf-armhf-libvirt 11 guest-start  fail REGR. vs. 101909

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 102396 pass in 
102412
 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail in 102396 pass in 
102412
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail pass in 102396

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101909
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101909
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101909

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuub0bcc86d2a87456f5a276f941dc775b265b309cf
baseline version:
 qemuu199a5bde46b0eab898ab1ec591f423000302569f

Last test of basis   101909  2016-11-03 23:21:40 Z   15 days
Failing since101943  2016-11-04 22:40:48 Z   14 days   32 attempts
Testing same since   102290  2016-11-16 07:12:21 Z3 days   10 attempts


People who touched revisions under test:
  Alberto Garcia 
  Ankit Kumar 
  ann.zhuangyany...@huawei.com
  Ashijeet Acharya 
  Balbir singh 
  Bharata B Rao 
  Brian Candler 
  Christian Borntraeger 
  Cornelia Huck 
  Cédric Le Goater 
  Daniel Oram 
  Daniel P. Berrange 
  David Gibson 
  Doug Evans 
  Eduardo Habkost 
  Eric Blake 
  Fam Zheng 
  Gautham R. Shenoy 
  Gerd Hoffmann 
  Gonglei 
  Greg Kurz 
  Halil Pasic 
  Jason Wang 
  Jeff Cody 
  John Snow 
  Jose Ricardo Ziviani 
  Juan Quintela 
  Julian Brown 

Re: [Xen-devel] [PATCH v3 for-4.8] tools/configure: fix pkg-config install path for FreeBSD

[Alexander Nusov]

Hello,



I've reinstalled xen from ports on FreeBSD-11.0

and it seems xenlight.pc is not being installed to 
/usr/local/libdata/pkgconfig/ directory.



root@controller:/usr/ports/devel/libvirt # find /usr/ -type f -name xenlight.pc
/usr/local/share/pkgconfig/xenlight.pc
root@controller:/usr/ports/devel/libvirt #

Name  : xen
Version : 4.7.0_2

Name  : xen-tools
Version : 4.7.0_4

could you apply this fix for FreeBSD ports tree please?

original issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213744


--

Thanks,

Alex




 On Wed, 26 Oct 2016 15:02:15 +0300Wei Liu wei.l...@citrix.com 
wrote 




On Tue, Oct 25, 2016 at 02:26:55PM +0100, Wei Liu wrote: 

 On Tue, Oct 25, 2016 at 11:53:28AM +0200, Roger Pau Monne wrote: 

  pkg-config from FreeBSD ports doesn't have ${prefix}/share/pkgconfig 
in the 

  default search path, fix this by having a PKG_INSTALLDIR variable 
that can 

  be changed on a per-OS basis. 

  

  It would be best to use PKG_INSTALLDIR as defined by the pkg.m4 
macro, but 

  sadly this also reports a wrong value on FreeBSD 
(${libdir}/pkgconfig, which 

  expands to /usr/local/lib/pkgconfig by default, and is also _not_ 
part of 

  the default pkg-config search path). 

  

  This patch should not change the behavior for Linux installs. 

  

  Signed-off-by: Roger Pau Monné roger@citrix.com 

  Reported-by: Alexander Nusov alexander.nu...@nfvexpress.com 

 

 Acked-by: Wei Liu wei.l...@citrix.com 

 

Applied. 






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

[Xen-devel] [PATCH] xen-scsifront: Add a missing call to kfree

[Quentin Lambert]

Most error branches following the call to kmalloc contain
a call to kfree. This patch add these calls where they are
missing.

This issue was found with Hector.

Signed-off-by: Quentin Lambert 

---
 drivers/scsi/xen-scsifront.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/scsi/xen-scsifront.c
+++ b/drivers/scsi/xen-scsifront.c
@@ -627,6 +627,7 @@ static int scsifront_action_handler(stru
 
if (scsifront_enter(info)) {
spin_unlock_irq(host->host_lock);
+   kfree(shadow);
return FAILED;
}
 

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

Re: [Xen-devel] [PATCH v3 (re-send)] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

[Hugh Dickins]

On Fri, 18 Nov 2016, Boris Ostrovsky wrote:
> On 11/18/2016 04:51 PM, Hugh Dickins wrote:
> > Hmm, sorry, but this seems overcomplicated to me: ingenious, but an
> > unusual use of the ->get_policy method, which is a little worrying,
> > since it has only been used for shmem (+ shm and kernfs) until now.
> >
> > Maybe I'm wrong, but wouldn't substituting VM_MIXEDMAP for VM_IO
> > solve the problem more simply?
> 
> It would indeed. I didn't want to use it because it has specific meaning
> ("Can contain "struct page" and pure PFN pages") and that didn't seem
> like the right flag to describe this vma.

It is okay if it contains 0 pure PFN pages; and no worse than VM_IO was.
A comment on why VM_MIXEDMAP is being used there would certainly be good.
But I do find its use preferable to enlisting an unusual ->get_policy.

Hugh

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

Re: [Xen-devel] [PATCH v3 (re-send)] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

[Hugh Dickins]

On Thu, 17 Nov 2016, Boris Ostrovsky wrote:

> Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
> NUMA balancing") set VM_IO flag to prevent grant maps from being
> subjected to NUMA balancing.
> 
> It was discovered recently that this flag causes get_user_pages() to
> always fail with -EFAULT.
> 
> check_vma_flags
> __get_user_pages
> __get_user_pages_locked
> __get_user_pages_unlocked
> get_user_pages_fast
> iov_iter_get_pages
> dio_refill_pages
> do_direct_IO
> do_blockdev_direct_IO
> do_blockdev_direct_IO
> ext4_direct_IO_read
> generic_file_read_iter
> aio_run_iocb
> 
> (which can happen if guest's vdisk has direct-io-safe option).
> 
> To avoid this don't use vm_flags. Instead, use mempolicy that prohibits
> page migration (i.e. clear MPOL_F_MOF|MPOL_F_MORON) and make sure we
> don't consult task's policy (which may include those flags) if vma
> doesn't have one.
> 
> Reported-by: Olaf Hering 
> Signed-off-by: Boris Ostrovsky 
> Cc: sta...@vger.kernel.org

Hmm, sorry, but this seems overcomplicated to me: ingenious, but an
unusual use of the ->get_policy method, which is a little worrying,
since it has only been used for shmem (+ shm and kernfs) until now.

Maybe I'm wrong, but wouldn't substituting VM_MIXEDMAP for VM_IO
solve the problem more simply?

Hugh

> ---
> 
> Mis-spelled David's address.
> 
> Changes in v3:
> * Don't use __mpol_dup() and get_task_policy() which are not exported
>   for use by drivers. Add vm_operations_struct.get_policy().
> * Copy to stable
> 
> 
>  drivers/xen/gntdev.c |   27 ++-
>  1 files changed, 26 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index bb95212..632edd4 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -433,10 +434,28 @@ static void gntdev_vma_close(struct vm_area_struct *vma)
>   return map->pages[(addr - map->pages_vm_start) >> PAGE_SHIFT];
>  }
>  
> +#ifdef CONFIG_NUMA
> +/*
> + * We have this op to make sure callers (such as vma_policy_mof()) don't
> + * check current task's policy which may include migrate flags (MPOL_F_MOF
> + * or MPOL_F_MORON)
> + */
> +static struct mempolicy *gntdev_vma_get_policy(struct vm_area_struct *vma,
> +unsigned long addr)
> +{
> + if (mpol_needs_cond_ref(vma->vm_policy))
> + mpol_get(vma->vm_policy);
> + return vma->vm_policy;
> +}
> +#endif
> +
>  static const struct vm_operations_struct gntdev_vmops = {
>   .open = gntdev_vma_open,
>   .close = gntdev_vma_close,
>   .find_special_page = gntdev_vma_find_special_page,
> +#ifdef CONFIG_NUMA
> + .get_policy = gntdev_vma_get_policy,
> +#endif
>  };
>  
>  /* -- */
> @@ -1007,7 +1026,13 @@ static int gntdev_mmap(struct file *flip, struct 
> vm_area_struct *vma)
>  
>   vma->vm_ops = _vmops;
>  
> - vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP | VM_IO;
> + vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
> +
> +#ifdef CONFIG_NUMA
> + /* Prevent NUMA balancing */
> + if (vma->vm_policy)
> + vma->vm_policy->flags &= ~(MPOL_F_MOF | MPOL_F_MORON);
> +#endif
>  
>   if (use_ptemod)
>   vma->vm_flags |= VM_DONTCOPY;
> -- 
> 1.7.1
> 
> 

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

Re: [Xen-devel] [PATCH v3 (re-send)] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

[Hugh Dickins]

On Fri, 18 Nov 2016, Boris Ostrovsky wrote:
> On 11/18/2016 05:27 PM, Hugh Dickins wrote:
> > On Fri, 18 Nov 2016, Boris Ostrovsky wrote:
> >> On 11/18/2016 04:51 PM, Hugh Dickins wrote:
> >>> Hmm, sorry, but this seems overcomplicated to me: ingenious, but an
> >>> unusual use of the ->get_policy method, which is a little worrying,
> >>> since it has only been used for shmem (+ shm and kernfs) until now.
> >>>
> >>> Maybe I'm wrong, but wouldn't substituting VM_MIXEDMAP for VM_IO
> >>> solve the problem more simply?
> >> It would indeed. I didn't want to use it because it has specific meaning
> >> ("Can contain "struct page" and pure PFN pages") and that didn't seem
> >> like the right flag to describe this vma.
> > It is okay if it contains 0 pure PFN pages; and no worse than VM_IO was.
> > A comment on why VM_MIXEDMAP is being used there would certainly be good.
> > But I do find its use preferable to enlisting an unusual ->get_policy.
> 
> OK, I'll set VM_MIXEDMAP then.

Thanks, if it accomplishes what you need, then please do use it.

> 
> I am still curious though why you feel get_policy is not appropriate
> here (beside the fact that so far it had limited use). It is essentially
> trying to say that the only policy to be consulted (in vma_policy_mof())
> is of the vma itself and not of the task.

I agree that get_policy is explicitly about NUMA, and so relevant to the
matter of (discouraging) NUMA balancing, without any apology needed.

But there are no other examples of its use that way, it's been something
private to shmem (hence shm and kernfs) up until now: the complement of
set_policy, which implements the mbind() syscall on shmem objects.

Introduce an exceptional new usage, and we're likely to introduce bugs
(not to mention the long history of bugs in mpol_dup() that you also use).
Perhaps I'd find one already if I took the time to study your patch.

Full disclosure: I'm also contemplating a change to its interface,
to handle a possible NUMA interleave issue, so I do need to keep
an eye on all its callers.

If we have to choose between two less-than-ideal solutions,
please let's choose the simplest.

Hugh

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

Re: [Xen-devel] [COVERITY ACCESS] for Embedded/Automotive team

[Lars Kurth]

On 18/11/2016 20:55, "Julien Grall"  wrote:

>Hello,
>
>On 18/11/2016 09:28, Konrad Rzeszutek Wilk wrote:
>> On Fri, Nov 18, 2016 at 01:56:38PM +, Andrew Cooper wrote:
>>> On 18/11/16 13:36, Artem Mygaiev wrote:
 Hello

 I would like to request access to Coverity Scan project. Hereby, I:
  - agree to follow the security response process.
  - undertake to report security issues discovered to the security team
 (secur...@xenproject.org) within 3 days of discovery.
  - agree to disclose the issue only to the security team and not to
 any other third party
  - waive their (security team) right to select the disclosure time
 line. Discoveries will follow the default time lines given in the
 policy.

 We work with Xen on ARM since 2012. Our primary goal is to introduce
 Xen for embedded and in particular in automotive SW domains. Our
 current activities are: ARM-based SoCs support (Renesas, TI, etc.), PV
 drivers development (audio, video, input, etc.), co-processors support
 and trusted environment support through OP-TEE integration. All of our
 work is public and published in OSS mailing lists. We would like to
 contribute in stability of Xen overall and Xen on ARM in particular
 since this is absolutely critical for most of embedded applications.
>>>
>>> I don't have an objection in principle.  However, I doubt you will find
>>> access useful.
>>>
>>> Because of the restriction of only being permitted a single Coverity
>>> stream, it is only the x86 build which is submitted for analysis.  To
>>> submit builds for separate architectures, we need alternative streams.
>>> I already requested this but the request was denied.
>>
>> Perhaps Artem doing it - along with linking to this thread could
>> sway their minds? (Hi Coverity folks!)
>
>Coverity has been proven useful on x86 to catch some bugs. A such things
>would be nice for ARM too. Is there anything we can do to get coverity
>testing ARM? (CC Lars).

Coverity does static code analysis. It analyses our entire tree, although
I don't know whether we updated it to point it to new repos such as the
mini-os one. 

>> +1 on the request.
>
>In the current state and regardless whether coverity supports ARM, I
>would lean towards -1 on the request.
>
>I would prefer to give coverity access to developer that have
>established contribution on Xen ARM upstream.
>
>Artem, in the mail subject you mentioned "Embedded/Automotive team".
>Does it mean you are requesting coverity access for all the team?
>
>Regards,
>
>[1] 
>https://www.xenproject.org/developers/teams/embedded-and-automotive.html
>
>-- 
>Julien Grall

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

Re: [Xen-devel] Opinions on removing the old, legacy libvirt Xen driver

[Wei Liu]

On Fri, Nov 18, 2016 at 02:25:18PM -0700, Jim Fehlig wrote:
> Hi All,
> 
> I briefly mentioned this at an evening event during the KVM Forum / Xen Dev
> Summit, but the list is certainly a better place to discuss such a topic.
> What do folks think about finally removing the old, legacy, xend-based
> driver from the libvirt sources?
> 
> The Xen community made xl/libxl the primary toolstack in Xen 4.1. In Xen
> 4.2, it was made the default toolstack. In Xen 4.5, xm/xend was completely
> removed from the Xen source tree. According to the Xen release support
> matrix [0], upstream maintenance of Xen 4.1-4.3 has been dropped for some
> time, including "long term" security support. Xen 4.4-4.5 no longer receive
> regular maintenance support, with security support ending in March for 4.4
> and January 2018 for 4.5. In short, the fully maintained upstream Xen
> releases don't even contain xm/xend :-).
> 
> As for downstreams, I doubt anyone is interested in running the last several
> libvirt releases on an old Xen installition with xm/xend, let alone
> libvirt.git master. SUSE, which still supports Xen, has no interest in using
> a new libvirt on older (but still supported) SLES that uses the xm/xend
> toolstack. I struggle to find a good reason to keep any of the old cruft
> under src/xen/. I do think we should keep the xm/sexpr config
> parsing/formatting code src/xenconfig/ since it is useful for converting old
> xm and sexpr config to libvirt domXML.
> 
> Thanks for opinions and comments!

FWIW I agree with your analysis.

Wei.

> 
> Regards,
> Jim
> 
> [0] https://wiki.xenproject.org/wiki/Xen_Project_Release_Features
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail in 102393 pass in 
102408
 test-amd64-i386-qemut-rhel6hvm-intel 9 redhat-install fail in 102393 pass in 
102408
 test-armhf-armhf-xl-xsm  14 guest-stop fail pass in 102393
 test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat  fail pass in 102393

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 102372
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102372
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 102372
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 102372
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102372
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 102372
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 102372
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 102372
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102372

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  58bd0c7985890e0292212f94a56235228a3445c3
baseline version:
 xen  160e12899212f6f666fe38781fc5911fe9f8ad35

Last test of basis   102372  2016-11-18 02:00:22 Z1 days
Testing same since   102393  2016-11-18 18:15:16 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  David Vrabel 

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

Re: [Xen-devel] Wondering about cirris and stdvga

[Pasi Kärkkäinen]

On Fri, Nov 18, 2016 at 07:04:15PM +0100, Dario Faggioli wrote:
> Sending again, this time, with Anthony's and xen-devel address spelled
> right. Sorry!! :-(
> ---
> Hello to you, various pseudo-random people,
> 
> It's not my field of expertise, so bear with me, at least a little bit
> (and, Konrad, you help me, or there will be consequences! :-D)
> 
> So, I and Konrad recently discovered --while testing the about to be
> released Fedora 25 as a Xen guest-- that the Cirrus emulated graphic
> card that we consume from QEMU for HVM guests is broken on Wayland.
> 
> We just discovered it because Fedora 25 uses Wayland by default, but it
> appears not to be something new:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1227770
> 
> And at least from what we see in that bugreport, not much has happened
> so far.
> 
> Using "vga='stdvga'" in the config file, or even "vga='qxl'" make
> things work again. Disabling Wayland in the guest also works (i.e., if
> not using Wayland, Cirrus is ok). And that's what made us think that
> it's probably a Wayland issue.
> 
> I've tried the same on KVM, and the situation is identical
> (Cirrus+Wayland=breaks, whatever-else+Wayland=works,
> Cirrus+Xorg=works).
> 
> I've also read around that these days, e.g., stdvga is at least as good
> as cirrus, performance wise, that cirrus is broken and impossible to
> fix (because it is the hardware that it's emulating that was broken),
> that stdvga enables better screen resolution in guests, etc.
> 
> I'm not sure about these claims, in particular the performance one, is
> probably pretty hard to verify. And as I said, it's not my field.
> 
> Still I thought it could be worthwhile to at least bring this up:
> should we start to consider changing the default from cirrus to stdvga
> (or something else)?
> 

There's multiple things here..

1) Yes, +1, let's change the Xen HVM default to "stdvga".

2) It'd good to create an upstream Wayland bugreport and investigate more about 
why cirrus is broken with Wayland.

3) It'd be good to have Xen HVM with "qxl" tested by OSStest aswell..


> Thanks for your time and Regards,
> Dario


Thanks,

-- Pasi


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

Re: [Xen-devel] Define a new Wiki part for Xen Project.

[Jason Long]

I'm thankful if you working on Xen Wiki more and thinking about interested 
beginners like us. If you did anything please email me.

Thank you.



On Friday, November 18, 2016 3:16 PM, Dario Faggioli 
 wrote:
On Fri, 2016-11-18 at 10:25 +, Jason Long wrote:
> Hello developers.
> I have a request and please let me know your idea.
> Can Xen experts define a new part on Wiki about Xen developing for
> beginners? I mean is something like "
> kernelnewbies.org" but for Xen. 
>
Yeah, that indeed could be nice.


> For example, say to users which programming languages are necessary,
> which book is good for learning those languages and which part of Xen
> codes are good for start.
>
Well, sure. A full-fledged program like kernelnewbies is way more than
that, and is not easy to put together.

For what it's worth, we already try to participate to programs like
Outreacy and GSOC, but certainly we can improve some of the sections of
our wiki with what you say in mind --e.g., the one(s) when we try to
keep a list of small projects.

I'll try to find some time to look into this and do something.

Thanks for your interest and suggestion.

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

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

Re: [Xen-devel] Define a new Wiki part for Xen Project.

[Jason Long]

I guess it is an old book!!! Is it OK in your idea? just C Programming needed?



On Friday, November 18, 2016 1:41 PM, Konrad Rzeszutek Wilk 
 wrote:
On Fri, Nov 18, 2016 at 08:45:44PM +, Jason Long wrote:
> Thank you.
> If you find amy book or other useful information then inform me.

About C?

I would recommend The C Programming Language by 
Brian W. Kernighan, Dennis M. Ritchie

> 
> On Fri, 11/18/16, Geza Gemes  wrote:
> 
>  Subject: Re: [Xen-devel] Define a new Wiki part for Xen Project.
>  To: xen-devel@lists.xen.org
>  Date: Friday, November 18, 2016, 7:22 AM
>  
>  On 11/18/2016 11:25 AM,
>  Jason Long wrote:
>  > Hello developers.
>  > I have a request and please let me know
>  your idea.
>  > Can Xen experts define a new
>  part on Wiki about Xen developing for beginners? I mean is
>  something like "
>  >
>  kernelnewbies.org" but for Xen. For example, say to
>  users which programming languages are necessary, which book
>  is good for learning those languages and which part of Xen
>  codes are good for start.
>  > I know it may
>  funny for someone here or smeone consider the questions like
>  it as Spam but be sure it help begginers and other users for
>  improve Xen and get involved to project.
>  > I like to hear developers idea.
>  >
>  > Thank you.
>  >
>  >
>  ___
>  > Xen-devel mailing list
>  > Xen-devel@lists.xen.org
>  > https://lists.xen.org/xen-devel
>  
>  Hi,
>  
>  As a xennewby I definitely support your
>  idea!
>  
>  Cheers,

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

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

[Xen-devel] [distros-debian-stretch test] 68065: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-armhf-stretch-netboot-pygrub 9 debian-di-install fail like 
68028
 test-amd64-i386-amd64-stretch-netboot-pygrub 9 debian-di-install fail like 
68028
 test-amd64-amd64-amd64-stretch-netboot-pvgrub 9 debian-di-install fail like 
68028
 test-amd64-i386-i386-stretch-netboot-pvgrub 9 debian-di-install fail like 68028
 test-amd64-amd64-i386-stretch-netboot-pygrub 9 debian-di-install fail like 
68028

baseline version:
 flight   68028

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-stretch-netboot-pvgrubfail
 test-amd64-i386-i386-stretch-netboot-pvgrub  fail
 test-amd64-i386-amd64-stretch-netboot-pygrub fail
 test-armhf-armhf-armhf-stretch-netboot-pygrubfail
 test-amd64-amd64-i386-stretch-netboot-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] [libvirt test] 102404: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  3 host-install(3)  broken REGR. vs. 102375
 test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail REGR. vs. 102375

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102375
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 102375
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 102375

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  f2bf5fbb04494a0635cbc690c083b844876aa4a6
baseline version:
 libvirt  135e77d32fe9e7299f5c82757563e5a6d28e2f3c

Last test of basis   102375  2016-11-18 04:25:18 Z1 days
Testing same since   102404  2016-11-19 04:23:07 Z0 days1 attempts


People who touched revisions under test:
  Martin Kletzander 

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



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

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

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

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

broken-step test-armhf-armhf-libvirt-qcow2 host-install(3)

Not pushing.


commit f2bf5fbb04494a0635cbc690c083b844876aa4a6
Author: Martin Kletzander 
Date:   Fri Nov 18 08:12:12 2016 +0100

Fix scheduler support check

Commit 94cc577807ba tried fixing build on systems that did not have
SCHED_BATCH or SCHED_IDLE defined.  But instead of changing it to
conditional support, it rather completely disabled the support for
setting any scheduler.  Since then, such old systems are not
supported, but rather than reverting that commit, let's