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

2016-06-30 Thread osstest service owner 
flight 96474 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96474/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 94748
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748

version targeted for testing:
 ovmf 05b39efb669eaa173a76e58daf8e65bce2e0299e
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z   37 days
Failing since 94750  2016-05-25 03:43:08 Z   36 days   78 attempts
Testing same since96474  2016-06-30 13:44:02 Z0 days1 attempts


People who touched revisions under test:
  Anandakrishnan Loganathan 
  Ard Biesheuvel 
  Bruce Cran 
  Bruce Cran 
  Chao Zhang 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Darbin Reyes 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Evgeny Yakovlev 
  Feng Tian 
  Fu Siyuan 
  Fu, Siyuan 
  Gary Li 
  Gary Lin 
  Giri P Mudusuru 
  Hao Wu 
  Hegde Nagaraj P 
  hegdenag 
  Heyi Guo 
  Jan D?bro? 
  Jan Dabros 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Joe Zhou 
  Jordan Justen 
  Katie Dellaquila 
  Laszlo Ersek 
  Liming Gao 
  Lu, ShifeiX A 
  lushifex 
  Marcin Wojtas 
  Marvin H?user 
  Marvin Haeuser 
  Maurice Ma 
  Michael Zimmermann 
  Qiu Shumin 
  Ruiyu Ni 
  Ryan Harkin 
  Sami Mujawar 
  Satya Yarlagadda 
  Shannon Zhao 
  Sriram Subramanian 
  Star Zeng 
  Sunny Wang 
  Tapan Shah 
  Thomas Palmer 
  Yarlagadda, Satya P 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

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

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

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


Not pushing.

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

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

[Xen-devel] [xen-4.3-testing test] 96460: tolerable FAIL - PUSHED

2016-06-30 Thread osstest service owner 
flight 96460 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96460/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 96378 
pass in 96460
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
96378

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail in 96378 like 87893
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 87893
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 87893

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-armhf-armhf-xl   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail never pass
 test-armhf-armhf-xl-vhd   6 xen-boot fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-armhf-armhf-libvirt  6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-armhf-armhf-xl-credit2   6 xen-boot fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass

version targeted for testing:
 xen  0a8c94fae993dd8f2b27fd4cc694f61c21de84bf
baseline version:
 xen  8fa31952e2d08ef63897c43b5e8b33475ebf5d93

Last test of basis87893  2016-03-29 13:49:52 Z   93 days
Failing since 92180  2016-04-20 17:49:21 Z   71 days   40 attempts
Testing same since96017  2016-06-20 17:22:27 Z   10 days   19 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Anthony PERARD 
  Gerd Hoffmann 
  Ian Jackson 
  Jan Beulich 
  Jim Paris 
  Stefan Hajnoczi 
  Tim Deegan 
  Wei Liu 

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

[Xen-devel] [xen-unstable test] 96459: trouble: blocked/broken/fail/pass

2016-06-30 Thread osstest service owner 
flight 96459 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96459/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 96296

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 96296
 build-amd64-rumpuserxen   6 xen-buildfail   like 96296
 build-i386-rumpuserxen6 xen-buildfail   like 96296
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 96296
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 96296
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 96296
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 96296

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  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-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 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

version targeted for testing:
 xen  3572f2fa7b0f6f20eb145bdccaf5888c76be8960
baseline version:
 xen  8384dc2d95538c5910d98db3df3ff5448bf0af48

Last test of basis96296  2016-06-27 01:55:48 Z3 days
Failing since 96315  2016-06-27 14:13:25 Z3 days5 attempts
Testing same since96459  2016-06-30 07:02:49 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Dirk Behme 
  Elena Ufimtseva 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Quan Xu 
  Razvan Cojocaru 
  Stefano Stabellini 
  Tamas K Lengyel 

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-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopsbroken  
 build-i386-pvops pass

[Xen-devel] [PATCH 8/8] minor #include change

2016-06-30 Thread Corneliu ZUZU 
Move xen/paging.h #include from hvm/monitor.h to hvm/monitor.c (include strictly
where needed) and also change to asm/paging.h (include strictly what's needed).

Signed-off-by: Corneliu ZUZU 
---
 xen/arch/x86/hvm/monitor.c| 1 +
 xen/include/asm-x86/hvm/monitor.h | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index 472926c..d81b11b 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 bool_t hvm_monitor_cr(unsigned int index, unsigned long value, unsigned long 
old)
diff --git a/xen/include/asm-x86/hvm/monitor.h 
b/xen/include/asm-x86/hvm/monitor.h
index ab433ed..6c6ea5c 100644
--- a/xen/include/asm-x86/hvm/monitor.h
+++ b/xen/include/asm-x86/hvm/monitor.h
@@ -19,7 +19,6 @@
 #ifndef __ASM_X86_HVM_MONITOR_H__
 #define __ASM_X86_HVM_MONITOR_H__
 
-#include 
 #include 
 
 enum hvm_monitor_breakpoint_type
-- 
2.5.0


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

[Xen-devel] [PATCH 7/8] minor fixes (formatting, comments, unused includes etc.)

2016-06-30 Thread Corneliu ZUZU 
Minor fixes:
 - remove some empty lines
 - remove some unused includes
 - multi-line comment fixes
 - 80-columns formatting fixes

Signed-off-by: Corneliu ZUZU 
---
 xen/arch/arm/domain.c |  1 -
 xen/arch/arm/traps.c  |  1 -
 xen/arch/x86/hvm/hvm.c|  3 ---
 xen/arch/x86/hvm/vmx/vmx.c|  2 --
 xen/arch/x86/monitor.c|  1 -
 xen/arch/x86/vm_event.c   |  3 ---
 xen/common/monitor.c  |  1 -
 xen/common/vm_event.c |  6 --
 xen/include/asm-arm/vm_event.h|  9 +++--
 xen/include/asm-x86/hvm/monitor.h |  1 -
 xen/include/asm-x86/monitor.h |  3 ---
 xen/include/asm-x86/vm_event.h|  1 -
 xen/include/public/vm_event.h | 38 +++---
 xen/include/xen/vm_event.h|  1 -
 14 files changed, 26 insertions(+), 45 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 6ce4645..61fc08e 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -294,7 +294,6 @@ static void continue_new_vcpu(struct vcpu *prev)
 else
 /* check_wakeup_from_wait(); */
 reset_stack_and_jump(return_to_new_vcpu64);
-
 }
 
 void context_switch(struct vcpu *prev, struct vcpu *next)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 44926ca..fb01703 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -439,7 +439,6 @@ static void inject_abt32_exception(struct cpu_user_regs 
*regs,
 far |= addr << 32;
 WRITE_SYSREG(far, FAR_EL1);
 WRITE_SYSREG(fsr, IFSR32_EL2);
-
 #endif
 }
 else
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 03dffb8..bdfd5ff 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -31,7 +31,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -63,11 +62,9 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index de04e6c..effe534 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -34,7 +34,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -57,7 +56,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 static bool_t __initdata opt_force_ept;
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 88d14ae..c2ea037 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 int arch_monitor_init_domain(struct domain *d)
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index f21ff10..e7f352d 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -18,9 +18,6 @@
  * License along with this program; If not, see .
  */
 
-#include 
-#include 
-#include 
 #include 
 
 /* Implicitly serialized by the domctl lock. */
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index 436214a..08d1d98 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 89a25d1..9a89bf0 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -770,8 +770,10 @@ void vm_event_vcpu_unpause(struct vcpu *v)
 {
 int old, new, prev = v->vm_event_pause_count.counter;
 
-/* All unpause requests as a result of toolstack responses.  Prevent
- * underflow of the vcpu pause count. */
+/*
+ * All unpause requests as a result of toolstack responses.
+ * Prevent underflow of the vcpu pause count.
+ */
 do
 {
 old = prev;
diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index a3fc4ce..ccc4b60 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -23,21 +23,18 @@
 #include 
 #include 
 
-static inline
-int vm_event_init_domain(struct domain *d)
+static inline int vm_event_init_domain(struct domain *d)
 {
 /* Nothing to do. */
 return 0;
 }
 
-static inline
-void vm_event_cleanup_domain(struct domain *d)
+static inline void vm_event_cleanup_domain(struct domain *d)
 {
 memset(>monitor, 0, sizeof(d->monitor));
 }
 
-static inline
-void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
+static inline void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
 {
 /* Not supported on ARM. */
 }
diff --git a/xen/include/asm-x86/hvm/monitor.h 
b/xen/include/asm-x86/hvm/monitor.h
index 55d435e..ab433ed 100644
--- a/xen/include/asm-x86/hvm/monitor.h
+++ b/xen/include/asm-x86/hvm/monitor.h
@@ -19,7 +19,6 @@
 #ifndef __ASM_X86_HVM_MONITOR_H__
 #define __ASM_X86_HVM_MONITOR_H__
 
-#include 
 #include 
 #include 
 
diff --git a/xen/include/asm-x86/monitor.h

[Xen-devel] [PATCH 6/8] x86/vm_event_resume: surround VM_EVENT_REASON_MOV_TO_MSR w/ CONFIG_X86

2016-06-30 Thread Corneliu ZUZU 
VM_EVENT_REASON_MOV_TO_MSR is X86-specific, surround w/ #ifdef accordingly.

Signed-off-by: Corneliu ZUZU 
---
 xen/common/vm_event.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 17d2716..89a25d1 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -394,7 +394,9 @@ void vm_event_resume(struct domain *d, struct 
vm_event_domain *ved)
  */
 switch ( rsp.reason )
 {
+#ifdef CONFIG_X86
 case VM_EVENT_REASON_MOV_TO_MSR:
+#endif
 case VM_EVENT_REASON_WRITE_CTRLREG:
 vm_event_register_write_resume(v, );
 break;
-- 
2.5.0


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

[Xen-devel] [PATCH 5/8] x86/vm-event/monitor: don't compromise monitor_write_data on domain cleanup

2016-06-30 Thread Corneliu ZUZU 
The arch_vm_event structure is dynamically allocated and freed @
vm_event_cleanup_domain. This cleanup is triggered e.g. when the toolstack user
disables domain monitoring (xc_monitor_disable), which in turn effectively
discards any information that was in arch_vm_event.write_data.

But this can yield unexpected behavior since if a CR-write was awaiting to be
committed on the scheduling tail (hvm_do_resume->arch_monitor_write_data)
before xc_monitor_disable is called, then the domain CR write is wrongfully
ignored, which of course, in these cases, can easily render a domain crash.

To fix the issue, this patch makes only arch_vm_event.emul_read_data dynamically
allocated instead of the whole arch_vm_event structure. With this we can avoid
invalidation of an awaiting arch_vm_event.write_data by selectively cleaning up
only emul_read_data and emulate_flags @ vm_event_cleanup_domain.

Small note: arch_vm_event structure definition needed to be moved from
asm-x86/vm_event.h to asm-x86/domain.h in the process.

Signed-off-by: Corneliu ZUZU 
---
 xen/arch/x86/domain.c  |  5 ++--
 xen/arch/x86/hvm/emulate.c |  8 +++---
 xen/arch/x86/hvm/hvm.c | 62 ++
 xen/arch/x86/mm/p2m.c  |  4 +--
 xen/arch/x86/monitor.c |  7 +
 xen/arch/x86/vm_event.c| 16 +--
 xen/include/asm-x86/domain.h   | 42 +---
 xen/include/asm-x86/monitor.h  |  3 +-
 xen/include/asm-x86/vm_event.h | 10 ---
 9 files changed, 73 insertions(+), 84 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index bb59247..06e68ae 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -492,8 +492,9 @@ int vcpu_initialise(struct vcpu *v)
 
 void vcpu_destroy(struct vcpu *v)
 {
-xfree(v->arch.vm_event);
-v->arch.vm_event = NULL;
+v->arch.vm_event.emulate_flags = 0;
+xfree(v->arch.vm_event.emul_read_data);
+v->arch.vm_event.emul_read_data = NULL;
 
 if ( is_pv_32bit_vcpu(v) )
 {
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 855af4d..68f5515 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -73,12 +73,12 @@ static int set_context_data(void *buffer, unsigned int size)
 {
 struct vcpu *curr = current;
 
-if ( curr->arch.vm_event )
+if ( curr->arch.vm_event.emul_read_data )
 {
 unsigned int safe_size =
-min(size, curr->arch.vm_event->emul_read_data.size);
+min(size, curr->arch.vm_event.emul_read_data->size);
 
-memcpy(buffer, curr->arch.vm_event->emul_read_data.data, safe_size);
+memcpy(buffer, curr->arch.vm_event.emul_read_data->data, safe_size);
 memset(buffer + safe_size, 0, size - safe_size);
 return X86EMUL_OKAY;
 }
@@ -523,7 +523,7 @@ static int hvmemul_virtual_to_linear(
  * vm_event being triggered for repeated writes to a whole page.
  */
 if ( unlikely(current->domain->arch.mem_access_emulate_each_rep) &&
- current->arch.vm_event->emulate_flags != 0 )
+ current->arch.vm_event.emulate_flags != 0 )
max_reps = 1;
 
 /*
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 884ae40..03dffb8 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -473,24 +473,24 @@ void hvm_do_resume(struct vcpu *v)
 if ( !handle_hvm_io_completion(v) )
 return;
 
-if ( unlikely(v->arch.vm_event) )
+if ( unlikely(v->arch.vm_event.emulate_flags) )
 {
-if ( v->arch.vm_event->emulate_flags )
-{
-enum emul_kind kind = EMUL_KIND_NORMAL;
+enum emul_kind kind;
 
-if ( v->arch.vm_event->emulate_flags &
- VM_EVENT_FLAG_SET_EMUL_READ_DATA )
-kind = EMUL_KIND_SET_CONTEXT;
-else if ( v->arch.vm_event->emulate_flags &
-  VM_EVENT_FLAG_EMULATE_NOWRITE )
-kind = EMUL_KIND_NOWRITE;
+ASSERT(v->arch.vm_event.emul_read_data);
 
-hvm_mem_access_emulate_one(kind, TRAP_invalid_op,
-   HVM_DELIVER_NO_ERROR_CODE);
+kind = EMUL_KIND_NORMAL;
 
-v->arch.vm_event->emulate_flags = 0;
-}
+if ( v->arch.vm_event.emulate_flags & VM_EVENT_FLAG_SET_EMUL_READ_DATA 
)
+kind = EMUL_KIND_SET_CONTEXT;
+else if ( v->arch.vm_event.emulate_flags &
+  VM_EVENT_FLAG_EMULATE_NOWRITE )
+kind = EMUL_KIND_NOWRITE;
+
+hvm_mem_access_emulate_one(kind, TRAP_invalid_op,
+   HVM_DELIVER_NO_ERROR_CODE);
+
+v->arch.vm_event.emulate_flags = 0;
 }
 
 arch_monitor_write_data(v);
@@ -2178,17 +2178,15 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
 if ( may_defer && unlikely(v->domain->arch.monitor.write_ctrlreg_enabled &

[Xen-devel] [PATCH 4/8] x86/vm-event/monitor: turn monitor_write_data.do_write into enum

2016-06-30 Thread Corneliu ZUZU 
After trapping a control-register write vm-event and -until- deciding if that
write is to be permitted or not (VM_EVENT_FLAG_DENY) and doing the actual write,
there cannot and should not be another trapped control-register write event.
That is, currently -only one- of the fields of monitor_write_data.do_write can
be true at any given moment and therefore it would be more appropriate to
replace those fields with an enum value.

Signed-off-by: Corneliu ZUZU 
---
 xen/arch/x86/hvm/hvm.c   | 18 +++---
 xen/arch/x86/monitor.c   | 37 ++---
 xen/arch/x86/vm_event.c  | 25 ++---
 xen/include/asm-x86/domain.h | 20 ++--
 4 files changed, 41 insertions(+), 59 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 5481a6e..884ae40 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2186,8 +2186,9 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
  * The actual write will occur in arch_monitor_write_data(), if
  * permitted.
  */
-v->arch.vm_event->write_data.do_write.cr0 = 1;
-v->arch.vm_event->write_data.cr0 = value;
+ASSERT(MWS_NOWRITE == v->arch.vm_event->write_data.status);
+v->arch.vm_event->write_data.status = MWS_CR0;
+v->arch.vm_event->write_data.value = value;
 
 return X86EMUL_OKAY;
 }
@@ -2291,8 +2292,9 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
  * The actual write will occur in arch_monitor_write_data(), if
  * permitted.
  */
-v->arch.vm_event->write_data.do_write.cr3 = 1;
-v->arch.vm_event->write_data.cr3 = value;
+ASSERT(MWS_NOWRITE == v->arch.vm_event->write_data.status);
+v->arch.vm_event->write_data.status = MWS_CR3;
+v->arch.vm_event->write_data.value = value;
 
 return X86EMUL_OKAY;
 }
@@ -2374,8 +2376,9 @@ int hvm_set_cr4(unsigned long value, bool_t may_defer)
  * The actual write will occur in arch_monitor_write_data(), if
  * permitted.
  */
-v->arch.vm_event->write_data.do_write.cr4 = 1;
-v->arch.vm_event->write_data.cr4 = value;
+ASSERT(MWS_NOWRITE == v->arch.vm_event->write_data.status);
+v->arch.vm_event->write_data.status = MWS_CR4;
+v->arch.vm_event->write_data.value = value;
 
 return X86EMUL_OKAY;
 }
@@ -3756,7 +3759,8 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
  * The actual write will occur in arch_monitor_write_data(), if
  * permitted.
  */
-v->arch.vm_event->write_data.do_write.msr = 1;
+ASSERT(MWS_NOWRITE == v->arch.vm_event->write_data.status);
+v->arch.vm_event->write_data.status = MWS_MSR;
 v->arch.vm_event->write_data.msr = msr;
 v->arch.vm_event->write_data.value = msr_content;
 
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 90e4856..5c8d4da 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -53,29 +53,28 @@ void arch_monitor_write_data(struct vcpu *v)
 
 w = >arch.vm_event->write_data;
 
-if ( w->do_write.msr )
-{
-hvm_msr_write_intercept(w->msr, w->value, 0);
-w->do_write.msr = 0;
-}
-
-if ( w->do_write.cr0 )
-{
-hvm_set_cr0(w->cr0, 0);
-w->do_write.cr0 = 0;
-}
+if ( likely(MWS_NOWRITE == w->status) )
+return;
 
-if ( w->do_write.cr4 )
+switch ( w->status )
 {
-hvm_set_cr4(w->cr4, 0);
-w->do_write.cr4 = 0;
+case MWS_MSR:
+hvm_msr_write_intercept(w->msr, w->value, 0);
+break;
+case MWS_CR0:
+hvm_set_cr0(w->value, 0);
+break;
+case MWS_CR3:
+hvm_set_cr3(w->value, 0);
+break;
+case MWS_CR4:
+hvm_set_cr4(w->value, 0);
+break;
+default:
+break;
 }
 
-if ( w->do_write.cr3 )
-{
-hvm_set_cr3(w->cr3, 0);
-w->do_write.cr3 = 0;
-}
+w->status = MWS_NOWRITE;
 }
 
 static unsigned long *monitor_bitmap_for_msr(const struct domain *d, u32 *msr)
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 80f84d6..825da48 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -73,34 +73,13 @@ void vm_event_register_write_resume(struct vcpu *v, 
vm_event_response_t *rsp)
 {
 if ( rsp->flags & VM_EVENT_FLAG_DENY )
 {
-struct monitor_write_data *w = >arch.vm_event->write_data;
-
-ASSERT(w);
+ASSERT(v->arch.vm_event);
 
 /* deny flag requires the vCPU to be paused */
 if ( !atomic_read(>vm_event_pause_count) )
 return;
 
-switch ( rsp->reason )
-{
-case VM_EVENT_REASON_MOV_TO_MSR:
-w->do_write.msr = 0;
-

[Xen-devel] [PATCH 3/8] x86/vm-event/monitor: relocate code-motion more appropriately

2016-06-30 Thread Corneliu ZUZU 
For readability:

* Add function arch_monitor_write_data (in x86/monitor.c) and separate handling
of monitor_write_data there (previously done directly in hvm_do_resume).

* Add function write_ctrlreg_adjust_traps (in x86/monitor.c) and relocate
enabling/disabling of CPU_BASED_CR3_LOAD_EXITING for CR3 monitor vm-events there
(previously done through CR0 node @ vmx_update_guest_cr(v, 0)).

Signed-off-by: Corneliu ZUZU 
---
 xen/arch/x86/hvm/hvm.c| 48 +-
 xen/arch/x86/hvm/vmx/vmx.c|  5 ---
 xen/arch/x86/monitor.c| 94 +++
 xen/include/asm-x86/monitor.h |  2 +
 4 files changed, 107 insertions(+), 42 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c89ab6e..5481a6e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -475,8 +475,6 @@ void hvm_do_resume(struct vcpu *v)
 
 if ( unlikely(v->arch.vm_event) )
 {
-struct monitor_write_data *w = >arch.vm_event->write_data;
-
 if ( v->arch.vm_event->emulate_flags )
 {
 enum emul_kind kind = EMUL_KIND_NORMAL;
@@ -493,32 +491,10 @@ void hvm_do_resume(struct vcpu *v)
 
 v->arch.vm_event->emulate_flags = 0;
 }
-
-if ( w->do_write.msr )
-{
-hvm_msr_write_intercept(w->msr, w->value, 0);
-w->do_write.msr = 0;
-}
-
-if ( w->do_write.cr0 )
-{
-hvm_set_cr0(w->cr0, 0);
-w->do_write.cr0 = 0;
-}
-
-if ( w->do_write.cr4 )
-{
-hvm_set_cr4(w->cr4, 0);
-w->do_write.cr4 = 0;
-}
-
-if ( w->do_write.cr3 )
-{
-hvm_set_cr3(w->cr3, 0);
-w->do_write.cr3 = 0;
-}
 }
 
+arch_monitor_write_data(v);
+
 /* Inject pending hw/sw trap */
 if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
 {
@@ -2206,7 +2182,10 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
 
 if ( hvm_monitor_crX(CR0, value, old_value) )
 {
-/* The actual write will occur in hvm_do_resume(), if permitted. */
+/*
+ * The actual write will occur in arch_monitor_write_data(), if
+ * permitted.
+ */
 v->arch.vm_event->write_data.do_write.cr0 = 1;
 v->arch.vm_event->write_data.cr0 = value;
 
@@ -2308,7 +2287,10 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
 
 if ( hvm_monitor_crX(CR3, value, old) )
 {
-/* The actual write will occur in hvm_do_resume(), if permitted. */
+/*
+ * The actual write will occur in arch_monitor_write_data(), if
+ * permitted.
+ */
 v->arch.vm_event->write_data.do_write.cr3 = 1;
 v->arch.vm_event->write_data.cr3 = value;
 
@@ -2388,7 +2370,10 @@ int hvm_set_cr4(unsigned long value, bool_t may_defer)
 
 if ( hvm_monitor_crX(CR4, value, old_cr) )
 {
-/* The actual write will occur in hvm_do_resume(), if permitted. */
+/*
+ * The actual write will occur in arch_monitor_write_data(), if
+ * permitted.
+ */
 v->arch.vm_event->write_data.do_write.cr4 = 1;
 v->arch.vm_event->write_data.cr4 = value;
 
@@ -3767,7 +3752,10 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 {
 ASSERT(v->arch.vm_event);
 
-/* The actual write will occur in hvm_do_resume() (if permitted). */
+/*
+ * The actual write will occur in arch_monitor_write_data(), if
+ * permitted.
+ */
 v->arch.vm_event->write_data.do_write.msr = 1;
 v->arch.vm_event->write_data.msr = msr;
 v->arch.vm_event->write_data.value = msr_content;
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 15c84c2..de04e6c 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1442,11 +1442,6 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned 
int cr)
 if ( !hvm_paging_enabled(v) && !vmx_unrestricted_guest(v) )
 v->arch.hvm_vmx.exec_control |= cr3_ctls;
 
-/* Trap CR3 updates if CR3 memory events are enabled. */
-if ( v->domain->arch.monitor.write_ctrlreg_enabled &
- monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
-v->arch.hvm_vmx.exec_control |= CPU_BASED_CR3_LOAD_EXITING;
-
 if ( old_ctls != v->arch.hvm_vmx.exec_control )
 vmx_update_cpu_exec_control(v);
 }
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index a271161..90e4856 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -20,6 +20,9 @@
  */
 
 #include 
+#include 
+#include 
+#include 
 #include 
 
 int arch_monitor_init_domain(struct domain *d)
@@ -41,6 +44,40 @@ void

[Xen-devel] [PATCH 2/8] x86/vmx_update_guest_cr: minor optimization

2016-06-30 Thread Corneliu ZUZU 
Minor optimization @ vmx_update_guest_cr: checks if v->arch.hvm_vmx.exec_control
was modified before actually calling vmx_update_cpu_exec_control(v).

Signed-off-by: Corneliu ZUZU 
---
 xen/arch/x86/hvm/vmx/vmx.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index a0f5793..15c84c2 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1434,8 +1434,10 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned 
int cr)
 if ( paging_mode_hap(v->domain) )
 {
 /* Manage GUEST_CR3 when CR0.PE=0. */
+uint32_t old_ctls = v->arch.hvm_vmx.exec_control;
 uint32_t cr3_ctls = (CPU_BASED_CR3_LOAD_EXITING |
  CPU_BASED_CR3_STORE_EXITING);
+
 v->arch.hvm_vmx.exec_control &= ~cr3_ctls;
 if ( !hvm_paging_enabled(v) && !vmx_unrestricted_guest(v) )
 v->arch.hvm_vmx.exec_control |= cr3_ctls;
@@ -1445,7 +1447,8 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned 
int cr)
  monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
 v->arch.hvm_vmx.exec_control |= CPU_BASED_CR3_LOAD_EXITING;
 
-vmx_update_cpu_exec_control(v);
+if ( old_ctls != v->arch.hvm_vmx.exec_control )
+vmx_update_cpu_exec_control(v);
 }
 
 if ( !nestedhvm_vcpu_in_guestmode(v) )
-- 
2.5.0


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

[Xen-devel] [PATCH 1/8] x86/vm-event: proper vCPU-paused checks at resume

2016-06-30 Thread Corneliu ZUZU 
A VM_EVENT_FLAG_VCPU_PAUSED flag in a vm-event response should only be treated
as informative that the toolstack user wants the vm-event subsystem to unpause
the target vCPU, but not be relied upon to decide if the target vCPU is actually
paused.

That being said, this patch does the following:

* Fixes (replaces) the old behavior in vm_event_resume, which relied on
  VM_EVENT_FLAG_VCPU_PAUSED to determine if the target vCPU is paused, by
  actually checking the vCPU vm-event pause-count.

* ASSERTs that the vCPU is paused in vm_event_set_registers and
  vm_event_toggle_singlestep.

* Ignores VM_EVENT_FLAG_DENY @ vm_event_register_write_resume if the target vCPU
  is not paused. Also adjusts comment in public/vm_event.h to reflect that.

Signed-off-by: Corneliu ZUZU 
---
 xen/arch/x86/vm_event.c   | 10 +-
 xen/common/vm_event.c |  6 --
 xen/include/public/vm_event.h |  1 +
 3 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index a9d3861..80f84d6 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -61,9 +61,11 @@ void vm_event_cleanup_domain(struct domain *d)
 
 void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
 {
-if ( !is_hvm_domain(d) || !atomic_read(>vm_event_pause_count) )
+if ( !is_hvm_domain(d) )
 return;
 
+ASSERT(atomic_read(>vm_event_pause_count));
+
 hvm_toggle_singlestep(v);
 }
 
@@ -75,6 +77,10 @@ void vm_event_register_write_resume(struct vcpu *v, 
vm_event_response_t *rsp)
 
 ASSERT(w);
 
+/* deny flag requires the vCPU to be paused */
+if ( !atomic_read(>vm_event_pause_count) )
+return;
+
 switch ( rsp->reason )
 {
 case VM_EVENT_REASON_MOV_TO_MSR:
@@ -100,6 +106,8 @@ void vm_event_register_write_resume(struct vcpu *v, 
vm_event_response_t *rsp)
 
 void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp)
 {
+ASSERT(atomic_read(>vm_event_pause_count));
+
 v->arch.user_regs.eax = rsp->data.regs.x86.rax;
 v->arch.user_regs.ebx = rsp->data.regs.x86.rbx;
 v->arch.user_regs.ecx = rsp->data.regs.x86.rcx;
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index b303180..17d2716 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -417,7 +417,8 @@ void vm_event_resume(struct domain *d, struct 
vm_event_domain *ved)
 if ( rsp.flags & VM_EVENT_FLAG_ALTERNATE_P2M )
 p2m_altp2m_check(v, rsp.altp2m_idx);
 
-if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
+/* Check flags which apply only when the vCPU is paused */
+if ( atomic_read(>vm_event_pause_count) )
 {
 if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
 vm_event_set_registers(v, );
@@ -425,7 +426,8 @@ void vm_event_resume(struct domain *d, struct 
vm_event_domain *ved)
 if ( rsp.flags & VM_EVENT_FLAG_TOGGLE_SINGLESTEP )
 vm_event_toggle_singlestep(d, v);
 
-vm_event_vcpu_unpause(v);
+if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
+vm_event_vcpu_unpause(v);
 }
 }
 }
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index 9270d52..f888fdd 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -77,6 +77,7 @@
  /*
   * Deny completion of the operation that triggered the event.
   * Currently only useful for MSR, CR0, CR3 and CR4 write events.
+  * Requires the vCPU to be paused already (synchronous events only).
   */
 #define VM_EVENT_FLAG_DENY   (1 << 6)
 /*
-- 
2.5.0


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

[Xen-devel] [PATCH 0/8] x86/vm-event: Adjustments & fixes

2016-06-30 Thread Corneliu ZUZU 
This patch-series makes some adjustments and fixes to the X86 vm-events code.
Summary:
1. proper checks for vCPU pause @ vm_event_resume
2. minor optimization
3. relocate some code into added vm-event functions
4. turn monitor_write_data.do_write into enum
5. fix monitor_write_data behavior on domain cleanup
6. surround VM_EVENT_REASON_MOV_TO_MSR w/ #ifdef CONFIG_X86
7+8. minor fixes (cleanup stuff)

Corneliu ZUZU (8):
  x86/vm-event: proper vCPU-paused checks at resume
  x86/vmx_update_guest_cr: minor optimization
  x86/vm-event/monitor: relocate code-motion more appropriately
  x86/vm-event/monitor: turn monitor_write_data.do_write into enum
  x86/vm-event/monitor: don't compromise monitor_write_data on domain
cleanup
  x86/vm_event_resume: surround VM_EVENT_REASON_MOV_TO_MSR w/ CONFIG_X86
  minor fixes (formatting, comments, unused includes etc.)
  minor #include change

 xen/arch/arm/domain.c |   1 -
 xen/arch/arm/traps.c  |   1 -
 xen/arch/x86/domain.c |   5 +-
 xen/arch/x86/hvm/emulate.c|   8 +--
 xen/arch/x86/hvm/hvm.c| 105 --
 xen/arch/x86/hvm/monitor.c|   1 +
 xen/arch/x86/hvm/vmx/vmx.c|  12 ++---
 xen/arch/x86/mm/p2m.c |   4 +-
 xen/arch/x86/monitor.c|  87 ---
 xen/arch/x86/vm_event.c   |  50 ++
 xen/common/monitor.c  |   1 -
 xen/common/vm_event.c |  14 +++--
 xen/include/asm-arm/vm_event.h|   9 ++--
 xen/include/asm-x86/domain.h  |  42 +--
 xen/include/asm-x86/hvm/monitor.h |   2 -
 xen/include/asm-x86/monitor.h |   8 +--
 xen/include/asm-x86/vm_event.h|  11 
 xen/include/public/vm_event.h |  37 +++---
 xen/include/xen/vm_event.h|   1 -
 19 files changed, 216 insertions(+), 183 deletions(-)

-- 
2.5.0


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

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

2016-06-30 Thread osstest service owner 
flight 96447 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96447/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 94856
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 94856
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 94856
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
94856
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
94856
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 94856
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 94856
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 94856

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

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

version targeted for testing:
 qemuuef8757f1fe8095a256ee617e4dbac69d3b33ae94
baseline version:
 qemuud6550e9ed2e1a60d889dfb721de00d9a4e3bafbe

Last test of basis94856  2016-05-27 20:14:49 Z   33 days
Failing since 94983  2016-05-31 09:40:12 Z   30 days   42 attempts
Testing same since96447  2016-06-30 04:03:04 Z0 days1 attempts


People who touched revisions under test:
  Aaron Larson 
  Alberto Garcia 
  Aleksandar Markovic 
  Alex Bennée 
  Alex Bligh 
  Alex Williamson 
  Alexander Graf 
  Alexey Kardashevskiy 
  Alistair Francis 
  Amit Shah 
  Andrea Arcangeli 
  Andrew Jeffery 
  Andrew Jones 
  Aneesh Kumar K.V 
  Anthony PERARD 
  Anton Blanchard 
  Ard Biesheuvel

[Xen-devel] [PATCH] tools/xl: Allow callers of `xl info` to select specific information

2016-06-30 Thread Andrew Cooper 
When scripting, it is much more convenient to use:

[root@fusebot ~]# xl info xen_version
4.8-unstable

than to construct some sed/awk/other to parse:

[root@fusebot ~]# xl info
...
xen_version: 4.8-unstable
...

This works by wrapping all printf() calls in main_info() with maybe_printf(),
which formats its arguments, compares the resulting string to the provided
restriction, and discards it if no match is found.

A restriction like this doesn't make sense in combination with --numa, so is
excluded in that case.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 

Embarrassingly, this has been kicking around in the XenServer patch queue since
Xen 4.4.  It is high time it got sent upstream.

This patch is far more easily reviewed with `git diff --color-words`
---
 tools/libxl/xl_cmdimpl.c | 118 +++
 1 file changed, 77 insertions(+), 41 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 6459eec..d1fcfa4 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5928,6 +5928,33 @@ int main_vcpuset(int argc, char **argv)
 return EXIT_SUCCESS;
 }
 
+/* Possibly select a specific piece of `xl info` to print. */
+static const char *info_name;
+static int maybe_printf(const char *fmt, ...) 
__attribute__((format(printf,1,2)));
+static int maybe_printf(const char *fmt, ...)
+{
+va_list ap;
+char *str;
+int count = 0;
+
+va_start(ap, fmt);
+if (vasprintf(, fmt, ap) != -1) {
+if (info_name) {
+char *s;
+
+if (!strncmp(str, info_name, strlen(info_name)) &&
+(s = strchr(str, ':')) && s[1] == ' ')
+count = fputs([2], stdout);
+} else
+count = fputs(str, stdout);
+
+free(str);
+}
+va_end(ap);
+
+return count;
+}
+
 static void output_xeninfo(void)
 {
 const libxl_version_info *info;
@@ -5946,22 +5973,22 @@ static void output_xeninfo(void)
 }
 sched = rc;
 
-printf("xen_major  : %d\n", info->xen_version_major);
-printf("xen_minor  : %d\n", info->xen_version_minor);
-printf("xen_extra  : %s\n", info->xen_version_extra);
-printf("xen_version: %d.%d%s\n", info->xen_version_major,
+maybe_printf("xen_major  : %d\n", info->xen_version_major);
+maybe_printf("xen_minor  : %d\n", info->xen_version_minor);
+maybe_printf("xen_extra  : %s\n", info->xen_version_extra);
+maybe_printf("xen_version: %d.%d%s\n", info->xen_version_major,
info->xen_version_minor, info->xen_version_extra);
-printf("xen_caps   : %s\n", info->capabilities);
-printf("xen_scheduler  : %s\n", libxl_scheduler_to_string(sched));
-printf("xen_pagesize   : %u\n", info->pagesize);
-printf("platform_params: virt_start=0x%"PRIx64"\n", 
info->virt_start);
-printf("xen_changeset  : %s\n", info->changeset);
-printf("xen_commandline: %s\n", info->commandline);
-printf("cc_compiler: %s\n", info->compiler);
-printf("cc_compile_by  : %s\n", info->compile_by);
-printf("cc_compile_domain  : %s\n", info->compile_domain);
-printf("cc_compile_date: %s\n", info->compile_date);
-printf("build_id   : %s\n", info->build_id);
+maybe_printf("xen_caps   : %s\n", info->capabilities);
+maybe_printf("xen_scheduler  : %s\n", 
libxl_scheduler_to_string(sched));
+maybe_printf("xen_pagesize   : %u\n", info->pagesize);
+maybe_printf("platform_params: virt_start=0x%"PRIx64"\n", 
info->virt_start);
+maybe_printf("xen_changeset  : %s\n", info->changeset);
+maybe_printf("xen_commandline: %s\n", info->commandline);
+maybe_printf("cc_compiler: %s\n", info->compiler);
+maybe_printf("cc_compile_by  : %s\n", info->compile_by);
+maybe_printf("cc_compile_domain  : %s\n", info->compile_domain);
+maybe_printf("cc_compile_date: %s\n", info->compile_date);
+maybe_printf("build_id   : %s\n", info->build_id);
 
 return;
 }
@@ -5973,10 +6000,10 @@ static void output_nodeinfo(void)
 if (uname() < 0)
 return;
 
-printf("host   : %s\n", utsbuf.nodename);
-printf("release: %s\n", utsbuf.release);
-printf("version: %s\n", utsbuf.version);
-printf("machine: %s\n", utsbuf.machine);
+maybe_printf("host   : %s\n", utsbuf.nodename);
+maybe_printf("release: %s\n", utsbuf.release);
+maybe_printf("version: %s\n", utsbuf.version);
+maybe_printf("machine: %s\n", utsbuf.machine);
 }
 
 static

[Xen-devel] [PATCH linux v2 9/9] xen/pvhvm: run xen_vcpu_setup() for the boot CPU

2016-06-30 Thread Vitaly Kuznetsov 
Historically we didn't call VCPUOP_register_vcpu_info for CPU0 for PVHVM
guests (while we had it for PV and ARM guests). This is usually fine as we
can use vcpu info in the sared_info page but when we try booting on a vCPU
with Xen's vCPU id > 31 (e.g. when we try to kdump after crashing on this
CPU) we're not able to boot. Switch to always doing
VCPUOP_register_vcpu_info for the boot CPU.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/enlighten.c | 2 +-
 arch/x86/xen/smp.c   | 7 +++
 arch/x86/xen/xen-ops.h   | 1 +
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index bfdd51b..7c91631 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -184,7 +184,7 @@ static void clamp_max_cpus(void)
 #endif
 }
 
-static void xen_vcpu_setup(int cpu)
+void xen_vcpu_setup(int cpu)
 {
struct vcpu_register_vcpu_info info;
int err;
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index a3118f2..0b4d04c 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -322,6 +322,13 @@ static void __init xen_smp_prepare_boot_cpu(void)
xen_filter_cpu_maps();
xen_setup_vcpu_info_placement();
}
+
+   /*
+* Setup vcpu_info for boot CPU.
+*/
+   if (xen_hvm_domain())
+   xen_vcpu_setup(0);
+
/*
 * The alternative logic (which patches the unlock/lock) runs before
 * the smp bootup up code is activated. Hence we need to set this up
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 4140b07..3cbce3b 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -76,6 +76,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id);
 
 bool xen_vcpu_stolen(int vcpu);
 
+void xen_vcpu_setup(int cpu);
 void xen_setup_vcpu_info_placement(void);
 
 #ifdef CONFIG_SMP
-- 
2.5.5


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

[Xen-devel] [PATCH linux v2 8/9] xen/evtchn: use xen_vcpu_id mapping

2016-06-30 Thread Vitaly Kuznetsov 
Use the newly introduced xen_vcpu_id mapping to get Xen's idea of vCPU id
for CPU0.

Signed-off-by: Vitaly Kuznetsov 
---
Changes since v1:
- Use xen_vcpu_nr() helper [David Vrabel]
---
 drivers/xen/evtchn.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index f4edd6df..7c3113e 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -55,6 +55,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct per_user_data {
@@ -448,7 +449,7 @@ static long evtchn_ioctl(struct file *file,
break;
 
bind_virq.virq = bind.virq;
-   bind_virq.vcpu = 0;
+   bind_virq.vcpu = xen_vcpu_nr(0);
rc = HYPERVISOR_event_channel_op(EVTCHNOP_bind_virq,
 _virq);
if (rc != 0)
-- 
2.5.5


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

[Xen-devel] [PATCH linux v2 1/9] x86/xen: update cpuid.h from Xen-4.7

2016-06-30 Thread Vitaly Kuznetsov 
Update cpuid.h header from xen hypervisor tree to get
XEN_HVM_CPUID_VCPU_ID_PRESENT definition.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/include/asm/xen/cpuid.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/xen/cpuid.h b/arch/x86/include/asm/xen/cpuid.h
index 0d809e9..3bdd10d 100644
--- a/arch/x86/include/asm/xen/cpuid.h
+++ b/arch/x86/include/asm/xen/cpuid.h
@@ -76,15 +76,18 @@
 /*
  * Leaf 5 (0x4x04)
  * HVM-specific features
+ * EAX: Features
+ * EBX: vcpu id (iff EAX has XEN_HVM_CPUID_VCPU_ID_PRESENT flag)
  */
 
-/* EAX Features */
 /* Virtualized APIC registers */
 #define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0)
 /* Virtualized x2APIC accesses */
 #define XEN_HVM_CPUID_X2APIC_VIRT  (1u << 1)
 /* Memory mapped from other domains has valid IOMMU entries */
 #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
+/* vcpu id is present in EBX */
+#define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3)
 
 #define XEN_CPUID_MAX_NUM_LEAVES 4
 
-- 
2.5.5


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

[Xen-devel] [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs

2016-06-30 Thread Vitaly Kuznetsov 
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 we
need to have a mapping between Linux's and Xen's vCPU ids.

This series solves the issue for x86 PVHVM guests. PV guests don't (and
probably won't) support kdump so I always assume Xen's vCPU id == Linux's
vCPU id. ARM guests will probably need to get proper mapping once we start
supporting kexec/kdump there.

Changes since v1:
- "x86/acpi: store ACPI ids from MADT for future usage" patch added.
- Use ACPI ids instead of vLAPIC ids/2 [Andrew Cooper, Jan Beulich]
- Introduce xen_vcpu_nr() helper [David Vrabel].
- Modify all callers of HYPERVISOR_vcpu_op() instead of modifying
  HYPERVISOR_vcpu_op() [David Vrabel]

Vitaly Kuznetsov (9):
  x86/xen: update cpuid.h from Xen-4.7
  x86/acpi: store ACPI ids from MADT for future usage
  xen: introduce xen_vcpu_id mapping
  x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op
  x86/xen: use xen_vcpu_id mapping when pointing vcpu_info to the
shared_info page
  xen/events: use xen_vcpu_id mapping in events_base
  xen/events: fifo: use xen_vcpu_id mapping
  xen/evtchn: use xen_vcpu_id mapping
  xen/pvhvm: run xen_vcpu_setup() for the boot CPU

 arch/arm/xen/enlighten.c | 13 +++-
 arch/x86/include/asm/cpu.h   |  1 +
 arch/x86/include/asm/smp.h   |  2 ++
 arch/x86/include/asm/xen/cpuid.h |  5 -
 arch/x86/kernel/acpi/boot.c  | 16 ++
 arch/x86/kernel/apic/apic.c  |  2 ++
 arch/x86/kernel/setup_percpu.c   |  3 +++
 arch/x86/xen/enlighten.c | 45 +++-
 arch/x86/xen/irq.c   |  3 ++-
 arch/x86/xen/smp.c   | 18 +++-
 arch/x86/xen/time.c  | 18 ++--
 arch/x86/xen/xen-ops.h   |  1 +
 drivers/xen/events/events_base.c | 13 ++--
 drivers/xen/events/events_fifo.c |  2 +-
 drivers/xen/evtchn.c |  3 ++-
 drivers/xen/time.c   |  2 +-
 include/xen/xen-ops.h|  6 ++
 17 files changed, 116 insertions(+), 37 deletions(-)

-- 
2.5.5


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

[Xen-devel] [PATCH linux v2 4/9] x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op

2016-06-30 Thread Vitaly Kuznetsov 
HYPERVISOR_vcpu_op() passes Linux's idea of vCPU id as a parameter while
Xen's idea is expected. In some cases these ideas diverge so we need to
do remapping. Convert all callers of HYPERVISOR_vcpu_op() to use
xen_vcpu_nr(). Leave xen_fill_possible_map() and xen_filter_cpu_maps()
intact as they're only being called by PV guests before perpu areas are
initialized. While the issue could be solved by switching to early_percpu
for xen_vcpu_id I think it's not worth it: PV guests will probably never
get to the point where their idea of vCPU id diverges from Xen's.

Signed-off-by: Vitaly Kuznetsov 
---
Changes since v1:
- Modify all callers of HYPERVISOR_vcpu_op() instead of modifying
  HYPERVISOR_vcpu_op() [David Vrabel]
---
 arch/arm/xen/enlighten.c |  3 ++-
 arch/x86/xen/enlighten.c | 10 ++
 arch/x86/xen/irq.c   |  3 ++-
 arch/x86/xen/smp.c   | 11 ++-
 arch/x86/xen/time.c  | 18 --
 drivers/xen/events/events_base.c |  3 ++-
 drivers/xen/time.c   |  2 +-
 7 files changed, 31 insertions(+), 19 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 1678446..6d3a171 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -189,7 +189,8 @@ static void xen_percpu_init(void)
info.mfn = virt_to_gfn(vcpup);
info.offset = xen_offset_in_page(vcpup);
 
-   err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, cpu, );
+   err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, xen_vcpu_nr(cpu),
+);
BUG_ON(err);
per_cpu(xen_vcpu, cpu) = vcpup;
 
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index ff01f3d..7e3bf5a 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -228,7 +228,8 @@ static void xen_vcpu_setup(int cpu)
   hypervisor has no unregister variant and this hypercall does not
   allow to over-write info.mfn and info.offset.
 */
-   err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, cpu, );
+   err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, xen_vcpu_nr(cpu),
+);
 
if (err) {
printk(KERN_DEBUG "register_vcpu_info failed: err=%d\n", err);
@@ -252,10 +253,11 @@ void xen_vcpu_restore(void)
 
for_each_possible_cpu(cpu) {
bool other_cpu = (cpu != smp_processor_id());
-   bool is_up = HYPERVISOR_vcpu_op(VCPUOP_is_up, cpu, NULL);
+   bool is_up = HYPERVISOR_vcpu_op(VCPUOP_is_up, xen_vcpu_nr(cpu),
+   NULL);
 
if (other_cpu && is_up &&
-   HYPERVISOR_vcpu_op(VCPUOP_down, cpu, NULL))
+   HYPERVISOR_vcpu_op(VCPUOP_down, xen_vcpu_nr(cpu), NULL))
BUG();
 
xen_setup_runstate_info(cpu);
@@ -264,7 +266,7 @@ void xen_vcpu_restore(void)
xen_vcpu_setup(cpu);
 
if (other_cpu && is_up &&
-   HYPERVISOR_vcpu_op(VCPUOP_up, cpu, NULL))
+   HYPERVISOR_vcpu_op(VCPUOP_up, xen_vcpu_nr(cpu), NULL))
BUG();
}
 }
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index a1207cb..33e9295 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -109,7 +109,8 @@ static void xen_safe_halt(void)
 static void xen_halt(void)
 {
if (irqs_disabled())
-   HYPERVISOR_vcpu_op(VCPUOP_down, smp_processor_id(), NULL);
+   HYPERVISOR_vcpu_op(VCPUOP_down,
+  xen_vcpu_nr(smp_processor_id()), NULL);
else
xen_safe_halt();
 }
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 719cf29..a3118f2 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -454,7 +454,7 @@ cpu_initialize_context(unsigned int cpu, struct task_struct 
*idle)
 #endif
ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_gfn(swapper_pg_dir));
-   if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
+   if (HYPERVISOR_vcpu_op(VCPUOP_initialise, xen_vcpu_nr(cpu), ctxt))
BUG();
 
kfree(ctxt);
@@ -492,7 +492,7 @@ static int xen_cpu_up(unsigned int cpu, struct task_struct 
*idle)
if (rc)
return rc;
 
-   rc = HYPERVISOR_vcpu_op(VCPUOP_up, cpu, NULL);
+   rc = HYPERVISOR_vcpu_op(VCPUOP_up, xen_vcpu_nr(cpu), NULL);
BUG_ON(rc);
 
while (cpu_report_state(cpu) != CPU_ONLINE)
@@ -520,7 +520,8 @@ static int xen_cpu_disable(void)
 
 static void xen_cpu_die(unsigned int cpu)
 {
-   while (xen_pv_domain() && HYPERVISOR_vcpu_op(VCPUOP_is_up, cpu, NULL)) {
+   while (xen_pv_domain() && HYPERVISOR_vcpu_op(VCPUOP_is_up,
+xen_vcpu_nr(cpu), NULL)) {

[Xen-devel] [PATCH linux v2 2/9] x86/acpi: store ACPI ids from MADT for future usage

2016-06-30 Thread Vitaly Kuznetsov 
Currently we don't save ACPI ids (unlike LAPIC ids which go to
x86_cpu_to_apicid) from MADT and we may need this information later.
Particularly, ACPI ids is the only existent way for a PVHVM Xen guest
to figure out Xen's idea of its vCPUs ids before these CPUs boot and
in some cases these ids diverge from Linux's cpu ids.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/include/asm/cpu.h |  1 +
 arch/x86/include/asm/smp.h |  2 ++
 arch/x86/kernel/acpi/boot.c| 16 
 arch/x86/kernel/apic/apic.c|  2 ++
 arch/x86/kernel/setup_percpu.c |  3 +++
 5 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
index 678637a..a7fb9dd 100644
--- a/arch/x86/include/asm/cpu.h
+++ b/arch/x86/include/asm/cpu.h
@@ -16,6 +16,7 @@ extern void prefill_possible_map(void);
 static inline void prefill_possible_map(void) {}
 
 #define cpu_physical_id(cpu)   boot_cpu_physical_apicid
+#define cpu_acpi_id(cpu)   0
 #define safe_smp_processor_id()0
 #define stack_smp_processor_id()   0
 
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index 66b0573..c47b42b 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -33,6 +33,7 @@ static inline struct cpumask *cpu_llc_shared_mask(int cpu)
 }
 
 DECLARE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_cpu_to_apicid);
+DECLARE_EARLY_PER_CPU_READ_MOSTLY(u32, x86_cpu_to_acpiid);
 DECLARE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_bios_cpu_apicid);
 #if defined(CONFIG_X86_LOCAL_APIC) && defined(CONFIG_X86_32)
 DECLARE_EARLY_PER_CPU_READ_MOSTLY(int, x86_cpu_to_logical_apicid);
@@ -147,6 +148,7 @@ void x86_idle_thread_init(unsigned int cpu, struct 
task_struct *idle);
 void smp_store_boot_cpu_info(void);
 void smp_store_cpu_info(int id);
 #define cpu_physical_id(cpu)   per_cpu(x86_cpu_to_apicid, cpu)
+#define cpu_acpi_id(cpu)   per_cpu(x86_cpu_to_acpiid, cpu)
 
 #else /* !CONFIG_SMP */
 #define wbinvd_on_cpu(cpu) wbinvd()
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 9414f84..6738e5c 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -161,13 +161,15 @@ static int __init acpi_parse_madt(struct 
acpi_table_header *table)
 /**
  * acpi_register_lapic - register a local apic and generates a logic cpu number
  * @id: local apic id to register
+ * @acpiid: ACPI id to register
  * @enabled: this cpu is enabled or not
  *
  * Returns the logic cpu number which maps to the local apic
  */
-static int acpi_register_lapic(int id, u8 enabled)
+static int acpi_register_lapic(int id, u32 acpiid, u8 enabled)
 {
unsigned int ver = 0;
+   int cpu;
 
if (id >= MAX_LOCAL_APIC) {
printk(KERN_INFO PREFIX "skipped apicid that is too big\n");
@@ -182,7 +184,11 @@ static int acpi_register_lapic(int id, u8 enabled)
if (boot_cpu_physical_apicid != -1U)
ver = apic_version[boot_cpu_physical_apicid];
 
-   return generic_processor_info(id, ver);
+   cpu = generic_processor_info(id, ver);
+   if (cpu >= 0)
+   early_per_cpu(x86_cpu_to_acpiid, cpu) = acpiid;
+
+   return cpu;
 }
 
 static int __init
@@ -212,7 +218,7 @@ acpi_parse_x2apic(struct acpi_subtable_header *header, 
const unsigned long end)
if (!apic->apic_id_valid(apic_id) && enabled)
printk(KERN_WARNING PREFIX "x2apic entry ignored\n");
else
-   acpi_register_lapic(apic_id, enabled);
+   acpi_register_lapic(apic_id, processor->uid, enabled);
 #else
printk(KERN_WARNING PREFIX "x2apic entry ignored\n");
 #endif
@@ -240,6 +246,7 @@ acpi_parse_lapic(struct acpi_subtable_header * header, 
const unsigned long end)
 * when we use CPU hotplug.
 */
acpi_register_lapic(processor->id,  /* APIC ID */
+   processor->processor_id, /* ACPI ID */
processor->lapic_flags & ACPI_MADT_ENABLED);
 
return 0;
@@ -258,6 +265,7 @@ acpi_parse_sapic(struct acpi_subtable_header *header, const 
unsigned long end)
acpi_table_print_madt_entry(header);
 
acpi_register_lapic((processor->id << 8) | processor->eid,/* APIC ID */
+   processor->processor_id, /* ACPI ID */
processor->lapic_flags & ACPI_MADT_ENABLED);
 
return 0;
@@ -714,7 +722,7 @@ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, 
int *pcpu)
 {
int cpu;
 
-   cpu = acpi_register_lapic(physid, ACPI_MADT_ENABLED);
+   cpu = acpi_register_lapic(physid, U32_MAX, ACPI_MADT_ENABLED);
if (cpu < 0) {
pr_info(PREFIX "Unable to map lapic to logical cpu number\n");
return cpu;
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 60078a6..db2326f 100644
--- a/arch/x86/kernel/apic/apic.c

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

2016-06-30 Thread Vitaly Kuznetsov 
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 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..1678446 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(int, xen_vcpu_id) = -1;
+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;
+
info.mfn = virt_to_gfn(vcpup);
info.offset = xen_offset_in_page(vcpup);
 
@@ -328,6 +335,9 @@ static int __init xen_guest_init(void)
if (xen_vcpu_info == NULL)
return -ENOMEM;
 
+   /* Direct vCPU id mapping for ARM guests. */
+   per_cpu(xen_vcpu_id, 0) = 0;
+
if (gnttab_setup_auto_xlat_frames(grant_frames)) {
free_percpu(xen_vcpu_info);
return -ENOMEM;
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 760789a..ff01f3d 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -118,6 +119,10 @@ DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
  */
 DEFINE_PER_CPU(struct vcpu_info, xen_vcpu_info);
 
+/* Linux <-> Xen vCPU id mapping */
+DEFINE_PER_CPU(int, xen_vcpu_id) = -1;
+EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
+
 enum xen_domain_type xen_domain_type = XEN_NATIVE;
 EXPORT_SYMBOL_GPL(xen_domain_type);
 
@@ -1137,8 +1142,11 @@ void xen_setup_vcpu_info_placement(void)
 {
int cpu;
 
-   for_each_possible_cpu(cpu)
+   for_each_possible_cpu(cpu) {
+   /* Set up direct vCPU id mapping for PV guests. */
+   per_cpu(xen_vcpu_id, cpu) = cpu;
xen_vcpu_setup(cpu);
+   }
 
/* xen_vcpu_setup managed to place the vcpu_info within the
 * percpu area for all cpus, so make use of it. Note that for
@@ -1729,6 +1737,9 @@ asmlinkage __visible void __init xen_start_kernel(void)
 #endif
xen_raw_console_write("about to get started...\n");
 
+   /* Let's presume PV guests always boot on vCPU with id 0. */
+   per_cpu(xen_vcpu_id, 0) = 0;
+
xen_setup_runstate_info(0);
 
xen_efi_init();
@@ -1797,6 +1808,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;
@@ -1808,6 +1825,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;
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..a4926f1 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(int, xen_vcpu_id);
+static

[Xen-devel] [PATCH linux v2 6/9] xen/events: use xen_vcpu_id mapping in events_base

2016-06-30 Thread Vitaly Kuznetsov 
EVTCHNOP_bind_ipi and EVTCHNOP_bind_virq pass vCPU id as a parameter and
Xen's idea of vCPU id should be used. Use the newly introduced xen_vcpu_id
mapping to convert it from Linux's id.

Signed-off-by: Vitaly Kuznetsov 
---
Changes since v1:
- Use xen_vcpu_nr() helper [David Vrabel]
---
 drivers/xen/events/events_base.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 8fb7cbf..d5dbdb9 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -895,7 +895,7 @@ static int bind_ipi_to_irq(unsigned int ipi, unsigned int 
cpu)
irq_set_chip_and_handler_name(irq, _percpu_chip,
  handle_percpu_irq, "ipi");
 
-   bind_ipi.vcpu = cpu;
+   bind_ipi.vcpu = xen_vcpu_nr(cpu);
if (HYPERVISOR_event_channel_op(EVTCHNOP_bind_ipi,
_ipi) != 0)
BUG();
@@ -991,7 +991,7 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu, 
bool percpu)
  handle_edge_irq, "virq");
 
bind_virq.virq = virq;
-   bind_virq.vcpu = cpu;
+   bind_virq.vcpu = xen_vcpu_nr(cpu);
ret = HYPERVISOR_event_channel_op(EVTCHNOP_bind_virq,
_virq);
if (ret == 0)
@@ -1319,7 +1319,7 @@ static int rebind_irq_to_cpu(unsigned irq, unsigned tcpu)
 
/* Send future instances of this interrupt to other vcpu. */
bind_vcpu.port = evtchn;
-   bind_vcpu.vcpu = tcpu;
+   bind_vcpu.vcpu = xen_vcpu_nr(tcpu);
 
/*
 * Mask the event while changing the VCPU binding to prevent
@@ -1459,7 +1459,7 @@ static void restore_cpu_virqs(unsigned int cpu)
 
/* Get a new binding from Xen. */
bind_virq.virq = virq;
-   bind_virq.vcpu = cpu;
+   bind_virq.vcpu = xen_vcpu_nr(cpu);
if (HYPERVISOR_event_channel_op(EVTCHNOP_bind_virq,
_virq) != 0)
BUG();
@@ -1483,7 +1483,7 @@ static void restore_cpu_ipis(unsigned int cpu)
BUG_ON(ipi_from_irq(irq) != ipi);
 
/* Get a new binding from Xen. */
-   bind_ipi.vcpu = cpu;
+   bind_ipi.vcpu = xen_vcpu_nr(cpu);
if (HYPERVISOR_event_channel_op(EVTCHNOP_bind_ipi,
_ipi) != 0)
BUG();
-- 
2.5.5


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

[Xen-devel] [PATCH linux v2 5/9] x86/xen: use xen_vcpu_id mapping when pointing vcpu_info to the shared_info page

2016-06-30 Thread Vitaly Kuznetsov 
shared_info page has space for 32 vcpu info slots for first 32 vCPUs but
these are the first 32 vCPUs from Xen's perspective and we should map them
accordingly with the newly introduced xen_vcpu_id mapping.

Signed-off-by: Vitaly Kuznetsov 
---
Changes since v1:
- Use xen_vcpu_nr() helper [David Vrabel]
---
 arch/x86/xen/enlighten.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 7e3bf5a..bfdd51b 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -207,8 +207,9 @@ static void xen_vcpu_setup(int cpu)
if (per_cpu(xen_vcpu, cpu) == _cpu(xen_vcpu_info, cpu))
return;
}
-   if (cpu < MAX_VIRT_CPUS)
-   per_cpu(xen_vcpu,cpu) = _shared_info->vcpu_info[cpu];
+   if (xen_vcpu_nr(cpu) < MAX_VIRT_CPUS)
+   per_cpu(xen_vcpu, cpu) =
+   _shared_info->vcpu_info[xen_vcpu_nr(cpu)];
 
if (!have_vcpu_info_placement) {
if (cpu >= MAX_VIRT_CPUS)
@@ -1783,9 +1784,10 @@ void __ref xen_hvm_init_shared_info(void)
 * in that case multiple vcpus might be online. */
for_each_online_cpu(cpu) {
/* Leave it to be NULL. */
-   if (cpu >= MAX_VIRT_CPUS)
+   if (xen_vcpu_nr(cpu) >= MAX_VIRT_CPUS)
continue;
-   per_cpu(xen_vcpu, cpu) = 
_shared_info->vcpu_info[cpu];
+   per_cpu(xen_vcpu, cpu) =
+   _shared_info->vcpu_info[xen_vcpu_nr(cpu)];
}
 }
 
-- 
2.5.5


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

[Xen-devel] [PATCH linux v2 7/9] xen/events: fifo: use xen_vcpu_id mapping

2016-06-30 Thread Vitaly Kuznetsov 
EVTCHNOP_init_control has vCPU id as a parameter and Xen's idea of vCPU id
should be used. Use the newly introduced xen_vcpu_id mapping to convert
it from Linux's id.

Signed-off-by: Vitaly Kuznetsov 
---
Changes since v1:
- Use xen_vcpu_nr() helper [David Vrabel]
---
 drivers/xen/events/events_fifo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c
index 9289a17..266c2c7 100644
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -113,7 +113,7 @@ static int init_control_block(int cpu,
 
init_control.control_gfn = virt_to_gfn(control_block);
init_control.offset  = 0;
-   init_control.vcpu= cpu;
+   init_control.vcpu= xen_vcpu_nr(cpu);
 
return HYPERVISOR_event_channel_op(EVTCHNOP_init_control, 
_control);
 }
-- 
2.5.5


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

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

2016-06-30 Thread osstest service owner 
flight 96476 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96476/

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  bb4f41b3dff831faaf5a3248e0ecd123024d7f8f
baseline version:
 xen  8cf167595f4e5db8cbc223c1ff6e109d6daad5ff

Last test of basis96470  2016-06-30 12:02:13 Z0 days
Testing same since96476  2016-06-30 14:01:02 Z0 days1 attempts


People who touched revisions under test:
  Kai Huang 
  Kevin Tian 
  Tianyang Chen 

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=bb4f41b3dff831faaf5a3248e0ecd123024d7f8f
+ . ./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 
bb4f41b3dff831faaf5a3248e0ecd123024d7f8f
+ branch=xen-unstable-smoke
+ revision=bb4f41b3dff831faaf5a3248e0ecd123024d7f8f
+ . ./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
+ '[' xbb4f41b3dff831faaf5a3248e0ecd123024d7f8f = 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 v2] xen/arm: register clocks used by the hypervisor

2016-06-30 Thread Julien Grall 

Hi,

On 30/06/16 16:18, Mark Rutland wrote:

On Thu, Jun 30, 2016 at 04:56:40PM +0200, Dirk Behme wrote:

On 30.06.2016 16:21, Mark Rutland wrote:

On Thu, Jun 30, 2016 at 12:32:32PM +0200, Dirk Behme wrote:

+- clocks: one or more clocks to be registered.
+  Xen hypervisor drivers might replace native drivers, resulting in
+  clocks not registered by these native drivers. To avoid that these
+  unregistered clocks are disabled, then, e.g. by clk_disable_unused(),
+  register them in the hypervisor node.
+  An example for this are the clocks of the serial driver. If the clocks
+  used by the serial hardware interface are not registered by the serial
+  driver the serial output might stop once clk_disable_unused() is called.


This shouldn't be described in terms of the Linux implementation details
like clk_disable_unused. Those can change at any time, and don't define
the contract as such.


Ok. I remove that from the description. Thanks!


Great, thanks.


What exactly is the contract here? I assume that you don't want the
kernel to alter the state of these clocks in any way,


I don't think so. I think what we want is that the kernel just don't
disable the (from kernel's point of view) "unused" clocks. I think
we get this from the fact that using 'clk_ignore_unused' is a
working workaround for this issue.


What if the clock (or a parent thereof) is shared with another device?

Surely you don't want that other driver to change the rate (changing the
rate of the UART behind Xen's back)?

I appreciate that clk_ignore_unused might work on platforms today, but
that relies on the behaviour of drivers, which might change. It may also
not work on other platforms in future, in cases like the above.


e.g. the rate cannot be changed, they must be left always on, parent
clocks cannot be altered if that would result in momentary jitter.

I suspect it may be necessary to do more to ensure that, but I'm not
familiar enough with the clocks subsystem to say.

Are we likely to need to care about regulators, GPIOs, resets, etc? I
worry that this may be the tip of hte iceberg


I don't think so. If there is a user in the kernel of the clock,
fine. Then hopefully the user in the kernel knows what he is doing
with the clock and then he should do what ever he wants.


I'm not sure that's true. A user of the clock may know nothing about
other users. As far as I can see, nothing prevents it from changing the
clock rate.

While drivers in the same kernel can co-ordinate to avoid problems such
as that, we can't do that if we know nothing about the user hidden by
Xen.

 From looking at the Xen bug tracker, it's not clear which
platforms/devices this is necessary for, so it's still not clear to me
if we need to care about regulators, GPIOs, resets, and so on.

Do we know which platforms in particular we need this for?


I believe this is necessary for all the platforms where the UART has a 
clock described in the firmware.


This workaround was first required on the arndale. Note that UART on 
Juno r2 has a clock described but 'clk_ignore_unused' is not necessary. 
I am wondering why it is working.


The number of devices used by Xen is very limited (UART, timer and 
SMMU). However we may also want to consider device passthrough where a 
clock would be handled by another guest.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] xen/arm: register clocks used by the hypervisor

2016-06-30 Thread Mark Rutland 
Hi,

On Thu, Jun 30, 2016 at 04:56:40PM +0200, Dirk Behme wrote:
> On 30.06.2016 16:21, Mark Rutland wrote:
> >On Thu, Jun 30, 2016 at 12:32:32PM +0200, Dirk Behme wrote:
> >>+- clocks: one or more clocks to be registered.
> >>+  Xen hypervisor drivers might replace native drivers, resulting in
> >>+  clocks not registered by these native drivers. To avoid that these
> >>+  unregistered clocks are disabled, then, e.g. by clk_disable_unused(),
> >>+  register them in the hypervisor node.
> >>+  An example for this are the clocks of the serial driver. If the clocks
> >>+  used by the serial hardware interface are not registered by the serial
> >>+  driver the serial output might stop once clk_disable_unused() is called.
> >
> >This shouldn't be described in terms of the Linux implementation details
> >like clk_disable_unused. Those can change at any time, and don't define
> >the contract as such.
> 
> Ok. I remove that from the description. Thanks!

Great, thanks.

> >What exactly is the contract here? I assume that you don't want the
> >kernel to alter the state of these clocks in any way,
> 
> I don't think so. I think what we want is that the kernel just don't
> disable the (from kernel's point of view) "unused" clocks. I think
> we get this from the fact that using 'clk_ignore_unused' is a
> working workaround for this issue.

What if the clock (or a parent thereof) is shared with another device?

Surely you don't want that other driver to change the rate (changing the
rate of the UART behind Xen's back)?

I appreciate that clk_ignore_unused might work on platforms today, but
that relies on the behaviour of drivers, which might change. It may also
not work on other platforms in future, in cases like the above.

> >e.g. the rate cannot be changed, they must be left always on, parent
> >clocks cannot be altered if that would result in momentary jitter.
> >
> >I suspect it may be necessary to do more to ensure that, but I'm not
> >familiar enough with the clocks subsystem to say.
> >
> >Are we likely to need to care about regulators, GPIOs, resets, etc? I
> >worry that this may be the tip of hte iceberg
> 
> I don't think so. If there is a user in the kernel of the clock,
> fine. Then hopefully the user in the kernel knows what he is doing
> with the clock and then he should do what ever he wants.

I'm not sure that's true. A user of the clock may know nothing about
other users. As far as I can see, nothing prevents it from changing the
clock rate.

While drivers in the same kernel can co-ordinate to avoid problems such
as that, we can't do that if we know nothing about the user hidden by
Xen.

From looking at the Xen bug tracker, it's not clear which
platforms/devices this is necessary for, so it's still not clear to me
if we need to care about regulators, GPIOs, resets, and so on.

Do we know which platforms in particular we need this for?

> As there is a user in the kernel, we don't have to care about
> 'accidentally' disabling it.
> 
> Just let us care about the clocks there is no user.

As above, I don't believe that alone is sufficient in general, though it
may happen to be for a particular platform. Without information
regarding the affected platform(s), it's rather difficult to tell.

Thanks,
Mark.

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

Re: [Xen-devel] [PATCH v3] xsm: add a default policy to .init.data

2016-06-30 Thread Konrad Rzeszutek Wilk 
On Thu, Jun 30, 2016 at 10:01:18AM -0400, Daniel De Graaf wrote:
> On 06/30/2016 09:45 AM, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jun 29, 2016 at 11:09:01AM -0400, Daniel De Graaf wrote:
> > > This adds a Kconfig option and support for including the XSM policy from
> > > tools/flask/policy in the hypervisor so that the bootloader does not
> > > need to provide a policy to get sane behavior from an XSM-enabled
> > > hypervisor.  The policy provided by the bootloader, if present, will
> > > override the built-in policy.
> > > 
> > > The XSM policy is not moved out of tools because that remains the
> > > primary location for installing and configuring the policy.
> > > 
> > > Signed-off-by: Daniel De Graaf 
> > > ---
> > > 
> > > Changes from v2 (dropped acks and reviewed-by):
> > >  - Drop linker script changes, use python binary-to-C file script
> > >  - Make the config option always include the policy if selected
> > >  - Note the new conditional dependency on checkpolicy in INSTALL
> > 
> > I liked the previous patch of putting in it in __init section.
> > Is that something this patch could do? Ah, n/m. I see that
> > the python script generates the binary with __init!
> > 
> > Secondly I was wondering why the suggestion I had - which was to check
> > of the 'checkpolicy' availability - and if not found - then
> > hide the Kconfig option was not mentioned?
> 
> At the moment, since FLASK is the only XSM implementation and it is not
> enabled by default, if someone enables XSM they will need to generate a
> security policy at some point: either during the hypervisor build or in
> the tools build.  Otherwise, they will need to disable FLASK at runtime
> or (worst case) run without a policy at all, which means all domains can
> act as dom0.  If you plan to disable FLASK at runtime, it is better to
> compile without XSM enabled so you don't pay the cost of the function
> calls to the XSM hooks on (almost) every hypercall.
> 
> Otherwise, I was planning to just change the default from always "y" to
> "y" if checkpolicy was found and "n" if not.  This would end up running
> "checkpolicy -h" on every (recursive) Make invocation if placed in the
> top-level Config.mk - I'm unsure if that would be a problem or not.

We already do quite a lot of other checks in there. I am not sure if
an extra one would be so bad. Do other maintainers care about it?
> 
> > .. snip...
> > > +sys.stdout.write("\n};\nconst int __init xsm_init_policy_size = %d;\n" % 
> > > policy_size)
> > > diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
> > > index 8df1a3c..93c7d43 100644
> > > --- a/xen/xsm/xsm_core.c
> > > +++ b/xen/xsm/xsm_core.c
> > > @@ -36,6 +36,24 @@ static inline int verify(struct xsm_operations *ops)
> > >  return 0;
> > >  }
> > > 
> > > +#ifdef CONFIG_XSM_POLICY
> > > +extern char xsm_init_policy[];
> > 
> > > +extern int xsm_init_policy_size;
> > > +#else
> > > +#define xsm_init_policy 0
> > > +#endif
> > > +
> > > +static void __init xsm_policy_init(void)
> > > +{
> > > +#ifdef CONFIG_XSM_POLICY
> > > +if ( policy_size == 0 )
> > > +{
> > > +policy_buffer = xsm_init_policy;
> > > +policy_size = xsm_init_policy_size;
> > > +}
> > > +#endif
> > > +}
> > > +
> > 
> > This all looks like it could go in a header file?
> 
> Sure, I could move it to xsm.h.  I thought it might be clearer to have the
> assignment and the xfree() check in the same file.

You are the maintainer of that code, so it is your call.

Having externs in C code is not that great (from my perspective),
so if you move all of this to a header file that should get easier?

But as said - you are the maintainer and I am just voicing my
preferences - and if the code looks "nicer" your way - by all means
do it that way! I am not going to get offended :-)


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

Re: [Xen-devel] [PATCH v5 08/14] hvmloader: Locate the BIOS blob

2016-06-30 Thread Anthony PERARD 
On Mon, Jun 27, 2016 at 01:13:43AM -0600, Jan Beulich wrote:
> >>> On 24.06.16 at 19:02,  wrote:
> > On Fri, Jun 24, 2016 at 01:33:45AM -0600, Jan Beulich wrote:
> >> >>> On 22.06.16 at 19:15,  wrote:
> >> > --- a/tools/firmware/hvmloader/hvmloader.c
> >> > +++ b/tools/firmware/hvmloader/hvmloader.c
> >> > @@ -253,10 +253,51 @@ static void acpi_enable_sci(void)
> >> >  BUG_ON(!(pm1a_cnt_val & ACPI_PM1C_SCI_EN));
> >> >  }
> >> >  
> >> > +const struct hvm_modlist_entry *get_module_entry(
> >> > +const struct hvm_start_info *info,
> >> > +const char *name)
> >> > +{
> >> > +const struct hvm_modlist_entry *modlist =
> >> > +(struct hvm_modlist_entry *)(uint32_t)info->modlist_paddr;
> >> > +unsigned int i;
> >> > +
> >> > +if ( !modlist || info->modlist_paddr > UINT_MAX)
> >> > +return NULL;
> >> 
> >> How about info->modlist_paddr + info->nr_modules * sizeof()?
> >> You check for overflow below, but not here. I think you should
> >> either consistently rely on there being something right below 4Gb
> >> which makes this impossible (and then say so in a comment), or
> >> do full checks everywhere.
> > 
> > I'll do the full checks.
> > 
> >> > +for ( i = 0; i < info->nr_modules; i++ )
> >> > +{
> >> > +uint32_t module_name = modlist[i].cmdline_paddr;
> >> > +
> >> > +/* Skip if the module or its cmdline is missing. */
> >> > +if ( !module_name || !modlist[i].paddr )
> >> > +continue;
> >> > +
> >> > +/* Skip if the cmdline can not be read. */
> >> > +if ( modlist[i].cmdline_paddr > UINT_MAX )
> >> > +continue;
> >> 
> >> Similarly here.
> > 
> > Here, I don't know the size of the cmdline and I don't think calling an
> > extra strlen() would be usefull. I think that the strcmp() below is going to
> > be enough for the top bondary check.
> 
> No - once you reach the 4Gb boundary, the compare would continue
> at address zero. That's not what you want.
> > Or I could use the size of name.
> 
> Size of name?

The function get_module_entry() takes an argument called "name", I think
I was proposing to use that, strlen(name).

So, I'm going to add this condition:
(cmdline_paddr + strlen(name) > UINTPTR_MAX)
name is the string we are going to compare cmdline to. I think that
will be enough to do a full check of the module cmdline.


> >> > +{
> >> > +if ( modlist[i].paddr > UINT_MAX || modlist[i].size > 
> >> > UINT_MAX ||
> >> > + (modlist[i].paddr + modlist[i].size) > UINT_MAX )
> >> 
> >> I think the last one could be >=.
> > 
> > I think it's valid if addr+size == UINT_MAX. That would means the last
> > byte of the module would be at 0xFFFE.
> 
> It's even valid when addr+size == UINT_MAX+1 (without value
> wrapping of course), as the last valid byte (i.e. the last one
> hvmloader can address easily) is at 0x.

I'll do (addr+size-1 > UINTPTR_MAX) which should return true when the
module cross the 4GB boundary.

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v2] xen/arm: register clocks used by the hypervisor

2016-06-30 Thread Dirk Behme 

On 30.06.2016 16:21, Mark Rutland wrote:

On Thu, Jun 30, 2016 at 12:32:32PM +0200, Dirk Behme wrote:

Some clocks might be used by the Xen hypervisor and not by the Linux
kernel. If these are not registered by the Linux kernel, they might be
disabled by clk_disable_unused() as the kernel doesn't know that they
are used. The clock of the serial console handled by Xen is one
example for this. It might be disabled by clk_disable_unused() which
stops the whole serial output, even from Xen, then.

Up to now, the workaround for this has been to use the Linux kernel
command line parameter 'clk_ignore_unused'. See Xen bug

http://bugs.xenproject.org/xen/bug/45

too.

To fix this, we will add the "unused" clocks in Xen to the hypervisor
node. The Linux kernel has to register the clocks from the hypervisor
node, then.

Therefore, check if there is a "clocks" entry in the hypervisor node
and if so register the given clocks to the Linux kernel clock
framework and with this mark them as used. This prevents the clocks
from being disabled.

Signed-off-by: Dirk Behme 
---
Changes in v2:
  - Rebase against git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-4.8
  - Add changes to Documentation/devicetree/bindings/arm/xen.txt

  Documentation/devicetree/bindings/arm/xen.txt | 11 +++
  arch/arm/xen/enlighten.c  | 47 +++
  2 files changed, 58 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
b/Documentation/devicetree/bindings/arm/xen.txt
index c9b9321..55dfd3b 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -17,6 +17,17 @@ the following properties:
A GIC node is also required.
This property is unnecessary when booting Dom0 using ACPI.

+Optional properties:
+
+- clocks: one or more clocks to be registered.
+  Xen hypervisor drivers might replace native drivers, resulting in
+  clocks not registered by these native drivers. To avoid that these
+  unregistered clocks are disabled, then, e.g. by clk_disable_unused(),
+  register them in the hypervisor node.
+  An example for this are the clocks of the serial driver. If the clocks
+  used by the serial hardware interface are not registered by the serial
+  driver the serial output might stop once clk_disable_unused() is called.


This shouldn't be described in terms of the Linux implementation details
like clk_disable_unused. Those can change at any time, and don't define
the contract as such.



Ok. I remove that from the description. Thanks!



What exactly is the contract here? I assume that you don't want the
kernel to alter the state of these clocks in any way,



I don't think so. I think what we want is that the kernel just don't 
disable the (from kernel's point of view) "unused" clocks. I think we 
get this from the fact that using 'clk_ignore_unused' is a working 
workaround for this issue.




e.g. the rate
cannot be changed, they must be left always on, parent clocks cannot be
altered if that would result in momentary jitter.

I suspect it may be necessary to do more to ensure that, but I'm not
familiar enough with the clocks subsystem to say.

>

Are we likely to need to care about regulators, GPIOs, resets, etc? I
worry that this may be the tip of hte iceberg



I don't think so. If there is a user in the kernel of the clock, fine. 
Then hopefully the user in the kernel knows what he is doing with the 
clock and then he should do what ever he wants. As there is a user in 
the kernel, we don't have to care about 'accidentally' disabling it.


Just let us care about the clocks there is no user.

Best regards

Dirk



+
  To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" 
node
  under /hypervisor with following parameters:

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 47acb36..5c546d0 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -444,6 +445,52 @@ static int __init xen_pm_init(void)
  }
  late_initcall(xen_pm_init);

+/*
+ * Check if we want to register some clocks, that they
+ * are not freed because unused by clk_disable_unused().
+ * E.g. the serial console clock.
+ */
+static int __init xen_arm_register_clks(void)
+{
+   struct clk *clk;
+   struct device_node *xen_node;
+   unsigned int i, count;
+   int ret = 0;
+
+   xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
+   if (!xen_node) {
+   pr_err("Xen support was detected before, but it has 
disappeared\n");
+   return -EINVAL;
+   }
+
+   count = of_clk_get_parent_count(xen_node);
+   if (!count)
+   goto out;
+
+   for (i = 0; i < count; i++) {
+   clk = of_clk_get(xen_node, i);
+   if (IS_ERR(clk)) {
+   pr_err("Xen

Re: [Xen-devel] [PATCH v2] xen/arm: register clocks used by the hypervisor

2016-06-30 Thread Mark Rutland 
On Thu, Jun 30, 2016 at 12:32:32PM +0200, Dirk Behme wrote:
> Some clocks might be used by the Xen hypervisor and not by the Linux
> kernel. If these are not registered by the Linux kernel, they might be
> disabled by clk_disable_unused() as the kernel doesn't know that they
> are used. The clock of the serial console handled by Xen is one
> example for this. It might be disabled by clk_disable_unused() which
> stops the whole serial output, even from Xen, then.
> 
> Up to now, the workaround for this has been to use the Linux kernel
> command line parameter 'clk_ignore_unused'. See Xen bug
> 
> http://bugs.xenproject.org/xen/bug/45
> 
> too.
> 
> To fix this, we will add the "unused" clocks in Xen to the hypervisor
> node. The Linux kernel has to register the clocks from the hypervisor
> node, then.
> 
> Therefore, check if there is a "clocks" entry in the hypervisor node
> and if so register the given clocks to the Linux kernel clock
> framework and with this mark them as used. This prevents the clocks
> from being disabled.
> 
> Signed-off-by: Dirk Behme 
> ---
> Changes in v2:
>  - Rebase against git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
> for-linus-4.8
>  - Add changes to Documentation/devicetree/bindings/arm/xen.txt
> 
>  Documentation/devicetree/bindings/arm/xen.txt | 11 +++
>  arch/arm/xen/enlighten.c  | 47 
> +++
>  2 files changed, 58 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
> b/Documentation/devicetree/bindings/arm/xen.txt
> index c9b9321..55dfd3b 100644
> --- a/Documentation/devicetree/bindings/arm/xen.txt
> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> @@ -17,6 +17,17 @@ the following properties:
>A GIC node is also required.
>This property is unnecessary when booting Dom0 using ACPI.
>  
> +Optional properties:
> +
> +- clocks: one or more clocks to be registered.
> +  Xen hypervisor drivers might replace native drivers, resulting in
> +  clocks not registered by these native drivers. To avoid that these
> +  unregistered clocks are disabled, then, e.g. by clk_disable_unused(),
> +  register them in the hypervisor node.
> +  An example for this are the clocks of the serial driver. If the clocks
> +  used by the serial hardware interface are not registered by the serial
> +  driver the serial output might stop once clk_disable_unused() is called.

This shouldn't be described in terms of the Linux implementation details
like clk_disable_unused. Those can change at any time, and don't define
the contract as such.

What exactly is the contract here? I assume that you don't want the
kernel to alter the state of these clocks in any way, e.g. the rate
cannot be changed, they must be left always on, parent clocks cannot be
altered if that would result in momentary jitter.

I suspect it may be necessary to do more to ensure that, but I'm not
familiar enough with the clocks subsystem to say.

Are we likely to need to care about regulators, GPIOs, resets, etc? I
worry that this may be the tip of hte iceberg, and we might need a
better way of catering for the general case of resources Xen wants to
own.

Thanks,
Mark.

> +
>  To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" 
> node
>  under /hypervisor with following parameters:
>  
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 47acb36..5c546d0 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -444,6 +445,52 @@ static int __init xen_pm_init(void)
>  }
>  late_initcall(xen_pm_init);
>  
> +/*
> + * Check if we want to register some clocks, that they
> + * are not freed because unused by clk_disable_unused().
> + * E.g. the serial console clock.
> + */
> +static int __init xen_arm_register_clks(void)
> +{
> + struct clk *clk;
> + struct device_node *xen_node;
> + unsigned int i, count;
> + int ret = 0;
> +
> + xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
> + if (!xen_node) {
> + pr_err("Xen support was detected before, but it has 
> disappeared\n");
> + return -EINVAL;
> + }
> +
> + count = of_clk_get_parent_count(xen_node);
> + if (!count)
> + goto out;
> +
> + for (i = 0; i < count; i++) {
> + clk = of_clk_get(xen_node, i);
> + if (IS_ERR(clk)) {
> + pr_err("Xen failed to register clock %i. Error: %li\n",
> +i, PTR_ERR(clk));
> + ret = PTR_ERR(clk);
> + goto out;
> + }
> +
> + ret = clk_prepare_enable(clk);
> + if (ret < 0) {
> + pr_err("Xen failed to enable clock %i. Error: %i\n",
> +i, ret);
> + goto out;
> +

Re: [Xen-devel] [PATCH v3] xsm: add a default policy to .init.data

2016-06-30 Thread Daniel De Graaf 

On 06/30/2016 09:45 AM, Konrad Rzeszutek Wilk wrote:

On Wed, Jun 29, 2016 at 11:09:01AM -0400, Daniel De Graaf wrote:

This adds a Kconfig option and support for including the XSM policy from
tools/flask/policy in the hypervisor so that the bootloader does not
need to provide a policy to get sane behavior from an XSM-enabled
hypervisor.  The policy provided by the bootloader, if present, will
override the built-in policy.

The XSM policy is not moved out of tools because that remains the
primary location for installing and configuring the policy.

Signed-off-by: Daniel De Graaf 
---

Changes from v2 (dropped acks and reviewed-by):
 - Drop linker script changes, use python binary-to-C file script
 - Make the config option always include the policy if selected
 - Note the new conditional dependency on checkpolicy in INSTALL


I liked the previous patch of putting in it in __init section.
Is that something this patch could do? Ah, n/m. I see that
the python script generates the binary with __init!

Secondly I was wondering why the suggestion I had - which was to check
of the 'checkpolicy' availability - and if not found - then
hide the Kconfig option was not mentioned?


At the moment, since FLASK is the only XSM implementation and it is not
enabled by default, if someone enables XSM they will need to generate a
security policy at some point: either during the hypervisor build or in
the tools build.  Otherwise, they will need to disable FLASK at runtime
or (worst case) run without a policy at all, which means all domains can
act as dom0.  If you plan to disable FLASK at runtime, it is better to
compile without XSM enabled so you don't pay the cost of the function
calls to the XSM hooks on (almost) every hypercall.

Otherwise, I was planning to just change the default from always "y" to
"y" if checkpolicy was found and "n" if not.  This would end up running
"checkpolicy -h" on every (recursive) Make invocation if placed in the
top-level Config.mk - I'm unsure if that would be a problem or not.


.. snip...

+sys.stdout.write("\n};\nconst int __init xsm_init_policy_size = %d;\n" % 
policy_size)
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 8df1a3c..93c7d43 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -36,6 +36,24 @@ static inline int verify(struct xsm_operations *ops)
 return 0;
 }

+#ifdef CONFIG_XSM_POLICY
+extern char xsm_init_policy[];



+extern int xsm_init_policy_size;
+#else
+#define xsm_init_policy 0
+#endif
+
+static void __init xsm_policy_init(void)
+{
+#ifdef CONFIG_XSM_POLICY
+if ( policy_size == 0 )
+{
+policy_buffer = xsm_init_policy;
+policy_size = xsm_init_policy_size;
+}
+#endif
+}
+


This all looks like it could go in a header file?


Sure, I could move it to xsm.h.  I thought it might be clearer to have the
assignment and the xfree() check in the same file.

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

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

2016-06-30 Thread osstest service owner 
flight 96470 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96470/

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  8cf167595f4e5db8cbc223c1ff6e109d6daad5ff
baseline version:
 xen  3572f2fa7b0f6f20eb145bdccaf5888c76be8960

Last test of basis96399  2016-06-29 19:02:03 Z0 days
Testing same since96470  2016-06-30 12:02:13 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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=8cf167595f4e5db8cbc223c1ff6e109d6daad5ff
+ . ./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 
8cf167595f4e5db8cbc223c1ff6e109d6daad5ff
+ branch=xen-unstable-smoke
+ revision=8cf167595f4e5db8cbc223c1ff6e109d6daad5ff
+ . ./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
+ '[' x8cf167595f4e5db8cbc223c1ff6e109d6daad5ff = 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 v3] xsm: add a default policy to .init.data

2016-06-30 Thread Konrad Rzeszutek Wilk 
On Wed, Jun 29, 2016 at 11:09:01AM -0400, Daniel De Graaf wrote:
> This adds a Kconfig option and support for including the XSM policy from
> tools/flask/policy in the hypervisor so that the bootloader does not
> need to provide a policy to get sane behavior from an XSM-enabled
> hypervisor.  The policy provided by the bootloader, if present, will
> override the built-in policy.
> 
> The XSM policy is not moved out of tools because that remains the
> primary location for installing and configuring the policy.
> 
> Signed-off-by: Daniel De Graaf 
> ---
> 
> Changes from v2 (dropped acks and reviewed-by):
>  - Drop linker script changes, use python binary-to-C file script
>  - Make the config option always include the policy if selected
>  - Note the new conditional dependency on checkpolicy in INSTALL

I liked the previous patch of putting in it in __init section.
Is that something this patch could do? Ah, n/m. I see that
the python script generates the binary with __init!

Secondly I was wondering why the suggestion I had - which was to check
of the 'checkpolicy' availability - and if not found - then
hide the Kconfig option was not mentioned?
.. snip...
> +sys.stdout.write("\n};\nconst int __init xsm_init_policy_size = %d;\n" % 
> policy_size)
> diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
> index 8df1a3c..93c7d43 100644
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -36,6 +36,24 @@ static inline int verify(struct xsm_operations *ops)
>  return 0;
>  }
>  
> +#ifdef CONFIG_XSM_POLICY
> +extern char xsm_init_policy[];

> +extern int xsm_init_policy_size;
> +#else
> +#define xsm_init_policy 0
> +#endif
> +
> +static void __init xsm_policy_init(void)
> +{
> +#ifdef CONFIG_XSM_POLICY
> +if ( policy_size == 0 )
> +{
> +policy_buffer = xsm_init_policy;
> +policy_size = xsm_init_policy_size;
> +}
> +#endif
> +}
> +

This all looks like it could go in a header file?

>  static int __init xsm_core_init(void)
>  {
>  if ( verify(_xsm_ops) )
> @@ -46,6 +64,7 @@ static int __init xsm_core_init(void)
>  }
>  
>  xsm_ops = _xsm_ops;
> +xsm_policy_init();
>  flask_init();
>  
>  return 0;
> @@ -98,7 +117,8 @@ int __init xsm_dt_init(void)
>  
>  ret = xsm_core_init();
>  
> -xfree(policy_buffer);
> +if ( policy_buffer != xsm_init_policy )
> +xfree(policy_buffer);
>  
>  return ret;
>  }
> -- 
> 2.7.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] Lenovo X200 IOMMU support through Xen 4.6 iommu=no-igfx switch

2016-06-30 Thread Konrad Rzeszutek Wilk 
On Sun, Jun 26, 2016 at 11:48:44PM +, Thierry Laurion wrote:
> Sorry for the precedent post that was written a bit too fast. Libreboot was
> flashed when I wrote it, which is the equivalent of a having vt-d
> deactivated (iommu=0). Thanks to a user that read this post and wrote to me
> personally so I could do my mea culpa. Sorry for the precedent misleading
> post.
> 
> Xen on a GM45 chipset and with IGD i915 driver is still getting the system
> hanged when vt-d is activated. I'm willing to borrow a machine to the Xen
> developer that could fix the iommu=no-igfx code for gm45 chipset to
> actually work.

This sounds like http://wiki.xenproject.org/wiki/Paravirtualized_DRM
issues.

Can you try and also attach lspci -v ?


diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index aef87fd..cf31aad 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -35,7 +35,7 @@
 #ifdef CONFIG_INTEL_IOMMU
 #define USE_PCI_DMA_API 1
 #else
-#define USE_PCI_DMA_API 0
+#define USE_PCI_DMA_API 1
 #endif
 
 struct intel_gtt_driver {
@@ -654,6 +654,7 @@ static int intel_gtt_init(void)
 
intel_private.needs_dmar = USE_PCI_DMA_API && INTEL_GTT_GEN > 2;
 
+   printk("%s: %s DMA ops\n", __func__,intel_private.needs_dmar ? "Using" 
: "Not using");
ret = intel_gtt_setup_scratch_page();
if (ret != 0) {
intel_gtt_cleanup();
> 
> A ticket is opened here with current states of thing:
> https://github.com/QubesOS/qubes-issues/issues/1594#issuecomment-209213917
> 
> Sorry about that (and repost since I wrote the same misleading post to two
> places)
> Thierry
> 
> Le dim. 28 févr. 2016 à 14:03, Thierry Laurion 
> a écrit :
> 
> > The problem wasn't with xen iommu support but kms/drm and i915 driver.
> >
> > Passing to the kernel i915.preliminary_hw_support=1 fixes it all :)
> >
> > Thanks
> >
> > Le mer. 6 janv. 2016 à 22:11, Thierry Laurion 
> > a écrit :
> >
> >> Nope. That commit is present in 4.6 and results in x200 being able to
> >> boot xen.
> >>
> >> Not having that option makes xen hang at boot.
> >>
> >> If present, it works until other vm access pass-through devices, which
> >> I'm not able to troubleshoot even through amt SOL.
> >>
> >> See here for debug logs:
> >> https://groups.google.com/forum/m/#!topic/qubes-users/bHQHjXqinaU
> >>
> >> Le mer. 6 janv. 2016 09:35, Jan Beulich  a écrit :
> >>
> >>> >>> On 22.12.15 at 19:04,  wrote:
> >>> > iommu=no-igfx is a gamechanger for Qubes support through 3.1 RC1
> >>> release,
> >>> > thanks to Xen 4.6 :)
> >>> >
> >>> > The Lenovo X200 supports vt-x, vt-d and TPM as reported and required by
> >>> > Qubes in the HCL attached to this e-mail. The problem is that when
> >>> Qubes
> >>> > launches it's netvm which uses IOMMU to talk to it's network card, it
> >>> > freezes the whole system up. Even when specifying sync_console, I
> >>> don't get
> >>> > much more verbosity. I ordered a PCMCIA to serial adapter which will be
> >>> > shipped to my door late January... Meanwhile, booting with iommu=0
> >>> makes
> >>> > things work, but a potential hardware component being compromised has
> >>> > chances to compromise the whole system since compartmentalization is
> >>> not
> >>> > guaranteed without IOMMU (vt-d).
> >>> >
> >>> > A little more love is needed from xen to make that laptop line
> >>> supported by
> >>> > Qubes and a nice alternative to the costy Librem currently promoted by
> >>> > Qubes-Purism
> >>> > partnership
> >>>
> >>> Is all of the above and below a quite complicated way of expressing
> >>> that you'd like to see commit 146341187a backported to 4.6.x?
> >>>
> >>> Jan
> >>>
> >>> > <
> >>> http://arstechnica.com/gadgets/2015/12/qubes-os-will-ship-pre-installed-on-p
> >>> > urisms-security-focused-librem-13-laptop/>which
> >>> > suggest that the laptop will be Respect Your Freedom compliant in the
> >>> > future with Intel participation in removing ME and AMT
> >>> > , which is not guaranteed at all.
> >>> > <
> >>> http://www.phoronix.com/scan.php?page=news_item=Purism-Librem-Still-Blobbe
> >>> > d>
> >>> > If Xen 4.6 can cooperate with Penryn GM45 chipset, it's all MiniFree
> >>> laptops
> >>> >  (and Libreboot
> >>> support of
> >>> > those ) that will be
> >>> potential
> >>> > candidates!
> >>> > Please share the love so that the community has a cheap alternative.
> >>> >
> >>> > Requirements to replicate bug:
> >>> > Model: X200 745434U with p8700 CPU running 1067a microcode(important),
> >>> > upgrable to 8go
> >>> > BIOS: Lenovo 3.22/1.07 (latest from 2013
> >>> > )
> >>> > Network card supports FLReset+ as requested here
> >>> > .
> >>> > Bios settings: vt-d and

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

2016-06-30 Thread osstest service owner 
flight 96449 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96449/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 94748
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748

version targeted for testing:
 ovmf 5f928b41aa65b98141b1956ebcf9ce9267f532d3
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z   36 days
Failing since 94750  2016-05-25 03:43:08 Z   36 days   77 attempts
Testing same since96449  2016-06-30 04:13:27 Z0 days1 attempts


People who touched revisions under test:
  Anandakrishnan Loganathan 
  Ard Biesheuvel 
  Bruce Cran 
  Bruce Cran 
  Chao Zhang 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Darbin Reyes 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Evgeny Yakovlev 
  Feng Tian 
  Fu Siyuan 
  Fu, Siyuan 
  Gary Li 
  Gary Lin 
  Giri P Mudusuru 
  Hao Wu 
  Hegde Nagaraj P 
  hegdenag 
  Heyi Guo 
  Jan D?bro? 
  Jan Dabros 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Joe Zhou 
  Jordan Justen 
  Katie Dellaquila 
  Laszlo Ersek 
  Liming Gao 
  Lu, ShifeiX A 
  lushifex 
  Marcin Wojtas 
  Marvin H?user 
  Marvin Haeuser 
  Maurice Ma 
  Michael Zimmermann 
  Qiu Shumin 
  Ruiyu Ni 
  Ryan Harkin 
  Sami Mujawar 
  Satya Yarlagadda 
  Shannon Zhao 
  Sriram Subramanian 
  Star Zeng 
  Sunny Wang 
  Tapan Shah 
  Thomas Palmer 
  Yarlagadda, Satya P 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH v5 19/44] xen: dma-mapping: Use unsigned long for dma_attrs

2016-06-30 Thread Konrad Rzeszutek Wilk 
On Thu, Jun 30, 2016 at 10:25:46AM +0200, Krzysztof Kozlowski wrote:
> Split out subsystem specific changes for easier reviews. This will be
> squashed with main commit.
> 
> Signed-off-by: Krzysztof Kozlowski 
> [for xen]
> Acked-by: David Vrabel 

Acked-by: Konrad Rzeszutek Wilk 
> ---
>  drivers/xen/swiotlb-xen.c | 14 +++---
>  include/xen/swiotlb-xen.h | 12 ++--
>  2 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 7399782c0998..87e6035c9e81 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -294,7 +294,7 @@ error:
>  void *
>  xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
>  dma_addr_t *dma_handle, gfp_t flags,
> -struct dma_attrs *attrs)
> +unsigned long attrs)
>  {
>   void *ret;
>   int order = get_order(size);
> @@ -346,7 +346,7 @@ EXPORT_SYMBOL_GPL(xen_swiotlb_alloc_coherent);
>  
>  void
>  xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
> -   dma_addr_t dev_addr, struct dma_attrs *attrs)
> +   dma_addr_t dev_addr, unsigned long attrs)
>  {
>   int order = get_order(size);
>   phys_addr_t phys;
> @@ -378,7 +378,7 @@ EXPORT_SYMBOL_GPL(xen_swiotlb_free_coherent);
>  dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
>   unsigned long offset, size_t size,
>   enum dma_data_direction dir,
> - struct dma_attrs *attrs)
> + unsigned long attrs)
>  {
>   phys_addr_t map, phys = page_to_phys(page) + offset;
>   dma_addr_t dev_addr = xen_phys_to_bus(phys);
> @@ -434,7 +434,7 @@ EXPORT_SYMBOL_GPL(xen_swiotlb_map_page);
>   */
>  static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
>size_t size, enum dma_data_direction dir,
> -  struct dma_attrs *attrs)
> +  unsigned long attrs)
>  {
>   phys_addr_t paddr = xen_bus_to_phys(dev_addr);
>  
> @@ -462,7 +462,7 @@ static void xen_unmap_single(struct device *hwdev, 
> dma_addr_t dev_addr,
>  
>  void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
>   size_t size, enum dma_data_direction dir,
> - struct dma_attrs *attrs)
> + unsigned long attrs)
>  {
>   xen_unmap_single(hwdev, dev_addr, size, dir, attrs);
>  }
> @@ -538,7 +538,7 @@ EXPORT_SYMBOL_GPL(xen_swiotlb_sync_single_for_device);
>  int
>  xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
>int nelems, enum dma_data_direction dir,
> -  struct dma_attrs *attrs)
> +  unsigned long attrs)
>  {
>   struct scatterlist *sg;
>   int i;
> @@ -599,7 +599,7 @@ EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg_attrs);
>  void
>  xen_swiotlb_unmap_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
>  int nelems, enum dma_data_direction dir,
> -struct dma_attrs *attrs)
> +unsigned long attrs)
>  {
>   struct scatterlist *sg;
>   int i;
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index 8b2eb93ae8ba..7c35e279d1e3 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -9,30 +9,30 @@ extern int xen_swiotlb_init(int verbose, bool early);
>  extern void
>  *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
>   dma_addr_t *dma_handle, gfp_t flags,
> - struct dma_attrs *attrs);
> + unsigned long attrs);
>  
>  extern void
>  xen_swiotlb_free_coherent(struct device *hwdev, size_t size,
> void *vaddr, dma_addr_t dma_handle,
> -   struct dma_attrs *attrs);
> +   unsigned long attrs);
>  
>  extern dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
>  unsigned long offset, size_t size,
>  enum dma_data_direction dir,
> -struct dma_attrs *attrs);
> +unsigned long attrs);
>  
>  extern void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
>  size_t size, enum dma_data_direction dir,
> -struct dma_attrs *attrs);
> +unsigned long attrs);
>  extern int
>  xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
>int nelems, enum dma_data_direction dir,
> -

[Xen-devel] [PATCH v2] xen/arm: register clocks used by the hypervisor

2016-06-30 Thread Dirk Behme 
Some clocks might be used by the Xen hypervisor and not by the Linux
kernel. If these are not registered by the Linux kernel, they might be
disabled by clk_disable_unused() as the kernel doesn't know that they
are used. The clock of the serial console handled by Xen is one
example for this. It might be disabled by clk_disable_unused() which
stops the whole serial output, even from Xen, then.

Up to now, the workaround for this has been to use the Linux kernel
command line parameter 'clk_ignore_unused'. See Xen bug

http://bugs.xenproject.org/xen/bug/45

too.

To fix this, we will add the "unused" clocks in Xen to the hypervisor
node. The Linux kernel has to register the clocks from the hypervisor
node, then.

Therefore, check if there is a "clocks" entry in the hypervisor node
and if so register the given clocks to the Linux kernel clock
framework and with this mark them as used. This prevents the clocks
from being disabled.

Signed-off-by: Dirk Behme 
---
Changes in v2:
 - Rebase against git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-4.8
 - Add changes to Documentation/devicetree/bindings/arm/xen.txt

 Documentation/devicetree/bindings/arm/xen.txt | 11 +++
 arch/arm/xen/enlighten.c  | 47 +++
 2 files changed, 58 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
b/Documentation/devicetree/bindings/arm/xen.txt
index c9b9321..55dfd3b 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -17,6 +17,17 @@ the following properties:
   A GIC node is also required.
   This property is unnecessary when booting Dom0 using ACPI.
 
+Optional properties:
+
+- clocks: one or more clocks to be registered.
+  Xen hypervisor drivers might replace native drivers, resulting in
+  clocks not registered by these native drivers. To avoid that these
+  unregistered clocks are disabled, then, e.g. by clk_disable_unused(),
+  register them in the hypervisor node.
+  An example for this are the clocks of the serial driver. If the clocks
+  used by the serial hardware interface are not registered by the serial
+  driver the serial output might stop once clk_disable_unused() is called.
+
 To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
 under /hypervisor with following parameters:
 
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 47acb36..5c546d0 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -444,6 +445,52 @@ static int __init xen_pm_init(void)
 }
 late_initcall(xen_pm_init);
 
+/*
+ * Check if we want to register some clocks, that they
+ * are not freed because unused by clk_disable_unused().
+ * E.g. the serial console clock.
+ */
+static int __init xen_arm_register_clks(void)
+{
+   struct clk *clk;
+   struct device_node *xen_node;
+   unsigned int i, count;
+   int ret = 0;
+
+   xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
+   if (!xen_node) {
+   pr_err("Xen support was detected before, but it has 
disappeared\n");
+   return -EINVAL;
+   }
+
+   count = of_clk_get_parent_count(xen_node);
+   if (!count)
+   goto out;
+
+   for (i = 0; i < count; i++) {
+   clk = of_clk_get(xen_node, i);
+   if (IS_ERR(clk)) {
+   pr_err("Xen failed to register clock %i. Error: %li\n",
+  i, PTR_ERR(clk));
+   ret = PTR_ERR(clk);
+   goto out;
+   }
+
+   ret = clk_prepare_enable(clk);
+   if (ret < 0) {
+   pr_err("Xen failed to enable clock %i. Error: %i\n",
+  i, ret);
+   goto out;
+   }
+   }
+
+   ret = 0;
+
+out:
+   of_node_put(xen_node);
+   return ret;
+}
+late_initcall(xen_arm_register_clks);
 
 /* empty stubs */
 void xen_arch_pre_suspend(void) { }
-- 
2.8.0


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

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

2016-06-30 Thread osstest service owner 
flight 96450 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96450/

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  e893d3ca8e133bafb8e7711e8fd625f606dcaa9a
baseline version:
 libvirt  ca5d51df27567ef8d77c126815d01c484deb359f

Last test of basis96364  2016-06-29 04:26:58 Z1 days
Testing same since96450  2016-06-30 04:20:39 Z0 days1 attempts


People who touched revisions under test:
  Erik Skultety 
  Jean-Marc Liger 
  Ján Tomko 

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=e893d3ca8e133bafb8e7711e8fd625f606dcaa9a
+ . ./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

Re: [Xen-devel] [PATCH] xen/arm: register clocks used by the hypervisor

2016-06-30 Thread Julien Grall 

Hi Dirk,

On 29/06/16 16:49, Dirk Behme wrote:

On 22.06.2016 17:26, Julien Grall wrote:

On 21/06/16 11:16, Dirk Behme wrote:
Would it be possible to use the flags CLK_IGNORE_UNUSED instead? So the
clock will be ignored by clk_disable_unused_subtree.



Yes, using CLK_IGNORE_UNUSED is an option. But ;)

But we can't set it directly in enlighten.c as we can't access the flags
part of the clock structs from outside the core clock code.


Maybe we can introduce a new function in the kernel to set the flags?

Anyway, I am not very familiar with the clock subsystem. So, as 
suggested by Mark, I would recommend you to start a discussion with with 
the clock maintainers to see what would be the best way to avoid DOM0 to 
disable any clock used by Xen or a guest.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping

2016-06-30 Thread Jan Beulich 
>>> On 29.06.16 at 18:27,  wrote:
> On 29/06/16 17:19, Vitaly Kuznetsov wrote:
>> To explain better what I'm trying to suggest here please take a look at
>> the attached patch. If we can guarantee long term that ACPI id always
>> equals to Xen's idea of vCPU id this is probably the easiest way.
>>
>> -- Vitaly
> 
> The code in hvmloader which sets up the MADT does:
> 
> for ( i = 0; i < hvm_info->nr_vcpus; i++ )
> {
> memset(lapic, 0, sizeof(*lapic));
> lapic->type= ACPI_PROCESSOR_LOCAL_APIC;
> lapic->length  = sizeof(*lapic);
> /* Processor ID must match processor-object IDs in the DSDT. */
> lapic->acpi_processor_id = i;
> lapic->apic_id = LAPIC_ID(i);
> lapic->flags = (test_bit(i, hvm_info->vcpu_online)
> ? ACPI_LOCAL_APIC_ENABLED : 0);
> lapic++;
> }
> 
> So relying on the acpi_processor_id does look to be reliable.  That code
> hasn't changed since 2007, and that was only a bugfix.  I would go so
> far as to say it is reasonable for us to guarantee this in the guest ABI.

In fact - is there any other way a guest could learn the vCPU IDs
of its CPUs in a reliable way? I don't think so, and hence this de
facto already is part of the ABI; we should of course spell it out
somewhere.

Jan


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

Re: [Xen-devel] [PATCH v7 2/3] x86/vm_event: Add HVM debug exception vm_events

2016-06-30 Thread Jan Beulich 
>>> On 29.06.16 at 19:26,  wrote:
> On Tue, Jun 28, 2016 at 1:37 AM, Jan Beulich  wrote:
> On 27.06.16 at 20:08,  wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -3376,7 +3376,29 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>>>  HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
>>>  write_debugreg(6, exit_qualification | DR_STATUS_RESERVED_ONE);
>>>  if ( !v->domain->debugger_attached )
>>> -vmx_propagate_intr(intr_info);
>>> +{
>>> +unsigned long insn_len = 0;
>>> +int rc;
>>> +unsigned long trap_type = MASK_EXTR(intr_info,
>>> +
> INTR_INFO_INTR_TYPE_MASK);
>>> +
>>> +if ( trap_type >= X86_EVENTTYPE_SW_INTERRUPT )
>>> +__vmread(VM_EXIT_INSTRUCTION_LEN, _len);
>>> +
>>> +rc = hvm_monitor_debug(regs->eip,
>>> +   HVM_MONITOR_DEBUG_EXCEPTION,
>>> +   trap_type, insn_len);
>>> +
>>> +/*
>>> + * !rccontinue normally
>>> + * rc > 0 paused waiting for response, work here is done
>>> + * rc < 0 error in monitor/vm_event, crash
>>> + */
>>> +if ( !rc )
>>> +vmx_propagate_intr(intr_info);
>>> +if ( rc < 0 )
>>> +goto exit_and_crash;
>>> +}
>>
>> As opposed to earlier versions, here omitting the "else" seems
>> undesirable. Or, perhaps better, simply re-order the two if()-s.
>> This is to make clear that what is now the second if() does in no
>> way depend on what the body of the current first if() does.
>>
>> The same would then apply to patch 3, and I'd be fine doing the
>> adjustment while committing (provided all necessary acks trickle
>> in). Feel free to add my ack here for the few changes for which
>> that's actually relevant.
> 
> That sounds fine to me. I think this patch only needs Wei's or Ian's
> ack now for the libxc changes.

Indeed.

Jan


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

[Xen-devel] [PATCH v5 43/44] dma-mapping: Remove dma_get_attr

2016-06-30 Thread Krzysztof Kozlowski 
After switching DMA attributes to unsigned long it is easier to just
compare the bits.

Signed-off-by: Krzysztof Kozlowski 
[for avr32]
Acked-by: Hans-Christian Noren Egtvedt 
[for arc]
Acked-by: Vineet Gupta 
[for arm64 and dma-iommu]
Acked-by: Robin Murphy 
---
 Documentation/DMA-API.txt  |  4 +--
 arch/arc/mm/dma.c  |  4 +--
 arch/arm/mm/dma-mapping.c  | 36 --
 arch/arm/xen/mm.c  |  4 +--
 arch/arm64/mm/dma-mapping.c| 10 +++
 arch/avr32/mm/dma-coherent.c   |  4 +--
 arch/ia64/sn/pci/pci_dma.c | 10 ++-
 arch/metag/kernel/dma.c|  2 +-
 arch/mips/mm/dma-default.c |  6 ++---
 arch/openrisc/kernel/dma.c |  4 +--
 arch/parisc/kernel/pci-dma.c   |  2 +-
 arch/powerpc/platforms/cell/iommu.c| 12 -
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  2 +-
 drivers/iommu/dma-iommu.c  |  2 +-
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  2 +-
 include/linux/dma-mapping.h| 10 ---
 16 files changed, 47 insertions(+), 67 deletions(-)

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 24f9688bb98a..1d26eeb6b5f6 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -422,9 +422,7 @@ void whizco_dma_map_sg_attrs(struct device *dev, dma_addr_t 
dma_addr,
 unsigned long attrs)
 {

-   int foo =  dma_get_attr(DMA_ATTR_FOO, attrs);
-   
-   if (foo)
+   if (attrs & DMA_ATTR_FOO)
/* twizzle the frobnozzle */

 
diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
index 3d1f467d1792..74bbe68dce9d 100644
--- a/arch/arc/mm/dma.c
+++ b/arch/arc/mm/dma.c
@@ -46,7 +46,7 @@ static void *arc_dma_alloc(struct device *dev, size_t size,
 *   (vs. always going to memory - thus are faster)
 */
if ((is_isa_arcv2() && ioc_exists) ||
-   dma_get_attr(DMA_ATTR_NON_CONSISTENT, attrs))
+   (attrs & DMA_ATTR_NON_CONSISTENT))
need_coh = 0;
 
/*
@@ -95,7 +95,7 @@ static void arc_dma_free(struct device *dev, size_t size, 
void *vaddr,
struct page *page = virt_to_page(dma_handle);
int is_non_coh = 1;
 
-   is_non_coh = dma_get_attr(DMA_ATTR_NON_CONSISTENT, attrs) ||
+   is_non_coh = (attrs & DMA_ATTR_NON_CONSISTENT) ||
(is_isa_arcv2() && ioc_exists);
 
if (PageHighMem(page) || !is_non_coh)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ebb3fde99043..43e03b5293d0 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -126,7 +126,7 @@ static dma_addr_t arm_dma_map_page(struct device *dev, 
struct page *page,
 unsigned long offset, size_t size, enum dma_data_direction dir,
 unsigned long attrs)
 {
-   if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+   if ((attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
__dma_page_cpu_to_dev(page, offset, size, dir);
return pfn_to_dma(dev, page_to_pfn(page)) + offset;
 }
@@ -155,7 +155,7 @@ static dma_addr_t arm_coherent_dma_map_page(struct device 
*dev, struct page *pag
 static void arm_dma_unmap_page(struct device *dev, dma_addr_t handle,
size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
-   if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+   if ((attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
__dma_page_dev_to_cpu(pfn_to_page(dma_to_pfn(dev, handle)),
  handle & ~PAGE_MASK, size, dir);
 }
@@ -622,9 +622,9 @@ static void __free_from_contiguous(struct device *dev, 
struct page *page,
 
 static inline pgprot_t __get_dma_pgprot(unsigned long attrs, pgprot_t prot)
 {
-   prot = dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs) ?
-   pgprot_writecombine(prot) :
-   pgprot_dmacoherent(prot);
+   prot = (attrs & DMA_ATTR_WRITE_COMBINE) ?
+   pgprot_writecombine(prot) :
+   pgprot_dmacoherent(prot);
return prot;
 }
 
@@ -744,7 +744,7 @@ static void *__dma_alloc(struct device *dev, size_t size, 
dma_addr_t *handle,
.gfp = gfp,
.prot = prot,
.caller = caller,
-   .want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs),
+   .want_vaddr = ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) == 0),
};
 
 #ifdef CONFIG_DMA_API_DEBUG
@@ -887,7 +887,7 @@ static void __arm_dma_free(struct device *dev, size_t size, 
void *cpu_addr,
.size = PAGE_ALIGN(size),
.cpu_addr = cpu_addr,
.page =

[Xen-devel] [PATCH v5 19/44] xen: dma-mapping: Use unsigned long for dma_attrs

2016-06-30 Thread Krzysztof Kozlowski 
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
[for xen]
Acked-by: David Vrabel 
---
 drivers/xen/swiotlb-xen.c | 14 +++---
 include/xen/swiotlb-xen.h | 12 ++--
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 7399782c0998..87e6035c9e81 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -294,7 +294,7 @@ error:
 void *
 xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
   dma_addr_t *dma_handle, gfp_t flags,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
void *ret;
int order = get_order(size);
@@ -346,7 +346,7 @@ EXPORT_SYMBOL_GPL(xen_swiotlb_alloc_coherent);
 
 void
 xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
- dma_addr_t dev_addr, struct dma_attrs *attrs)
+ dma_addr_t dev_addr, unsigned long attrs)
 {
int order = get_order(size);
phys_addr_t phys;
@@ -378,7 +378,7 @@ EXPORT_SYMBOL_GPL(xen_swiotlb_free_coherent);
 dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
phys_addr_t map, phys = page_to_phys(page) + offset;
dma_addr_t dev_addr = xen_phys_to_bus(phys);
@@ -434,7 +434,7 @@ EXPORT_SYMBOL_GPL(xen_swiotlb_map_page);
  */
 static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
 size_t size, enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
phys_addr_t paddr = xen_bus_to_phys(dev_addr);
 
@@ -462,7 +462,7 @@ static void xen_unmap_single(struct device *hwdev, 
dma_addr_t dev_addr,
 
 void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
size_t size, enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
xen_unmap_single(hwdev, dev_addr, size, dir, attrs);
 }
@@ -538,7 +538,7 @@ EXPORT_SYMBOL_GPL(xen_swiotlb_sync_single_for_device);
 int
 xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 int nelems, enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
struct scatterlist *sg;
int i;
@@ -599,7 +599,7 @@ EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg_attrs);
 void
 xen_swiotlb_unmap_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
   int nelems, enum dma_data_direction dir,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
struct scatterlist *sg;
int i;
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index 8b2eb93ae8ba..7c35e279d1e3 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -9,30 +9,30 @@ extern int xen_swiotlb_init(int verbose, bool early);
 extern void
 *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
dma_addr_t *dma_handle, gfp_t flags,
-   struct dma_attrs *attrs);
+   unsigned long attrs);
 
 extern void
 xen_swiotlb_free_coherent(struct device *hwdev, size_t size,
  void *vaddr, dma_addr_t dma_handle,
- struct dma_attrs *attrs);
+ unsigned long attrs);
 
 extern dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
   unsigned long offset, size_t size,
   enum dma_data_direction dir,
-  struct dma_attrs *attrs);
+  unsigned long attrs);
 
 extern void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
   size_t size, enum dma_data_direction dir,
-  struct dma_attrs *attrs);
+  unsigned long attrs);
 extern int
 xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 int nelems, enum dma_data_direction dir,
-struct dma_attrs *attrs);
+unsigned long attrs);
 
 extern void
 xen_swiotlb_unmap_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
   int nelems, enum dma_data_direction dir,
-

[Xen-devel] [PATCH v5 23/44] x86: dma-mapping: Use unsigned long for dma_attrs

2016-06-30 Thread Krzysztof Kozlowski 
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/x86/include/asm/dma-mapping.h   |  5 ++---
 arch/x86/include/asm/swiotlb.h   |  4 ++--
 arch/x86/include/asm/xen/page-coherent.h |  9 -
 arch/x86/kernel/amd_gart_64.c| 20 ++--
 arch/x86/kernel/pci-calgary_64.c | 14 +++---
 arch/x86/kernel/pci-dma.c|  4 ++--
 arch/x86/kernel/pci-nommu.c  |  4 ++--
 arch/x86/kernel/pci-swiotlb.c|  4 ++--
 arch/x86/pci/sta2x11-fixup.c |  2 +-
 arch/x86/pci/vmd.c   | 16 
 10 files changed, 40 insertions(+), 42 deletions(-)

diff --git a/arch/x86/include/asm/dma-mapping.h 
b/arch/x86/include/asm/dma-mapping.h
index 3a27b93e6261..44461626830e 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -48,11 +47,11 @@ extern int dma_supported(struct device *hwdev, u64 mask);
 
 extern void *dma_generic_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_addr, gfp_t flag,
-   struct dma_attrs *attrs);
+   unsigned long attrs);
 
 extern void dma_generic_free_coherent(struct device *dev, size_t size,
  void *vaddr, dma_addr_t dma_addr,
- struct dma_attrs *attrs);
+ unsigned long attrs);
 
 #ifdef CONFIG_X86_DMA_REMAP /* Platform code defines bridge-specific code */
 extern bool dma_capable(struct device *dev, dma_addr_t addr, size_t size);
diff --git a/arch/x86/include/asm/swiotlb.h b/arch/x86/include/asm/swiotlb.h
index ab05d73e2bb7..d2f69b9ff732 100644
--- a/arch/x86/include/asm/swiotlb.h
+++ b/arch/x86/include/asm/swiotlb.h
@@ -31,9 +31,9 @@ static inline void dma_mark_clean(void *addr, size_t size) {}
 
 extern void *x86_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
dma_addr_t *dma_handle, gfp_t flags,
-   struct dma_attrs *attrs);
+   unsigned long attrs);
 extern void x86_swiotlb_free_coherent(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_addr,
-   struct dma_attrs *attrs);
+   unsigned long attrs);
 
 #endif /* _ASM_X86_SWIOTLB_H */
diff --git a/arch/x86/include/asm/xen/page-coherent.h 
b/arch/x86/include/asm/xen/page-coherent.h
index acd844c017d3..f02f025ff988 100644
--- a/arch/x86/include/asm/xen/page-coherent.h
+++ b/arch/x86/include/asm/xen/page-coherent.h
@@ -2,12 +2,11 @@
 #define _ASM_X86_XEN_PAGE_COHERENT_H
 
 #include 
-#include 
 #include 
 
 static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
dma_addr_t *dma_handle, gfp_t flags,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
void *vstart = (void*)__get_free_pages(flags, get_order(size));
*dma_handle = virt_to_phys(vstart);
@@ -16,18 +15,18 @@ static inline void *xen_alloc_coherent_pages(struct device 
*hwdev, size_t size,
 
 static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
void *cpu_addr, dma_addr_t dma_handle,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
free_pages((unsigned long) cpu_addr, get_order(size));
 }
 
 static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
 dma_addr_t dev_addr, unsigned long offset, size_t size,
-enum dma_data_direction dir, struct dma_attrs *attrs) { }
+enum dma_data_direction dir, unsigned long attrs) { }
 
 static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
size_t size, enum dma_data_direction dir,
-   struct dma_attrs *attrs) { }
+   unsigned long attrs) { }
 
 static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir) { }
diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
index 8e3842fc8bea..4aff288e37a4 100644
--- a/arch/x86/kernel/amd_gart_64.c
+++ b/arch/x86/kernel/amd_gart_64.c
@@ -242,7 +242,7 @@ static dma_addr_t dma_map_area(struct device *dev, 
dma_addr_t phys_mem,
 static dma_addr_t gart_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+

[Xen-devel] [PATCH v5 04/44] ARM: dma-mapping: Use unsigned long for dma_attrs

2016-06-30 Thread Krzysztof Kozlowski 
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/common/dmabounce.c  |  4 +-
 arch/arm/include/asm/dma-mapping.h   | 13 +++--
 arch/arm/include/asm/xen/page-coherent.h | 16 +++
 arch/arm/mm/dma-mapping.c| 81 
 arch/arm/xen/mm.c|  4 +-
 5 files changed, 56 insertions(+), 62 deletions(-)

diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c
index 1143c4d5c567..301281645d08 100644
--- a/arch/arm/common/dmabounce.c
+++ b/arch/arm/common/dmabounce.c
@@ -310,7 +310,7 @@ static inline void unmap_single(struct device *dev, struct 
safe_buffer *buf,
  */
 static dma_addr_t dmabounce_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size, enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
dma_addr_t dma_addr;
int ret;
@@ -344,7 +344,7 @@ static dma_addr_t dmabounce_map_page(struct device *dev, 
struct page *page,
  * should be)
  */
 static void dmabounce_unmap_page(struct device *dev, dma_addr_t dma_addr, 
size_t size,
-   enum dma_data_direction dir, struct dma_attrs *attrs)
+   enum dma_data_direction dir, unsigned long attrs)
 {
struct safe_buffer *buf;
 
diff --git a/arch/arm/include/asm/dma-mapping.h 
b/arch/arm/include/asm/dma-mapping.h
index a83570f10124..d009f7911ffc 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -5,7 +5,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -174,7 +173,7 @@ static inline void dma_mark_clean(void *addr, size_t size) 
{ }
  * to be the device-viewed address.
  */
 extern void *arm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
-  gfp_t gfp, struct dma_attrs *attrs);
+  gfp_t gfp, unsigned long attrs);
 
 /**
  * arm_dma_free - free memory allocated by arm_dma_alloc
@@ -191,7 +190,7 @@ extern void *arm_dma_alloc(struct device *dev, size_t size, 
dma_addr_t *handle,
  * during and after this call executing are illegal.
  */
 extern void arm_dma_free(struct device *dev, size_t size, void *cpu_addr,
-dma_addr_t handle, struct dma_attrs *attrs);
+dma_addr_t handle, unsigned long attrs);
 
 /**
  * arm_dma_mmap - map a coherent DMA allocation into user space
@@ -208,7 +207,7 @@ extern void arm_dma_free(struct device *dev, size_t size, 
void *cpu_addr,
  */
 extern int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
-   struct dma_attrs *attrs);
+   unsigned long attrs);
 
 /*
  * This can be called during early boot to increase the size of the atomic
@@ -262,16 +261,16 @@ extern void dmabounce_unregister_dev(struct device *);
  * The scatter list versions of the above methods.
  */
 extern int arm_dma_map_sg(struct device *, struct scatterlist *, int,
-   enum dma_data_direction, struct dma_attrs *attrs);
+   enum dma_data_direction, unsigned long attrs);
 extern void arm_dma_unmap_sg(struct device *, struct scatterlist *, int,
-   enum dma_data_direction, struct dma_attrs *attrs);
+   enum dma_data_direction, unsigned long attrs);
 extern void arm_dma_sync_sg_for_cpu(struct device *, struct scatterlist *, int,
enum dma_data_direction);
 extern void arm_dma_sync_sg_for_device(struct device *, struct scatterlist *, 
int,
enum dma_data_direction);
 extern int arm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
-   struct dma_attrs *attrs);
+   unsigned long attrs);
 
 #endif /* __KERNEL__ */
 #endif
diff --git a/arch/arm/include/asm/xen/page-coherent.h 
b/arch/arm/include/asm/xen/page-coherent.h
index 9408a994cc91..95ce6ac3a971 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -2,15 +2,14 @@
 #define _ASM_ARM_XEN_PAGE_COHERENT_H
 
 #include 
-#include 
 #include 
 
 void __xen_dma_map_page(struct device *hwdev, struct page *page,
 dma_addr_t dev_addr, unsigned long offset, size_t size,
-enum dma_data_direction dir, struct dma_attrs *attrs);
+enum dma_data_direction dir, unsigned long attrs);
 void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
size_t size, enum dma_data_direction dir,
-   struct dma_attrs *attrs);
+   unsigned long attrs);
 void __xen_dma_sync_single_for_cpu(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir);
 
@@ -18,22 +17,20 @@

[Xen-devel] [PATCH v5 00/44] dma-mapping: Use unsigned long for dma_attrs

2016-06-30 Thread Krzysztof Kozlowski 
Hi,


This is fifth approach for replacing struct dma_attrs with unsigned
long.

The main patch (1/44) doing the change is split into many subpatches
for easier review (2-42).  They should be squashed together when
applying.


Rebased on v4.7-rc5.

For easier testing the patchset is available here:
repo:   https://github.com/krzk/linux
branch: for-next/dma-attrs-const-v5


Changes since v4

1. Collect some acks. Still need more.
2. Minor fixes pointed by Robin Murphy.
3. Applied changes from Bart Van Assche's comment.
4. More tests and builds (using https://www.kernel.org/pub/tools/crosstool/).


Changes since v3

1. Collect some acks.
2. Drop wrong patch 1/45 ("powerpc: dma-mapping: Don't hard-code
   the value of DMA_ATTR_WEAK_ORDERING").
3. Minor fix pointed out by Michael Ellerman.


Changes since v2

1. Follow Christoph Hellwig's comments (don't use BIT add
   documentation, remove dma_get_attr).


Rationale
=
The dma-mapping core and the implementations do not change the
DMA attributes passed by pointer.  Thus the pointer can point to const
data.  However the attributes do not have to be a bitfield. Instead
unsigned long will do fine:

1. This is just simpler.  Both in terms of reading the code and setting
   attributes.  Instead of initializing local attributes on the stack
   and passing pointer to it to dma_set_attr(), just set the bits.

2. It brings safeness and checking for const correctness because the
   attributes are passed by value.


Best regards,
Krzysztof


Krzysztof Kozlowski (44):
  dma-mapping: Use unsigned long for dma_attrs
  alpha: dma-mapping: Use unsigned long for dma_attrs
  arc: dma-mapping: Use unsigned long for dma_attrs
  ARM: dma-mapping: Use unsigned long for dma_attrs
  arm64: dma-mapping: Use unsigned long for dma_attrs
  avr32: dma-mapping: Use unsigned long for dma_attrs
  blackfin: dma-mapping: Use unsigned long for dma_attrs
  c6x: dma-mapping: Use unsigned long for dma_attrs
  cris: dma-mapping: Use unsigned long for dma_attrs
  frv: dma-mapping: Use unsigned long for dma_attrs
  drm/exynos: dma-mapping: Use unsigned long for dma_attrs
  drm/mediatek: dma-mapping: Use unsigned long for dma_attrs
  drm/msm: dma-mapping: Use unsigned long for dma_attrs
  drm/nouveau: dma-mapping: Use unsigned long for dma_attrs
  drm/rockship: dma-mapping: Use unsigned long for dma_attrs
  infiniband: dma-mapping: Use unsigned long for dma_attrs
  iommu: dma-mapping: Use unsigned long for dma_attrs
  [media] dma-mapping: Use unsigned long for dma_attrs
  xen: dma-mapping: Use unsigned long for dma_attrs
  swiotlb: dma-mapping: Use unsigned long for dma_attrs
  powerpc: dma-mapping: Use unsigned long for dma_attrs
  video: dma-mapping: Use unsigned long for dma_attrs
  x86: dma-mapping: Use unsigned long for dma_attrs
  iommu: intel: dma-mapping: Use unsigned long for dma_attrs
  h8300: dma-mapping: Use unsigned long for dma_attrs
  hexagon: dma-mapping: Use unsigned long for dma_attrs
  ia64: dma-mapping: Use unsigned long for dma_attrs
  m68k: dma-mapping: Use unsigned long for dma_attrs
  metag: dma-mapping: Use unsigned long for dma_attrs
  microblaze: dma-mapping: Use unsigned long for dma_attrs
  mips: dma-mapping: Use unsigned long for dma_attrs
  mn10300: dma-mapping: Use unsigned long for dma_attrs
  nios2: dma-mapping: Use unsigned long for dma_attrs
  openrisc: dma-mapping: Use unsigned long for dma_attrs
  parisc: dma-mapping: Use unsigned long for dma_attrs
  misc: mic: dma-mapping: Use unsigned long for dma_attrs
  s390: dma-mapping: Use unsigned long for dma_attrs
  sh: dma-mapping: Use unsigned long for dma_attrs
  sparc: dma-mapping: Use unsigned long for dma_attrs
  tile: dma-mapping: Use unsigned long for dma_attrs
  unicore32: dma-mapping: Use unsigned long for dma_attrs
  xtensa: dma-mapping: Use unsigned long for dma_attrs
  dma-mapping: Remove dma_get_attr
  dma-mapping: Document the DMA attributes next to the declaration

 Documentation/DMA-API.txt  |  33 +++---
 Documentation/DMA-attributes.txt   |   2 +-
 arch/alpha/include/asm/dma-mapping.h   |   2 -
 arch/alpha/kernel/pci-noop.c   |   2 +-
 arch/alpha/kernel/pci_iommu.c  |  12 +-
 arch/arc/mm/dma.c  |  12 +-
 arch/arm/common/dmabounce.c|   4 +-
 arch/arm/include/asm/dma-mapping.h |  13 +--
 arch/arm/include/asm/xen/page-coherent.h   |  16 +--
 arch/arm/mm/dma-mapping.c  | 117 +--
 arch/arm/xen/mm.c  |   8 +-
 arch/arm64/mm/dma-mapping.c|  66 +--
 arch/avr32/mm/dma-coherent.c   |  12 +-
 arch/blackfin/kernel/dma-mapping.c |   8 +-
 arch/c6x/include/asm/dma-mapping.h |   4 +-
 arch/c6x/kernel/dma.c  |

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

2016-06-30 Thread osstest service owner 
flight 96378 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96378/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt5 libvirt-buildfail in 96355 REGR. vs. 87893
 build-amd64-libvirt   5 libvirt-buildfail in 96355 REGR. vs. 87893
 build-armhf   5 xen-buildfail in 96355 REGR. vs. 87893

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 96355

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 87893
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 87893
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 87893

Tests which did not succeed, but are not blocking:
 build-armhf-libvirt   1 build-check(1)blocked in 96355 n/a
 test-amd64-i386-libvirt   1 build-check(1)blocked in 96355 n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked in 96355 n/a
 test-armhf-armhf-libvirt  1 build-check(1)blocked in 96355 n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)blocked in 96355 n/a
 test-armhf-armhf-xl   1 build-check(1)blocked in 96355 n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)  blocked in 96355 n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)blocked in 96355 n/a
 test-amd64-amd64-libvirt  1 build-check(1)blocked in 96355 n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)blocked in 96355 n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)  blocked in 96355 n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)blocked in 96355 n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)blocked in 96355 n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  never pass
 test-armhf-armhf-libvirt  6 xen-boot fail   never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-armhf-armhf-xl   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail never pass
 test-armhf-armhf-xl-vhd   6 xen-boot fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-armhf-armhf-xl-credit2   6 xen-boot fail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass

version targeted for testing:
 xen  0a8c94fae993dd8f2b27fd4cc694f61c21de84bf
baseline version:
 xen  8fa31952e2d08ef63897c43b5e8b33475ebf5d93

Last test of basis87893  2016-03-29 13:49:52 Z   92 days
Failing since 92180  2016-04-20 17:49:21 Z   70 days   39 attempts
Testing same since96017  2016-06-20 17:22:27 Z9 days   18 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Anthony PERARD 
  Gerd Hoffmann 
  Ian Jackson 
  Jan Beulich 
  Jim Paris 
  Stefan Hajnoczi 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvops

[Xen-devel] [ovmf bisection] complete build-amd64

2016-06-30 Thread osstest service owner 
branch xen-unstable
xenbranch xen-unstable
job build-amd64
testid xen-build

Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  ovmf https://github.com/tianocore/edk2.git
  Bug introduced:  848e14723964231cc64dfe71342201237979e9fb
  Bug not present: c99bcf3d8aa5c098881360e8598b4c9e612d0a2b
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/96456/


  commit 848e14723964231cc64dfe71342201237979e9fb
  Author: Cinnamon Shia 
  Date:   Tue Jun 28 17:40:35 2016 +0800
  
  MdeModulePkg/MemoryStatusCode: Expose the DXE memory status code table.
  
  Let data of DXE memory status code can be used by other modules.
  1. Save the address of DXE memory status code table to 
DxeConfigurationTable.
  2. Save the address of SMM memory status code table to 
SmmConfigurationTable.
  3. Move RUNTIME_MEMORY_STATUSCODE_HEADER to its public header file.
  
  Contributed-under: TianoCore Contribution Agreement 1.0
  Signed-off-by: Cinnamon Shia 
  Reviewed-by: Liming Gao 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/ovmf/build-amd64.xen-build 
--summary-out=tmp/96456.bisection-summary --basis-template=94748 
--blessings=real,real-bisect ovmf build-amd64 xen-build
Searching for failure / basis pass:
 96444 fail [host=baroque1] / 96339 ok.
Failure / basis pass flights: 96444 / 96339
(tree with no url: minios)
(tree with no url: seabios)
(tree in basispass but not in latest: qemu)
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest f2ae1ef7ecf6d3124b9d7b2de0a6ca9558b0b4de 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
Basis pass 631c942726640615d53e4a358c078bb915e1bdd4 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
Generating revisions with ./adhoc-revtuple-generator  
https://github.com/tianocore/edk2.git#631c942726640615d53e4a358c078bb915e1bdd4-f2ae1ef7ecf6d3124b9d7b2de0a6ca9558b0b4de
 
git://xenbits.xen.org/qemu-xen.git#44a072f0de0d57c95c2212bbce0232b7b74f-44a072f0de0d57c95c2212bbce0232b7b74f
 
git://xenbits.xen.org/xen.git#8384dc2d95538c5910d98db3df3ff5448bf0af48-8384dc2d95538c5910d98db3df3ff5448bf0af48
Loaded 1001 nodes in revision graph
Searching for test results:
 96339 pass 631c942726640615d53e4a358c078bb915e1bdd4 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
 96334 pass irrelevant
 96342 pass irrelevant
 96332 [host=italia1]
 96373 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
 96361 fail fd5d2dd2f55eedb3cf6001cc00587020c90411f5 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
 96368 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
 96376 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
 96456 fail 848e14723964231cc64dfe71342201237979e9fb 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
 96440 fail 287f05cd1f8cc7ae693868b4882d4cebd87ff6dc 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
 96418 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
 96439 fail 287f05cd1f8cc7ae693868b4882d4cebd87ff6dc 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
 96441 pass e2b083de916cfc56a227df6f4ef67202cf5449c8 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
 96394 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
 96422 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
 96443 fail 848e14723964231cc64dfe71342201237979e9fb 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
 96408 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
 96428 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 
44a072f0de0d57c95c2212bbce0232b7b74f 
8384dc2d95538c5910d98db3df3ff5448bf0af48
 96445 pass c99bcf3d8aa5c098881360e8598b4c9e612d0a2b

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

2016-06-30 Thread osstest service owner 
flight 96371 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96371/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm   5 xen-build fail REGR. vs. 96296
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 96296
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 96296
 test-armhf-armhf-xl-vhd   7 host-ping-check-xen   fail REGR. vs. 96296

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

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

version targeted for testing:
 xen  3cdad93704aaa8bf1f274969e401ca21152bc4a2
baseline version:
 xen  8384dc2d95538c5910d98db3df3ff5448bf0af48

Last test of basis96296  2016-06-27 01:55:48 Z3 days
Failing since 96315  2016-06-27 14:13:25 Z2 days4 attempts
Testing same since96371  2016-06-29 10:23:46 Z0 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Dirk Behme 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Quan Xu 
  Razvan Cojocaru 
  Stefano Stabellini 
  Tamas K Lengyel 

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