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

2016-09-02 Thread osstest service owner
flight 100743 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100743/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 72092534a9283291edd6b497c9aa934049c4b928
baseline version:
 ovmf 646a9e5b799b009426fe37af7ac8528a98cc96ce

Last test of basis   100739  2016-09-02 22:14:43 Z0 days
Testing same since   100743  2016-09-03 03:47:36 Z0 days1 attempts


People who touched revisions under test:
  Giri P Mudusuru 
  Mudusuru, Giri P 

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=72092534a9283291edd6b497c9aa934049c4b928
+ . ./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 
72092534a9283291edd6b497c9aa934049c4b928
+ branch=ovmf
+ revision=72092534a9283291edd6b497c9aa934049c4b928
+ . ./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.7-testing
+ '[' x72092534a9283291edd6b497c9aa934049c4b928 = 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/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

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

2016-09-02 Thread Platform Team regression test user
This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 646a9e5b799b009426fe37af7ac8528a98cc96ce
baseline version:
 ovmf 0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3

Last test of basis67630  2016-09-02 21:47:42 Z0 days
Testing same since67631  2016-09-03 03:48:54 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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 646a9e5b799b009426fe37af7ac8528a98cc96ce
Author: Ard Biesheuvel 
Date:   Wed Aug 31 16:35:57 2016 +0100

ArmVirtPkg: remove now unused PciHostBridgeDxe

This code is now no longer used, so remove it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65

commit 9d64ac2369673607a8d5d1339e05d45723efc496
Author: Ard Biesheuvel 
Date:   Sun Aug 21 18:51:04 2016 +0200

ArmVirtPkg/FdtPciHostBridgeLib: add MMIO64 support

If the pci-host-ecam-generic DT node describes a 64-bit MMIO region,
account for it in the PCI_ROOT_BRIDGE description that we return to
the generic PciHostBridgeDxe implementation, which will be able to
allocate BARs from it without any further changes.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65

commit 53ee81bb686c18789fb1f58b062f40c69f19dec1
Author: Ard Biesheuvel 
Date:   Sun Aug 21 18:53:34 2016 +0200

ArmVirtPkg/ArmVirtQemu: switch to generic PciHostBridgeDxe

Wire up the FdtPciHostBridgeLib introduced in the previous patch
to the generic PciHostBridgeDxe implementation, and drop the special
ArmVirtPkg version. The former's dependency on gEfiCpuIo2ProtocolGuid
is satisfied by adding ArmPciCpuIo2Dxe.inf as well, and adding the PCD
gArmTokenSpaceGuid.PcdPciIoTranslation as a dynamic PCD.

In terms of functionality, no changes are intended.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65

commit d4cb9a30494ddf003497fae3aaf37dae137f6b45
Author: Ard Biesheuvel 
Date:   Sun Aug 21 17:34:19 2016 +0200

ArmVirtPkg: implement FdtPciHostBridgeLib

Implement PciHostBridgeLib for DT platforms that expose a PCI root bridge
via a pci-host-ecam-generic DT node. The DT parsing logic is copied from
the PciHostBridgeDxe implementation in ArmVirtPkg, with the one notable
difference that we don't set some of the legacy PCI attributes for IDE
and VGA I/O ranges.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65

commit c8f1a75aa997b3614b0ab751399690a4a0bfc18e
Author: Ard Biesheuvel 
Date:   Wed Aug 24 19:03:00 2016 +0200

ArmVirtPkg/FdtPciPcdProducerLib: add handling of PcdPciIoTranslation

Add handling of the PcdPciIoTranslation PCD, so that modules that include
this library via NULL resolution are guaranteed that it 

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

2016-09-02 Thread osstest service owner
flight 100738 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100738/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   9 debian-install   fail REGR. vs. 100734

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail  like 100734
 build-i386-rumpuserxen6 xen-buildfail  like 100734
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100734
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100734
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100734
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100734
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100734
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100734

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-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  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-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-xsm  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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-xsm  12 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-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass

version targeted for testing:
 xen  158dd1bdca161a6456ee6be293969f87ecde3922
baseline version:
 xen  f59174d7e5fb8bb530246003d373345b5b433ea0

Last test of basis   100734  2016-09-02 14:15:24 Z0 days
Testing same since   100738  2016-09-02 21:44:47 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Razvan Cojocaru 
  Wei Liu 

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   

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

2016-09-02 Thread osstest service owner
flight 100739 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100739/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 646a9e5b799b009426fe37af7ac8528a98cc96ce
baseline version:
 ovmf 0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3

Last test of basis   100737  2016-09-02 19:44:57 Z0 days
Testing same since   100739  2016-09-02 22:14:43 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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=646a9e5b799b009426fe37af7ac8528a98cc96ce
+ . ./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 
646a9e5b799b009426fe37af7ac8528a98cc96ce
+ branch=ovmf
+ revision=646a9e5b799b009426fe37af7ac8528a98cc96ce
+ . ./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.7-testing
+ '[' x646a9e5b799b009426fe37af7ac8528a98cc96ce = 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/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

Re: [Xen-devel] [PATCH 2/3] mini-os: add testbuild target to Makefile

2016-09-02 Thread Samuel Thibault
Juergen Gross, on Fri 02 Sep 2016 10:56:46 +0200, wrote:
> Add a "testbuild" target to the Makefile to test building a set of
> pre-defined configurations.
> 
> Configurations tested are stored under arch//testbuild in form
> of configuration files. All configurations found there are built in
> a local directory.

Please also document just above the CONFIG_* lines in Config.mk that new
CONFIG options should be set in all-* testbuilds.

> Signed-off-by: Juergen Gross 

Reviewed-by: Samuel Thibault 

Samuel

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


Re: [Xen-devel] [PATCH 1/3] mini-os: fix builds with uncommon config settings

2016-09-02 Thread Samuel Thibault
Juergen Gross, on Fri 02 Sep 2016 10:56:45 +0200, wrote:
> Some config settings won't build standalone. Fix the following cases:
> 
> - all CONFIG_* set to "n"
> - standard config with latest Xen interface version
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Samuel Thibault 

> ---
>  include/x86/os.h | 5 +
>  include/xenbus.h | 6 --
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/include/x86/os.h b/include/x86/os.h
> index 90ab6e6..0f5dd6c 100644
> --- a/include/x86/os.h
> +++ b/include/x86/os.h
> @@ -514,6 +514,11 @@ static __inline__ unsigned long __ffs(unsigned long word)
>  #endif /* ifdef __INSIDE_MINIOS */
>  
>  /* common i386 and x86_64  /
> +#define xen_mb()  mb()
> +#define xen_rmb() rmb()
> +#define xen_wmb() wmb()
> +#define xen_barrier() asm volatile ( "" : : : "memory")
> +
>  #define wrmsr(msr,val1,val2) \
>__asm__ __volatile__("wrmsr" \
> : /* no outputs */ \
> diff --git a/include/xenbus.h b/include/xenbus.h
> index c254652..12391b9 100644
> --- a/include/xenbus.h
> +++ b/include/xenbus.h
> @@ -7,10 +7,14 @@ typedef unsigned long xenbus_transaction_t;
>  #define XBT_NIL ((xenbus_transaction_t)0)
>  
>  #ifdef CONFIG_XENBUS
> +extern uint32_t xenbus_evtchn;
> +
>  /* Initialize the XenBus system. */
>  void init_xenbus(void);
>  void get_xenbus(void *p);
>  #else
> +#define xenbus_evtchn ~0
> +
>  static inline void init_xenbus(void)
>  {
>  }
> @@ -33,8 +37,6 @@ struct xenbus_event {
>  };
>  typedef struct xenbus_event *xenbus_event_queue;
>  
> -extern uint32_t xenbus_evtchn;
> -
>  char *xenbus_watch_path_token(xenbus_transaction_t xbt, const char *path, 
> const char *token, xenbus_event_queue *events);
>  char *xenbus_unwatch_path_token(xenbus_transaction_t xbt, const char *path, 
> const char *token);
>  extern struct wait_queue_head xenbus_watch_queue;
> -- 
> 2.6.6
> 

-- 
Samuel
(03:13:14)  bon
(03:13:19)  il est tard :p
(03:13:25)  c'est l'heure de manger
(03:13:38)  hm j'ai mangé à 1h moi, j'ai des horaires raisonnables

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


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

2016-09-02 Thread Platform Team regression test user
This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3
baseline version:
 ovmf 8953d69a5ca7f18f80f46e67da95c2527ca6ee89

Last test of basis67627  2016-09-02 13:16:23 Z0 days
Testing same since67630  2016-09-02 21:47:42 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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 0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3
Author: Ard Biesheuvel 
Date:   Wed Aug 31 10:07:33 2016 +0100

ArmPkg/BaseMemoryLibStm: implement new IsZeroBuffer() API function

BaseMemoryLib has recently been extended with an API function
IsZeroBuffer(), so copy the default implementation into BaseMemoryLibStm
as well.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

commit a548a5421f98f0890e3ab9703a5209d3ef8a9183
Author: Ard Biesheuvel 
Date:   Wed Aug 31 10:07:32 2016 +0100

ArmPkg/BaseMemoryLibStm: implement new IsZeroGuid() API function

BaseMemoryLib has recently been extended with an API function
IsZeroGuid(), so copy the default implementation into BaseMemoryLibStm
as well.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

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


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

2016-09-02 Thread osstest service owner
flight 100735 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100735/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt  9 debian-install   fail REGR. vs. 100669

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 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-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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 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-xl-multivcpu 12 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-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-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 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

version targeted for testing:
 qemuu1dc33ed90bf1fe1c2014dffa0d9e863c520d953a
baseline version:
 qemuu12d2c4184c5ab60be3428b2bdea5ae66e8d5d960

Last test of basis   100669  2016-08-31 00:23:42 Z2 days
Testing same since   100735  2016-09-02 15:14:36 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 

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

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

2016-09-02 Thread osstest service owner
flight 100737 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100737/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3
baseline version:
 ovmf 8953d69a5ca7f18f80f46e67da95c2527ca6ee89

Last test of basis   100721  2016-09-02 10:46:07 Z0 days
Testing same since   100737  2016-09-02 19:44:57 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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=0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3
+ . ./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 
0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3
+ branch=ovmf
+ revision=0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3
+ . ./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.7-testing
+ '[' x0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3 = 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/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

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

2016-09-02 Thread osstest service owner
flight 100734 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100734/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail  like 100712
 build-i386-rumpuserxen6 xen-buildfail  like 100712
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100712
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100712
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100712
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100712
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100712
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100712

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-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  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-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-xsm  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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-xsm  12 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-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 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-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass

version targeted for testing:
 xen  f59174d7e5fb8bb530246003d373345b5b433ea0
baseline version:
 xen  a4f39a6450abe5207cb33f877b4b6cd5db8a6cca

Last test of basis   100712  2016-09-02 02:49:03 Z0 days
Testing same since   100734  2016-09-02 14:15:24 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Juergen Gross 
  Tim Deegan 
  Wei Liu 

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 

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

2016-09-02 Thread Platform Team regression test user
This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pygrub   6 xen-boot  fail REGR. vs. 67617
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 67617
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 67617
 test-amd64-i386-xl-xsm6 xen-boot  fail REGR. vs. 67617
 test-amd64-i386-freebsd10-i386  6 xen-bootfail REGR. vs. 67617
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 67617
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot   fail REGR. vs. 67617
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 67617
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. 
vs. 67617
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 67617
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 67617
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 67617
 test-amd64-amd64-amd64-pvgrub  6 xen-boot fail REGR. vs. 67617
 test-amd64-amd64-i386-pvgrub  6 xen-boot  fail REGR. vs. 67617
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-boot fail REGR. vs. 67617
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 67617
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
67617
 test-amd64-i386-pair  9 xen-boot/src_host fail REGR. vs. 67617
 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 67617
 test-amd64-i386-migrupgrade  10 xen-boot/dst_host fail REGR. vs. 67617
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host fail REGR. vs. 67617
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 67617

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 67617
 build-i386-rumpuserxen6 xen-buildfail   like 67617
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 67617
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67617
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-install fail like 67617
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67617
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install   fail like 67617
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 67617

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt 12 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 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-xsm 12 migrate-support-checkfail   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-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-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-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 

Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

2016-09-02 Thread Tamas K Lengyel
On Fri, Sep 2, 2016 at 1:10 PM, Julien Grall  wrote:
>
>
> On 02/09/2016 19:47, Tamas K Lengyel wrote:
>>
>> On Fri, Sep 2, 2016 at 12:40 PM, Julien Grall 
>> wrote:
>>>
>>> On 02/09/2016 18:45, Andrew Cooper wrote:


 On 02/09/16 18:37, Tamas K Lengyel wrote:
>
>
> On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru
>  wrote:
>>
>>
>> On 08/01/2016 08:59 PM, Tamas K Lengyel wrote:
>>>
>>>
>>> Add support for getting/setting registers through vm_event on ARM.
>>> Only
>>> TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC
>>> is
>>> set
>>> as part of a response. The set of registers can be expanded in the
>>> future to
>>> include other registers as well if necessary.
>>>
>>> Signed-off-by: Tamas K Lengyel 
>>> Reviewed-by: Andrew Cooper 
>>
>>
>> Acked-by: Razvan Cojocaru 
>
>
> Patch ping.



 Requires an ARM ack.
>>>
>>>
>>>
>>> I don't think it requires an ack from Stefano and I, it touches only the
>>> vm_event subsystem.
>>>
>>> If you still want an ARM ack, then I will defer to Stefano.
>>
>>
>> Indeed it only touches the vm_event system so just wanted to double
>> check it's OK from your side as we had lengthy discussion about it. If
>> there are no objections a formal ack should not be necessary and it's
>> good to go.
>
>
> My objections are still there. Hence why I said I will defer to Stefano.

Fair enough.

Thanks,
Tamas

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


Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

2016-09-02 Thread Julien Grall



On 02/09/2016 19:47, Tamas K Lengyel wrote:

On Fri, Sep 2, 2016 at 12:40 PM, Julien Grall  wrote:

On 02/09/2016 18:45, Andrew Cooper wrote:


On 02/09/16 18:37, Tamas K Lengyel wrote:


On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru
 wrote:


On 08/01/2016 08:59 PM, Tamas K Lengyel wrote:


Add support for getting/setting registers through vm_event on ARM. Only
TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC is
set
as part of a response. The set of registers can be expanded in the
future to
include other registers as well if necessary.

Signed-off-by: Tamas K Lengyel 
Reviewed-by: Andrew Cooper 


Acked-by: Razvan Cojocaru 


Patch ping.



Requires an ARM ack.



I don't think it requires an ack from Stefano and I, it touches only the
vm_event subsystem.

If you still want an ARM ack, then I will defer to Stefano.


Indeed it only touches the vm_event system so just wanted to double
check it's OK from your side as we had lengthy discussion about it. If
there are no objections a formal ack should not be necessary and it's
good to go.


My objections are still there. Hence why I said I will defer to Stefano.

Regards,

--
Julien Grall

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


Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

2016-09-02 Thread Tamas K Lengyel
On Fri, Sep 2, 2016 at 12:40 PM, Julien Grall  wrote:
> On 02/09/2016 18:45, Andrew Cooper wrote:
>>
>> On 02/09/16 18:37, Tamas K Lengyel wrote:
>>>
>>> On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru
>>>  wrote:

 On 08/01/2016 08:59 PM, Tamas K Lengyel wrote:
>
> Add support for getting/setting registers through vm_event on ARM. Only
> TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC is
> set
> as part of a response. The set of registers can be expanded in the
> future to
> include other registers as well if necessary.
>
> Signed-off-by: Tamas K Lengyel 
> Reviewed-by: Andrew Cooper 

 Acked-by: Razvan Cojocaru 
>>>
>>> Patch ping.
>>
>>
>> Requires an ARM ack.
>
>
> I don't think it requires an ack from Stefano and I, it touches only the
> vm_event subsystem.
>
> If you still want an ARM ack, then I will defer to Stefano.

Indeed it only touches the vm_event system so just wanted to double
check it's OK from your side as we had lengthy discussion about it. If
there are no objections a formal ack should not be necessary and it's
good to go.

Thanks,
Tamas

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


Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

2016-09-02 Thread Julien Grall

On 02/09/2016 18:45, Andrew Cooper wrote:

On 02/09/16 18:37, Tamas K Lengyel wrote:

On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru
 wrote:

On 08/01/2016 08:59 PM, Tamas K Lengyel wrote:

Add support for getting/setting registers through vm_event on ARM. Only
TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC is set
as part of a response. The set of registers can be expanded in the future to
include other registers as well if necessary.

Signed-off-by: Tamas K Lengyel 
Reviewed-by: Andrew Cooper 

Acked-by: Razvan Cojocaru 

Patch ping.


Requires an ARM ack.


I don't think it requires an ack from Stefano and I, it touches only the 
vm_event subsystem.


If you still want an ARM ack, then I will defer to Stefano.

Cheers,

--
Julien Grall

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


Re: [Xen-devel] [PATCH v3] mem_access: sanitize code around sending vm_event request

2016-09-02 Thread Tamas K Lengyel
On Wed, Aug 3, 2016 at 12:41 PM, Tamas K Lengyel
 wrote:
> The two functions monitor_traps and mem_access_send_req duplicate some of the
> same functionality. The mem_access_send_req however leaves a lot of the
> standard vm_event fields to be filled by other functions.
>
> Remove mem_access_send_req() completely, making use of monitor_traps() to put
> requests into the monitor ring.  This in turn causes some cleanup around the
> old callsites of mem_access_send_req(). We also update monitor_traps to now
> include setting the common vcpu_id field so that all other call-sites can 
> ommit
> this step.
>
> Finally, this change identifies that errors from mem_access_send_req() were
> never checked.  As errors constitute a problem with the monitor ring,
> crashing the domain is the most appropriate action to take.
>
> Signed-off-by: Tamas K Lengyel 
> Reviewed-by: Andrew Cooper 
> Acked-by: Razvan Cojocaru 
> ---
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Jan Beulich 
> Cc: George Dunlap 
>
> v3: reduce the code movement and sanitization performed to a minimum

Patch ping. Needs an ARM ack (George has acked v2 for x86 that I
forgot to update in the patch message).

Tamas

> ---
>  xen/arch/arm/p2m.c   | 15 ---
>  xen/arch/x86/hvm/hvm.c   | 18 --
>  xen/arch/x86/hvm/monitor.c   |  5 -
>  xen/arch/x86/mm/p2m.c| 26 +-
>  xen/common/mem_access.c  | 11 ---
>  xen/common/monitor.c |  2 ++
>  xen/include/asm-x86/p2m.h| 13 -
>  xen/include/xen/mem_access.h |  7 ---
>  8 files changed, 31 insertions(+), 66 deletions(-)
>
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 40a0b80..a3f05b4 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -5,7 +5,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1740,10 +1740,6 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, 
> const struct npfec npfec)
>  {
>  req->reason = VM_EVENT_REASON_MEM_ACCESS;
>
> -/* Pause the current VCPU */
> -if ( xma != XENMEM_access_n2rwx )
> -req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
> -
>  /* Send request to mem access subscriber */
>  req->u.mem_access.gfn = gpa >> PAGE_SHIFT;
>  req->u.mem_access.offset =  gpa & ((1 << PAGE_SHIFT) - 1);
> @@ -1760,16 +1756,13 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, 
> const struct npfec npfec)
>  req->u.mem_access.flags |= npfec.read_access? MEM_ACCESS_R : 0;
>  req->u.mem_access.flags |= npfec.write_access   ? MEM_ACCESS_W : 0;
>  req->u.mem_access.flags |= npfec.insn_fetch ? MEM_ACCESS_X : 0;
> -req->vcpu_id = v->vcpu_id;
>
> -mem_access_send_req(v->domain, req);
> +if ( monitor_traps(v, (xma != XENMEM_access_n2rwx), req) < 0 )
> +domain_crash(v->domain);
> +
>  xfree(req);
>  }
>
> -/* Pause the current VCPU */
> -if ( xma != XENMEM_access_n2rwx )
> -vm_event_vcpu_pause(v);
> -
>  return false;
>  }
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index daaee1d..42f163e 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1707,7 +1707,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
> long gla,
>  int rc, fall_through = 0, paged = 0;
>  int sharing_enomem = 0;
>  vm_event_request_t *req_ptr = NULL;
> -bool_t ap2m_active;
> +bool_t ap2m_active, sync = 0;
>
>  /* On Nested Virtualization, walk the guest page table.
>   * If this succeeds, all is fine.
> @@ -1846,11 +1846,15 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
> long gla,
>  }
>  }
>
> -if ( p2m_mem_access_check(gpa, gla, npfec, _ptr) )
> -{
> +sync = p2m_mem_access_check(gpa, gla, npfec, _ptr);
> +
> +if ( !sync )
>  fall_through = 1;
> -} else {
> -/* Rights not promoted, vcpu paused, work here is done */
> +else
> +{
> +/*
> + * Rights not promoted (aka. sync event), work here is done
> + */
>  rc = 1;
>  goto out_put_gfn;
>  }
> @@ -1956,7 +1960,9 @@ out:
>  }
>  if ( req_ptr )
>  {
> -mem_access_send_req(currd, req_ptr);
> +if ( monitor_traps(curr, sync, req_ptr) < 0 )
> +rc = 0;
> +
>  xfree(req_ptr);
>  }
>  return rc;
> diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
> index 7277c12..0f6ef96 100644
> --- a/xen/arch/x86/hvm/monitor.c
> +++ 

Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 3/3] Making altp2m struct dynamically allocated.

2016-09-02 Thread Lai, Paul C
[PAUL] in line

-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com] 
Sent: Friday, September 2, 2016 6:47 AM
To: Lai, Paul C 
Cc: george.dun...@citrix.com; Sahita, Ravi ; xen-devel 

Subject: Re: [PATCH v2 Altp2m cleanup v3 3/3] Making altp2m struct dynamically 
allocated.

>>> On 19.08.16 at 19:22,  wrote:
> Ravi Sahita's dynamically allocated altp2m structs

I think I've asked before: With this and ...

> Signed-off-by: Paul Lai 
> Reviewed-by: Ravi Sahita 

... this - who's the actual author?

[PAUL] Ravi is the actual author.  I thought the commit message would have been 
clear :(

> @@ -5279,11 +5279,11 @@ static int do_altp2m_op(
>  break;
>  }
>  
> -ostate = d->arch.altp2m_active;
> -d->arch.altp2m_active = !!a.u.domain_state.state;
> +ostate = altp2m_active(d);
> +set_altp2m_active(d, !!a.u.domain_state.state);

The !! shouldn't be needed anymore.

> --- a/xen/arch/x86/mm/altp2m.c
> +++ b/xen/arch/x86/mm/altp2m.c
> @@ -73,23 +73,23 @@ hvm_altp2m_init( struct domain *d)
>  unsigned int i = 0;
>  
>  /* Init alternate p2m data. */
> -if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> +if ( (d->arch.altp2m->altp2m_eptp = alloc_xenheap_page()) == NULL 
> + )
>  {
>  rc = -ENOMEM;
>  goto out;
>  }
>  
>  for ( i = 0; i < MAX_EPTP; i++ )
> -d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> +d->arch.altp2m->altp2m_eptp[i] = mfn_x(INVALID_MFN);
>  
>  for ( i = 0; i < MAX_ALTP2M; i++ )
>  {
> -rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
> +rc = p2m_alloc_table(d->arch.altp2m->altp2m_p2m[i]);
>  if ( rc != 0 )
> goto out;
>  }
>  
> -d->arch.altp2m_active = 0;
> +set_altp2m_active(d, 0);

"false" please (also elsewhere).

> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -193,12 +193,15 @@ static void p2m_teardown_altp2m(struct domain 
> *d)
>  
>  for ( i = 0; i < MAX_ALTP2M; i++ )
>  {
> -if ( !d->arch.altp2m_p2m[i] )
> +if ( !d->arch.altp2m->altp2m_p2m[i] )
>  continue;
> -p2m = d->arch.altp2m_p2m[i];
> +p2m = d->arch.altp2m->altp2m_p2m[i];
>  p2m_free_one(p2m);
> -d->arch.altp2m_p2m[i] = NULL;
> +d->arch.altp2m->altp2m_p2m[i] = NULL;
>  }
> +
> +if ( d->arch.altp2m )
> +xfree(d->arch.altp2m);

Two problems here: First, xfree() happily deals with NULL being passed. But 
then, such a NULL check clearly should not come _after_ the pointer did already 
get dereferenced. I.e. first of all you need to clarify for yourself whether 
the function can be called with the pointer being NULL.

[PAUL] great catch

> @@ -206,10 +209,14 @@ static int p2m_init_altp2m(struct domain *d)

And then, considering this is the last patch in the series - how come these two 
functions are still in this source file?

> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -338,6 +338,13 @@ struct p2m_domain {
>  };
>  };
>  
> +struct altp2m_domain {
> +bool_t altp2m_active;
> +struct p2m_domain *altp2m_p2m[MAX_ALTP2M];
> +mm_lock_t altp2m_list_lock;
> +uint64_t *altp2m_eptp;
> +};

None of the altp2m_ prefixes here are really useful for anything afaics.

Jan


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


Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 2/3] Move altp2m specific functions to altp2m files.

2016-09-02 Thread Lai, Paul C
[PAUL] in-line

Ravi -- please comment on swap comment below.

-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com] 
Sent: Friday, September 2, 2016 6:31 AM
To: Lai, Paul C 
Cc: george.dun...@citrix.com; Sahita, Ravi ; xen-devel 

Subject: Re: [PATCH v2 Altp2m cleanup v3 2/3] Move altp2m specific functions to 
altp2m files.

>>> On 19.08.16 at 19:22,  wrote:
> @@ -65,6 +66,50 @@ altp2m_vcpu_destroy(struct vcpu *v)
>  vcpu_unpause(v);
>  }
>  
> +int
> +hvm_altp2m_init( struct domain *d)

Stray blank (more elsewhere). Also I don't think hvm_ is a proper prefix for a 
function placed in this file, i.e. if altp2m_init() is used elsewhere already, 
then altp2m_hvm_init() or perhaps better
altp2m_domain_init() please.

> +{
> +int rc = 0;
> +unsigned int i = 0;

Pointless initializers.

> +/* Init alternate p2m data. */
> +if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> +{
> +rc = -ENOMEM;
> +goto out;
> +}

When the epilogue (after the target label) is just a return statement, please 
avoid using goto.

[PAUL] I don't see this code in an epilogue (after the target label).  

> +void
> +hvm_altp2m_teardown( struct domain *d) {
> +unsigned int i = 0;
> +d->arch.altp2m_active = 0;
> +
> +if ( d->arch.altp2m_eptp )
> +{
> +free_xenheap_page(d->arch.altp2m_eptp);
> +d->arch.altp2m_eptp = NULL;
> +}

Please avoid the if() - free_xenheap_page() happily deals with a NULL pointer 
passed to it.

> +for ( i = 0; i < MAX_ALTP2M; i++ )
> +p2m_teardown(d->arch.altp2m_p2m[i]);

I realize it's been that way in the original code, but wouldn't swapping the 
two things be both more natural and more robust?

[PAUL] Ravi ?

> @@ -501,24 +502,9 @@ int hap_enable(struct domain *d, u32 mode)
>  
>  if ( hvm_altp2m_supported() )
>  {
> -/* Init alternate p2m data */
> -if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> -{
> -rv = -ENOMEM;
> -goto out;
> -}
> -
> -for ( i = 0; i < MAX_EPTP; i++ )
> -d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> -
> -for ( i = 0; i < MAX_ALTP2M; i++ )
> -{
> -rv = p2m_alloc_table(d->arch.altp2m_p2m[i]);
> -if ( rv != 0 )
> -   goto out;
> -}
> -
> -d->arch.altp2m_active = 0;
> +rv = hvm_altp2m_init(d);
> +if ( rv != 0 )
> +   goto out;
>  }
>  
>  /* Now let other users see the new mode */ @@ -534,18 +520,7 @@ 
> void hap_final_teardown(struct domain *d)
>  unsigned int i;
>  
>  if ( hvm_altp2m_supported() )
> -{
> -d->arch.altp2m_active = 0;
> -
> -if ( d->arch.altp2m_eptp )
> -{
> -free_xenheap_page(d->arch.altp2m_eptp);
> -d->arch.altp2m_eptp = NULL;
> -}
> -
> -for ( i = 0; i < MAX_ALTP2M; i++ )
> -p2m_teardown(d->arch.altp2m_p2m[i]);
> -}
> +hvm_altp2m_teardown(d);

I wonder whether in both cases the hvm_altp2m_supported() would better also be 
moved into the functions.

It looks like the parts above and below this point, except for header file 
adjustments, are completely independent. Please consider splitting into two 
patches.

> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -1329,6 +1329,45 @@ void setup_ept_dump(void)
>  register_keyhandler('D', ept_dump_p2m_table, "dump VT-x EPT 
> tables", 0);  }
>  
> +void p2m_init_altp2m_ept_helper( struct domain *d, unsigned int i)

Please drop the _helper suffix now that there is _ept.

Jan


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


Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

2016-09-02 Thread Andrew Cooper
On 02/09/16 18:37, Tamas K Lengyel wrote:
> On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru
>  wrote:
>> On 08/01/2016 08:59 PM, Tamas K Lengyel wrote:
>>> Add support for getting/setting registers through vm_event on ARM. Only
>>> TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC is set
>>> as part of a response. The set of registers can be expanded in the future to
>>> include other registers as well if necessary.
>>>
>>> Signed-off-by: Tamas K Lengyel 
>>> Reviewed-by: Andrew Cooper 
>> Acked-by: Razvan Cojocaru 
> Patch ping.

Requires an ARM ack.

~Andrew

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


Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

2016-09-02 Thread Tamas K Lengyel
On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru
 wrote:
> On 08/01/2016 08:59 PM, Tamas K Lengyel wrote:
>> Add support for getting/setting registers through vm_event on ARM. Only
>> TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC is set
>> as part of a response. The set of registers can be expanded in the future to
>> include other registers as well if necessary.
>>
>> Signed-off-by: Tamas K Lengyel 
>> Reviewed-by: Andrew Cooper 
>
> Acked-by: Razvan Cojocaru 

Patch ping.

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


[Xen-devel] [xen-unstable-smoke test] 100736: tolerable all pass - PUSHED

2016-09-02 Thread osstest service owner
flight 100736 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100736/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  158dd1bdca161a6456ee6be293969f87ecde3922
baseline version:
 xen  f59174d7e5fb8bb530246003d373345b5b433ea0

Last test of basis   100732  2016-09-02 12:01:43 Z0 days
Testing same since   100733  2016-09-02 14:01:51 Z0 days2 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Razvan Cojocaru 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=158dd1bdca161a6456ee6be293969f87ecde3922
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
158dd1bdca161a6456ee6be293969f87ecde3922
+ branch=xen-unstable-smoke
+ revision=158dd1bdca161a6456ee6be293969f87ecde3922
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x158dd1bdca161a6456ee6be293969f87ecde3922 = 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/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
  

Re: [Xen-devel] [PATCH] libxc: zero-initialize structures in macros

2016-09-02 Thread Tamas K Lengyel
On Fri, Sep 2, 2016 at 11:18 AM, Andrew Cooper
 wrote:
> On 02/09/16 17:39, Tamas K Lengyel wrote:
>> While debugging applications built on top of libxc with Valgrind we get a lot
>> of complaining about relying on uninitialized values allocated in libxc.
>> While these warnings are safe to ignore, zero-initializing the structures
>> reduces Valgrind clutter a lot and aids in spotting real bugs.
>>
>> Signed-off-by: Tamas K Lengyel 
>> ---
>> Cc: Ian Jackson 
>> Cc: Wei Liu 
>> ---
>>  tools/libxc/xc_private.h | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
>> index 75b761c..4e9073b 100644
>> --- a/tools/libxc/xc_private.h
>> +++ b/tools/libxc/xc_private.h
>> @@ -59,11 +59,11 @@ struct iovec {
>>  #include 
>>  #endif
>>
>> -#define DECLARE_DOMCTL struct xen_domctl domctl
>> -#define DECLARE_SYSCTL struct xen_sysctl sysctl
>> -#define DECLARE_PHYSDEV_OP struct physdev_op physdev_op
>> -#define DECLARE_FLASK_OP struct xen_flask_op op
>> -#define DECLARE_PLATFORM_OP struct xen_platform_op platform_op
>> +#define DECLARE_DOMCTL struct xen_domctl domctl = {0}
>> +#define DECLARE_SYSCTL struct xen_sysctl sysctl = {0}
>> +#define DECLARE_PHYSDEV_OP struct physdev_op physdev_op = {0}
>> +#define DECLARE_FLASK_OP struct xen_flask_op op = {0}
>> +#define DECLARE_PLATFORM_OP struct xen_platform_op platform_op = {0}
>
> I specifically took those out in the past, because it hides real
> problems from Valgrind.
>
> Instead, I would recommend removing these wrappers entirely.  They serve
> no useful purpose.
>
> Taking a random example of xc_get_pfn_type_batch(), it would be rather
> more efficient to write
>
> ...
> DECLARE_HYPERCALL_BOUNCE(arr, sizeof(*arr) * num,
> XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
> struct xen_domctl domctl = {
> .cmd = XEN_DOMCTL_getpageframeinfo3,
> .domain = dom,
> .u.getpageframeinfo3.num = num,
> };
> ...
>
> as it permits the compiler more freedom in how xen_domctl gets
> constructed, as well as being able to plainly see exactly what is done
> to the memory.
>

Yea I don't really see much point using these macros as they are
either and the one you propose certainly would make more sense.

Tamas

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


Re: [Xen-devel] [PATCH] libxc: zero-initialize structures in macros

2016-09-02 Thread Andrew Cooper
On 02/09/16 17:39, Tamas K Lengyel wrote:
> While debugging applications built on top of libxc with Valgrind we get a lot
> of complaining about relying on uninitialized values allocated in libxc.
> While these warnings are safe to ignore, zero-initializing the structures
> reduces Valgrind clutter a lot and aids in spotting real bugs.
>
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/libxc/xc_private.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
> index 75b761c..4e9073b 100644
> --- a/tools/libxc/xc_private.h
> +++ b/tools/libxc/xc_private.h
> @@ -59,11 +59,11 @@ struct iovec {
>  #include 
>  #endif
>  
> -#define DECLARE_DOMCTL struct xen_domctl domctl
> -#define DECLARE_SYSCTL struct xen_sysctl sysctl
> -#define DECLARE_PHYSDEV_OP struct physdev_op physdev_op
> -#define DECLARE_FLASK_OP struct xen_flask_op op
> -#define DECLARE_PLATFORM_OP struct xen_platform_op platform_op
> +#define DECLARE_DOMCTL struct xen_domctl domctl = {0}
> +#define DECLARE_SYSCTL struct xen_sysctl sysctl = {0}
> +#define DECLARE_PHYSDEV_OP struct physdev_op physdev_op = {0}
> +#define DECLARE_FLASK_OP struct xen_flask_op op = {0}
> +#define DECLARE_PLATFORM_OP struct xen_platform_op platform_op = {0}

I specifically took those out in the past, because it hides real
problems from Valgrind.

Instead, I would recommend removing these wrappers entirely.  They serve
no useful purpose.

Taking a random example of xc_get_pfn_type_batch(), it would be rather
more efficient to write

...
DECLARE_HYPERCALL_BOUNCE(arr, sizeof(*arr) * num,
XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
struct xen_domctl domctl = {
.cmd = XEN_DOMCTL_getpageframeinfo3,
.domain = dom,
.u.getpageframeinfo3.num = num,
};
...

as it permits the compiler more freedom in how xen_domctl gets
constructed, as well as being able to plainly see exactly what is done
to the memory.

~Andrew

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


[Xen-devel] [PATCH] libxc: zero-initialize structures in macros

2016-09-02 Thread Tamas K Lengyel
While debugging applications built on top of libxc with Valgrind we get a lot
of complaining about relying on uninitialized values allocated in libxc.
While these warnings are safe to ignore, zero-initializing the structures
reduces Valgrind clutter a lot and aids in spotting real bugs.

Signed-off-by: Tamas K Lengyel 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/libxc/xc_private.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 75b761c..4e9073b 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -59,11 +59,11 @@ struct iovec {
 #include 
 #endif
 
-#define DECLARE_DOMCTL struct xen_domctl domctl
-#define DECLARE_SYSCTL struct xen_sysctl sysctl
-#define DECLARE_PHYSDEV_OP struct physdev_op physdev_op
-#define DECLARE_FLASK_OP struct xen_flask_op op
-#define DECLARE_PLATFORM_OP struct xen_platform_op platform_op
+#define DECLARE_DOMCTL struct xen_domctl domctl = {0}
+#define DECLARE_SYSCTL struct xen_sysctl sysctl = {0}
+#define DECLARE_PHYSDEV_OP struct physdev_op physdev_op = {0}
+#define DECLARE_FLASK_OP struct xen_flask_op op = {0}
+#define DECLARE_PLATFORM_OP struct xen_platform_op platform_op = {0}
 
 #undef PAGE_SHIFT
 #undef PAGE_SIZE
-- 
2.9.3


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


Re: [Xen-devel] [PATCH 4/5] gcov: add option to determine gcov format

2016-09-02 Thread Wei Liu
On Fri, Sep 02, 2016 at 01:08:27PM +0100, Wei Liu wrote:
> On Fri, Sep 02, 2016 at 06:01:22AM -0600, Jan Beulich wrote:
> > >>> On 02.09.16 at 13:47,  wrote:
> > > Currently only gcc 3.4 format is supported.
> > 
> > Doesn't this patch contradict your coverage letter? Here you provide
> > means to add support for further formats, but there you said there's
> > no obvious route to that goal.
> > 
> 
> There is a way, we can ditch the old interface and just hand back the
> blob.
> 

Let me try to make myself clearer because now I reread my reply it
doesn't seem to convey my thought.

There are two issues:

1. The sysctl interface is tied to gcc 3.4 format.
2. The implementation inside Xen is tied to gcc 3.4 format.

My cover letter was referring to #1 because there is no way to fit newer
gcc format into the existing Xen sysctl coverage interface. To solve #1
I'm afraid we need to design new interfaces.

#2 is independent of #1. Regardless of what the sysctl interface looks
like, Xen needs to know which format to use (size of the structure,
offset of fields etc) in order to extract information.

This patch (sorta) deals with #2 and is one step towards dealing with
#1.

Wei.

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


Re: [Xen-devel] [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping

2016-09-02 Thread Julien Grall

Hi Vitaly,

On 26/07/16 13:30, Vitaly Kuznetsov wrote:

It may happen that Xen's and Linux's ideas of vCPU id diverge. In
particular, when we crash on a secondary vCPU we may want to do kdump
and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
on the vCPU which crashed. This doesn't work very well for PVHVM guests as
we have a number of hypercalls where we pass vCPU id as a parameter. These
hypercalls either fail or do something unexpected. To solve the issue
introduce percpu xen_vcpu_id mapping. ARM and PV guests get direct mapping
for now. Boot CPU for PVHVM guest gets its id from CPUID. With secondary
CPUs it is a bit more trickier. Currently, we initialize IPI vectors
before these CPUs boot so we can't use CPUID. Use ACPI ids from MADT
instead.

Signed-off-by: Vitaly Kuznetsov 
---
Changes since v2:
- Use uint32_t for xen_vcpu_id mapping [Julien Grall]

Changes since v1:
- Introduce xen_vcpu_nr() helper [David Vrabel]
- Use ACPI ids instead of vLAPIC ids /2 [Andrew Cooper, Jan Beulich]
---
 arch/arm/xen/enlighten.c | 10 ++
 arch/x86/xen/enlighten.c | 23 ++-
 include/xen/xen-ops.h|  6 ++
 3 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..fe32267 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -46,6 +46,10 @@ struct shared_info *HYPERVISOR_shared_info = (void 
*)_dummy_shared_info;
 DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
 static struct vcpu_info __percpu *xen_vcpu_info;

+/* Linux <-> Xen vCPU id mapping */
+DEFINE_PER_CPU(uint32_t, xen_vcpu_id) = U32_MAX;
+EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
+
 /* These are unused until we support booting "pre-ballooned" */
 unsigned long xen_released_pages;
 struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
@@ -179,6 +183,9 @@ static void xen_percpu_init(void)
pr_info("Xen: initializing cpu%d\n", cpu);
vcpup = per_cpu_ptr(xen_vcpu_info, cpu);

+   /* Direct vCPU id mapping for ARM guests. */
+   per_cpu(xen_vcpu_id, cpu) = cpu;
+


We did some internal testing on ARM64 with the latest Linux kernel 
(4.8-rc4) and noticed that this patch is breaking SMP support. Sorry for 
noticing the issue that late.


This function is called on the running CPU whilst some code (e.g 
init_control_block in drivers/xen/events/events_fifo.c) is executed 
whilst preparing the CPU on the boot CPU.


So xen_vcpu_nr(cpu) will always return 0 in this case and 
init_control_block will fail to execute.


I am not sure how to fix. I guess we could setup per_cpu(xen_vcpu_id, *) 
in xen_guest_init. Any opinions?


[...]


diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 0f87db2..c833912 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1795,6 +1806,12 @@ static void __init init_hvm_pv_info(void)

xen_setup_features();

+   cpuid(base + 4, , , , );
+   if (eax & XEN_HVM_CPUID_VCPU_ID_PRESENT)
+   this_cpu_write(xen_vcpu_id, ebx);
+   else
+   this_cpu_write(xen_vcpu_id, smp_processor_id());
+
pv_info.name = "Xen HVM";

xen_domain_type = XEN_HVM_DOMAIN;
@@ -1806,6 +1823,10 @@ static int xen_hvm_cpu_notify(struct notifier_block 
*self, unsigned long action,
int cpu = (long)hcpu;
switch (action) {
case CPU_UP_PREPARE:
+   if (cpu_acpi_id(cpu) != U32_MAX)
+   per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
+   else
+   per_cpu(xen_vcpu_id, cpu) = cpu;


I have not tried myself. But looking at the code, the notifiers 
xen_hvm_cpu_notifier and evtchn_fifo_cpu_notifier have the same 
priority. So what does prevent the code above to be executed after the 
event channel callback?



xen_vcpu_setup(cpu);
if (xen_have_vector_callback) {
if (xen_feature(XENFEAT_hvm_safe_pvclock))
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 86abe07..648ce814 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -9,6 +9,12 @@

 DECLARE_PER_CPU(struct vcpu_info *, xen_vcpu);

+DECLARE_PER_CPU(uint32_t, xen_vcpu_id);
+static inline int xen_vcpu_nr(int cpu)
+{
+   return per_cpu(xen_vcpu_id, cpu);
+}
+
 void xen_arch_pre_suspend(void);
 void xen_arch_post_suspend(int suspend_cancelled);


Regards,

--
Julien Grall

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


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

2016-09-02 Thread Platform Team regression test user
This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 8953d69a5ca7f18f80f46e67da95c2527ca6ee89
baseline version:
 ovmf 4a2aaff2fca69d9f41c5b8906699ba242278cbaa

Last test of basis67626  2016-09-02 10:46:31 Z0 days
Testing same since67627  2016-09-02 13:16:23 Z0 days1 attempts


People who touched revisions under test:
  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.


commit 8953d69a5ca7f18f80f46e67da95c2527ca6ee89
Author: Liming Gao 
Date:   Thu Sep 1 13:41:20 2016 +0800

MdeModulePkg UefiBootManagerLib: Ignore BootManagerMenu from LoadFile

BootManagerMenu boot option is handled by EfiBootManagerGetBootManagerMenu.
Don't need to handle it again when parse LoadFile protocol.

In V2, use "BootManagerMenu" instead of "BootMenuApp".

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Ruiyu Ni 
Reviewed-by: Sunny Wang 

commit 7c69fbf20d409516c80355de9a40656ec55f5e21
Author: Liming Gao 
Date:   Thu Sep 1 13:30:13 2016 +0800

MdeModulePkg UefiBootManagerLib: Rename BootMenuApp to BootManagerMenu

Rename local function name BootMenuApp to BootManagerMenu to align to
other public function name.

In V2, use "BootManagerMenu" instead of "BootMenuApp".

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Ruiyu Ni 
Reviewed-by: Sunny Wang 

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


Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Tamas K Lengyel
On Sep 2, 2016 09:17, "Razvan Cojocaru"  wrote:
>
> On 09/02/2016 06:13 PM, Tamas K Lengyel wrote:
> > On Sep 2, 2016 09:03, "Jan Beulich"  > > wrote:
> >>
> >> >>> On 02.09.16 at 16:50,  > > wrote:
> >> > On Sep 2, 2016 05:45, "Jan Beulich"  > > wrote:
> >> >>
> >> >> >>> On 02.09.16 at 13:18,  > > wrote:
> >> >> > On 09/02/2016 01:02 PM, Jan Beulich wrote:
> >> >> > On 02.09.16 at 10:51,  > > wrote:
> >> >> >>> Changes since V1 / RFC:
> >> >> >>>  - Renamed xc_set_mem_access_sparse() to
xc_set_mem_access_multi(),
> >> >> >>>and XENMEM_access_op_set_access_sparse to
> >> >> >>>XENMEM_access_op_set_access_multi.
> >> >> >>>  - Renamed the 'nr' parameter to 'size'.
> >> >> >>
> >> >> >> Why?
> >> >> >
> >> >> > Tamas suggested it, size sounded more intuitive to him. I have no
> >> >> > problem with either nr or size.
> >> >>
> >> >> Size to me means something in bytes, which clearly isn't the case
> >> >> here. There's not even support for other then 4k pages so far.
> >> >
> >> > Lets make it array_size then to clarify?
> >>
> >> What's wrong with "nr", matching the other (existing) function?
> >>
> >
> > IMHO it's too generic. So either a more descriptive name or a comment is
> > warranted to explain the inputs.
>
> If this satisfies everybody, I'll keep 'nr' and add a comment describing
> the function and parameters (which is a good thing anyway).
>
>

SGTM.

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


Re: [Xen-devel] [PATCH] x86: correct CPUID output for out of bounds input

2016-09-02 Thread Andrew Cooper
On 01/09/16 16:27, Jan Beulich wrote:
>
>>> +{
>>> +if ( d->arch.x86_vendor == X86_VENDOR_AMD )
>>> +{
>>> +*eax = 0;
>>> +*ebx = 0;
>>> +*ecx = 0;
>>> +*edx = 0;
>>> +return;
>>> +}
>>> +if ( input >> 16 )
>>> +hvm_cpuid(0, , NULL, NULL, NULL);
>> Is this really the right way round?  The AMD method of "reserved always
>> as zero" is the more sane default to take.
> If anything I'd then say let's _always_ follow the AMD model.

It would certainly be better to default to AMD, and special case others
on an as-needed basis.

Strictly speaking, following the AMD model is compatible with the
"Reserved" nature specified for Intel.

Lets just go with this.

~Andrew

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


Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Razvan Cojocaru
On 09/02/2016 06:13 PM, Tamas K Lengyel wrote:
> On Sep 2, 2016 09:03, "Jan Beulich"  > wrote:
>>
>> >>> On 02.09.16 at 16:50,  > wrote:
>> > On Sep 2, 2016 05:45, "Jan Beulich"  > wrote:
>> >>
>> >> >>> On 02.09.16 at 13:18,  > wrote:
>> >> > On 09/02/2016 01:02 PM, Jan Beulich wrote:
>> >> > On 02.09.16 at 10:51,  > wrote:
>> >> >>> Changes since V1 / RFC:
>> >> >>>  - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
>> >> >>>and XENMEM_access_op_set_access_sparse to
>> >> >>>XENMEM_access_op_set_access_multi.
>> >> >>>  - Renamed the 'nr' parameter to 'size'.
>> >> >>
>> >> >> Why?
>> >> >
>> >> > Tamas suggested it, size sounded more intuitive to him. I have no
>> >> > problem with either nr or size.
>> >>
>> >> Size to me means something in bytes, which clearly isn't the case
>> >> here. There's not even support for other then 4k pages so far.
>> >
>> > Lets make it array_size then to clarify?
>>
>> What's wrong with "nr", matching the other (existing) function?
>>
> 
> IMHO it's too generic. So either a more descriptive name or a comment is
> warranted to explain the inputs.

If this satisfies everybody, I'll keep 'nr' and add a comment describing
the function and parameters (which is a good thing anyway).


Thanks,
Razvan

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


Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Tamas K Lengyel
On Sep 2, 2016 09:03, "Jan Beulich"  wrote:
>
> >>> On 02.09.16 at 16:50,  wrote:
> > On Sep 2, 2016 05:45, "Jan Beulich"  wrote:
> >>
> >> >>> On 02.09.16 at 13:18,  wrote:
> >> > On 09/02/2016 01:02 PM, Jan Beulich wrote:
> >> > On 02.09.16 at 10:51,  wrote:
> >> >>> Changes since V1 / RFC:
> >> >>>  - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
> >> >>>and XENMEM_access_op_set_access_sparse to
> >> >>>XENMEM_access_op_set_access_multi.
> >> >>>  - Renamed the 'nr' parameter to 'size'.
> >> >>
> >> >> Why?
> >> >
> >> > Tamas suggested it, size sounded more intuitive to him. I have no
> >> > problem with either nr or size.
> >>
> >> Size to me means something in bytes, which clearly isn't the case
> >> here. There's not even support for other then 4k pages so far.
> >
> > Lets make it array_size then to clarify?
>
> What's wrong with "nr", matching the other (existing) function?
>

IMHO it's too generic. So either a more descriptive name or a comment is
warranted to explain the inputs.

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


Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Jan Beulich
>>> On 02.09.16 at 16:50,  wrote:
> On Sep 2, 2016 05:45, "Jan Beulich"  wrote:
>>
>> >>> On 02.09.16 at 13:18,  wrote:
>> > On 09/02/2016 01:02 PM, Jan Beulich wrote:
>> > On 02.09.16 at 10:51,  wrote:
>> >>> Changes since V1 / RFC:
>> >>>  - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
>> >>>and XENMEM_access_op_set_access_sparse to
>> >>>XENMEM_access_op_set_access_multi.
>> >>>  - Renamed the 'nr' parameter to 'size'.
>> >>
>> >> Why?
>> >
>> > Tamas suggested it, size sounded more intuitive to him. I have no
>> > problem with either nr or size.
>>
>> Size to me means something in bytes, which clearly isn't the case
>> here. There's not even support for other then 4k pages so far.
> 
> Lets make it array_size then to clarify?

What's wrong with "nr", matching the other (existing) function?

Jan


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


[Xen-devel] [xen-unstable-smoke test] 100733: regressions - trouble: blocked/broken/pass

2016-09-02 Thread osstest service owner
flight 100733 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100733/

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  158dd1bdca161a6456ee6be293969f87ecde3922
baseline version:
 xen  f59174d7e5fb8bb530246003d373345b5b433ea0

Last test of basis   100732  2016-09-02 12:01:43 Z0 days
Testing same since   100733  2016-09-02 14:01:51 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Razvan Cojocaru 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  broken  
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Not pushing.


commit 158dd1bdca161a6456ee6be293969f87ecde3922
Author: Wei Liu 
Date:   Mon Aug 15 16:27:27 2016 +0100

tools: delete gtraceview and gtracestat

There has not been any substantial update to them since 2011. My quick
check shows that they don't work.

Just delete them. It would be easy to resurrect them from git log should
people still need them.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 

commit 341e8c0b7a13fa5e23337e77b6df202c79e088da
Author: Jan Beulich 
Date:   Fri Sep 2 14:22:28 2016 +0200

x86/mm: drop pointless use of __FUNCTION__

Non-debugging message text should be (and is here) distinguishable
without also logging function names.

Signed-off-by: Jan Beulich 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 
Acked-by: George Dunlap 

commit 6dc9ac9f52b8651b5700e24567fadd5b2b61786d
Author: Jan Beulich 
Date:   Fri Sep 2 14:20:23 2016 +0200

x86emul: check alignment of SSE and AVX memory operands

It only now occurred to me that there's no new hook needed to do so.
Eliminate the two work item comments.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit 8d6af808a7e9d9ae1d129e1e5a0def7f8b2333ee
Author: Jan Beulich 
Date:   Fri Sep 2 14:19:51 2016 +0200

memory: fix compat handling of XENMEM_access_op

Within compat_memory_op() this needs to be placed in the first switch()
statement, or it ends up being dead code (as that first switch() has a
default case chaining to compat_arch_memory_op()).

Signed-off-by: Jan Beulich 
Tested-by: Razvan Cojocaru 
Reviewed-by: Andrew Cooper 

commit bea64b3ed25864b90a41e1ca6eeb5a58895bb751
Author: Jan Beulich 
Date:   Fri Sep 2 14:19:29 2016 +0200

x86/PV: make PMU MSR handling consistent

So far accesses to Intel MSRs on an AMD system fall through to the
default case, while accesses to AMD MSRs on an Intel system bail (in
the RDMSR case without updating EAX and EDX). Make the "AMD MSRs on
Intel" case match the "Intel MSR on AMD" one.

Signed-off-by: Jan Beulich 
Reviewed-by: Boris Ostrovsky 
Reviewed-by: Andrew Cooper 

commit f8f185dc4359a1cd8e7896dfbcacb54b473436c8
Author: Jan Beulich 
Date:   Fri Sep 2 14:18:52 2016 

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Tamas K Lengyel
On Sep 2, 2016 05:45, "Jan Beulich"  wrote:
>
> >>> On 02.09.16 at 13:18,  wrote:
> > On 09/02/2016 01:02 PM, Jan Beulich wrote:
> > On 02.09.16 at 10:51,  wrote:
> >>> Changes since V1 / RFC:
> >>>  - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
> >>>and XENMEM_access_op_set_access_sparse to
> >>>XENMEM_access_op_set_access_multi.
> >>>  - Renamed the 'nr' parameter to 'size'.
> >>
> >> Why?
> >
> > Tamas suggested it, size sounded more intuitive to him. I have no
> > problem with either nr or size.
>
> Size to me means something in bytes, which clearly isn't the case
> here. There's not even support for other then 4k pages so far.
>

Lets make it array_size then to clarify?

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


Re: [Xen-devel] [RFC] Classify and remove (some) abort()s in libxl

2016-09-02 Thread Wei Liu
Andrew and Doug, do you have more comments?

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


Re: [Xen-devel] [PATCH v5 00/16] Xen ARM DomU ACPI support

2016-09-02 Thread Wei Liu
Thanks for posting.

I go over all the patches and I think this series is in good shape. I
will defer most of the table construction code to ARM maintainers.

Wei.

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


Re: [Xen-devel] [PATCH v5 01/16] tools/libxl: Add an unified configuration option for ACPI

2016-09-02 Thread Wei Liu
On Fri, Sep 02, 2016 at 10:55:24AM +0800, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> Since the existing configuration option "u.hvm.acpi" is x86 specific and
> we want to reuse it on ARM as well, add a unified option "acpi" for
> x86 and ARM, and for ARM it's disabled by default.
> 
> Signed-off-by: Shannon Zhao 

Acked-by: Wei Liu 

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


Re: [Xen-devel] [PATCH v5 02/16] libxl/arm: prepare for constructing ACPI tables

2016-09-02 Thread Wei Liu
On Fri, Sep 02, 2016 at 10:55:25AM +0800, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> It only constructs the ACPI tables for 64-bit ARM DomU when user enables
> acpi because 32-bit DomU doesn't support ACPI. And the generation codes
> are only built for 64-bit toolstack.
> 
> Signed-off-by: Shannon Zhao 

The code looks reasonable to me.

Subject to an ack from ARM maintainers:

Acked-by: Wei Liu 

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


Re: [Xen-devel] [PATCH v5 03/16] libxl/arm: Generate static ACPI DSDT table

2016-09-02 Thread Wei Liu
On Fri, Sep 02, 2016 at 10:55:26AM +0800, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> It uses static DSDT table like the way x86 uses. Currently the DSDT
> table only contains processor device objects and it generates the
> maximal objects which so far is 128.
> 
> While the GUEST_MAX_VCPUS is defined under __XEN__ or __XEN_TOOLS__, it
> needs to add -D__XEN_TOOLS__ to compile mk_dsdt.c.
> 
> Also only check iasl for aarch64 in configure since ACPI on ARM32 is not
> supported.
> 
> Signed-off-by: Shannon Zhao 
> ---
> Note: this patch needs to be rebased on Boris's v3 patchset for only 
> generating dsdt_anycpu_arm.c for ARM64.
> ---
>  tools/configure.ac|  2 +-

Note to Ian and myself: need to rerun autogen.sh while committing.

>  tools/libacpi/Makefile| 13 -
>  tools/libacpi/mk_dsdt.c   | 27 ++-

This could use review from Jan, Boris and Andrew.

>  tools/libxl/Makefile  |  5 -
>  tools/libxl/libxl_arm_acpi.c  |  5 +

Again, subject from an ack from ARM maintainers:

Acked-by: Wei Liu 

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


Re: [Xen-devel] [PATCH v5] xen/sm{e, a}p: allow disabling sm{e, a}p for Xen itself

2016-09-02 Thread Jan Beulich
>>> On 02.09.16 at 10:20,  wrote:
> +/* smep: Enable/disable Supervisor Mode Execution Protection (default on). */
> +#define SMEP_HVM_ONLY (-1)
> +static s8 __initdata opt_smep = 1;
> +static void __init parse_smep_param(char *s)
> +{
> +if ( !parse_bool(s) )
> +{
> +opt_smep = 0;
> +}
> +else if ( !strcmp(s, "hvm") )
> +{
> +opt_smep = SMEP_HVM_ONLY;
> +}
> +
> +if ( opt_smep == 1 )
> +__set_bit(X86_FEATURE_XEN_SMEP, boot_cpu_data.x86_capability);
> +}
> +custom_param("smep", parse_smep_param);

The pointless braces are still there, and it still doesn't look like e.g.
"smep=0 smep=1" would work. Did you take the time to look at
other callers of parse_bool()?

And then - I'm sorry for not having noticed before - setting the
feature flag here means it won't get set if no "smep=" was given.
I.e. you rather want to move that ...

> @@ -1403,12 +1433,12 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>  if ( !opt_smep )
>  setup_clear_cpu_cap(X86_FEATURE_SMEP);

... around here.

Jan


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


Re: [Xen-devel] Can't build ipxe with 6.1.1

2016-09-02 Thread Ian Jackson
Andrew Cooper writes ("Re: [Xen-devel] Can't build ipxe with 6.1.1"):
> Ian: Can we see about getting xenbits:ipxe.git which works, and is
> tested by osstest, in the same way as seabios currently is?

As I said on IRC, I have no objection to this plan.  When there is an
appropriate ipxe git branch we can put it on xenbits nest to seabios.
There would have to be a corresponding xen.git patch to clone and use
the new ipxe git repo.

If those pieces are present, I would be happy to do the associated
osstest work (which is very straightforward).

> iPXE has a rolling release with no specific version number, but does
> have a xen-netfront implementation (when we start using a version which
> isn't 6 years old), so some system testing of PXE booting HVM guests
> would be a good move.

There is currently no testing of pxebooting guests, in osstest.  I
would welcome patches to do that.  I guess they'd end up using ipxe
with qemu-trad and native pxe support with qemu upstream (assuming all
the toolstack plumbing is in place - which I'm not sure about TBH).
The starting point would probably be the Debian d-i test cases.
(Search for test-debian-di in osstest.git:make-flight.)

Thanks,
Ian.

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


Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

2016-09-02 Thread Wei Liu
On Tue, Aug 30, 2016 at 12:02:26PM +0100, Ian Jackson wrote:
> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu 
> depriv)"):
> > Well, in a way. And then not: Initially I had thought no issue would
> > arise, until I came to realize the kernel memory corruption potential.
> > Question is whether now we're overlooking some other not
> > immediately obvious issue. The problem with auditing is that
> > generally you can only look for things you're aware of (or magically
> > become aware of while looking at the code). But I guess we should
> > just go ahead with the patterns we know of.
> 
> I think so, yes.  I will take a look at the interfaces, at least, to
> see if I can spot anything missing.  This will probably generate some
> more stupid questions...
> 
> So, then, is everyone now happy with the overall approach ?  That is,
> as I wrote up in:
>   Message-ID: <22464.10246.708893.563...@mariner.uk.xensource.com>
>   Subject: Re: Device model operation hypercall (DMOP, re qemu depriv)
>   Date: Fri, 26 Aug 2016 12:29:10 +0100
> 

It looks like a reasonable plan to me.

Wei.

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


Re: [Xen-devel] [PATCH] docs: document old SUSE/Novell unplug for HVM

2016-09-02 Thread Wei Liu
On Fri, Sep 02, 2016 at 11:32:55AM +0200, Olaf Hering wrote:
> Signed-off-by: Olaf Hering 

More document is always a good thing. :-)

I will leave the review to Konrad and Stefano because I don't know
enough about this.

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


Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

2016-09-02 Thread Jan Beulich
>>> On 02.09.16 at 15:15,  wrote:

> 
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, September 2, 2016 6:46 PM
>> To: Wu, Feng 
>> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
>> de...@lists.xen.org 
>> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after assigning
>> PI hooks
>> 
>> >>> On 02.09.16 at 12:30,  wrote:
>> 
>> >
>> >> -Original Message-
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Friday, September 2, 2016 5:26 PM
>> >> To: Wu, Feng 
>> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> >> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
>> >> de...@lists.xen.org 
>> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
>> assigning
>> >> PI hooks
>> >>
>> >> >>> On 02.09.16 at 10:40,  wrote:
>> >>
>> >> >
>> >> >> -Original Message-
>> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> >> Sent: Friday, September 2, 2016 4:16 PM
>> >> >> To: Wu, Feng 
>> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> >> >> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
>> >> >> de...@lists.xen.org 
>> >> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
>> >> assigning
>> >> >> PI hooks
>> >> >>
>> >> >> >>> On 02.09.16 at 09:31,  wrote:
>> >> >>
>> >> >> >
>> >> >> >> -Original Message-
>> >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> >> >> Sent: Friday, September 2, 2016 3:04 PM
>> >> >> >> To: Wu, Feng 
>> >> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> >> >> >> george.dun...@eu.citrix.com; Tian, Kevin ;
>> xen-
>> >> >> >> de...@lists.xen.org 
>> >> >> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
>> >> >> assigning
>> >> >> >> PI hooks
>> >> >> >>
>> >> >> >> >>> On 02.09.16 at 03:46,  wrote:
>> >> >> >>
>> >> >> >> >
>> >> >> >> >> -Original Message-
>> >> >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> >> >> >> Sent: Thursday, September 1, 2016 4:30 PM
>> >> >> >> >> To: Wu, Feng 
>> >> >> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> >> >> >> >> george.dun...@eu.citrix.com; Tian, Kevin ;
>> >> xen-
>> >> >> >> >> de...@lists.xen.org 
>> >> >> >> >> Subject: Re: [PATCH v3 4/6] Pause/Unpause the domain
>> before/after
>> >> >> >> assigning
>> >> >> >> >> PI hooks
>> >> >> >> >>
>> >> >> >> >> >>> On 31.08.16 at 05:56,  wrote:
>> >> >> >> >> > --- a/xen/arch/x86/hvm/vmx/vmx.c
>> >> >> >> >> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> >> >> >> >> > @@ -219,8 +219,19 @@ void vmx_pi_hooks_assign(struct domain
>> *d)
>> >> >> >> >> >
>> >> >> >> >> >  ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
>> >> >> >> >> >
>> >> >> >> >> > +/*
>> >> >> >> >> > + * Pausing the domain can make sure the vCPU is not
>> >> >> >> >> > + * running and hence calling the hooks simultaneously
>> >> >> >> >> > + * when deassigning the PI hooks. This makes sure that
>> >> >> >> >> > + * all the appropriate state of PI descriptor is actually
>> >> >> >> >> > + * set up for all vCPus before leaving this function.
>> >> >> >> >> > + */
>> >> >> >> >> > +domain_pause(d);
>> >> >> >> >> > +
>> >> >> >> >> >  d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
>> >> >> >> >> >  d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
>> >> >> >> >> > +
>> >> >> >> >> > +domain_unpause(d);
>> >> >> >> >> >  }
>> >> >> >> >>
>> >> >> >> >> First of all I'm missing a word on whether the race mentioned in
>> >> >> >> >> the description and comment can actually happen. Device
>> >> >> >> >> (de)assignment should already be pretty much serialized (via
>> >> >> >> >> the domctl lock, and maybe also via the pcidevs one).
>> >> >> >> >
>> >> >> >> > The purpose of this patch is to address the race condition that
>> >> >> >> > the _vCPU_ is running while we are installing these hooks. Do you
>> >> >> >> > think this cannot happen?  This patch is trying to fix the issue
>> >> >> >> > described at:
>> >> >> >> > http://www.gossamer-threads.com/lists/xen/devel/433229 
>> >> >> >> > Consider that the other two hooks were installed when the VM
>> >> >> >> > is created, seems no such race condition. However, according
>> >> >> >> > to the discussion about patch 1 and patch 2 of series, we need
>> >> >> >> > to install the other two hooks here as well,
>> >> >> >>
>> >> >> >> I don't think we've agreed that the creation time installation of
>> >> >> >> those hooks is actually necessary. In fact your most recent
>> >> >> >> response to patch 1 makes me think you now 

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

2016-09-02 Thread osstest service owner
flight 100712 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100712/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100667
 build-amd64-rumpuserxen   6 xen-buildfail  like 100674
 build-i386-rumpuserxen6 xen-buildfail  like 100674
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100674
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100674
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100674
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100674
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100674

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-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  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-xsm  12 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-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 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-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass

version targeted for testing:
 xen  a4f39a6450abe5207cb33f877b4b6cd5db8a6cca
baseline version:
 xen  4b314c89be24c26abfad47900f806cebeafc805e

Last test of basis   100674  2016-08-31 08:49:52 Z2 days
Failing since100681  2016-08-31 18:14:20 Z1 days5 attempts
Testing same since   100706  2016-09-01 19:14:21 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Feng Wu 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Wei Liu 

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 

Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 3/3] Making altp2m struct dynamically allocated.

2016-09-02 Thread Jan Beulich
>>> On 19.08.16 at 19:22,  wrote:
> Ravi Sahita's dynamically allocated altp2m structs

I think I've asked before: With this and ...

> Signed-off-by: Paul Lai 
> Reviewed-by: Ravi Sahita 

... this - who's the actual author?

> @@ -5279,11 +5279,11 @@ static int do_altp2m_op(
>  break;
>  }
>  
> -ostate = d->arch.altp2m_active;
> -d->arch.altp2m_active = !!a.u.domain_state.state;
> +ostate = altp2m_active(d);
> +set_altp2m_active(d, !!a.u.domain_state.state);

The !! shouldn't be needed anymore.

> --- a/xen/arch/x86/mm/altp2m.c
> +++ b/xen/arch/x86/mm/altp2m.c
> @@ -73,23 +73,23 @@ hvm_altp2m_init( struct domain *d)
>  unsigned int i = 0;
>  
>  /* Init alternate p2m data. */
> -if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> +if ( (d->arch.altp2m->altp2m_eptp = alloc_xenheap_page()) == NULL )
>  {
>  rc = -ENOMEM;
>  goto out;
>  }
>  
>  for ( i = 0; i < MAX_EPTP; i++ )
> -d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> +d->arch.altp2m->altp2m_eptp[i] = mfn_x(INVALID_MFN);
>  
>  for ( i = 0; i < MAX_ALTP2M; i++ )
>  {
> -rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
> +rc = p2m_alloc_table(d->arch.altp2m->altp2m_p2m[i]);
>  if ( rc != 0 )
> goto out;
>  }
>  
> -d->arch.altp2m_active = 0;
> +set_altp2m_active(d, 0);

"false" please (also elsewhere).

> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -193,12 +193,15 @@ static void p2m_teardown_altp2m(struct domain *d)
>  
>  for ( i = 0; i < MAX_ALTP2M; i++ )
>  {
> -if ( !d->arch.altp2m_p2m[i] )
> +if ( !d->arch.altp2m->altp2m_p2m[i] )
>  continue;
> -p2m = d->arch.altp2m_p2m[i];
> +p2m = d->arch.altp2m->altp2m_p2m[i];
>  p2m_free_one(p2m);
> -d->arch.altp2m_p2m[i] = NULL;
> +d->arch.altp2m->altp2m_p2m[i] = NULL;
>  }
> +
> +if ( d->arch.altp2m )
> +xfree(d->arch.altp2m);

Two problems here: First, xfree() happily deals with NULL being
passed. But then, such a NULL check clearly should not come
_after_ the pointer did already get dereferenced. I.e. first of all
you need to clarify for yourself whether the function can be called
with the pointer being NULL.

> @@ -206,10 +209,14 @@ static int p2m_init_altp2m(struct domain *d)

And then, considering this is the last patch in the series - how come
these two functions are still in this source file?

> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -338,6 +338,13 @@ struct p2m_domain {
>  };
>  };
>  
> +struct altp2m_domain {
> +bool_t altp2m_active;
> +struct p2m_domain *altp2m_p2m[MAX_ALTP2M];
> +mm_lock_t altp2m_list_lock;
> +uint64_t *altp2m_eptp;
> +};

None of the altp2m_ prefixes here are really useful for anything afaics.

Jan


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


[Xen-devel] [PATCH] xen: Have __DEFINE_COMPAT_HANDLE() generate const versions

2016-09-02 Thread Razvan Cojocaru
Both DEFINE_XEN_GUEST_HANDLE() and __DEFINE_XEN_GUEST_HANDLE()
each produce both const and non-const handles,
only DEFINE_COMPAT_HANDLE() does (__DEFINE_COMPAT_HANDLE()
does not). This patch has __DEFINE_COMPAT_HANDLE() also
produce a const handle.

Suggested-by: Jan Beulich 
Signed-off-by: Razvan Cojocaru 
---
 xen/include/xen/compat.h | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/include/xen/compat.h b/xen/include/xen/compat.h
index 3f4cef6..ce913ac 100644
--- a/xen/include/xen/compat.h
+++ b/xen/include/xen/compat.h
@@ -15,11 +15,14 @@
 typedef struct { \
 compat_ptr_t c; \
 type *_[0] __packed; \
-} __compat_handle_ ## name
+} __compat_handle_ ## name; \
+typedef struct { \
+compat_ptr_t c; \
+const type *_[0] __packed; \
+} __compat_handle_const_ ## name
 
 #define DEFINE_COMPAT_HANDLE(name) \
-__DEFINE_COMPAT_HANDLE(name, name); \
-__DEFINE_COMPAT_HANDLE(const_ ## name, const name)
+__DEFINE_COMPAT_HANDLE(name, name)
 #define COMPAT_HANDLE(name)  __compat_handle_ ## name
 
 /* NB: it is assumed that if an arch uses the compat layer it does not
-- 
1.9.1


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


[Xen-devel] [xen-unstable-smoke test] 100732: tolerable all pass - PUSHED

2016-09-02 Thread osstest service owner
flight 100732 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100732/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  f59174d7e5fb8bb530246003d373345b5b433ea0
baseline version:
 xen  c8777e62d9af845b5fd158684eaed10918fc5cf8

Last test of basis   100720  2016-09-02 09:01:31 Z0 days
Testing same since   100732  2016-09-02 12:01:43 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Tim Deegan 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=f59174d7e5fb8bb530246003d373345b5b433ea0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
f59174d7e5fb8bb530246003d373345b5b433ea0
+ branch=xen-unstable-smoke
+ revision=f59174d7e5fb8bb530246003d373345b5b433ea0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' xf59174d7e5fb8bb530246003d373345b5b433ea0 = 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/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local 

Re: [Xen-devel] [PATCH] tools: delete gtraceview and gtracestat

2016-09-02 Thread Wei Liu
On Fri, Sep 02, 2016 at 12:36:21PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH] tools: delete gtraceview and gtracestat"):
> > On Fri, Sep 02, 2016 at 12:13:04PM +0100, George Dunlap wrote:
> > > If so, it's probably just the case that the trace record format has
> > > changed somewhat and these weren't updated.  It would probably be fairly
> > > straightforward to fix; but if nobody's using it, I'd just as soon
> > > delete it.  The "gtracestat" functionality would probably better be
> > > added to xenalyze in any case.
> > 
> > Yes. I agree.
> 
> OK, thanks for the discussion.  I'm sold.
> 
> Acked-by: Ian Jackson 

Pushed with your ack. Thanks.

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


Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Razvan Cojocaru
On 09/02/2016 04:26 PM, Julien Grall wrote:
> 
> 
> On 02/09/16 14:22, Razvan Cojocaru wrote:
>> On 09/02/2016 04:17 PM, Julien Grall wrote:
>>> Hello Razvan,
>>
>> Hello Julien, thanks for the email!
>>
>>> On 02/09/16 09:51, Razvan Cojocaru wrote:
 Currently it is only possible to set mem_access restrictions only for
 a contiguous range of GFNs (or, as a particular case, for a single GFN).
 This patch introduces a new libxc function taking an array of GFNs.
 The alternative would be to set each page in turn, using a userspace-HV
 roundtrip for each call, and triggering a TLB flush per page set.

 Signed-off-by: Razvan Cojocaru 

 ---
 Changes since V1 / RFC:
  - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
and XENMEM_access_op_set_access_sparse to
XENMEM_access_op_set_access_multi.
  - Renamed the 'nr' parameter to 'size'.
  - Wrapped long line in the implementation of xc_set_mem_access_multi().
  - Factored out common code in _p2m_set_mem_access() (and modified
p2m_set_altp2m_mem_access() in the process, to take an unsigned
long argument instead of a gfn_t).
  - Factored out xenmem_access_t to p2m_access_t conversion code in
p2m_xenmem_access_to_p2m_access().
  - Added hypercall continuation support.
  - Added compat translation support.
  - No longer allocating buffers (now using copy_from_guest_offset()).
  - Added support for setting an array of access restrictions, as
suggested by Tamas Lengyel.
  - This patch incorporates Jan Beulich's "memory: fix compat handling
of XENMEM_access_op".
 ---
  tools/libxc/include/xenctrl.h |   4 ++
  tools/libxc/xc_mem_access.c   |  38 ++
  xen/arch/x86/mm/p2m.c | 161
 --
  xen/common/compat/memory.c|  24 +--
  xen/common/mem_access.c   |  11 +++
  xen/include/public/memory.h   |  14 +++-
  xen/include/xen/p2m-common.h  |   6 ++
>>>
>>> p2m-common.h contains prototype common between ARM and x86. I would have
>>> expected to see a change in the ARM port because of that.
>>
>> The only change to p2m-common.h is the addition of a single function,
>> p2m_set_mem_access_multi(). As long as the ARM bits don't make use of
>> it, there's nothing to modify there.
> 
> p2m_set_mem_access_multi is called from common code. If you had tried
> to build Xen on ARM you would have noticed a compilation error:
> 
> prelink.o: In function `mem_access_memop':
> /local/home/julieng/works/xen/xen/common/mem_access.c:80: undefined reference 
> to `p2m_set_mem_access_multi'
> aarch64-linux-gnu-ld: /local/home/julieng/works/xen/xen/.xen-syms.0: hidden 
> symbol `p2m_set_mem_access_multi' isn't defined

I see. Sorry about that. I'll fix that in V3.


Thanks,
Razvan


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


Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

2016-09-02 Thread Wei Liu
On Fri, Sep 02, 2016 at 02:21:28PM +0100, Julien Grall wrote:
> Hi Wei,
> 
> On 02/09/16 13:01, Wei Liu wrote:
> >On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote:
> >On 02.09.16 at 13:47,  wrote:
> >>
> >>Since this is a config option - why bother issuing a warning and
> >>tainting the hypervisor?
> >>
> >
> >Because there isn't a clear indicator if gcov is enabled.
> 
> I think this is an issue to all .config option. If I am not mistaken,
> currently you are not able to know whether option FOO has been enabled for
> your kernel.
> 
> Maybe we should integrate the .config in the binary?
> 

I think that would be a good idea.  It is orthogonal to what I'm trying
to do here though.

Wei.

> Regards,
> 
> -- 
> Julien Grall

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


Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

2016-09-02 Thread Wei Liu
On Fri, Sep 02, 2016 at 01:30:40PM +0100, Andrew Cooper wrote:
> On 02/09/16 13:26, Jan Beulich wrote:
>  On 02.09.16 at 14:13,  wrote:
> >> On 02/09/16 13:06, Jan Beulich wrote:
> >> On 02.09.16 at 14:01,  wrote:
>  On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote:
>  On 02.09.16 at 13:47,  wrote:
> > Since this is a config option - why bother issuing a warning and
> > tainting the hypervisor?
> >
>  Because there isn't a clear indicator if gcov is enabled.
> 
>  I think it would be valuable to just tell from the backtrace or console
>  log that gcov is enabled, then we can legitimately refuse to provide
>  (security) support for such builds.
> >>> Then perhaps making it match the "debug=" would be the better
> >>> approach for a feature not controlled on the command line?
> >> I would prefer not to make it depend on debug=
> >>
> >> Coverage on a release hypervisor is equally important, and will be
> >> different from a debug hypervisor.
> > I didn't say "depend on", but "match" (which I mean just logging wise).
> >
> >> I am on the fence as to whether a taint is right to use, but I do think
> >> that a "with GCOV" is needed somewhere obvious on the banner line.
> > Right, hence the matching goal with "debug=".
> 
> Ah - I see what you mean.  Yes - that would be fine by me.
> 

Fine by me, too.

I will replace this patch with a new one.

Wei.

> ~Andrew

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


Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 2/3] Move altp2m specific functions to altp2m files.

2016-09-02 Thread Jan Beulich
>>> On 19.08.16 at 19:22,  wrote:
> @@ -65,6 +66,50 @@ altp2m_vcpu_destroy(struct vcpu *v)
>  vcpu_unpause(v);
>  }
>  
> +int
> +hvm_altp2m_init( struct domain *d)

Stray blank (more elsewhere). Also I don't think hvm_ is a proper
prefix for a function placed in this file, i.e. if altp2m_init() is used
elsewhere already, then altp2m_hvm_init() or perhaps better
altp2m_domain_init() please.

> +{
> +int rc = 0;
> +unsigned int i = 0;

Pointless initializers.

> +/* Init alternate p2m data. */
> +if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> +{
> +rc = -ENOMEM;
> +goto out;
> +}

When the epilogue (after the target label) is just a return statement,
please avoid using goto.

> +void
> +hvm_altp2m_teardown( struct domain *d)
> +{
> +unsigned int i = 0;
> +d->arch.altp2m_active = 0;
> +
> +if ( d->arch.altp2m_eptp )
> +{
> +free_xenheap_page(d->arch.altp2m_eptp);
> +d->arch.altp2m_eptp = NULL;
> +}

Please avoid the if() - free_xenheap_page() happily deals with a
NULL pointer passed to it.

> +for ( i = 0; i < MAX_ALTP2M; i++ )
> +p2m_teardown(d->arch.altp2m_p2m[i]);

I realize it's been that way in the original code, but wouldn't swapping
the two things be both more natural and more robust?

> @@ -501,24 +502,9 @@ int hap_enable(struct domain *d, u32 mode)
>  
>  if ( hvm_altp2m_supported() )
>  {
> -/* Init alternate p2m data */
> -if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> -{
> -rv = -ENOMEM;
> -goto out;
> -}
> -
> -for ( i = 0; i < MAX_EPTP; i++ )
> -d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> -
> -for ( i = 0; i < MAX_ALTP2M; i++ )
> -{
> -rv = p2m_alloc_table(d->arch.altp2m_p2m[i]);
> -if ( rv != 0 )
> -   goto out;
> -}
> -
> -d->arch.altp2m_active = 0;
> +rv = hvm_altp2m_init(d);
> +if ( rv != 0 )
> +   goto out;
>  }
>  
>  /* Now let other users see the new mode */
> @@ -534,18 +520,7 @@ void hap_final_teardown(struct domain *d)
>  unsigned int i;
>  
>  if ( hvm_altp2m_supported() )
> -{
> -d->arch.altp2m_active = 0;
> -
> -if ( d->arch.altp2m_eptp )
> -{
> -free_xenheap_page(d->arch.altp2m_eptp);
> -d->arch.altp2m_eptp = NULL;
> -}
> -
> -for ( i = 0; i < MAX_ALTP2M; i++ )
> -p2m_teardown(d->arch.altp2m_p2m[i]);
> -}
> +hvm_altp2m_teardown(d);

I wonder whether in both cases the hvm_altp2m_supported()
would better also be moved into the functions.

It looks like the parts above and below this point, except for header
file adjustments, are completely independent. Please consider
splitting into two patches.

> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -1329,6 +1329,45 @@ void setup_ept_dump(void)
>  register_keyhandler('D', ept_dump_p2m_table, "dump VT-x EPT tables", 0);
>  }
>  
> +void p2m_init_altp2m_ept_helper( struct domain *d, unsigned int i)

Please drop the _helper suffix now that there is _ept.

Jan


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


Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Julien Grall


On 02/09/16 14:22, Razvan Cojocaru wrote:
> On 09/02/2016 04:17 PM, Julien Grall wrote:
>> Hello Razvan,
> 
> Hello Julien, thanks for the email!
> 
>> On 02/09/16 09:51, Razvan Cojocaru wrote:
>>> Currently it is only possible to set mem_access restrictions only for
>>> a contiguous range of GFNs (or, as a particular case, for a single GFN).
>>> This patch introduces a new libxc function taking an array of GFNs.
>>> The alternative would be to set each page in turn, using a userspace-HV
>>> roundtrip for each call, and triggering a TLB flush per page set.
>>>
>>> Signed-off-by: Razvan Cojocaru 
>>>
>>> ---
>>> Changes since V1 / RFC:
>>>  - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
>>>and XENMEM_access_op_set_access_sparse to
>>>XENMEM_access_op_set_access_multi.
>>>  - Renamed the 'nr' parameter to 'size'.
>>>  - Wrapped long line in the implementation of xc_set_mem_access_multi().
>>>  - Factored out common code in _p2m_set_mem_access() (and modified
>>>p2m_set_altp2m_mem_access() in the process, to take an unsigned
>>>long argument instead of a gfn_t).
>>>  - Factored out xenmem_access_t to p2m_access_t conversion code in
>>>p2m_xenmem_access_to_p2m_access().
>>>  - Added hypercall continuation support.
>>>  - Added compat translation support.
>>>  - No longer allocating buffers (now using copy_from_guest_offset()).
>>>  - Added support for setting an array of access restrictions, as
>>>suggested by Tamas Lengyel.
>>>  - This patch incorporates Jan Beulich's "memory: fix compat handling
>>>of XENMEM_access_op".
>>> ---
>>>  tools/libxc/include/xenctrl.h |   4 ++
>>>  tools/libxc/xc_mem_access.c   |  38 ++
>>>  xen/arch/x86/mm/p2m.c | 161
>>> --
>>>  xen/common/compat/memory.c|  24 +--
>>>  xen/common/mem_access.c   |  11 +++
>>>  xen/include/public/memory.h   |  14 +++-
>>>  xen/include/xen/p2m-common.h  |   6 ++
>>
>> p2m-common.h contains prototype common between ARM and x86. I would have
>> expected to see a change in the ARM port because of that.
> 
> The only change to p2m-common.h is the addition of a single function,
> p2m_set_mem_access_multi(). As long as the ARM bits don't make use of
> it, there's nothing to modify there.

p2m_set_mem_access_multi is called from common code. If you had tried
to build Xen on ARM you would have noticed a compilation error:

prelink.o: In function `mem_access_memop':
/local/home/julieng/works/xen/xen/common/mem_access.c:80: undefined reference 
to `p2m_set_mem_access_multi'
aarch64-linux-gnu-ld: /local/home/julieng/works/xen/xen/.xen-syms.0: hidden 
symbol `p2m_set_mem_access_multi' isn't defined

Regards,

-- 
Julien Grall

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


Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Razvan Cojocaru
On 09/02/2016 04:10 PM, Jan Beulich wrote:
 On 02.09.16 at 15:03,  wrote:
>> On 09/02/2016 03:56 PM, Jan Beulich wrote:
>> On 02.09.16 at 14:41,  wrote:
 On 09/02/2016 03:33 PM, Jan Beulich wrote:
 On 02.09.16 at 14:21,  wrote:
>> On 09/02/2016 01:02 PM, Jan Beulich wrote:
 +/*
> + * Corresponding list of access settings for pfn_list
> + * Used only with XENMEM_access_op_set_access_multi
> + */
> +XEN_GUEST_HANDLE(uint8) access_list;
>>> And for both of them - I don't think the arrays are meant to be
>>> used for output? In which case they should be handles of const
>>> types.
>>
>> Actually I can't seem to be able to find a magic combination that works.
>>
>> XEN_GUEST_HANDLE(const uint8) access_list; tells me:
>>
>> ./public/arch-x86/xen.h:53:41: error: '__guest_handle_const' does not
>> name a type
>>  #define __XEN_GUEST_HANDLE(name)__guest_handle_ ## name
>>
>> which is fair. I've tried:
>>
>> XEN_GUEST_HANDLE(const_uint8) access_list;
>>
>> which does go further with the compilation process, but still kills it 
>> with:
>>
>> xen/include/compat/memory.h:154:5: error: unknown type name
>> '__compat_handle_const_uint8'
>>  COMPAT_HANDLE(const_uint8) access_list;
>>
>> What would be the appropriate const type to use here?
>
> This one. Did you check that handle actually gets created? Per
> my brief checking it doesn't look so. And neither the native one.

 Running ./configure again, followed by 'make clean' and a new 'make
 dist' didn't help, so if it's supposed to be generated automatically it
 doesn't seem to be (or I'm doing something wrong). I'll investigate more.
>>>
>>> The compat one is supposed to get auto-generated once the native
>>> one is there.
>>
>> Changing both handles to XEN_GUEST_HANLDE(const_void) compiles cleanly.
>> As soon as I change to either XEN_GUEST_HANLDE(const_uint8) or
>> XEN_GUEST_HANLDE(const_uint64) I start getting errors.
>>
>> Previously the auto-generation seems to have worked fine, so this is
>> likely something more subtle.
> 
> Oh, I see where the issue is: Both DEFINE_XEN_GUEST_HANDLE()
> and __DEFINE_XEN_GUEST_HANDLE() auto-magically produce const
> counterparts, but while DEFINE_COMPAT_HANDLE() does too,
> __DEFINE_COMPAT_HANDLE() doesn't. That'll need fixing, I think.

I see it, thanks! I'll submit a small patch shortly.


Thanks,
Razvan


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


Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

2016-09-02 Thread Julien Grall

Hi Wei,

On 02/09/16 13:01, Wei Liu wrote:

On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote:

On 02.09.16 at 13:47,  wrote:


Since this is a config option - why bother issuing a warning and
tainting the hypervisor?



Because there isn't a clear indicator if gcov is enabled.


I think this is an issue to all .config option. If I am not mistaken, 
currently you are not able to know whether option FOO has been enabled 
for your kernel.


Maybe we should integrate the .config in the binary?

Regards,

--
Julien Grall

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


Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Razvan Cojocaru
On 09/02/2016 04:17 PM, Julien Grall wrote:
> Hello Razvan,

Hello Julien, thanks for the email!

> On 02/09/16 09:51, Razvan Cojocaru wrote:
>> Currently it is only possible to set mem_access restrictions only for
>> a contiguous range of GFNs (or, as a particular case, for a single GFN).
>> This patch introduces a new libxc function taking an array of GFNs.
>> The alternative would be to set each page in turn, using a userspace-HV
>> roundtrip for each call, and triggering a TLB flush per page set.
>>
>> Signed-off-by: Razvan Cojocaru 
>>
>> ---
>> Changes since V1 / RFC:
>>  - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
>>and XENMEM_access_op_set_access_sparse to
>>XENMEM_access_op_set_access_multi.
>>  - Renamed the 'nr' parameter to 'size'.
>>  - Wrapped long line in the implementation of xc_set_mem_access_multi().
>>  - Factored out common code in _p2m_set_mem_access() (and modified
>>p2m_set_altp2m_mem_access() in the process, to take an unsigned
>>long argument instead of a gfn_t).
>>  - Factored out xenmem_access_t to p2m_access_t conversion code in
>>p2m_xenmem_access_to_p2m_access().
>>  - Added hypercall continuation support.
>>  - Added compat translation support.
>>  - No longer allocating buffers (now using copy_from_guest_offset()).
>>  - Added support for setting an array of access restrictions, as
>>suggested by Tamas Lengyel.
>>  - This patch incorporates Jan Beulich's "memory: fix compat handling
>>of XENMEM_access_op".
>> ---
>>  tools/libxc/include/xenctrl.h |   4 ++
>>  tools/libxc/xc_mem_access.c   |  38 ++
>>  xen/arch/x86/mm/p2m.c | 161
>> --
>>  xen/common/compat/memory.c|  24 +--
>>  xen/common/mem_access.c   |  11 +++
>>  xen/include/public/memory.h   |  14 +++-
>>  xen/include/xen/p2m-common.h  |   6 ++
> 
> p2m-common.h contains prototype common between ARM and x86. I would have
> expected to see a change in the ARM port because of that.

The only change to p2m-common.h is the addition of a single function,
p2m_set_mem_access_multi(). As long as the ARM bits don't make use of
it, there's nothing to modify there.


Thanks,
Razvan

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


Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Julien Grall

Hello Razvan,

On 02/09/16 09:51, Razvan Cojocaru wrote:

Currently it is only possible to set mem_access restrictions only for
a contiguous range of GFNs (or, as a particular case, for a single GFN).
This patch introduces a new libxc function taking an array of GFNs.
The alternative would be to set each page in turn, using a userspace-HV
roundtrip for each call, and triggering a TLB flush per page set.

Signed-off-by: Razvan Cojocaru 

---
Changes since V1 / RFC:
 - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
   and XENMEM_access_op_set_access_sparse to
   XENMEM_access_op_set_access_multi.
 - Renamed the 'nr' parameter to 'size'.
 - Wrapped long line in the implementation of xc_set_mem_access_multi().
 - Factored out common code in _p2m_set_mem_access() (and modified
   p2m_set_altp2m_mem_access() in the process, to take an unsigned
   long argument instead of a gfn_t).
 - Factored out xenmem_access_t to p2m_access_t conversion code in
   p2m_xenmem_access_to_p2m_access().
 - Added hypercall continuation support.
 - Added compat translation support.
 - No longer allocating buffers (now using copy_from_guest_offset()).
 - Added support for setting an array of access restrictions, as
   suggested by Tamas Lengyel.
 - This patch incorporates Jan Beulich's "memory: fix compat handling
   of XENMEM_access_op".
---
 tools/libxc/include/xenctrl.h |   4 ++
 tools/libxc/xc_mem_access.c   |  38 ++
 xen/arch/x86/mm/p2m.c | 161 --
 xen/common/compat/memory.c|  24 +--
 xen/common/mem_access.c   |  11 +++
 xen/include/public/memory.h   |  14 +++-
 xen/include/xen/p2m-common.h  |   6 ++


p2m-common.h contains prototype common between ARM and x86. I would have 
expected to see a change in the ARM port because of that.


Regards,

--
Julien Grall

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


Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

2016-09-02 Thread Wu, Feng


> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, September 2, 2016 6:46 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org
> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after assigning
> PI hooks
> 
> >>> On 02.09.16 at 12:30,  wrote:
> 
> >
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Friday, September 2, 2016 5:26 PM
> >> To: Wu, Feng 
> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> >> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> >> de...@lists.xen.org
> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
> assigning
> >> PI hooks
> >>
> >> >>> On 02.09.16 at 10:40,  wrote:
> >>
> >> >
> >> >> -Original Message-
> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> Sent: Friday, September 2, 2016 4:16 PM
> >> >> To: Wu, Feng 
> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> >> >> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> >> >> de...@lists.xen.org
> >> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
> >> assigning
> >> >> PI hooks
> >> >>
> >> >> >>> On 02.09.16 at 09:31,  wrote:
> >> >>
> >> >> >
> >> >> >> -Original Message-
> >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> >> Sent: Friday, September 2, 2016 3:04 PM
> >> >> >> To: Wu, Feng 
> >> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> >> >> >> george.dun...@eu.citrix.com; Tian, Kevin ;
> xen-
> >> >> >> de...@lists.xen.org
> >> >> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
> >> >> assigning
> >> >> >> PI hooks
> >> >> >>
> >> >> >> >>> On 02.09.16 at 03:46,  wrote:
> >> >> >>
> >> >> >> >
> >> >> >> >> -Original Message-
> >> >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> >> >> Sent: Thursday, September 1, 2016 4:30 PM
> >> >> >> >> To: Wu, Feng 
> >> >> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> >> >> >> >> george.dun...@eu.citrix.com; Tian, Kevin ;
> >> xen-
> >> >> >> >> de...@lists.xen.org
> >> >> >> >> Subject: Re: [PATCH v3 4/6] Pause/Unpause the domain
> before/after
> >> >> >> assigning
> >> >> >> >> PI hooks
> >> >> >> >>
> >> >> >> >> >>> On 31.08.16 at 05:56,  wrote:
> >> >> >> >> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> >> >> >> >> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> >> >> >> >> > @@ -219,8 +219,19 @@ void vmx_pi_hooks_assign(struct domain
> *d)
> >> >> >> >> >
> >> >> >> >> >  ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
> >> >> >> >> >
> >> >> >> >> > +/*
> >> >> >> >> > + * Pausing the domain can make sure the vCPU is not
> >> >> >> >> > + * running and hence calling the hooks simultaneously
> >> >> >> >> > + * when deassigning the PI hooks. This makes sure that
> >> >> >> >> > + * all the appropriate state of PI descriptor is actually
> >> >> >> >> > + * set up for all vCPus before leaving this function.
> >> >> >> >> > + */
> >> >> >> >> > +domain_pause(d);
> >> >> >> >> > +
> >> >> >> >> >  d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
> >> >> >> >> >  d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
> >> >> >> >> > +
> >> >> >> >> > +domain_unpause(d);
> >> >> >> >> >  }
> >> >> >> >>
> >> >> >> >> First of all I'm missing a word on whether the race mentioned in
> >> >> >> >> the description and comment can actually happen. Device
> >> >> >> >> (de)assignment should already be pretty much serialized (via
> >> >> >> >> the domctl lock, and maybe also via the pcidevs one).
> >> >> >> >
> >> >> >> > The purpose of this patch is to address the race condition that
> >> >> >> > the _vCPU_ is running while we are installing these hooks. Do you
> >> >> >> > think this cannot happen?  This patch is trying to fix the issue
> >> >> >> > described at:
> >> >> >> > http://www.gossamer-threads.com/lists/xen/devel/433229
> >> >> >> > Consider that the other two hooks were installed when the VM
> >> >> >> > is created, seems no such race condition. However, according
> >> >> >> > to the discussion about patch 1 and patch 2 of series, we need
> >> >> >> > to install the other two hooks here as well,
> >> >> >>
> >> >> >> I don't think we've agreed that the creation time installation of
> >> >> >> those hooks is actually necessary. In fact your most recent
> >> >> >> response to patch 1 makes me think you now agree we don't
> >> >> >> need to do so. And hence with that precondition not holding
> >> >> >> anymore, I don't think the conclusion does.
> >> >> >
> >> >> > I think 

[Xen-devel] [libvirt test] 100715: tolerable FAIL - PUSHED

2016-09-02 Thread osstest service owner
flight 100715 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100715/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  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-amd64-libvirt-vhd 11 migrate-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-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass

version targeted for testing:
 libvirt  8540301b782a36a0721ece0fe756e7e328d61418
baseline version:
 libvirt  36f57ad7d792f9a1342d48c9977ca9f5af647d1d

Last test of basis   100671  2016-08-31 04:21:56 Z2 days
Testing same since   100686  2016-09-01 04:21:33 Z1 days2 attempts


People who touched revisions under test:
  Michal Privoznik 

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 fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd pass



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=8540301b782a36a0721ece0fe756e7e328d61418
+ . ./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 libvirt 
8540301b782a36a0721ece0fe756e7e328d61418
+ branch=libvirt
+ 

Re: [Xen-devel] xen arm64 dom0 question

2016-09-02 Thread Julien Grall



On 02/09/16 12:27, Peng Fan wrote:

Hi Julien, Stefano


Hi Peng,



On My ARM64 platform, there is 6GB memory.
0x8000 - 0xfff: 2GB
0x88000 - 0x9: 4GB

xen will alloc 1:1 mapping for Dom0 memory, so if I assign dom0_mem with a 
bigger
value, saying 2048MB or bigger. xen will alloc continus memory from higher 
address
space in the higer 4GB.

But the SD controller in my ARM64 platform has a limitation that it can only
access 32bit address space. So if Dom0 memory is at higher 4GB, SD controller
can not work as expected, because it only works when the dma address is 32bit
address.

So, Can we assign a hole in lower 32bit address space for Dom0 guest physical
memory, just as DomU? Dynamically find out a hole and size 128MB or bigger?
Or do you have any ideas?


Looking at the allocation code (allocate_memory in 
arch/arm/domain_build.c), Xen is trying to allocate as much memory as 
possible below 4GB for 32-bit domain to accommodate non-LPAE kernel.


We haven't though about devices that can only handle 32-bit address at 
that time. I think replacing "lowmen = is_32bit_domain(d)" by "lowmem = 
true" should do the job.


Note that, a proper upstream patch would require to modify the 
description of the function and potentially kill lowmen (or gate it with 
a command line parameter?).


Regards,

--
Julien Grall

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


Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Jan Beulich
>>> On 02.09.16 at 15:03,  wrote:
> On 09/02/2016 03:56 PM, Jan Beulich wrote:
> On 02.09.16 at 14:41,  wrote:
>>> On 09/02/2016 03:33 PM, Jan Beulich wrote:
>>> On 02.09.16 at 14:21,  wrote:
> On 09/02/2016 01:02 PM, Jan Beulich wrote:
>>> +/*
 + * Corresponding list of access settings for pfn_list
 + * Used only with XENMEM_access_op_set_access_multi
 + */
 +XEN_GUEST_HANDLE(uint8) access_list;
>> And for both of them - I don't think the arrays are meant to be
>> used for output? In which case they should be handles of const
>> types.
>
> Actually I can't seem to be able to find a magic combination that works.
>
> XEN_GUEST_HANDLE(const uint8) access_list; tells me:
>
> ./public/arch-x86/xen.h:53:41: error: '__guest_handle_const' does not
> name a type
>  #define __XEN_GUEST_HANDLE(name)__guest_handle_ ## name
>
> which is fair. I've tried:
>
> XEN_GUEST_HANDLE(const_uint8) access_list;
>
> which does go further with the compilation process, but still kills it 
> with:
>
> xen/include/compat/memory.h:154:5: error: unknown type name
> '__compat_handle_const_uint8'
>  COMPAT_HANDLE(const_uint8) access_list;
>
> What would be the appropriate const type to use here?

 This one. Did you check that handle actually gets created? Per
 my brief checking it doesn't look so. And neither the native one.
>>>
>>> Running ./configure again, followed by 'make clean' and a new 'make
>>> dist' didn't help, so if it's supposed to be generated automatically it
>>> doesn't seem to be (or I'm doing something wrong). I'll investigate more.
>> 
>> The compat one is supposed to get auto-generated once the native
>> one is there.
> 
> Changing both handles to XEN_GUEST_HANLDE(const_void) compiles cleanly.
> As soon as I change to either XEN_GUEST_HANLDE(const_uint8) or
> XEN_GUEST_HANLDE(const_uint64) I start getting errors.
> 
> Previously the auto-generation seems to have worked fine, so this is
> likely something more subtle.

Oh, I see where the issue is: Both DEFINE_XEN_GUEST_HANDLE()
and __DEFINE_XEN_GUEST_HANDLE() auto-magically produce const
counterparts, but while DEFINE_COMPAT_HANDLE() does too,
__DEFINE_COMPAT_HANDLE() doesn't. That'll need fixing, I think.

Jan


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


Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 1/3] altp2m cleanup work

2016-09-02 Thread Jan Beulich
>>> On 19.08.16 at 19:22,  wrote:
> @@ -5213,12 +5213,25 @@ static int do_altp2m_op(
>  return -EFAULT;
>  
>  if ( a.pad1 || a.pad2 ||
> - (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
> - (a.cmd < HVMOP_altp2m_get_domain_state) ||
> - (a.cmd > HVMOP_altp2m_change_gfn) )
> +(a.version != HVMOP_ALTP2M_INTERFACE_VERSION) )
>  return -EINVAL;
>  
> -d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
> +switch( a.cmd )

Missing blank.

> +{
> +case HVMOP_altp2m_get_domain_state:
> +case HVMOP_altp2m_set_domain_state:
> +case HVMOP_altp2m_vcpu_enable_notify:
> +case HVMOP_altp2m_create_p2m:
> +case HVMOP_altp2m_destroy_p2m:
> +case HVMOP_altp2m_switch_p2m:
> +case HVMOP_altp2m_set_mem_access:
> +case HVMOP_altp2m_change_gfn:
> +break;
> +default:
> +return -ENOSYS;
> +}
> +
> +d = ( a.cmd != HVMOP_altp2m_vcpu_enable_notify ) ?
>  rcu_lock_domain_by_any_id(a.domain) : rcu_lock_current_domain();
>  
>  if ( d == NULL )
> @@ -5335,6 +5348,8 @@ static int do_altp2m_op(
>  rc = p2m_change_altp2m_gfn(d, a.u.change_gfn.view,
>  _gfn(a.u.change_gfn.old_gfn),
>  _gfn(a.u.change_gfn.new_gfn));
> +default:
> +return -EINVAL;
>  }

Together with the earlier switch() this is dead code. So if anything,
ASSERT_UNREACHABLE() please.

>  /* emulates #VE */
> -bool_t altp2m_vcpu_emulate_ve(struct vcpu *v);
> +static inline bool_t altp2m_vcpu_emulate_ve(struct vcpu *v)
> +{
> +if ( hvm_funcs.altp2m_vcpu_emulate_ve )
> +return hvm_funcs.altp2m_vcpu_emulate_ve(v);
> +return 0;
> +}

Since you already touch this, plain "bool" and "false" please.

Jan


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


Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Razvan Cojocaru
On 09/02/2016 03:56 PM, Jan Beulich wrote:
 On 02.09.16 at 14:41,  wrote:
>> On 09/02/2016 03:33 PM, Jan Beulich wrote:
>> On 02.09.16 at 14:21,  wrote:
 On 09/02/2016 01:02 PM, Jan Beulich wrote:
>> +/*
>>> + * Corresponding list of access settings for pfn_list
>>> + * Used only with XENMEM_access_op_set_access_multi
>>> + */
>>> +XEN_GUEST_HANDLE(uint8) access_list;
> And for both of them - I don't think the arrays are meant to be
> used for output? In which case they should be handles of const
> types.

 Actually I can't seem to be able to find a magic combination that works.

 XEN_GUEST_HANDLE(const uint8) access_list; tells me:

 ./public/arch-x86/xen.h:53:41: error: '__guest_handle_const' does not
 name a type
  #define __XEN_GUEST_HANDLE(name)__guest_handle_ ## name

 which is fair. I've tried:

 XEN_GUEST_HANDLE(const_uint8) access_list;

 which does go further with the compilation process, but still kills it 
 with:

 xen/include/compat/memory.h:154:5: error: unknown type name
 '__compat_handle_const_uint8'
  COMPAT_HANDLE(const_uint8) access_list;

 What would be the appropriate const type to use here?
>>>
>>> This one. Did you check that handle actually gets created? Per
>>> my brief checking it doesn't look so. And neither the native one.
>>
>> Running ./configure again, followed by 'make clean' and a new 'make
>> dist' didn't help, so if it's supposed to be generated automatically it
>> doesn't seem to be (or I'm doing something wrong). I'll investigate more.
> 
> The compat one is supposed to get auto-generated once the native
> one is there.

Changing both handles to XEN_GUEST_HANLDE(const_void) compiles cleanly.
As soon as I change to either XEN_GUEST_HANLDE(const_uint8) or
XEN_GUEST_HANLDE(const_uint64) I start getting errors.

Previously the auto-generation seems to have worked fine, so this is
likely something more subtle.


Thanks,
Razvan

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


Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Jan Beulich
>>> On 02.09.16 at 14:41,  wrote:
> On 09/02/2016 03:33 PM, Jan Beulich wrote:
> On 02.09.16 at 14:21,  wrote:
>>> On 09/02/2016 01:02 PM, Jan Beulich wrote:
> +/*
>> + * Corresponding list of access settings for pfn_list
>> + * Used only with XENMEM_access_op_set_access_multi
>> + */
>> +XEN_GUEST_HANDLE(uint8) access_list;
 And for both of them - I don't think the arrays are meant to be
 used for output? In which case they should be handles of const
 types.
>>>
>>> Actually I can't seem to be able to find a magic combination that works.
>>>
>>> XEN_GUEST_HANDLE(const uint8) access_list; tells me:
>>>
>>> ./public/arch-x86/xen.h:53:41: error: '__guest_handle_const' does not
>>> name a type
>>>  #define __XEN_GUEST_HANDLE(name)__guest_handle_ ## name
>>>
>>> which is fair. I've tried:
>>>
>>> XEN_GUEST_HANDLE(const_uint8) access_list;
>>>
>>> which does go further with the compilation process, but still kills it with:
>>>
>>> xen/include/compat/memory.h:154:5: error: unknown type name
>>> '__compat_handle_const_uint8'
>>>  COMPAT_HANDLE(const_uint8) access_list;
>>>
>>> What would be the appropriate const type to use here?
>> 
>> This one. Did you check that handle actually gets created? Per
>> my brief checking it doesn't look so. And neither the native one.
> 
> Running ./configure again, followed by 'make clean' and a new 'make
> dist' didn't help, so if it's supposed to be generated automatically it
> doesn't seem to be (or I'm doing something wrong). I'll investigate more.

The compat one is supposed to get auto-generated once the native
one is there.

Jan


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


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

2016-09-02 Thread osstest service owner
flight 100721 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100721/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 8953d69a5ca7f18f80f46e67da95c2527ca6ee89
baseline version:
 ovmf 4a2aaff2fca69d9f41c5b8906699ba242278cbaa

Last test of basis   100719  2016-09-02 07:17:48 Z0 days
Testing same since   100721  2016-09-02 10:46:07 Z0 days1 attempts


People who touched revisions under test:
  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=8953d69a5ca7f18f80f46e67da95c2527ca6ee89
+ . ./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 
8953d69a5ca7f18f80f46e67da95c2527ca6ee89
+ branch=ovmf
+ revision=8953d69a5ca7f18f80f46e67da95c2527ca6ee89
+ . ./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.7-testing
+ '[' x8953d69a5ca7f18f80f46e67da95c2527ca6ee89 = 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/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

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

2016-09-02 Thread Platform Team regression test user
This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 4a2aaff2fca69d9f41c5b8906699ba242278cbaa
baseline version:
 ovmf b8922094f6f8b5293f01a09035b74463fff12320

Last test of basis67624  2016-09-02 05:18:08 Z0 days
Testing same since67626  2016-09-02 10:46:31 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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 4a2aaff2fca69d9f41c5b8906699ba242278cbaa
Author: Ard Biesheuvel 
Date:   Wed Aug 17 16:36:42 2016 +0200

MdeModulePkg/EbcDxe AARCH64: simplify interpreter entry point thunks

The prototypes of EbcInterpret() and ExecuteEbcImageEntryPoint() are
private to the AARCH64 implementation of EbcDxe, so we can shuffle
the arguments around a bit and make the assembler thunking glue a lot
simpler.

For ExecuteEbcImageEntryPoint(), this involves passing the EntryPoint
argument as the third parameter, rather than the first, which allows
us to do a tail call. For EbcInterpret(), instead of copying each
argument beyond #8 from one native stack frame to the next (before
another copy is made into the VM stack), pass a pointer to the
argument stack.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 
Reviewed-by: Feng Tian 

commit 3226e315d20c6f572de818d6d1229a88b5b6e7b3
Author: Ard Biesheuvel 
Date:   Wed Aug 17 16:29:09 2016 +0200

MdeModulePkg/EbcDxe AARCH64: use tail call for EBC to native thunk

Instead of pessimistically copying at least 64 bytes from the VM stack
to the native stack, and popping off the register arguments again
before doing the native call, try to avoid touching the stack completely
if the VM stack frame is <= 64 bytes. Also, if the stack frame does exceed
64 bytes, there is no need to copy the first 64 bytes, since we are passing
those in registers anyway.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 
Reviewed-by: Feng Tian 

commit 4d1f5a214bb3c7904c26f2634294dee2a18be5d3
Author: Ard Biesheuvel 
Date:   Wed Aug 17 16:24:52 2016 +0200

MdeModulePkg/EbcDxe AARCH64: use a fixed size thunk structure

The thunk generation is needlessly complex, given that it attempts to
deal with variable length instructions, which don't exist on AArch64.

So replace it with a simple template coded in assembler, with a matching
struct definition in C. That way, we can create and manipulate the thunks
easily without looping over the instructions looking for 'magic' numbers.

Also, use x16 rather than x9, since it is the architectural register to
use for thunks/veneers.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 
Reviewed-by: Feng Tian 

commit 72b0eaa02679de8a0f0984a4d41ed1386262f3f3
Author: Ard Biesheuvel 
Date:   Wed Aug 17 16:08:21 2016 +0200

MdeModulePkg/EbcDxe AARCH64: clean up comment style in ASM file

Change to consistent // style comments. Also, remove bogus global
definitions for external 

Re: [Xen-devel] [PATCH 23/24] xen: credit2: optimize runq_tickle() a little bit

2016-09-02 Thread anshul makkar

On 17/08/16 18:20, Dario Faggioli wrote:

By not looking at the same cpu (to check whether
we want to preempt who's running there) twice, if
the vcpu being woken up has both soft and hard
affinity.

In fact, all the cpus that are part of both soft
affinity and hard-affinity (of the waking vcpu)
are checked during the soft-affinity balancing
step. If none turns out to be suitable, e.g.,
because they're running vcpus with higher credits,
there's no point in re-checking them, only to
re-assess the same, during the hard-affinity
step.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
  xen/common/sched_credit2.c |   43 +++
  1 file changed, 39 insertions(+), 4 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 6963872..f03ecce 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -997,7 +997,7 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
  s_time_t lowest = (1<<30);
  unsigned int bs, cpu = new->vcpu->processor;
  struct csched2_runqueue_data *rqd = RQD(ops, cpu);
-cpumask_t mask;
+cpumask_t mask, skip_mask;
  struct csched2_vcpu * cur;

  ASSERT(new->rqd == rqd);
@@ -1017,6 +1017,13 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
  (unsigned char *));
  }

+/*
+ * Cpus that end up in this mask, have been already checked during the
+ * soft-affinity step, and need not to be checked again when doing hard
+ * affinity.
+ */
+cpumask_clear(_mask);
+
  for_each_affinity_balance_step( bs )
  {
  /*
@@ -1073,7 +1080,8 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
  cpumask_andnot(, >active, >idle);
  cpumask_andnot(, , >tickled);
  cpumask_and(, , cpumask_scratch);
-if ( cpumask_test_cpu(cpu, ) )
+if ( cpumask_test_cpu(cpu, ) &&
+ !cpumask_test_cpu(cpu, _mask) )
  {
  cur = CSCHED2_VCPU(curr_on_cpu(cpu));

@@ -1102,13 +1110,26 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
  ipid = cpu;
  goto tickle;
  }
+
+/*
+ * If we're here, cpu is just not a valid candidate for being
+ * tickled. Set its bit in skip_mask, to avoid calling
+ * burn_credits() and check its current vcpu for preemption
+ * twice.
+ */
+__cpumask_set_cpu(cpu, _mask);
  }
  }

  for_each_cpu(i, )
  {
-/* Already looked at this one above */
-if ( i == cpu )
+/*
+ * Already looked at these ones above, either because it's the
+ * cpu where new was running before, or because we are at the
+ * hard-affinity step, and we checked this during the
+ * soft-affinity one
+ */
Sorry for my naiveness here, but can we be sure that situation has not 
changed since we checked during soft-affinity step. ?

+if ( i == cpu || cpumask_test_cpu(i, _mask) )
  continue;

  cur = CSCHED2_VCPU(curr_on_cpu(i));
@@ -1139,6 +1160,20 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
  ipid = i;
  lowest = cur->credit;
  }
+
+/*
+ * No matter if i is the new lowest or not. We've run
+ * burn_credits() on it, and we've checked it for preemption.
+ *
+ * If we are at soft-affinity balancing step, and i is indeed
+ * the lowest, it will be tickled (and we exit the function).
+ * If it is not the lowest among the cpus in the soft-affinity
+ * mask, it can't be the lowest among the cpus in the hard
+ * affinity mask (assuming we'll actually do the second
+ * balancing step), as hard-affinity is a superset of soft
+ * affinity, and therefore we can flag it to be skipped.
+ */
+__cpumask_set_cpu(i, _mask);
  }
  }





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


Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Razvan Cojocaru
On 09/02/2016 03:33 PM, Jan Beulich wrote:
 On 02.09.16 at 14:21,  wrote:
>> On 09/02/2016 01:02 PM, Jan Beulich wrote:
 +/*
> + * Corresponding list of access settings for pfn_list
> + * Used only with XENMEM_access_op_set_access_multi
> + */
> +XEN_GUEST_HANDLE(uint8) access_list;
>>> And for both of them - I don't think the arrays are meant to be
>>> used for output? In which case they should be handles of const
>>> types.
>>
>> Actually I can't seem to be able to find a magic combination that works.
>>
>> XEN_GUEST_HANDLE(const uint8) access_list; tells me:
>>
>> ./public/arch-x86/xen.h:53:41: error: '__guest_handle_const' does not
>> name a type
>>  #define __XEN_GUEST_HANDLE(name)__guest_handle_ ## name
>>
>> which is fair. I've tried:
>>
>> XEN_GUEST_HANDLE(const_uint8) access_list;
>>
>> which does go further with the compilation process, but still kills it with:
>>
>> xen/include/compat/memory.h:154:5: error: unknown type name
>> '__compat_handle_const_uint8'
>>  COMPAT_HANDLE(const_uint8) access_list;
>>
>> What would be the appropriate const type to use here?
> 
> This one. Did you check that handle actually gets created? Per
> my brief checking it doesn't look so. And neither the native one.

Running ./configure again, followed by 'make clean' and a new 'make
dist' didn't help, so if it's supposed to be generated automatically it
doesn't seem to be (or I'm doing something wrong). I'll investigate more.


Thanks,
Razvan

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


Re: [Xen-devel] fail to register IRQ for virtualization exception

2016-09-02 Thread Big Strong
Or should I modify the linux kernel to add support for handling #VE
exception?

2016-09-02 16:35 GMT+08:00 Big Strong :

> Sorry for that. Could you give any suggestions on how to register the IRQ
> handler for #VE?
>
> 2016-09-02 15:52 GMT+08:00 Jan Beulich :
>
>> >>> On 02.09.16 at 04:59,  wrote:
>> > I'm recently trying to utilize the virtualization exception (#VE)
>> feature.
>> > As the document says, #VE is handled by guest interrupt handler. The IRQ
>> > number of #VE is 20. However, when I tried to register an IRQ handler
>> for
>> > #VE, it returns errno -22, which means invalid arguments.
>> >
>> > request_irq(20, ve_handler, IRQF_NO_SUSPEND, "ve", NULL)
>> >
>> > Is there anything wrong?
>>
>> You're mixing up exception vectors and IRQ numbers.
>>
>> Jan
>>
>>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Jan Beulich
>>> On 02.09.16 at 14:21,  wrote:
> On 09/02/2016 01:02 PM, Jan Beulich wrote:
>>> +/*
>>> > + * Corresponding list of access settings for pfn_list
>>> > + * Used only with XENMEM_access_op_set_access_multi
>>> > + */
>>> > +XEN_GUEST_HANDLE(uint8) access_list;
>> And for both of them - I don't think the arrays are meant to be
>> used for output? In which case they should be handles of const
>> types.
> 
> Actually I can't seem to be able to find a magic combination that works.
> 
> XEN_GUEST_HANDLE(const uint8) access_list; tells me:
> 
> ./public/arch-x86/xen.h:53:41: error: '__guest_handle_const' does not
> name a type
>  #define __XEN_GUEST_HANDLE(name)__guest_handle_ ## name
> 
> which is fair. I've tried:
> 
> XEN_GUEST_HANDLE(const_uint8) access_list;
> 
> which does go further with the compilation process, but still kills it with:
> 
> xen/include/compat/memory.h:154:5: error: unknown type name
> '__compat_handle_const_uint8'
>  COMPAT_HANDLE(const_uint8) access_list;
> 
> What would be the appropriate const type to use here?

This one. Did you check that handle actually gets created? Per
my brief checking it doesn't look so. And neither the native one.

Jan


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


[Xen-devel] [PATCH v2] xen/pciback: support driver_override

2016-09-02 Thread Juergen Gross
Support the driver_override scheme introduced with commit 782a985d7af2
("PCI: Introduce new device binding path using pci_dev.driver_override")

As pcistub_probe() is called for all devices (it has to check for a
match based on the slot address rather than device type) it has to
check for driver_override set to "pciback" itself.

Signed-off-by: Juergen Gross 
---
V2: removed now unused label
---
 drivers/xen/xen-pciback/pci_stub.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c 
b/drivers/xen/xen-pciback/pci_stub.c
index 258b7c3..85c28f7 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -25,6 +25,8 @@
 #include "conf_space.h"
 #include "conf_space_quirks.h"
 
+#define PCISTUB_DRIVER_NAME "pciback"
+
 static char *pci_devs_to_hide;
 wait_queue_head_t xen_pcibk_aer_wait_queue;
 /*Add sem for sync AER handling and xen_pcibk remove/reconfigue ops,
@@ -529,16 +531,18 @@ static int pcistub_probe(struct pci_dev *dev, const 
struct pci_device_id *id)
"don't have a normal (0) or bridge (1) "
"header type!\n");
err = -ENODEV;
-   goto out;
}
 
+   } else if (!dev->driver_override ||
+  strcmp(dev->driver_override, PCISTUB_DRIVER_NAME))
+   /* Didn't find the device */
+   err = -ENODEV;
+
+   if (!err) {
dev_info(>dev, "seizing device\n");
err = pcistub_seize(dev);
-   } else
-   /* Didn't find the device */
-   err = -ENODEV;
+   }
 
-out:
return err;
 }
 
@@ -945,7 +949,7 @@ static const struct pci_error_handlers 
xen_pcibk_error_handler = {
 static struct pci_driver xen_pcibk_pci_driver = {
/* The name should be xen_pciback, but until the tools are updated
 * we will keep it as pciback. */
-   .name = "pciback",
+   .name = PCISTUB_DRIVER_NAME,
.id_table = pcistub_ids,
.probe = pcistub_probe,
.remove = pcistub_remove,
-- 
2.6.6


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


Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

2016-09-02 Thread Andrew Cooper
On 02/09/16 13:26, Jan Beulich wrote:
 On 02.09.16 at 14:13,  wrote:
>> On 02/09/16 13:06, Jan Beulich wrote:
>> On 02.09.16 at 14:01,  wrote:
 On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote:
 On 02.09.16 at 13:47,  wrote:
> Since this is a config option - why bother issuing a warning and
> tainting the hypervisor?
>
 Because there isn't a clear indicator if gcov is enabled.

 I think it would be valuable to just tell from the backtrace or console
 log that gcov is enabled, then we can legitimately refuse to provide
 (security) support for such builds.
>>> Then perhaps making it match the "debug=" would be the better
>>> approach for a feature not controlled on the command line?
>> I would prefer not to make it depend on debug=
>>
>> Coverage on a release hypervisor is equally important, and will be
>> different from a debug hypervisor.
> I didn't say "depend on", but "match" (which I mean just logging wise).
>
>> I am on the fence as to whether a taint is right to use, but I do think
>> that a "with GCOV" is needed somewhere obvious on the banner line.
> Right, hence the matching goal with "debug=".

Ah - I see what you mean.  Yes - that would be fine by me.

~Andrew

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


Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

2016-09-02 Thread Jan Beulich
>>> On 02.09.16 at 14:13,  wrote:
> On 02/09/16 13:06, Jan Beulich wrote:
> On 02.09.16 at 14:01,  wrote:
>>> On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote:
>>> On 02.09.16 at 13:47,  wrote:
 Since this is a config option - why bother issuing a warning and
 tainting the hypervisor?

>>> Because there isn't a clear indicator if gcov is enabled.
>>>
>>> I think it would be valuable to just tell from the backtrace or console
>>> log that gcov is enabled, then we can legitimately refuse to provide
>>> (security) support for such builds.
>> Then perhaps making it match the "debug=" would be the better
>> approach for a feature not controlled on the command line?
> 
> I would prefer not to make it depend on debug=
> 
> Coverage on a release hypervisor is equally important, and will be
> different from a debug hypervisor.

I didn't say "depend on", but "match" (which I mean just logging wise).

> I am on the fence as to whether a taint is right to use, but I do think
> that a "with GCOV" is needed somewhere obvious on the banner line.

Right, hence the matching goal with "debug=".

Jan


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


Re: [Xen-devel] [PATCH] xen/pciback: support driver_override

2016-09-02 Thread kbuild test robot
Hi Juergen,

[auto build test WARNING on xen-tip/linux-next]
[also build test WARNING on v4.8-rc4 next-20160825]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Juergen-Gross/xen-pciback-support-driver_override/20160902-195956
base:   https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git linux-next
config: x86_64-randconfig-x001-201635 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/xen/xen-pciback/pci_stub.c: In function 'pcistub_probe':
>> drivers/xen/xen-pciback/pci_stub.c:545:1: warning: label 'out' defined but 
>> not used [-Wunused-label]
out:
^~~

vim +/out +545 drivers/xen/xen-pciback/pci_stub.c

30edc14b Konrad Rzeszutek Wilk 2009-10-13  529  && 
dev->hdr_type != PCI_HEADER_TYPE_BRIDGE) {
30edc14b Konrad Rzeszutek Wilk 2009-10-13  530  
dev_err(>dev, "can't export pci devices that "
30edc14b Konrad Rzeszutek Wilk 2009-10-13  531  
"don't have a normal (0) or bridge (1) "
30edc14b Konrad Rzeszutek Wilk 2009-10-13  532  
"header type!\n");
30edc14b Konrad Rzeszutek Wilk 2009-10-13  533  err = 
-ENODEV;
30edc14b Konrad Rzeszutek Wilk 2009-10-13  534  }
30edc14b Konrad Rzeszutek Wilk 2009-10-13  535  
c77427ce Juergen Gross 2016-09-02  536  } else if 
(!dev->driver_override ||
c77427ce Juergen Gross 2016-09-02  537 
strcmp(dev->driver_override, PCISTUB_DRIVER_NAME))
30edc14b Konrad Rzeszutek Wilk 2009-10-13  538  /* Didn't find 
the device */
30edc14b Konrad Rzeszutek Wilk 2009-10-13  539  err = -ENODEV;
30edc14b Konrad Rzeszutek Wilk 2009-10-13  540  
c77427ce Juergen Gross 2016-09-02  541  if (!err) {
c77427ce Juergen Gross 2016-09-02  542  
dev_info(>dev, "seizing device\n");
c77427ce Juergen Gross 2016-09-02  543  err = 
pcistub_seize(dev);
c77427ce Juergen Gross 2016-09-02  544  }
30edc14b Konrad Rzeszutek Wilk 2009-10-13 @545  out:
30edc14b Konrad Rzeszutek Wilk 2009-10-13  546  return err;
30edc14b Konrad Rzeszutek Wilk 2009-10-13  547  }
30edc14b Konrad Rzeszutek Wilk 2009-10-13  548  
24d8bf1b Konrad Rzeszutek Wilk 2014-04-21  549  /* Called when 'unbind'. This 
means we must _NOT_ call pci_reset_function or
24d8bf1b Konrad Rzeszutek Wilk 2014-04-21  550   * other functions that take 
the sysfs lock. */
30edc14b Konrad Rzeszutek Wilk 2009-10-13  551  static void 
pcistub_remove(struct pci_dev *dev)
30edc14b Konrad Rzeszutek Wilk 2009-10-13  552  {
30edc14b Konrad Rzeszutek Wilk 2009-10-13  553  struct pcistub_device 
*psdev, *found_psdev = NULL;

:: The code at line 545 was first introduced by commit
:: 30edc14bf39afde24ef7db2de66c91805db80828 xen/pciback: xen pci backend 
driver.

:: TO: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
:: CC: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Razvan Cojocaru
On 09/02/2016 01:02 PM, Jan Beulich wrote:
>> +/*
>> > + * Corresponding list of access settings for pfn_list
>> > + * Used only with XENMEM_access_op_set_access_multi
>> > + */
>> > +XEN_GUEST_HANDLE(uint8) access_list;
> And for both of them - I don't think the arrays are meant to be
> used for output? In which case they should be handles of const
> types.

Actually I can't seem to be able to find a magic combination that works.

XEN_GUEST_HANDLE(const uint8) access_list; tells me:

./public/arch-x86/xen.h:53:41: error: '__guest_handle_const' does not
name a type
 #define __XEN_GUEST_HANDLE(name)__guest_handle_ ## name

which is fair. I've tried:

XEN_GUEST_HANDLE(const_uint8) access_list;

which does go further with the compilation process, but still kills it with:

xen/include/compat/memory.h:154:5: error: unknown type name
'__compat_handle_const_uint8'
 COMPAT_HANDLE(const_uint8) access_list;

What would be the appropriate const type to use here?


Thanks,
Razvan

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


Re: [Xen-devel] [PATCH 0/5] gcov: more cleanup

2016-09-02 Thread Andrew Cooper
On 02/09/16 13:06, Wei Liu wrote:
> On Fri, Sep 02, 2016 at 01:04:45PM +0100, Andrew Cooper wrote:
>> On 02/09/16 12:47, Wei Liu wrote:
>>> This series further cleans up existing gcov code. It should be now clear 
>>> that
>>> Xen's gcov is using gcc 3.4 format.
>>>
>>> I have tried to integrate gcc 4.7 format. The amount of work is moderate in
>>> terms of coding effort, but I now believe it is a mistake to have invented 
>>> xen
>>> specific format which is in fact tied to gcc 3.4. I can't map gcc 4.7 
>>> format to
>>> Xen's own format, so I stop here.
>> Given that the interface has clearly bitrotten since it was first
>> introduced, I think it is reasonable to declare amnesty to fix it properly.
>>
>> As the format is chosen at configure time, I think it is reasonable for
>> the Xen interface to just hand back blobs, and require the tools in dom0
>> to know how to interpret them.
>>
> Yes. I think that's how I would do it. But I don't have time for it now.

That's perfectly ok.  Thanks for getting this far.

~Andrew

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


Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

2016-09-02 Thread Andrew Cooper
On 02/09/16 13:06, Jan Beulich wrote:
 On 02.09.16 at 14:01,  wrote:
>> On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote:
>> On 02.09.16 at 13:47,  wrote:
>>> Since this is a config option - why bother issuing a warning and
>>> tainting the hypervisor?
>>>
>> Because there isn't a clear indicator if gcov is enabled.
>>
>> I think it would be valuable to just tell from the backtrace or console
>> log that gcov is enabled, then we can legitimately refuse to provide
>> (security) support for such builds.
> Then perhaps making it match the "debug=" would be the better
> approach for a feature not controlled on the command line?

I would prefer not to make it depend on debug=

Coverage on a release hypervisor is equally important, and will be
different from a debug hypervisor.

I am on the fence as to whether a taint is right to use, but I do think
that a "with GCOV" is needed somewhere obvious on the banner line.

~Andrew

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


Re: [Xen-devel] [PATCH 2/5] gcov: collect more sections to constructor list

2016-09-02 Thread Wei Liu
On Fri, Sep 02, 2016 at 05:58:43AM -0600, Jan Beulich wrote:
> >>> On 02.09.16 at 13:47,  wrote:
> > --- a/xen/arch/x86/xen.lds.S
> > +++ b/xen/arch/x86/xen.lds.S
> > @@ -205,6 +205,8 @@ SECTIONS
> > . = ALIGN(8);
> > __ctors_start = .;
> > *(.ctors)
> > +   *(SORT(.init_array.*))
> > +   *(.init_array)
> > __ctors_end = .;
> >} :text
> 
> Is the ordering meaningful? If so, a comment is warranted. If not,
> elsewhere we have  precede .* .
> 

I don't think the order matters.

I will swap the position of the two entries.

Wei.

> Jan
> 

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


Re: [Xen-devel] [PATCH 4/5] gcov: add option to determine gcov format

2016-09-02 Thread Wei Liu
On Fri, Sep 02, 2016 at 06:01:22AM -0600, Jan Beulich wrote:
> >>> On 02.09.16 at 13:47,  wrote:
> > Currently only gcc 3.4 format is supported.
> 
> Doesn't this patch contradict your coverage letter? Here you provide
> means to add support for further formats, but there you said there's
> no obvious route to that goal.
> 

There is a way, we can ditch the old interface and just hand back the
blob.

Wei.

> Jan
> 

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


Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

2016-09-02 Thread Jan Beulich
>>> On 02.09.16 at 14:01,  wrote:
> On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote:
>> >>> On 02.09.16 at 13:47,  wrote:
>> 
>> Since this is a config option - why bother issuing a warning and
>> tainting the hypervisor?
>> 
> 
> Because there isn't a clear indicator if gcov is enabled.
> 
> I think it would be valuable to just tell from the backtrace or console
> log that gcov is enabled, then we can legitimately refuse to provide
> (security) support for such builds.

Then perhaps making it match the "debug=" would be the better
approach for a feature not controlled on the command line?

Jan


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


Re: [Xen-devel] [PATCH 0/5] gcov: more cleanup

2016-09-02 Thread Wei Liu
On Fri, Sep 02, 2016 at 01:04:45PM +0100, Andrew Cooper wrote:
> On 02/09/16 12:47, Wei Liu wrote:
> > This series further cleans up existing gcov code. It should be now clear 
> > that
> > Xen's gcov is using gcc 3.4 format.
> >
> > I have tried to integrate gcc 4.7 format. The amount of work is moderate in
> > terms of coding effort, but I now believe it is a mistake to have invented 
> > xen
> > specific format which is in fact tied to gcc 3.4. I can't map gcc 4.7 
> > format to
> > Xen's own format, so I stop here.
> 
> Given that the interface has clearly bitrotten since it was first
> introduced, I think it is reasonable to declare amnesty to fix it properly.
> 
> As the format is chosen at configure time, I think it is reasonable for
> the Xen interface to just hand back blobs, and require the tools in dom0
> to know how to interpret them.
> 

Yes. I think that's how I would do it. But I don't have time for it now.

Wei.

> ~Andrew

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


Re: [Xen-devel] [PATCH 0/5] gcov: more cleanup

2016-09-02 Thread Andrew Cooper
On 02/09/16 12:47, Wei Liu wrote:
> This series further cleans up existing gcov code. It should be now clear that
> Xen's gcov is using gcc 3.4 format.
>
> I have tried to integrate gcc 4.7 format. The amount of work is moderate in
> terms of coding effort, but I now believe it is a mistake to have invented xen
> specific format which is in fact tied to gcc 3.4. I can't map gcc 4.7 format 
> to
> Xen's own format, so I stop here.

Given that the interface has clearly bitrotten since it was first
introduced, I think it is reasonable to declare amnesty to fix it properly.

As the format is chosen at configure time, I think it is reasonable for
the Xen interface to just hand back blobs, and require the tools in dom0
to know how to interpret them.

~Andrew

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


Re: [Xen-devel] [PATCH 4/5] gcov: add option to determine gcov format

2016-09-02 Thread Jan Beulich
>>> On 02.09.16 at 13:47,  wrote:
> Currently only gcc 3.4 format is supported.

Doesn't this patch contradict your coverage letter? Here you provide
means to add support for further formats, but there you said there's
no obvious route to that goal.

Jan


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


Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

2016-09-02 Thread Wei Liu
On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote:
> >>> On 02.09.16 at 13:47,  wrote:
> 
> Since this is a config option - why bother issuing a warning and
> tainting the hypervisor?
> 

Because there isn't a clear indicator if gcov is enabled.

I think it would be valuable to just tell from the backtrace or console
log that gcov is enabled, then we can legitimately refuse to provide
(security) support for such builds.

> > --- a/xen/common/gcov/gcov.c
> > +++ b/xen/common/gcov/gcov.c
> > @@ -23,6 +23,11 @@
> >  #include 
> >  #include 
> >  
> > +const char __initconst warning_gcov[] =
> > +"WARNING: GCOV SUPPORT IS ENABLED\n"
> > +"This option is *ONLY* intended to aid testing of Xen.\n"
> > +"Please *DO NOT* use this in production.\n";
> 
> Note the type (const) difference between this and ...
> 
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -792,6 +792,10 @@ void __init console_init_postirq(void)
> >  console_init_ring();
> >  }
> >  
> > +#ifdef CONFIG_GCOV
> > +extern char warning_gcov[];
> > +#endif
> 
> ... this. That's one of the reasons declarations of stuff defined in
> C sources should be put in a header, which then gets included by
> both producer and consumer(s). But ...
> 
> > @@ -802,6 +806,11 @@ void __init console_endboot(void)
> >  printk(" (Rate-limited: %s)", 
> > loglvl_str(xenlog_guest_upper_thresh));
> >  printk("\n");
> >  
> > +#ifdef CONFIG_GCOV
> > +warning_add(warning_gcov);
> > +add_taint(TAINT_GCOV);
> > +#endif
> 
> ... (if we want this in the first place) how about
> 
> #ifdef CONFIG_GCOV
> {
> static const char __initconst warning_gcov[] = "...";
> 
> warning_add(warning_gcov);
> add_taint(TAINT_GCOV);
> }
> #endif
> 

Fine with me.

Wei.

> Jan
> 

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


Re: [Xen-devel] [PATCH 3/5] xen: replace TEST_COVERAGE with CONFIG_GCOV

2016-09-02 Thread Jan Beulich
>>> On 02.09.16 at 13:47,  wrote:
> The sole purpose of TEST_COVERAGE macro is to guard the availability of
> gcov sysctl. Now we have a proper CONFIG_GCOV, use it.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 


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


Re: [Xen-devel] [PATCH 2/5] gcov: collect more sections to constructor list

2016-09-02 Thread Jan Beulich
>>> On 02.09.16 at 13:47,  wrote:
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -205,6 +205,8 @@ SECTIONS
> . = ALIGN(8);
> __ctors_start = .;
> *(.ctors)
> +   *(SORT(.init_array.*))
> +   *(.init_array)
> __ctors_end = .;
>} :text

Is the ordering meaningful? If so, a comment is warranted. If not,
elsewhere we have  precede .* .

Jan


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


[Xen-devel] [PATCH] xen/pciback: support driver_override

2016-09-02 Thread Juergen Gross
Support the driver_override scheme introduced with commit 782a985d7af2
("PCI: Introduce new device binding path using pci_dev.driver_override")

As pcistub_probe() is called for all devices (it has to check for a
match based on the slot address rather than device type) it has to
check for driver_override set to "pciback" itself.

Signed-off-by: Juergen Gross 
---
 drivers/xen/xen-pciback/pci_stub.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c 
b/drivers/xen/xen-pciback/pci_stub.c
index 258b7c3..8193868 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -25,6 +25,8 @@
 #include "conf_space.h"
 #include "conf_space_quirks.h"
 
+#define PCISTUB_DRIVER_NAME "pciback"
+
 static char *pci_devs_to_hide;
 wait_queue_head_t xen_pcibk_aer_wait_queue;
 /*Add sem for sync AER handling and xen_pcibk remove/reconfigue ops,
@@ -529,15 +531,17 @@ static int pcistub_probe(struct pci_dev *dev, const 
struct pci_device_id *id)
"don't have a normal (0) or bridge (1) "
"header type!\n");
err = -ENODEV;
-   goto out;
}
 
+   } else if (!dev->driver_override ||
+  strcmp(dev->driver_override, PCISTUB_DRIVER_NAME))
+   /* Didn't find the device */
+   err = -ENODEV;
+
+   if (!err) {
dev_info(>dev, "seizing device\n");
err = pcistub_seize(dev);
-   } else
-   /* Didn't find the device */
-   err = -ENODEV;
-
+   }
 out:
return err;
 }
@@ -945,7 +949,7 @@ static const struct pci_error_handlers 
xen_pcibk_error_handler = {
 static struct pci_driver xen_pcibk_pci_driver = {
/* The name should be xen_pciback, but until the tools are updated
 * we will keep it as pciback. */
-   .name = "pciback",
+   .name = PCISTUB_DRIVER_NAME,
.id_table = pcistub_ids,
.probe = pcistub_probe,
.remove = pcistub_remove,
-- 
2.6.6


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


Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

2016-09-02 Thread Jan Beulich
>>> On 02.09.16 at 13:47,  wrote:

Since this is a config option - why bother issuing a warning and
tainting the hypervisor?

> --- a/xen/common/gcov/gcov.c
> +++ b/xen/common/gcov/gcov.c
> @@ -23,6 +23,11 @@
>  #include 
>  #include 
>  
> +const char __initconst warning_gcov[] =
> +"WARNING: GCOV SUPPORT IS ENABLED\n"
> +"This option is *ONLY* intended to aid testing of Xen.\n"
> +"Please *DO NOT* use this in production.\n";

Note the type (const) difference between this and ...

> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -792,6 +792,10 @@ void __init console_init_postirq(void)
>  console_init_ring();
>  }
>  
> +#ifdef CONFIG_GCOV
> +extern char warning_gcov[];
> +#endif

... this. That's one of the reasons declarations of stuff defined in
C sources should be put in a header, which then gets included by
both producer and consumer(s). But ...

> @@ -802,6 +806,11 @@ void __init console_endboot(void)
>  printk(" (Rate-limited: %s)", loglvl_str(xenlog_guest_upper_thresh));
>  printk("\n");
>  
> +#ifdef CONFIG_GCOV
> +warning_add(warning_gcov);
> +add_taint(TAINT_GCOV);
> +#endif

... (if we want this in the first place) how about

#ifdef CONFIG_GCOV
{
static const char __initconst warning_gcov[] = "...";

warning_add(warning_gcov);
add_taint(TAINT_GCOV);
}
#endif

Jan


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


[Xen-devel] [PATCH 0/5] gcov: more cleanup

2016-09-02 Thread Wei Liu
This series further cleans up existing gcov code. It should be now clear that
Xen's gcov is using gcc 3.4 format.

I have tried to integrate gcc 4.7 format. The amount of work is moderate in
terms of coding effort, but I now believe it is a mistake to have invented xen
specific format which is in fact tied to gcc 3.4. I can't map gcc 4.7 format to
Xen's own format, so I stop here.

Wei.

Wei Liu (5):
  xen: add tainted state and show warning is gcov is enabled
  gcov: collect more sections to constructor list
  xen: replace TEST_COVERAGE with CONFIG_GCOV
  gcov: add option to determine gcov format
  gcov: split out gcc version specific stuff

 xen/Kconfig.debug  | 13 +++
 xen/Rules.mk   |  2 +-
 xen/arch/arm/xen.lds.S |  2 ++
 xen/arch/x86/xen.lds.S |  2 ++
 xen/common/gcov/gcov.c | 69 -
 xen/common/gcov/gcov_3_4.h | 84 ++
 xen/common/kernel.c|  6 ++--
 xen/common/sysctl.c|  2 +-
 xen/drivers/char/console.c |  9 +
 xen/include/xen/gcov.h | 82 +---
 xen/include/xen/lib.h  |  1 +
 11 files changed, 164 insertions(+), 108 deletions(-)
 create mode 100644 xen/common/gcov/gcov_3_4.h

-- 
2.1.4


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


[Xen-devel] [PATCH 5/5] gcov: split out gcc version specific stuff

2016-09-02 Thread Wei Liu
Gcov record format is tied to specific gcc versions. The current code in
tree conforms to gcc 3.4 format.

Move structure definitions to a specific file and factor out some
version specific functions.

No functional change.

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/common/gcov/gcov.c | 64 ++-
 xen/common/gcov/gcov_3_4.h | 84 ++
 xen/include/xen/gcov.h | 80 ---
 3 files changed, 125 insertions(+), 103 deletions(-)
 create mode 100644 xen/common/gcov/gcov_3_4.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index 6d18729..2c2f05a 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -22,6 +22,11 @@
 #include 
 #include 
 #include 
+#if defined(CONFIG_GCOV_FORMAT_3_4)
+#include "gcov_3_4.h"
+#else
+# error Gcov format not supported
+#endif
 
 const char __initconst warning_gcov[] =
 "WARNING: GCOV SUPPORT IS ENABLED\n"
@@ -69,10 +74,13 @@ void __gcov_merge_delta(gcov_type *counters, unsigned int 
n_counters)
 /* Unused. */
 }
 
-static inline int counter_active(const struct gcov_info *info, unsigned int 
type)
+#if defined(CONFIG_GCOV_FORMAT_3_4)
+static inline int counter_active(const struct gcov_info *info,
+ unsigned int type)
 {
 return (1 << type) & info->ctr_mask;
 }
+#endif
 
 typedef struct write_iter_t
 {
@@ -122,6 +130,37 @@ static inline void align_iter(write_iter_t *iter)
 (iter->write_offset + sizeof(uint64_t) - 1) & -sizeof(uint64_t);
 }
 
+#if defined(CONFIG_GCOV_FORMAT_3_4)
+static int dump(write_iter_t *iter, const struct gcov_info *info)
+{
+const struct gcov_ctr_info *ctr;
+size_t size_fn = sizeof(struct gcov_fn_info);
+int type;
+int ret;
+
+/* dump counters */
+ctr = info->counts;
+for ( type = -1; next_type(info, ) < XENCOV_COUNTERS; ++ctr )
+{
+align_iter(iter);
+chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+chk(write32(iter, ctr->num));
+chk(write_raw(iter, ctr->values,
+  ctr->num * sizeof(ctr->values[0])));
+
+size_fn += sizeof(unsigned);
+}
+
+/* dump all functions together */
+align_iter(iter);
+chk(write32(iter, XENCOV_TAG_FUNC));
+chk(write32(iter, info->n_functions));
+chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+
+return 0;
+}
+#endif
+
 static int write_gcov(write_iter_t *iter)
 {
 struct gcov_info *info;
@@ -133,34 +172,13 @@ static int write_gcov(write_iter_t *iter)
 /* dump all files */
 for ( info = info_list ; info; info = info->next )
 {
-const struct gcov_ctr_info *ctr;
-int type;
-size_t size_fn = sizeof(struct gcov_fn_info);
-
 align_iter(iter);
 chk(write32(iter, XENCOV_TAG_FILE));
 chk(write32(iter, info->version));
 chk(write32(iter, info->stamp));
 chk(write_string(iter, info->filename));
 
-/* dump counters */
-ctr = info->counts;
-for ( type = -1; next_type(info, ) < XENCOV_COUNTERS; ++ctr )
-{
-align_iter(iter);
-chk(write32(iter, XENCOV_TAG_COUNTER(type)));
-chk(write32(iter, ctr->num));
-chk(write_raw(iter, ctr->values,
-  ctr->num * sizeof(ctr->values[0])));
-
-size_fn += sizeof(unsigned);
-}
-
-/* dump all functions together */
-align_iter(iter);
-chk(write32(iter, XENCOV_TAG_FUNC));
-chk(write32(iter, info->n_functions));
-chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+chk(dump(iter, info));
 }
 
 /* stop tag */
diff --git a/xen/common/gcov/gcov_3_4.h b/xen/common/gcov/gcov_3_4.h
new file mode 100644
index 000..e10c568
--- /dev/null
+++ b/xen/common/gcov/gcov_3_4.h
@@ -0,0 +1,84 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *Copyright IBM Corp. 2009
+ *Author(s): Peter Oberparleiter 
+ *
+ *Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_3_4_H__
+#define __XEN_GCOV_3_4_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - 

[Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

2016-09-02 Thread Wei Liu
Signed-off-by: Wei Liu 
---
The location of warning_add() is a bit arbitrary because gcov doesn't
have an initialisation routine.

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/common/gcov/gcov.c | 5 +
 xen/common/kernel.c| 6 --
 xen/drivers/char/console.c | 9 +
 xen/include/xen/lib.h  | 1 +
 4 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index b5717b9..6d18729 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -23,6 +23,11 @@
 #include 
 #include 
 
+const char __initconst warning_gcov[] =
+"WARNING: GCOV SUPPORT IS ENABLED\n"
+"This option is *ONLY* intended to aid testing of Xen.\n"
+"Please *DO NOT* use this in production.\n";
+
 static struct gcov_info *info_list;
 
 /*
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 2d3db64..324cc24 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -173,6 +173,7 @@ unsigned int tainted;
  *
  *  'C' - Console output is synchronous.
  *  'E' - An error (e.g. a machine check exceptions) has been injected.
+ *  'G' - GCov support is enabled.
  *  'H' - HVM forced emulation prefix is permitted.
  *  'M' - Machine had a machine check experience.
  *
@@ -182,11 +183,12 @@ char *print_tainted(char *str)
 {
 if ( tainted )
 {
-snprintf(str, TAINT_STRING_MAX_LEN, "Tainted: %c%c%c%c",
+snprintf(str, TAINT_STRING_MAX_LEN, "Tainted: %c%c%c%c%c",
  tainted & TAINT_MACHINE_CHECK ? 'M' : ' ',
  tainted & TAINT_SYNC_CONSOLE ? 'C' : ' ',
  tainted & TAINT_ERROR_INJECT ? 'E' : ' ',
- tainted & TAINT_HVM_FEP ? 'H' : ' ');
+ tainted & TAINT_HVM_FEP ? 'H' : ' ',
+ tainted & TAINT_GCOV ? 'G' : ' ');
 }
 else
 {
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 650035d..77604f9 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -792,6 +792,10 @@ void __init console_init_postirq(void)
 console_init_ring();
 }
 
+#ifdef CONFIG_GCOV
+extern char warning_gcov[];
+#endif
+
 void __init console_endboot(void)
 {
 printk("Std. Loglevel: %s", loglvl_str(xenlog_lower_thresh));
@@ -802,6 +806,11 @@ void __init console_endboot(void)
 printk(" (Rate-limited: %s)", loglvl_str(xenlog_guest_upper_thresh));
 printk("\n");
 
+#ifdef CONFIG_GCOV
+warning_add(warning_gcov);
+add_taint(TAINT_GCOV);
+#endif
+
 warning_print();
 
 video_endboot();
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index e518adc..7bcc910 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -143,6 +143,7 @@ uint64_t muldiv64(uint64_t a, uint32_t b, uint32_t c);
 #define TAINT_MACHINE_CHECK (1u << 1)
 #define TAINT_ERROR_INJECT  (1u << 2)
 #define TAINT_HVM_FEP   (1u << 3)
+#define TAINT_GCOV  (1u << 4)
 extern unsigned int tainted;
 #define TAINT_STRING_MAX_LEN20
 extern char *print_tainted(char *str);
-- 
2.1.4


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


[Xen-devel] [PATCH 4/5] gcov: add option to determine gcov format

2016-09-02 Thread Wei Liu
Currently only gcc 3.4 format is supported.

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/Kconfig.debug | 13 +
 1 file changed, 13 insertions(+)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 06afd80..2366b06 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -33,6 +33,19 @@ config GCOV
---help---
  Enable gcov (a test coverage program in GCC) support.
 
+choice
+   prompt "Specify Gcov format"
+   depends on GCOV
+   ---help---
+   The gcov format is determined by gcc version.
+
+config GCOV_FORMAT_3_4
+   bool "GCC 3.4 format"
+   ---help---
+   Select this option to use the format specified in GCC 3.4.
+
+endchoice
+
 config LOCK_PROFILE
bool "Lock Profiling"
---help---
-- 
2.1.4


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


[Xen-devel] [PATCH 3/5] xen: replace TEST_COVERAGE with CONFIG_GCOV

2016-09-02 Thread Wei Liu
The sole purpose of TEST_COVERAGE macro is to guard the availability of
gcov sysctl. Now we have a proper CONFIG_GCOV, use it.

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/Rules.mk   | 2 +-
 xen/common/sysctl.c| 2 +-
 xen/include/xen/gcov.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 696aaa8..a9fda71 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -116,7 +116,7 @@ subdir-all := $(subdir-y) $(subdir-n)
 $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += 
-DINIT_SECTIONS_ONLY
 
 ifeq ($(CONFIG_GCOV),y)
-$(filter-out %.init.o $(nogcov-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += 
-fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+$(filter-out %.init.o $(nogcov-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += 
-fprofile-arcs -ftest-coverage
 endif
 
 ifeq ($(lto),y)
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 55f2077..8aea6ef 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -396,7 +396,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
 }
 break;
 
-#ifdef TEST_COVERAGE
+#ifdef CONFIG_GCOV
 case XEN_SYSCTL_coverage_op:
 ret = sysctl_coverage_op(>u.coverage_op);
 break;
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index 27c5c37..a7d4a35 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -86,7 +86,7 @@ struct gcov_info
 /**
  * Sysctl operations for coverage
  */
-#ifdef TEST_COVERAGE
+#ifdef CONFIG_GCOV
 int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
 #endif
 
-- 
2.1.4


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


Re: [Xen-devel] [PATCH 19/24] xen: credit2: soft-affinity awareness in load balancing

2016-09-02 Thread anshul makkar

On 17/08/16 18:19, Dario Faggioli wrote:

We want is soft-affinity to play a role in load
balancing, i.e., when deciding whether or not to



something like that at some point.

(Oh, and while there, just a couple of style fixes
are also done.)

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
  xen/common/sched_credit2.c |  359 
  1 file changed, 326 insertions(+), 33 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 2d7228a..3722f46 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1786,19 +1786,21 @@ csched2_cpu_pick(const struct scheduler *ops, struct 
vcpu *vc)
  return new_cpu;
  }

-/* Working state of the load-balancing algorithm */
+/* Working state of the load-balancing algorithm. */
  typedef struct {
-/* NB: Modified by consider() */
+/* NB: Modified by consider(). */
  s_time_t load_delta;
  struct csched2_vcpu * best_push_svc, *best_pull_svc;
-/* NB: Read by consider() */
+/* NB: Read by consider() (and the various consider_foo() functions). */
  struct csched2_runqueue_data *lrqd;
-struct csched2_runqueue_data *orqd;
+struct csched2_runqueue_data *orqd;
+bool_t push_has_soft_aff, pull_has_soft_aff;
+s_time_t push_soft_aff_load, pull_soft_aff_load;
  } balance_state_t;

-static void consider(balance_state_t *st,
- struct csched2_vcpu *push_svc,
- struct csched2_vcpu *pull_svc)
+static inline s_time_t consider_load(balance_state_t *st,
+ struct csched2_vcpu *push_svc,
+ struct csched2_vcpu *pull_svc)
  {
  s_time_t l_load, o_load, delta;

@@ -1821,11 +1823,166 @@ static void consider(balance_state_t *st,
  if ( delta < 0 )
  delta = -delta;

+return delta;
+}
+
+/*
+ * Load balancing and soft-affinity.
+ *
+ * When trying to figure out whether or not it's best to move a vcpu from
+ * one runqueue to another, we must keep soft-affinity in mind. Intuitively
+ * we would want to know the following:
+ *  - 'how much' affinity does the vcpu have with its current runq?
+ *  - 'how much' affinity will it have with its new runq?
+ *
+ * But we certainly need to be more precise about how much it is that 'how
+ * much'! Let's start with some definitions:
+ *
+ *  - let v be a vcpu, running in runq I, with soft-affinity to vi
+ *pcpus of runq I, and soft affinity with vj pcpus of runq J;
+ *  - let k be another vcpu, running in runq J, with soft-affinity to kj
+ *pcpus of runq J, and with ki pcpus of runq I;
+ *  - let runq I have Ci pcpus, and runq J Cj pcpus;
+ *  - let vcpu v have an average load of lv, and k an average load of lk;
+ *  - let runq I have an average load of Li, and J an average load of Lj.
+ *
+ * We also define the following::
+ *
+ *  - lvi = lv * (vi / Ci)  as the 'perceived load' of v, when running
+ *  in runq i;
+ *  - lvj = lv * (vj / Cj)  as the 'perceived load' of v, it running
+ *  in runq j;
+ *  - the same for k, mutatis mutandis.
+ *
+ * Idea is that vi/Ci (i.e., the ratio of the number of cpus of a runq that
+ * a vcpu has soft-affinity with, over the total number of cpus of the runq
+ * itself) can be seen as the 'degree of soft-affinity' of v to runq I (and
+ * vj/Cj the one of v to J). In other words, we define the degree of soft
+ * affinity of a vcpu to a runq as what fraction of pcpus of the runq itself
+ * the vcpu has soft-affinity with. Then, we multiply this 'degree of
+ * soft-affinity' by the vcpu load, and call the result the 'perceived load'.
+ *
+ * Basically, if a soft-affinity is defined, the work done by a vcpu on a
+ * runq to which it has higher degree of soft-affinity, is considered
+ * 'lighter' than the same work done by the same vcpu on a runq to which it
+ * has smaller degree of soft-affinity (degree of soft affinity is <= 1). In
+ * fact, if soft-affinity is used to achieve NUMA-aware scheduling, the higher
+ * the degree of soft-affinity of the vcpu to a runq, the greater the 
probability
+ * of accessing local memory, when running on such runq. And that is certainly\
+ * 'lighter' than having to fetch memory from remote NUMA nodes.
Do we ensure that while defining soft-affinity for a vcpu, NUMA 
architecture is considered. If not, then this whole calculation can go 
wrong and have negative impact on performance.


Degree of affinity to runq will give good result if the affinity to 
pcpus has been chosen after due consideration ..

+ *
+ * SoXX, evaluating pushing v from I to J would mean removing (from I) a
+ * perceived load of lv*(vi/Ci) and adding (to J) a perceived load of
+ * lv*(vj/Cj), which we (looking at things from the point of view of I,
+ * which is what balance_load() does) can call 

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

2016-09-02 Thread Jan Beulich
>>> On 02.09.16 at 13:18,  wrote:
> On 09/02/2016 01:02 PM, Jan Beulich wrote:
> On 02.09.16 at 10:51,  wrote:
>>> Changes since V1 / RFC:
>>>  - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
>>>and XENMEM_access_op_set_access_sparse to
>>>XENMEM_access_op_set_access_multi.
>>>  - Renamed the 'nr' parameter to 'size'.
>> 
>> Why?
> 
> Tamas suggested it, size sounded more intuitive to him. I have no
> problem with either nr or size.

Size to me means something in bytes, which clearly isn't the case
here. There's not even support for other then 4k pages so far.

Jan


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


Re: [Xen-devel] [PATCH] tools: delete gtraceview and gtracestat

2016-09-02 Thread Ian Jackson
Wei Liu writes ("Re: [PATCH] tools: delete gtraceview and gtracestat"):
> On Fri, Sep 02, 2016 at 12:13:04PM +0100, George Dunlap wrote:
> > If so, it's probably just the case that the trace record format has
> > changed somewhat and these weren't updated.  It would probably be fairly
> > straightforward to fix; but if nobody's using it, I'd just as soon
> > delete it.  The "gtracestat" functionality would probably better be
> > added to xenalyze in any case.
> 
> Yes. I agree.

OK, thanks for the discussion.  I'm sold.

Acked-by: Ian Jackson 

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


[Xen-devel] xen arm64 dom0 question

2016-09-02 Thread Peng Fan
Hi Julien, Stefano


On My ARM64 platform, there is 6GB memory.
0x8000 - 0xfff: 2GB
0x88000 - 0x9: 4GB

xen will alloc 1:1 mapping for Dom0 memory, so if I assign dom0_mem with a 
bigger
value, saying 2048MB or bigger. xen will alloc continus memory from higher 
address
space in the higer 4GB.

But the SD controller in my ARM64 platform has a limitation that it can only
access 32bit address space. So if Dom0 memory is at higher 4GB, SD controller
can not work as expected, because it only works when the dma address is 32bit
address.

So, Can we assign a hole in lower 32bit address space for Dom0 guest physical
memory, just as DomU? Dynamically find out a hole and size 128MB or bigger?
Or do you have any ideas?

Thanks,
Peng.

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


Re: [Xen-devel] [PATCH] x86emul: check alignment of SSE and AVX memory operands

2016-09-02 Thread Andrew Cooper
On 02/09/16 08:49, Jan Beulich wrote:
> It only now occurred to me that there's no new hook needed to do so.
> Eliminate the two work item comments.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH] memory: fix compat handling of XENMEM_access_op

2016-09-02 Thread Andrew Cooper
On 30/08/16 10:15, Jan Beulich wrote:
> Within compat_memory_op() this needs to be placed in the first switch()
> statement, or it ends up being dead code (as that first switch() has a
> default case chaining to compat_arch_memory_op()).
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


  1   2   >