[Xen-devel] [xen-unstable test] 96371: regressions - FAIL
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 pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern
[Xen-devel] [PATCH v4] x86/cpuid: AVX-512 Feature Detection
AVX-512 is an extention of AVX2. Its spec can be found at:
https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
This patch detects AVX-512 features by CPUID.
Signed-off-by: Luwei Kang
---
[V4]:
Update the description about features dependency.
[V3]:
Adjust dependencies between features.
[V2]:
1.get max xstate_size from each bit.
2.change get cpuid function parameter from 0x07 to 7.
3.add dependencies between features in xen/tools/gen-cpuid.py.
4.split the cpuid call just like the way the hvm_cpuid() side works.
---
xen/arch/x86/hvm/hvm.c | 14 ++
xen/arch/x86/traps.c| 22 +-
xen/include/public/arch-x86/cpufeatureset.h | 9 +
xen/tools/gen-cpuid.py | 11 +++
4 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c89ab6e..7696b1e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3474,6 +3474,20 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
unsigned int *ebx,
xstate_sizes[_XSTATE_BNDCSR]);
}
+if ( _ebx & cpufeat_mask(X86_FEATURE_AVX512F) )
+{
+xfeature_mask |= XSTATE_OPMASK | XSTATE_ZMM | XSTATE_HI_ZMM;
+xstate_size = max(xstate_size,
+ xstate_offsets[_XSTATE_OPMASK] +
+ xstate_sizes[_XSTATE_OPMASK]);
+xstate_size = max(xstate_size,
+ xstate_offsets[_XSTATE_ZMM] +
+ xstate_sizes[_XSTATE_ZMM]);
+xstate_size = max(xstate_size,
+ xstate_offsets[_XSTATE_HI_ZMM] +
+ xstate_sizes[_XSTATE_HI_ZMM]);
+}
+
if ( _ecx & cpufeat_mask(X86_FEATURE_PKU) )
{
xfeature_mask |= XSTATE_PKRU;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 767d0b0..8fb697b 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -975,7 +975,7 @@ void pv_cpuid(struct cpu_user_regs *regs)
switch ( leaf )
{
-uint32_t tmp, _ecx;
+uint32_t tmp, _ecx, _ebx;
case 0x0001:
c &= pv_featureset[FEATURESET_1c];
@@ -1157,6 +1157,26 @@ void pv_cpuid(struct cpu_user_regs *regs)
xstate_sizes[_XSTATE_YMM]);
}
+if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
+domain_cpuid(currd, 7, 0, &tmp, &_ebx, &tmp, &tmp);
+else
+cpuid_count(7, 0, &tmp, &_ebx, &tmp, &tmp);
+_ebx &= pv_featureset[FEATURESET_7b0];
+
+if ( _ebx & cpufeat_mask(X86_FEATURE_AVX512F) )
+{
+xfeature_mask |= XSTATE_OPMASK | XSTATE_ZMM | XSTATE_HI_ZMM;
+xstate_size = max(xstate_size,
+ xstate_offsets[_XSTATE_OPMASK] +
+ xstate_sizes[_XSTATE_OPMASK]);
+xstate_size = max(xstate_size,
+ xstate_offsets[_XSTATE_ZMM] +
+ xstate_sizes[_XSTATE_ZMM]);
+xstate_size = max(xstate_size,
+ xstate_offsets[_XSTATE_HI_ZMM] +
+ xstate_sizes[_XSTATE_HI_ZMM]);
+}
+
a = (uint32_t)xfeature_mask;
d = (uint32_t)(xfeature_mask >> 32);
c = xstate_size;
diff --git a/xen/include/public/arch-x86/cpufeatureset.h
b/xen/include/public/arch-x86/cpufeatureset.h
index 39acf8c..9320c9e 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -206,15 +206,24 @@ XEN_CPUFEATURE(PQM, 5*32+12) /* Platform QoS
Monitoring */
XEN_CPUFEATURE(NO_FPU_SEL,5*32+13) /*! FPU CS/DS stored as zero */
XEN_CPUFEATURE(MPX, 5*32+14) /*S Memory Protection Extensions */
XEN_CPUFEATURE(PQE, 5*32+15) /* Platform QoS Enforcement */
+XEN_CPUFEATURE(AVX512F, 5*32+16) /*A AVX-512 Foundation Instructions */
+XEN_CPUFEATURE(AVX512DQ, 5*32+17) /*A AVX-512 Doubleword & Quadword
Instrs */
XEN_CPUFEATURE(RDSEED,5*32+18) /*A RDSEED instruction */
XEN_CPUFEATURE(ADX, 5*32+19) /*A ADCX, ADOX instructions */
XEN_CPUFEATURE(SMAP, 5*32+20) /*S Supervisor Mode Access Prevention
*/
+XEN_CPUFEATURE(AVX512IFMA,5*32+21) /*A AVX-512 Integer Fused Multiply Add
*/
XEN_CPUFEATURE(CLFLUSHOPT,5*32+23) /*A CLFLUSHOPT instruction */
XEN_CPUFEATURE(CLWB, 5*32+24) /*A CLWB instruction */
+XEN_CPUFEATURE(AVX512PF, 5*32+26) /*A AVX-512 Prefetch Instructions */
+XEN_CPUFEATURE(AVX512ER, 5*32+27) /*A AVX-512 Exponent & Reciprocal
Instrs */
+XEN_CPUFEATURE(AVX512CD, 5*32+28) /*
[Xen-devel] [qemu-mainline test] 96367: regressions - FAIL
flight 96367 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/96367/ 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-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 94856 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: qemuud7f30403576f04f1f3a5fb5a1d18cba8dfa7a6d2 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 29 days 41 attempts Testing same since96367 2016-06-29 07:23:33 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 Artyom Tarasenko Ashijeet Acharya Aurelien Jarno Bastian Koppelmann Benjamin Herrenschmidt Bharata B Rao Cao jin Changlong Xie Chao Peng Chen Fan Christian Borntraeger Christophe Lyon Cole Robinson Colin Lord Corey Minyard Cornelia Huck Cédric Le Goater
[Xen-devel] [ovmf test] 96444: regressions - FAIL
flight 96444 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96444/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 94748 build-amd64-xsm 5 xen-build fail REGR. vs. 94748 build-amd64 5 xen-build fail REGR. vs. 94748 build-i3865 xen-build fail REGR. vs. 94748 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf f2ae1ef7ecf6d3124b9d7b2de0a6ca9558b0b4de 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 76 attempts Testing same since96444 2016-06-30 03:17:34 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 fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7624 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 96439: regressions - FAIL
flight 96439 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96439/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 94748 build-amd64-xsm 5 xen-build fail REGR. vs. 94748 build-amd64 5 xen-build fail REGR. vs. 94748 build-i3865 xen-build fail REGR. vs. 94748 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 287f05cd1f8cc7ae693868b4882d4cebd87ff6dc 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 35 days 75 attempts Testing same since96435 2016-06-30 01:58:11 Z0 days2 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 fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7613 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 96435: regressions - FAIL
flight 96435 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96435/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 94748 build-amd64-xsm 5 xen-build fail REGR. vs. 94748 build-amd64 5 xen-build fail REGR. vs. 94748 build-i3865 xen-build fail REGR. vs. 94748 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 287f05cd1f8cc7ae693868b4882d4cebd87ff6dc 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 35 days 74 attempts Testing same since96435 2016-06-30 01:58:11 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 fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7613 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf bisection] complete build-amd64-xsm
branch xen-unstable xenbranch xen-unstable job build-amd64-xsm 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/96433/ 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-xsm.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-xsm.xen-build --summary-out=tmp/96433.bisection-summary --basis-template=94748 --blessings=real,real-bisect ovmf build-amd64-xsm xen-build Searching for failure / basis pass: 96430 fail [host=huxelrebe0] / 96339 [host=godello1] 96322 ok. Failure / basis pass flights: 96430 / 96322 (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 89b206573965e9604c534cc1ef468ecd58e1b4d4 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 Basis pass 6b5677e1bb62c289fba7848bbfde08220fc37ba1 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 Generating revisions with ./adhoc-revtuple-generator https://github.com/tianocore/edk2.git#6b5677e1bb62c289fba7848bbfde08220fc37ba1-89b206573965e9604c534cc1ef468ecd58e1b4d4 git://xenbits.xen.org/qemu-xen.git#44a072f0de0d57c95c2212bbce0232b7b74f-44a072f0de0d57c95c2212bbce0232b7b74f git://xenbits.xen.org/xen.git#8384dc2d95538c5910d98db3df3ff5448bf0af48-8384dc2d95538c5910d98db3df3ff5448bf0af48 From git://cache:9419/https://github.com/tianocore/edk2 89b2065..287f05c master -> origin/master Loaded 1001 nodes in revision graph Searching for test results: 96339 [host=godello1] 96322 pass 6b5677e1bb62c289fba7848bbfde08220fc37ba1 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96373 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96361 fail fd5d2dd2f55eedb3cf6001cc00587020c90411f5 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96368 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96376 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96417 pass 861b36d34f1ca198a4509b0a6e439daf4505998c 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96419 pass 2d24f4e70b5b452d0741c4b0e37936d510aeaecf 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96418 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96420 pass 0199f24fd151ddaf449fab7b696da8b1e329ac04 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96421 pass 763cfa739b1733715fe6700a29ec078c36453f5e 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96423 pass ba502ef477353968325242a85742889e09e8dd84 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96425 pass c99bcf3d8aa5c098881360e8598b4c9e612d0a2b 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96394 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96422 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96426 fail 848e14723964231cc64dfe71342201237979e9fb 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96408 fail 89b206573965e9604c534cc1ef
[Xen-devel] [ovmf test] 96430: regressions - FAIL
flight 96430 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96430/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 94748 build-amd64-xsm 5 xen-build fail REGR. vs. 94748 build-amd64 5 xen-build fail REGR. vs. 94748 build-i3865 xen-build fail REGR. vs. 94748 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 89b206573965e9604c534cc1ef468ecd58e1b4d4 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 35 days 73 attempts Testing same since96368 2016-06-29 08:45:08 Z0 days 11 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 fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7593 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 96428: regressions - FAIL
flight 96428 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96428/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 94748 build-amd64-xsm 5 xen-build fail REGR. vs. 94748 build-amd64 5 xen-build fail REGR. vs. 94748 build-i3865 xen-build fail REGR. vs. 94748 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 89b206573965e9604c534cc1ef468ecd58e1b4d4 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 35 days 72 attempts Testing same since96368 2016-06-29 08:45:08 Z0 days 10 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 fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7593 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 96422: regressions - FAIL
flight 96422 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96422/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 94748 build-amd64-xsm 5 xen-build fail REGR. vs. 94748 build-amd64 5 xen-build fail REGR. vs. 94748 build-i3865 xen-build fail REGR. vs. 94748 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 89b206573965e9604c534cc1ef468ecd58e1b4d4 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 35 days 71 attempts Testing same since96368 2016-06-29 08:45:08 Z0 days9 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 fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7593 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-4.3-testing test] 96374: tolerable FAIL - PUSHED
flight 96374 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96374/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 80927
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 80927
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass
test-amd64-i386-libvirt 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass
version targeted for testing:
qemuu12e8fccf5b5460be7aecddc71d27eceaba6e1f15
baseline version:
qemuu10c1b763c26feb645627a1639e722515f3e1e876
Last test of basis80927 2016-02-06 13:30:02 Z 144 days
Failing since 93977 2016-05-10 11:09:16 Z 50 days 156 attempts
Testing same since95534 2016-06-11 00:59:46 Z 18 days 36 attempts
People who touched revisions under test:
Anthony PERARD
Gerd Hoffmann
Ian Jackson
Stefano Stabellini
Wei Liu
jobs:
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 pass
test-amd64-i386-xl pass
test-amd64-i386-qemuu-rhel6hvm-amd 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-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-credit2 pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpupass
test-amd64-amd64-pairpass
test-amd64-i386-pair pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-amd64-amd64-amd64-pvgrubpass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2pass
test-amd64-i386-xl-raw pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-libvirt-vhd pass
test-amd64-amd64-xl-qemuu-winxpsp3 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=qemu-upstream-4.3-testing
+ revision=12e8fccf5b5460be7aecddc71d27eceaba6e1f15
+ . ./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_REPO
[Xen-devel] [ovmf test] 96418: regressions - FAIL
flight 96418 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96418/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 94748 build-amd64-xsm 5 xen-build fail REGR. vs. 94748 build-amd64 5 xen-build fail REGR. vs. 94748 build-i3865 xen-build fail REGR. vs. 94748 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 89b206573965e9604c534cc1ef468ecd58e1b4d4 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 35 days 70 attempts Testing same since96368 2016-06-29 08:45:08 Z0 days8 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 fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7593 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 96416: regressions - FAIL
flight 96416 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96416/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 94748 build-amd64-xsm 5 xen-build fail REGR. vs. 94748 build-amd64 5 xen-build fail REGR. vs. 94748 build-i3865 xen-build fail REGR. vs. 94748 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 89b206573965e9604c534cc1ef468ecd58e1b4d4 baseline version: ovmf dc99315b8732b6e3032d01319d3f534d440b43d0 Last test of basis94748 2016-05-24 22:43:25 Z 35 days Failing since 94750 2016-05-25 03:43:08 Z 35 days 69 attempts Testing same since96368 2016-06-29 08:45:08 Z0 days7 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 fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7593 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 96411: regressions - FAIL
flight 96411 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96411/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 94748 build-amd64-xsm 5 xen-build fail REGR. vs. 94748 build-amd64 5 xen-build fail REGR. vs. 94748 build-i3865 xen-build fail REGR. vs. 94748 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 89b206573965e9604c534cc1ef468ecd58e1b4d4 baseline version: ovmf dc99315b8732b6e3032d01319d3f534d440b43d0 Last test of basis94748 2016-05-24 22:43:25 Z 35 days Failing since 94750 2016-05-25 03:43:08 Z 35 days 68 attempts Testing same since96368 2016-06-29 08:45:08 Z0 days6 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 fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7593 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf bisection] complete build-i386-xsm
branch xen-unstable xenbranch xen-unstable job build-i386-xsm 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/96409/ 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-i386-xsm.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-i386-xsm.xen-build --summary-out=tmp/96409.bisection-summary --basis-template=94748 --blessings=real,real-bisect ovmf build-i386-xsm xen-build Searching for failure / basis pass: 96408 fail [host=huxelrebe1] / 96339 [host=italia1] 96322 [host=baroque1] 96298 [host=pinot1] 96282 [host=elbling1] 96258 [host=elbling1] 96242 [host=baroque0] 96220 [host=pinot0] 96196 [host=baroque1] 96169 [host=huxelrebe0] 96148 [host=baroque0] 96126 [host=italia1] 96082 [host=baroque0] 96050 [host=huxelrebe0] 96015 [host=merlot1] 95987 [host=italia1] 95974 [host=baroque0] 95961 [host=fiano1] 95935 [host=baroque1] 95905 [host=pinot1] 95884 [host=baroque1] 95863 [host=merlot1] 95833 [host=fiano0] 95775 ok. Failure / basis pass flights: 96408 / 95775 (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 89b206573965e9604c534cc1ef468ecd58e1b4d4 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 Basis pass 8f88f023fc59961973bb1ef121c7bee7b0a61975 44a072f0de0d57c95c2212bbce0232b7b74f c2a17869d5dcd845d646bf4db122cad73596a2be Generating revisions with ./adhoc-revtuple-generator https://github.com/tianocore/edk2.git#8f88f023fc59961973bb1ef121c7bee7b0a61975-89b206573965e9604c534cc1ef468ecd58e1b4d4 git://xenbits.xen.org/qemu-xen.git#44a072f0de0d57c95c2212bbce0232b7b74f-44a072f0de0d57c95c2212bbce0232b7b74f git://xenbits.xen.org/xen.git#c2a17869d5dcd845d646bf4db122cad73596a2be-8384dc2d95538c5910d98db3df3ff5448bf0af48 Loaded 2001 nodes in revision graph Searching for test results: 95775 pass 8f88f023fc59961973bb1ef121c7bee7b0a61975 44a072f0de0d57c95c2212bbce0232b7b74f c2a17869d5dcd845d646bf4db122cad73596a2be 95863 [host=merlot1] 95833 [host=fiano0] 95884 [host=baroque1] 95905 [host=pinot1] 95961 [host=fiano1] 95935 [host=baroque1] 95987 [host=italia1] 95974 [host=baroque0] 96015 [host=merlot1] 96050 [host=huxelrebe0] 96082 [host=baroque0] 96126 [host=italia1] 96148 [host=baroque0] 96196 [host=baroque1] 96169 [host=huxelrebe0] 96220 [host=pinot0] 96242 [host=baroque0] 96258 [host=elbling1] 96339 [host=italia1] 96322 [host=baroque1] 96282 [host=elbling1] 96298 [host=pinot1] 96373 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96361 fail fd5d2dd2f55eedb3cf6001cc00587020c90411f5 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96368 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96379 pass 8f88f023fc59961973bb1ef121c7bee7b0a61975 44a072f0de0d57c95c2212bbce0232b7b74f c2a17869d5dcd845d646bf4db122cad73596a2be 96383 fail 89b206573965e9604c534cc1ef468ecd58e1b4d4 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96384 pass e8531927e1bbd258b03ae7749d1cc6f8fc9fd526 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96385 pass 98f2c9e8e2d3b814f2768f9a9d4156f652eeb53f 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96386 pass 5a59c50e536450d08910057f74a855490a427acd 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96376 fail 89b206573965e9604c534cc1ef4
[Xen-devel] [ovmf test] 96408: regressions - FAIL
flight 96408 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96408/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 94748 build-amd64-xsm 5 xen-build fail REGR. vs. 94748 build-amd64 5 xen-build fail REGR. vs. 94748 build-i3865 xen-build fail REGR. vs. 94748 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 89b206573965e9604c534cc1ef468ecd58e1b4d4 baseline version: ovmf dc99315b8732b6e3032d01319d3f534d440b43d0 Last test of basis94748 2016-05-24 22:43:25 Z 35 days Failing since 94750 2016-05-25 03:43:08 Z 35 days 67 attempts Testing same since96368 2016-06-29 08:45:08 Z0 days5 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 fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7593 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 96394: regressions - FAIL
flight 96394 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96394/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 94748 build-amd64-xsm 5 xen-build fail REGR. vs. 94748 build-amd64 5 xen-build fail REGR. vs. 94748 build-i3865 xen-build fail REGR. vs. 94748 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 89b206573965e9604c534cc1ef468ecd58e1b4d4 baseline version: ovmf dc99315b8732b6e3032d01319d3f534d440b43d0 Last test of basis94748 2016-05-24 22:43:25 Z 35 days Failing since 94750 2016-05-25 03:43:08 Z 35 days 66 attempts Testing same since96368 2016-06-29 08:45:08 Z0 days4 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 fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7593 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 96399: tolerable all pass - PUSHED
flight 96399 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96399/
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 3572f2fa7b0f6f20eb145bdccaf5888c76be8960
baseline version:
xen fcbc4d0d52b7fbc2e27a84fc530cc4f83ec1d941
Last test of basis96382 2016-06-29 15:02:49 Z0 days
Testing same since96399 2016-06-29 19:02:03 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=3572f2fa7b0f6f20eb145bdccaf5888c76be8960
+ . ./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
3572f2fa7b0f6f20eb145bdccaf5888c76be8960
+ branch=xen-unstable-smoke
+ revision=3572f2fa7b0f6f20eb145bdccaf5888c76be8960
+ . ./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
+ '[' x3572f2fa7b0f6f20eb145bdccaf5888c76be8960 = 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
'git://cache:9419/https://githu
[Xen-devel] [xen-unstable bisection] complete build-armhf-xsm
branch xen-unstable xenbranch xen-unstable job build-armhf-xsm testid xen-build 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: xen git://xenbits.xen.org/xen.git Bug introduced: 08cffe6696c047123bd552e095163924c8ef4353 Bug not present: 668ba1f85bf2e4086cf18c35abc880b9eee4e8f2 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/96403/ commit 08cffe6696c047123bd552e095163924c8ef4353 Author: Daniel De Graaf Date: Mon Jun 20 10:04:26 2016 -0400 xsm: add a default policy to .init.data 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. Enabling this option only builds the policy if checkpolicy is available during compilation of the hypervisor; otherwise, it does nothing. 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 Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Doug Goldstein Reviewed-by: Andrew Cooper Acked-by: Julien Grall For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/build-armhf-xsm.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/xen-unstable/build-armhf-xsm.xen-build --summary-out=tmp/96403.bisection-summary --basis-template=96296 --blessings=real,real-bisect xen-unstable build-armhf-xsm xen-build Searching for failure / basis pass: 96351 fail [host=cubietruck-gleizes] / 96296 ok. Failure / basis pass flights: 96351 / 96296 Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 44a072f0de0d57c95c2212bbce0232b7b74f 9b15b2e367a8565c73d5ba975e05c89c99078e60 Basis pass 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/qemu-xen.git#44a072f0de0d57c95c2212bbce0232b7b74f-44a072f0de0d57c95c2212bbce0232b7b74f git://xenbits.xen.org/xen.git#8384dc2d95538c5910d98db3df3ff5448bf0af48-9b15b2e367a8565c73d5ba975e05c89c99078e60 Loaded 1001 nodes in revision graph Searching for test results: 96234 [host=cubietruck-metzinger] 96251 [host=cubietruck-metzinger] 96278 [host=arndale-bluewater] 96296 pass 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96372 pass 44a072f0de0d57c95c2212bbce0232b7b74f 8384dc2d95538c5910d98db3df3ff5448bf0af48 96351 fail 44a072f0de0d57c95c2212bbce0232b7b74f 9b15b2e367a8565c73d5ba975e05c89c99078e60 96375 fail 44a072f0de0d57c95c2212bbce0232b7b74f 9b15b2e367a8565c73d5ba975e05c89c99078e60 96380 pass 44a072f0de0d57c95c2212bbce0232b7b74f 668ba1f85bf2e4086cf18c35abc880b9eee4e8f2 96388 fail 44a072f0de0d57c95c2212bbce0232b7b74f dca07f30021ca0840bd923f107d546301a5dba7a 96392 fail 44a072f0de0d57c95c2212bbce0232b7b74f 08cffe6696c047123bd552e095163924c8ef4353 96396 pass 44a072f0de0d57c95c2212bbce0232b7b74f 668ba1f85bf2e4086cf18c35abc880b9eee4e8f2 96397 fail 44a072f0de0d57c95c2212bbce0232b7b74f 08cffe6696c047123bd552e095163924c8ef4353 96401 pass 44a072f0de0d57c95c2212bbce0232b7b74f 668ba1f85bf2e4086cf18c35abc880b9eee4e8f2 96403 fail 44a072f0de0d57c95c2212bbce0232b7b74f 08cffe6696c047123bd552e095163924c8ef4353 Searching for interesting versions Result found: flight 96296 (pass), for basis pass Result found: flight 96351 (fail), for basis failure Repro found: flight 96372 (pass), for basis pass Repro found: flight 96375 (fail), for basis failure 0 revisions at 44a072f0de0d57c95c2212bbce0232b7b74f 668ba1f85bf2e4086cf18c35abc880b9eee4e8f2 No revisions left to test, checking graph state. Result found: flight 96380 (pass), for last pass Result found: flight 96392 (fail), for first failure Repro found: flight 96396 (pass), for last pass Repro found: flight 96397 (fail), for first failure Repro found: flight 96401 (pass), for last pass Repro found: flight 96403 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: 08cffe6696c047123bd552e095163924c8ef4353 Bug not present: 668ba1f85bf2e4086cf18c35abc880b9eee4e8f2 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/96403/ commit 08cffe6696c047123bd552e095163924c8ef4353 Author: Daniel De Graaf Date: Mon Jun 20 10:04:26 2016 -0400 xsm: add a de
Re: [Xen-devel] [GIT PULL] (Xen) stable/for-jens-4.7 for v4.7-rc5
On 06/29/2016 10:39 AM, Konrad Rzeszutek Wilk wrote: Hey Jens, Please git pull the 'stable/for-jens-4.7' branch which is based on your 'for-4.7/drivers' branch. It will nicely merge in your 'for-linus' branch: git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-4.7 which has one fix for migration of guest. We found that if we migrate the guest from a host that has multi-queue to an older (or vice-versa) we would lose outstanding I/Os as we did not recreate all the queues properly and lost the I/Os. Please pull! Pulled, thanks. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table
On 06/28/2016 09:41 AM, Boris Ostrovsky wrote:
> On 06/28/2016 07:03 AM, Shannon Zhao wrote:
>> On 2016/6/27 20:05, Boris Ostrovsky wrote:
>>> On 06/27/2016 06:29 AM, Julien Grall wrote:
(CC Boris and Doug)
Hi Shannon,
On 27/06/16 07:01, Shannon Zhao wrote:
> On 2016/6/24 1:03, Julien Grall wrote:
>> On 23/06/16 04:16, Shannon Zhao wrote:
>>
>> [...]
>>
>>> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
>>> index 264b6ef..5347480 100644
>>> --- a/tools/libxl/Makefile
>>> +++ b/tools/libxl/Makefile
>>> @@ -77,7 +77,29 @@ endif
>>>
>>>LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
>>>LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o
>>> libxl_libfdt_compat.o
>>> -LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
>>> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o libxl_dsdt_anycpu_arm.o
>>> +
>>> +vpath iasl $(PATH)
>>> +libxl_mk_dsdt_arm: libxl_mk_dsdt_arm.c
>>> +$(CC) $(CFLAGS) -o $@ libxl_mk_dsdt_arm.c
>>> +
>>> +libxl_dsdt_anycpu_arm.asl: libxl_empty_dsdt_arm.asl libxl_mk_dsdt_arm
>>> +awk 'NR > 1 {print s} {s=$$0}' $< > $@
>>> +./libxl_mk_dsdt_arm >> $@
>>> +
>>> +libxl_dsdt_anycpu_arm.c: %.c: iasl %.asl
>>> +iasl -vs -p $* -tc $*.asl
>>> +sed -e 's/AmlCode/$*/g' $*.hex >$@
>>> +echo "int $*_len=sizeof($*);" >>$@
>>> +rm -f $*.aml $*.hex
>>> +
>> I don't like the idea to add iasl as a dependency for all ARM
>> platforms.
>> For instance ARMv7 platform will not use ACPI, but we still ask
>> users to
>> install iasl. So I think we should allow the user to opt-in/opt-out for
>> ACPI.
>>
>> Any opinions?
>>
> I agree. But how to exclude for ARMv7. I notice it only has the option
> CONFIG_ARM which doesn't distinguish ARM32 and ARM64.
I am not sure if we plan to introduce Kconfig for tools. If not, you
can add an option to the configure to enable/disable ACPI for guest.
This would be gated by the presence of "iasl".
[...]
>>> diff --git a/tools/libxl/libxl_mk_dsdt_arm.c
>>> b/tools/libxl/libxl_mk_dsdt_arm.c
>>> new file mode 100644
>>> index 000..96fadbd
>>> --- /dev/null
>>> +++ b/tools/libxl/libxl_mk_dsdt_arm.c
>> Can we share the code from tools/firmware/acpi/mk_dsdt.c?
>>
> Yeah, we can share push_block(), pop_block() stmt() and indent() but the
> main() function is totally different since there are only the processor
> device objects for ARM DSDT but there are many other things in x86.
>
> I think that since Boris will move the codes under
> tools/firmware/hvmloader/acpi to other place, after that we could see
> how to share codes then.
I would prefer if we discuss about it now in order to avoid code
duplication (I have CCed Boris).
For instance we can create a new directory under tools for mk_dsdt.c.
The main could be different, although it might be possible to gate ARM
options, and the rest of the code would be shared.
>>> So I think we decided earlier to keep ARM and x86 ACPI builders
>>> separate, at least for now.
>> I think so as well.
>>
>>> However, looking at the Makefile and mk_dsdt
>>> I wonder whether it would make sense to put the builders in the same
>>> directory (I am currently using tools/libacpi) so that those two files
>>> can be kept common as much as possible, with the sources being
>>> different. E.g. something like
>>>
>>> tools/libacpi:
>>> Makefile
>>> mk_dsdt.c
>>> acpi_x86.[ch]
>>> acpi_arm.[ch]
>>> *asl
>>> etc.
>>>
>>> The objects will be built in tools/libxl (there will be no libacpi.so)
>>> but the infrastructure and sources will live together.
>> I'm fine with this. But I think the patch moving the codes into
>> tools/libacpi should be posted firstly, since this series depend on it.
>> Boris, could you please send that patch? Then I can add the
>> corresponding ARM patch on top of that.
>
> I thought I had it almost ready yesterday but I encountered a problem
> that I need to resolve before I post it. If I don't get it fixed in the
> next couple of days I will send you a link to my repository so that you
> can see what I have.
This may take me longer than I thought so here is the repo:
git://oss.oracle.com/git/bostrovs/xen.git:acpi_v1_wip
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] No graphics with xen pv and Fedora qemu
I have been trying to trace a problem when using Fedora's qemu with a pv guest which is that no graphics are available. I get the errors xen be core: xen be: watching backend path (backend/console/2) failed xen be core: xen be: watching backend path (backend/vkbd/2) failed xen be core: xen be: watching backend path (backend/vfb/2) failed xen be core: xen be: watching backend path (backend/qdisk/2) failed xen be core: xen be: watching backend path (backend/qnic/2) failed in the qemu log file in /var/log/xen . So far I have traced it to rbd support in qemu, because qemu-system-i386 built with the --disable-rbd does have working graphics. Does anyone have suggestions on what the problem might be, or how I might debug the issue further. Michael Young ___ 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
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, &insn_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.
>
> Jan
That sounds fine to me. I think this patch only needs Wei's or Ian's
ack now for the libxc changes.
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 96376: regressions - FAIL
flight 96376 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96376/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 94748 build-amd64-xsm 5 xen-build fail REGR. vs. 94748 build-amd64 5 xen-build fail REGR. vs. 94748 build-i3865 xen-build fail REGR. vs. 94748 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 89b206573965e9604c534cc1ef468ecd58e1b4d4 baseline version: ovmf dc99315b8732b6e3032d01319d3f534d440b43d0 Last test of basis94748 2016-05-24 22:43:25 Z 35 days Failing since 94750 2016-05-25 03:43:08 Z 35 days 65 attempts Testing same since96368 2016-06-29 08:45:08 Z0 days3 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 fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7593 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 96382: tolerable all pass - PUSHED
flight 96382 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96382/
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 fcbc4d0d52b7fbc2e27a84fc530cc4f83ec1d941
baseline version:
xen 3cdad93704aaa8bf1f274969e401ca21152bc4a2
Last test of basis96349 2016-06-28 19:02:22 Z0 days
Testing same since96382 2016-06-29 15:02:49 Z0 days1 attempts
People who touched revisions under test:
Elena Ufimtseva
Jan Beulich
Konrad Rzeszutek Wilk
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=fcbc4d0d52b7fbc2e27a84fc530cc4f83ec1d941
+ . ./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
fcbc4d0d52b7fbc2e27a84fc530cc4f83ec1d941
+ branch=xen-unstable-smoke
+ revision=fcbc4d0d52b7fbc2e27a84fc530cc4f83ec1d941
+ . ./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
+ '[' xfcbc4d0d52b7fbc2e27a84fc530cc4f83ec1d941 = 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 ']'
Re: [Xen-devel] [PATCH v2 2/2] xen: sched: rtds: use non-atomic bit-ops
On Sat, 2016-06-25 at 20:48 -0400, Tianyang Chen wrote: > Vcpu flags are checked and cleared atomically. Performance can be > improved with corresponding non-atomic versions since schedule.c > already has spin_locks in place. > > Signed-off-by: Tianyang Chen > Reviewed-by: Dario Faggioli Thanks and Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [GIT PULL] (Xen) stable/for-jens-4.7 for v4.7-rc5
Hey Jens, Please git pull the 'stable/for-jens-4.7' branch which is based on your 'for-4.7/drivers' branch. It will nicely merge in your 'for-linus' branch: git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-4.7 which has one fix for migration of guest. We found that if we migrate the guest from a host that has multi-queue to an older (or vice-versa) we would lose outstanding I/Os as we did not recreate all the queues properly and lost the I/Os. Please pull! P.S. I've also also put sta...@vger.kernel.org on the patch. drivers/block/xen-blkfront.c | 91 +++- 1 file changed, 40 insertions(+), 51 deletions(-) Bob Liu (1): xen-blkfront: save uncompleted reqs in blkfront_resume() ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 96351: regressions - FAIL
On Wed, 2016-06-29 at 10:18 +, osstest service owner wrote: > flight 96351 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/96351/ > > 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-credit2 15 guest-start/debian.repeat fail REGR. > vs. 96296 > FWIW, I'm trying to free up some time in order to be able to look into this ASAP. Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping
On 29/06/16 17:19, Vitaly Kuznetsov wrote:
> Vitaly Kuznetsov writes:
>
>> > Andrew Cooper writes:
>> >
>>> >> On 29/06/16 13:16, Vitaly Kuznetsov wrote:
>>> Andrew Cooper writes:
>>>
> On 28/06/16 17:47, Vitaly Kuznetsov wrote:
>> > @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct
>> > notifier_block *self, unsigned long action,
>> >int cpu = (long)hcpu;
>> >switch (action) {
>> >case CPU_UP_PREPARE:
>> > + /* vLAPIC_ID == Xen's vCPU_ID * 2 for HVM guests */
>> > + per_cpu(xen_vcpu_id, cpu) = cpu_physical_id(cpu) / 2;
> Please do not assume or propagate this brokenness. It is incorrect
> in
> the general case, and I will be fixing in the hypervisor in due
> course.
>
> Always read the APIC_ID from the LAPIC, per regular hardware.
>>> (I'm probbaly missing something important - please bear with me)
>>>
>>> The problem here is that I need to get _other_ CPU's id before any code
>>> is executed on that CPU (or, at least, this is the current state of
>>> affairs if you look at xen_hvm_cpu_up()) so I can't use CPUID/do MSR
>>> reads/... The only option I see here is to rely on ACPI (MADT) data
>>> which is stored in x86_cpu_to_apicid (and that's what cpu_physical_id()
>>> gives us). MADT also has processor id which connects it to DSDT but I'm
>>> not sure Linux keeps this data. But this is something fixable I guess.
>>> >>
>>> >> Hmm yes - that is a tricky issue.
>>> >>
>>> >> It is not safe or correct to assume that xen_vcpu_id is APICID / 2.
>>> >>
>>> >> This is currently the case for most modern versions of Xen, but isn't
>>> >> the case for older versions, and won't be the case in the future when I
>>> >> (or someone else) fixes topology representation for guests.
>>> >>
>>> >> For this to work, we need one or more of:
>>> >>
>>> >> 1) to provide the guest a full mapping from APIC_ID to vcpu id at boot
>>> >> time.
>> >
>> > So can we rely on ACPI data? Especially on MADT and processor ids there?
>> > I think we can always guarantee that processor ids there match vCPU
>> > ids. If yes I can try saving this data when we parse MADT.
>> >
> 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.
Jan - thoughts?
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] repeating 'd1v0 Over-allocation for domain 1' messages in xen 4.7 Host logs on PVHVM Guest launch
In summary, there's a problem An indication of the guest trying to allocate more memory that the host admin has allowed. that's filling logs with 10s of thousands of redundant log entries, with a suspicion that it's 'ballooning' issue in the guest Perhaps something wrong in the guest's balloon driver. With no currently known way to identify or troubleshoot the problem, and provide info here that could be helpful I'm simply not aware of existing output which would help; I can't see any way around instrumenting involved code. Not particularly ideal. Since this is the recommended bug-report channel, any next suggestions? Is there a particular dev involved in the ballooning that can be cc'd, perhaps to add some insight? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] xen: sched: rtds code clean-up
On Sat, 2016-06-25 at 20:48 -0400, Tianyang Chen wrote: > No functional change: > -aligned comments in rt_vcpu struct > -removed double underscores from the names of some functions > -fixed coding sytle for control structures involving lists > -fixed typos in the comments > -added comments for UPDATE_LIMIT_SHIFT > > Signed-off-by: Tianyang Chen > Reviewed-by: Dario Faggioli Thanks and Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping
Vitaly Kuznetsov writes:
> Andrew Cooper writes:
>
>> On 29/06/16 13:16, Vitaly Kuznetsov wrote:
>>> Andrew Cooper writes:
>>>
On 28/06/16 17:47, Vitaly Kuznetsov wrote:
> @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block
> *self, unsigned long action,
> int cpu = (long)hcpu;
> switch (action) {
> case CPU_UP_PREPARE:
> + /* vLAPIC_ID == Xen's vCPU_ID * 2 for HVM guests */
> + per_cpu(xen_vcpu_id, cpu) = cpu_physical_id(cpu) / 2;
Please do not assume or propagate this brokenness. It is incorrect in
the general case, and I will be fixing in the hypervisor in due course.
Always read the APIC_ID from the LAPIC, per regular hardware.
>>> (I'm probbaly missing something important - please bear with me)
>>>
>>> The problem here is that I need to get _other_ CPU's id before any code
>>> is executed on that CPU (or, at least, this is the current state of
>>> affairs if you look at xen_hvm_cpu_up()) so I can't use CPUID/do MSR
>>> reads/... The only option I see here is to rely on ACPI (MADT) data
>>> which is stored in x86_cpu_to_apicid (and that's what cpu_physical_id()
>>> gives us). MADT also has processor id which connects it to DSDT but I'm
>>> not sure Linux keeps this data. But this is something fixable I guess.
>>
>> Hmm yes - that is a tricky issue.
>>
>> It is not safe or correct to assume that xen_vcpu_id is APICID / 2.
>>
>> This is currently the case for most modern versions of Xen, but isn't
>> the case for older versions, and won't be the case in the future when I
>> (or someone else) fixes topology representation for guests.
>>
>> For this to work, we need one or more of:
>>
>> 1) to provide the guest a full mapping from APIC_ID to vcpu id at boot
>> time.
>
> So can we rely on ACPI data? Especially on MADT and processor ids there?
> I think we can always guarantee that processor ids there match vCPU
> ids. If yes I can try saving this data when we parse MADT.
>
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
>From 7c9cd25bdcd3e6ee866aa49550c9a4160194c3ba Mon Sep 17 00:00:00 2001
From: Vitaly Kuznetsov
Date: Wed, 29 Jun 2016 18:13:01 +0200
Subject: [PATCH RFC/WIP] x86/acpi: store APIC ids for future usage (+use it in
xen_hvm_cpu_notify)
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/include/asm/smp.h | 1 +
arch/x86/kernel/acpi/boot.c| 18 ++
arch/x86/kernel/setup_percpu.c | 3 +++
arch/x86/xen/enlighten.c | 8 ++--
4 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index 66b0573..c68b56a 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(int, 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);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 9414f84..3bbf0ab 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -110,6 +110,9 @@ static u32 isa_irq_to_gsi[NR_IRQS_LEGACY] __read_mostly = {
#define ACPI_INVALID_GSI INT_MIN
+DEFINE_EARLY_PER_CPU_READ_MOSTLY(int, x86_cpu_to_acpiid, -1);
+EXPORT_EARLY_PER_CPU_SYMBOL(x86_cpu_to_acpiid);
+
/*
* This is just a simple wrapper around early_ioremap(),
* with sanity checks for phys == 0 and size == 0.
@@ -165,9 +168,10 @@ static int __init acpi_parse_madt(struct acpi_table_header *table)
*
* 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, int 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 +186,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 +220,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 +248,7 @@ acpi_parse_lapic(struc
Re: [Xen-devel] repeating 'd1v0 Over-allocation for domain 1' messages in xen 4.7 Host logs on PVHVM Guest launch
>>> On 29.06.16 at 17:38, wrote: > On 06/29/2016 07:17 AM, Jan Beulich wrote: >> I don't think a guest would itself issue any relevant messages. > > You mentioned ballooning in the guest. The doc I found addressed > ballooning, in the guest. > > If not that, then what output, with specificity, would be helpful in > troubleshooting this ? I'm simply not aware of existing output which would help; I can't see any way around instrumenting involved code. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen: use native disk xenbus protocol if possible
On Wed, Jun 29, 2016 at 05:50:48PM +0200, Juergen Gross wrote:
> The qdisk implementation is using the native xenbus protocol only in
> case of no protocol specified at all. As using the explicit 32- or
> 64-bit protocol is slower than the native one due to copying requests
> not by memcpy but element for element, this is not optimal.
>
> Correct this by using the native protocol in case word sizes of
> frontend and backend match.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Anthony PERARD
Thanks,
> ---
> V2: use native protocol in case of unknown protocol specified as
> requested by Anthony Perard
> ---
> hw/block/xen_disk.c | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> index 90aca73..d0aae67 100644
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -975,14 +975,16 @@ static int blk_connect(struct XenDevice *xendev)
> blkdev->feature_persistent = !!pers;
> }
>
> -blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
> -if (blkdev->xendev.protocol) {
> -if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_32) == 0) {
> -blkdev->protocol = BLKIF_PROTOCOL_X86_32;
> -}
> -if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_64) == 0) {
> -blkdev->protocol = BLKIF_PROTOCOL_X86_64;
> -}
> +if (!blkdev->xendev.protocol) {
> +blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
> +} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_NATIVE) ==
> 0) {
> +blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
> +} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_32) ==
> 0) {
> +blkdev->protocol = BLKIF_PROTOCOL_X86_32;
> +} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_64) ==
> 0) {
> +blkdev->protocol = BLKIF_PROTOCOL_X86_64;
> +} else {
> +blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
> }
>
> blkdev->sring = xengnttab_map_grant_ref(blkdev->xendev.gnttabdev,
> --
> 2.6.6
>
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] xen: use native disk xenbus protocol if possible
The qdisk implementation is using the native xenbus protocol only in
case of no protocol specified at all. As using the explicit 32- or
64-bit protocol is slower than the native one due to copying requests
not by memcpy but element for element, this is not optimal.
Correct this by using the native protocol in case word sizes of
frontend and backend match.
Signed-off-by: Juergen Gross
---
V2: use native protocol in case of unknown protocol specified as
requested by Anthony Perard
---
hw/block/xen_disk.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 90aca73..d0aae67 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -975,14 +975,16 @@ static int blk_connect(struct XenDevice *xendev)
blkdev->feature_persistent = !!pers;
}
-blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
-if (blkdev->xendev.protocol) {
-if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_32) == 0) {
-blkdev->protocol = BLKIF_PROTOCOL_X86_32;
-}
-if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_64) == 0) {
-blkdev->protocol = BLKIF_PROTOCOL_X86_64;
-}
+if (!blkdev->xendev.protocol) {
+blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
+} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_NATIVE) == 0) {
+blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
+} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_32) == 0) {
+blkdev->protocol = BLKIF_PROTOCOL_X86_32;
+} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_64) == 0) {
+blkdev->protocol = BLKIF_PROTOCOL_X86_64;
+} else {
+blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
}
blkdev->sring = xengnttab_map_grant_ref(blkdev->xendev.gnttabdev,
--
2.6.6
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: register clocks used by the hypervisor
Hi Julien,
On 22.06.2016 17:26, Julien Grall wrote:
Hello Dirk,
On 21/06/16 11:16, 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.
This new property would need to be documented in:
- linux/Documentation/devicetree/bindings/arm/xen.txt
- xen/docs/misc/arm/device-tree/guest.txt
Yes, as already discussed, I'll have a look to that.
Signed-off-by: Dirk Behme
---
arch/arm/xen/enlighten.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..ee6e81f 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -381,6 +382,40 @@ 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;
+unsigned int i, count;
+int ret;
+
+count = of_clk_get_parent_count(xen_node);
The code in this file has changed quite a lot with the support of ACPI.
For instance "xen_node" is not anymore a global variable. Can you rebase
your rework on top of the branch for-linus-4.8?
You can find the branch in:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
I'll have a look to that, too. Thanks!
Hopefully it won't be too complicated to rebase ;)
+if (!count)
+return 0;
+
+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));
+return PTR_ERR(clk);
+}
+
+ret = clk_prepare_enable(clk);
I am not sure why we would want Linux to enable the clock. Should not it
be already done either by the firmware or Xen?
After having a closer look to that, my understanding:
We have to call clk_prepare(clk) and clk_enable(clk) in this order (and
clk_prepare_enable() does this in one call) to get the enable count
incremented
http://lxr.free-electrons.com/source/drivers/clk/clk.c#L751
to prevent clk_disable_unused() to disable this clock.
That does mean that yes, you are right, the (hw-) clock itself is
already enabled by the firmware or Xen. But we are not really interested
in enabling the clock, here, but get the Linux kernel's enable_count
incremented.
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.
That would mean that we have to to set the clock flags in the device
tree. What would mean that for each clock we don't want to be disabled
we have to manipulate the root clock entry of that clock in the device
tree. While that would be possible, it doesn't sound that easy and I
wonder if that wouldn't be too complicated to be done in Xen (?)
You will correct me if I'm wrong ;)
Many thanks!
Dirk
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 script calling conventions
[Cc-ing Roger and Wei, which have *BSD experience]
On Tue, 2016-06-28 at 18:00 -0700, John Nemeth wrote:
> I'm trying to package Xen 4.6 (specifically Xen 4.6.3) for
> use with NetBSD. I have it mostly done; however, when I try to
> create a domU, libxl goes into an infinite loop calling the scripts.
> If I try to create a domU with no network or disk, it works fine
> (albeit of rather limited use). Have there been changes between
> Xen 4.5 and Xen 4.6 in the calling convention for the scripts? Is
> there documentation on what is expected somewhere? Please CC me on
> any responses. Here is my domU config file:
>
> -
> kernel = "/usr/pkg/etc/xen/kernels/netbsd-XEN3_DOMU.gz"
> #kernel = "/usr/pkg/etc/xen/kernels/netbsd-INSTALL_XEN3_DOMU.gz"
>
> memory = 512
>
> name = "netbsd1"
>
> vif = [ 'bridge=bridge0' ]
>
> #disk = [ 'file:/usr/pkg/etc/xen/disks/netbsd1,0x1,w' ]
> #disk = [ 'file:/usr/pkg/etc/xen/disks/netbsd1,0x1,w',
> 'file:/usr/local/isos/Net
> BSD-amd64-20140916.iso,0x2,r' ]
> #disk = [ 'phy:/dev/vnd0d,0x1,rw' ]
>
> extra = ""
> -
>
> Here is the output of "xl -v create netbsd1 -c":
>
> -
> Script started on Sat Jun 25 18:33:46 2016
> i386devel: {1} xl -v create netbsd1 -c
> Parsing config from netbsd1
> libxl: debug: libxl_create.c:1563:do_domain_create: ao
> 0x7a19e312b0c0: create: how=0x0 callback=0x0 poller=0x7a19e310d110
> libxl: debug: libxl_create.c:947:initiate_domain_create: running
> bootloader
> libxl: debug: libxl_bootloader.c:330:libxl__bootloader_run: no
> bootloader configured, using user supplied kernel
> libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch
> w=0x7a19e312e958: deregister unregistered
> domainbuilder: detail: xc_dom_allocate: cmdline="", features="(null)"
> libxl: debug: libxl_dom.c:625:libxl__build_pv: pv kernel mapped 0
> path /usr/pkg/etc/xen/kernels/netbsd-XEN3_DOMU.gz
> domainbuilder: detail: xc_dom_kernel_file:
> filename="/usr/pkg/etc/xen/kernels/netbsd-XEN3_DOMU.gz"
> domainbuilder: detail: xc_dom_malloc_filemap: 2288 kB
> domainbuilder: detail: xc_dom_malloc: 7293 kB
> domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x23c0c7 ->
> 0x71f606
> domainbuilder: detail: xc_dom_boot_xen_init: ver 4.6, caps xen-3.0-
> x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
> domainbuilder: detail: xc_dom_parse_image: called
> domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader
> ...
> domainbuilder: detail: loader probe OK
> xc: detail: elf_parse_binary: phdr: paddr=0x8000
> memsz=0x547f28
> xc: detail: elf_parse_binary: phdr: paddr=0x80647f40
> memsz=0x1b80c0
> xc: detail: elf_parse_binary: memory: 0x8000 ->
> 0x8080
> xc: detail: elf_xen_parse: __xen_guest:
> "GUEST_OS=NetBSD,GUEST_VER=4.99,XEN_VER=xen-
> 3.0,LOADER=generic,VIRT_BASE=0x8000,ELF_PADDR_OFFSET=0xff
> ff8000,VIRT_ENTRY=0x8010,HYPERCALL_PAGE=0x010
> 1,BSD_SYMTAB=yes"
> xc: detail: elf_xen_parse_guest_info: GUEST_OS="NetBSD"
> xc: detail: elf_xen_parse_guest_info: GUEST_VER="4.99"
> xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0"
> xc: detail: elf_xen_parse_guest_info: LOADER="generic"
> xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x8000"
> xc: detail: elf_xen_parse_guest_info:
> ELF_PADDR_OFFSET="0x8000"
> xc: detail: elf_xen_parse_guest_info: VIRT_ENTRY="0x8010"
> xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x0101"
> xc: detail: elf_xen_parse_guest_info: BSD_SYMTAB="yes"
> xc: detail: elf_xen_addr_calc_check: addresses:
> xc: detail: virt_base= 0x8000
> xc: detail: elf_paddr_offset = 0x8000
> xc: detail: virt_offset = 0x0
> xc: detail: virt_kstart = 0x8000
> xc: detail: virt_kend= 0x80899e78
> xc: detail: virt_entry = 0x8010
> xc: detail: p2m_base = 0x
> domainbuilder: detail: xc_dom_malloc: 615 kB
> domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64:
> 0x8000 -> 0x80933cf0
> domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x2
> pages, 4k each
> domainbuilder: detail: xc_dom_mem_init: 0x2 pages
> domainbuilder: detail: xc_dom_boot_mem_init: called
> domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size
> 64
> domainbuilder: detail: xc_dom_malloc: 1024 kB
> domainbuilder: detail: xc_dom_build_image: called
> domainbuilder: detail: xc_dom_alloc_segment: kernel :
> 0x8000 -> 0x80934000 (pfn 0x0 + 0x934 pages)
> domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
> 0x0+0x934 at 0x7a19debcc000
> xc: detail: elf_load_binary: phdr 0 at 0x7a19debcc000 ->
> 0x7a19df113f28
> xc: detail: elf_load_binary: phdr 1 at 0x7a19df213f40 ->
> 0x7a19df23d318
> xc: detail: elf_load_bsdsyms: shdr 25 at 0x7a19dfd
Re: [Xen-devel] [PATCH] x86/xen: Use DIV_ROUND_UP
On 29/06/16 16:00, Amitoj Kaur Chawla wrote: > The kernel.h macro DIV_ROUND_UP performs the computation > (((n) + (d) - 1) /(d)) but is perhaps more readable. > > The Coccinelle script used to make this change is as follows: > @haskernel@ > @@ > > #include > > @depends on haskernel@ > expression n,d; > @@ > > ( > - (n + d - 1) / d > + DIV_ROUND_UP(n,d) > | > - (n + (d - 1)) / d > + DIV_ROUND_UP(n,d) > ) Applied to for-linus-4.8, thanks. PFN_UP/DOWN() are for converting addresses to PFNs. DIV_ROUND_UP() is clearer when converting sizes to numbers of pages (as demonstrated by the incorrect suggestion to use PFN_DOWN()). David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: use native disk xenbus protocol if possible
On 29/06/16 17:20, Anthony PERARD wrote:
> On Fri, Jun 17, 2016 at 01:14:56PM +0200, Juergen Gross wrote:
>> The qdisk implementation is using the native xenbus protocol only in
>> case of no protocol specified at all. As using the explicit 32- or
>> 64-bit protocol is slower than the native one due to copying requests
>> not by memcpy but element for element, this is not optimal.
>>
>> Correct this by using the native protocol in case word sizes of
>> frontend and backend match.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> hw/block/xen_disk.c | 16
>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
>> index 2862b59..0961fcb 100644
>> --- a/hw/block/xen_disk.c
>> +++ b/hw/block/xen_disk.c
>> @@ -976,14 +976,14 @@ static int blk_connect(struct XenDevice *xendev)
>> blkdev->feature_persistent = !!pers;
>> }
>>
>> -blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
>> -if (blkdev->xendev.protocol) {
>> -if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_32) == 0) {
>> -blkdev->protocol = BLKIF_PROTOCOL_X86_32;
>> -}
>> -if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_64) == 0) {
>> -blkdev->protocol = BLKIF_PROTOCOL_X86_64;
>> -}
>> +if (!blkdev->xendev.protocol) {
>> +blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
>> +} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_NATIVE) ==
>> 0) {
>> +blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
>> +} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_32) ==
>> 0) {
>> +blkdev->protocol = BLKIF_PROTOCOL_X86_32;
>> +} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_64) ==
>> 0) {
>> +blkdev->protocol = BLKIF_PROTOCOL_X86_64;
>
> There is one difference with the previous code, in case the protocol is
> specified, but it not x86_32 or x86_64, then no blkdev->protocol is
> selected (then no ring is initialized). Could you re-add this case?
Aah, of course!
Thanks,
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/xen: Use DIV_ROUND_UP
On 29/06/16 17:34, Jan Beulich wrote:
On 29.06.16 at 17:00, wrote:
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -591,7 +591,7 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
>> {
>> unsigned long va = dtr->address;
>> unsigned int size = dtr->size + 1;
>> -unsigned pages = (size + PAGE_SIZE - 1) / PAGE_SIZE;
>> +unsigned pages = DIV_ROUND_UP(size, PAGE_SIZE);
>> unsigned long frames[pages];
>> int f;
>>
>> @@ -640,7 +640,7 @@ static void __init xen_load_gdt_boot(const struct
>> desc_ptr *dtr)
>> {
>> unsigned long va = dtr->address;
>> unsigned int size = dtr->size + 1;
>> -unsigned pages = (size + PAGE_SIZE - 1) / PAGE_SIZE;
>> +unsigned pages = DIV_ROUND_UP(size, PAGE_SIZE);
>> unsigned long frames[pages];
>> int f;
>>
>
> Perhaps even more readable would be PFN_DOWN()?
Or PFN_UP() to be correct?
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] repeating 'd1v0 Over-allocation for domain 1' messages in xen 4.7 Host logs on PVHVM Guest launch
On 06/29/2016 07:17 AM, Jan Beulich wrote: I don't think a guest would itself issue any relevant messages. You mentioned ballooning in the guest. The doc I found addressed ballooning, in the guest. If not that, then what output, with specificity, would be helpful in troubleshooting this ? I'd prefer to avoid the guessing game, and provide what's needed. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/xen: Use DIV_ROUND_UP
>>> On 29.06.16 at 17:00, wrote:
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -591,7 +591,7 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
> {
> unsigned long va = dtr->address;
> unsigned int size = dtr->size + 1;
> - unsigned pages = (size + PAGE_SIZE - 1) / PAGE_SIZE;
> + unsigned pages = DIV_ROUND_UP(size, PAGE_SIZE);
> unsigned long frames[pages];
> int f;
>
> @@ -640,7 +640,7 @@ static void __init xen_load_gdt_boot(const struct
> desc_ptr *dtr)
> {
> unsigned long va = dtr->address;
> unsigned int size = dtr->size + 1;
> - unsigned pages = (size + PAGE_SIZE - 1) / PAGE_SIZE;
> + unsigned pages = DIV_ROUND_UP(size, PAGE_SIZE);
> unsigned long frames[pages];
> int f;
>
Perhaps even more readable would be PFN_DOWN()?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] FW: vTPM detaching issue
On 06/29/2016 03:51 AM, Xu, Quan wrote: On June 15, 2016 7:49 PM, < wei.l...@citrix.com > wrote: On Tue, Jun 14, 2016 at 12:32:19PM +0200, Andrea Genuise wrote: [...] libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend /local/domain/748/backend/vtpm/749/0/state (hoping for state change to 6): xswait timeout (path=/local/domain/748/backend/vtpm/749/0/state) libxl: debug: libxl_event.c:677:libxl__ev_xswatch_deregister: watch w=0x1c4c1f0 wpath=/local/domain/748/backend/vtpm/749/0/state token=3/0: deregister slotnum=3 libxl: debug: libxl_event.c:867:devstate_callback: backend /local/domain/748/backend/vtpm/749/0/state wanted state 6 timed out This. The toolstack is waiting for the state to change to 6. But that never happened. libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch w=0x1c4c1f0: deregister unregistered libxl: debug: libxl_device.c:937:device_backend_callback: calling device_backend_cleanup libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch w=0x1c4c1f0: deregister unregistered libxl: debug: libxl_device.c:943:device_backend_callback: Timeout reached, initiating forced remove I think this is due to interaction between frontend and backend, but I'm not an expert on vtpm so I don't have further comment. Daniel, are you following this issue? --Quan I am, but I haven't had a chance to look at what is happening with the state changes. There are few, if any, use cases that actually need the ability to remove a vTPM without destroying the client domain (or the driver domain), so I don't think this ever got tested. I am guessing that the minios and/or Linux driver is missing a state change step. -- Daniel De Graaf National Security Agency ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: use native disk xenbus protocol if possible
On Fri, Jun 17, 2016 at 01:14:56PM +0200, Juergen Gross wrote:
> The qdisk implementation is using the native xenbus protocol only in
> case of no protocol specified at all. As using the explicit 32- or
> 64-bit protocol is slower than the native one due to copying requests
> not by memcpy but element for element, this is not optimal.
>
> Correct this by using the native protocol in case word sizes of
> frontend and backend match.
>
> Signed-off-by: Juergen Gross
> ---
> hw/block/xen_disk.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> index 2862b59..0961fcb 100644
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -976,14 +976,14 @@ static int blk_connect(struct XenDevice *xendev)
> blkdev->feature_persistent = !!pers;
> }
>
> -blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
> -if (blkdev->xendev.protocol) {
> -if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_32) == 0) {
> -blkdev->protocol = BLKIF_PROTOCOL_X86_32;
> -}
> -if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_64) == 0) {
> -blkdev->protocol = BLKIF_PROTOCOL_X86_64;
> -}
> +if (!blkdev->xendev.protocol) {
> +blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
> +} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_NATIVE) ==
> 0) {
> +blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
> +} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_32) ==
> 0) {
> +blkdev->protocol = BLKIF_PROTOCOL_X86_32;
> +} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_64) ==
> 0) {
> +blkdev->protocol = BLKIF_PROTOCOL_X86_64;
There is one difference with the previous code, in case the protocol is
specified, but it not x86_32 or x86_64, then no blkdev->protocol is
selected (then no ring is initialized). Could you re-add this case?
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3] xsm: add a default policy to .init.data
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 INSTALL | 6 +- docs/misc/xen-command-line.markdown | 16 +--- docs/misc/xsm-flask.txt | 30 +++--- xen/common/Kconfig | 16 xen/xsm/flask/.gitignore| 1 + xen/xsm/flask/Makefile | 11 +++ xen/xsm/flask/gen-policy.py | 19 +++ xen/xsm/xsm_core.c | 22 +- 8 files changed, 97 insertions(+), 24 deletions(-) create mode 100644 xen/xsm/flask/.gitignore create mode 100644 xen/xsm/flask/gen-policy.py diff --git a/INSTALL b/INSTALL index 616a67a..703cfe7 100644 --- a/INSTALL +++ b/INSTALL @@ -272,7 +272,11 @@ PYTHON_PREFIX_ARG= The hypervisor may be build with XSM/Flask support, which can be changed by running: make -C xen menuconfig -and enabling XSM/Flask in the 'Common Features' menu. +and enabling XSM/Flask in the 'Common Features' menu. By default, this +selection will also enable compiling a built-in policy, which requires +the SELinux policy compiler (checkpolicy) to build. The location of +this executable can be set using its environment variable. +CHECKPOLICY= Do a build for coverage. coverage=y diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index 2a088ca..5500242 100644 --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -712,13 +712,15 @@ enabled by running either: with untrusted guests. If a policy is provided by the bootloader, it will be loaded; errors will be reported to the ring buffer but will not prevent booting. The policy can be changed to enforcing mode using "xl setenforce". -* `enforcing`: This requires a security policy to be provided by the bootloader - and will enter enforcing mode prior to the creation of domain 0. If a valid - policy is not provided, the hypervisor will not continue booting. -* `late`: This disables loading of the security policy from the bootloader. - FLASK will be enabled but will not enforce access controls until a policy is - loaded by a domain using "xl loadpolicy". Once a policy is loaded, FLASK will - run in enforcing mode unless "xl setenforce" has changed that setting. +* `enforcing`: This will cause the security server to enter enforcing mode prior + to the creation of domain 0. If an valid policy is not provided by the + bootloader and no built-in policy is present, the hypervisor will not continue + booting. +* `late`: This disables loading of the built-in security policy or the policy + provided by the bootloader. FLASK will be enabled but will not enforce access + controls until a policy is loaded by a domain using "xl loadpolicy". Once a + policy is loaded, FLASK will run in enforcing mode unless "xl setenforce" has + changed that setting. * `disabled`: This causes the XSM framework to revert to the dummy module. The dummy module provides the same security policy as is used when compiling the hypervisor without support for XSM. The xsm\_op hypercall can also be used to diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt index 2f42585..62f15dd 100644 --- a/docs/misc/xsm-flask.txt +++ b/docs/misc/xsm-flask.txt @@ -141,21 +141,21 @@ only type enforcement is used and the user and role are set to system_u and system_r for all domains. The FLASK security framework is mostly configured using a security policy file. -This policy file is not normally generated during the Xen build process because -it relies on the SELinux compiler "checkpolicy"; run - - make -C tools/flask/policy - -to compile the example policy included with Xen. The policy is generated from -definition files under this directory. Most changes to security policy will -involve creating or modifying modules found in tools/flask/policy/modules/. The -modules.conf file there defines what modules are enabled and has short -descriptions of each module. - -The XSM policy file needs to be copied to /boot and loaded as a module by grub. -The exact position of the module does not matter as long as it is after the Xen -kernel; it is normally placed either just above the dom0 kernel or at the end. -Once dom0 is running, the policy can be reloaded
Re: [Xen-devel] [xen-unstable test] 96330: regressions - trouble: blocked/broken/fail/pass
On 06/29/2016 06:58 AM, Ian Jackson wrote:
Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 96330: regressions -
trouble: blocked/broken/fail/pass"):
On 28.06.16 at 21:16, wrote:
This latter one is
objcopy -S -I binary -O elf64-little --rename-section=.data=.init.xsm_policy
policy.bin policy.o
...
:policy.o: Invalid bfd target
Makefile:45: recipe for target 'policy.o' failed
make[5]: Leaving directory
'/home/osstest/build.96330.build-armhf-xsm/xen/xen/xsm/flask'
make[5]: *** [policy.o] Error 1
which looks to be the not really suitable use of elf64-little in
commit 08cffe6696 ("xsm: add a default policy to .init.data").
Since it's not immediately clear how to fix this preferably
without ugly ifdef-ery in the makefile, I think we better revert
this for now. Opinions?
Yes, I think reverting it for now is the right answer.
That's fine; I am planning on sending a v3 of this patch that drops
the use of objcopy for a python script converting the policy to an
array in a .c file. This also eliminates the linker script changes.
--
Daniel De Graaf
National Security Agency
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/xen: Use DIV_ROUND_UP
The kernel.h macro DIV_ROUND_UP performs the computation
(((n) + (d) - 1) /(d)) but is perhaps more readable.
The Coccinelle script used to make this change is as follows:
@haskernel@
@@
#include
@depends on haskernel@
expression n,d;
@@
(
- (n + d - 1) / d
+ DIV_ROUND_UP(n,d)
|
- (n + (d - 1)) / d
+ DIV_ROUND_UP(n,d)
)
Signed-off-by: Amitoj Kaur Chawla
---
arch/x86/xen/enlighten.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 880862c..6847512 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -591,7 +591,7 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
{
unsigned long va = dtr->address;
unsigned int size = dtr->size + 1;
- unsigned pages = (size + PAGE_SIZE - 1) / PAGE_SIZE;
+ unsigned pages = DIV_ROUND_UP(size, PAGE_SIZE);
unsigned long frames[pages];
int f;
@@ -640,7 +640,7 @@ static void __init xen_load_gdt_boot(const struct desc_ptr
*dtr)
{
unsigned long va = dtr->address;
unsigned int size = dtr->size + 1;
- unsigned pages = (size + PAGE_SIZE - 1) / PAGE_SIZE;
+ unsigned pages = DIV_ROUND_UP(size, PAGE_SIZE);
unsigned long frames[pages];
int f;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [V3] x86/cpuid: AVX-512 Feature Detection
>>> On 29.06.16 at 13:27, wrote: > AVX-512 is an extention of AVX2. Its spec can be found at: > https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf > This patch detects AVX-512 features by CPUID. > > Signed-off-by: Luwei Kang > --- > [V3] > 1.adjust dependencies between features. > [V2] > 1.one per bit, change from > > + xstate_size = max(xstate_size, > > + xstate_offsets[_XSTATE_HI_ZMM] + > > + xstate_sizes[_XSTATE_HI_ZMM]); > to > xstate_size = max(xstate_size, > xstate_offsets[_XSTATE_OPMASK] + > xstate_sizes[_XSTATE_OPMASK]); > xstate_size = max(xstate_size, > xstate_offsets[_XSTATE_ZMM] + > xstate_sizes[_XSTATE_ZMM]); > xstate_size = max(xstate_size, > xstate_offsets[_XSTATE_HI_ZMM] + > xstate_sizes[_XSTATE_HI_ZMM]); > 2.change form > domain_cpuid(currd, 0x07, 0, &tmp, &_ebx, &tmp, &tmp); > to > domain_cpuid(currd, 7, 0, &tmp, &_ebx, &tmp, &tmp); > 3.add dependencies between features in xen/tools/gen-cpuid.py > 4.split the cpuid call just like the way the hvm_cpuid() side works. Especially item 1 is clearly to verbose; note how I said "brief" when I asked for the revision log. > --- a/xen/tools/gen-cpuid.py > +++ b/xen/tools/gen-cpuid.py > @@ -243,6 +243,17 @@ def crunch_numbers(state): > # AMD K6-2+ and K6-III processors shipped with 3DNow+, beyond the > # standard 3DNow in the earlier K6 processors. > _3DNOW: [_3DNOWEXT], > + > +# AVX2 is an extension to AVX, providing mainly new integer > instructions. > +# In principle, AVX512 only depends on YMM register state, but many > AVX2 > +# instructions are extended by AVX512F to 512-bit forms. I realize you used the wording as suggested by Andrew, and while his reply to my question about it meanwhile clarified what is meant, I continue to think that the mentioning of YMM registers above is misleading. May I suggest something like "AVX512 only takes YMM register state as a prerequisite", subject to further improvement by Andrew or another native speaker? Apart from that the patch looks fine to me now. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [V3] x86/cpuid: AVX-512 Feature Detection
>>> On 29.06.16 at 13:45, wrote: > From table 2-2 I can see that > AVX512F = AVX512F & AVX512VL > AVX512CD = AVX512F & AVX512VL & AVX512CD > AVX512DQ = AVX512F & AVX512VL & AVX512DQ > AVX512BW = AVX512F & AVX512VL & AVX512BW > AVX512IFMA = AVX512F & AVX512VL & AVX512IFMA > AVX512VBMI = AVX512F & AVX512VL & AVX512VBMI > > From this depends list some AVX512 feature also depends on AVX512VL. You mis-interpreted that table - its left column header clearly says "Usage of 256/128 Vector Lengths". Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Domain creation errors
>>> On 29.06.16 at 13:21, wrote: > The other reason I am hesitant about PTR_ERR() is that it obfuscates the > semantics sufficiently for Coverity to give up. Mind giving some more detail? These inline functions aren't all that obfuscating - just a couple of casts. If that's enough to confuse Coverity then I think we have many more problems elsewhere (no matter how much we try to fight introduction of new casts). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] repeating 'd1v0 Over-allocation for domain 1' messages in xen 4.7 Host logs on PVHVM Guest launch
>>> On 29.06.16 at 14:58, wrote: > On 06/29/2016 03:07 AM, Jan Beulich wrote: >>> What needs to be fixed, or if of no concern, can these messages be silenced? >> >> Perhaps something wrong in the guest's balloon driver. > > I'm seeing these @host log-entries for Ubuntu, Arch & Opensuse guests. > > As a guest issue is suspected, a post of debug-level dmesg output from > the guest would be useful? I don't think a guest would itself issue any relevant messages. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/cpuid: AVX-512 Feature Detection
>>> On 29.06.16 at 13:37, wrote:
> On 29/06/16 11:03, Jan Beulich wrote:
> On 29.06.16 at 11:50, wrote:
>>> On 29/06/16 03:20, Luwei Kang wrote:
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -235,6 +235,10 @@ def crunch_numbers(state):
# subsequent instruction groups may only be VEX encoded.
AVX: [FMA, FMA4, F16C, AVX2, XOP],
+# AVX-512 is an extention of AVX2 and it depends on AVX2
available.
+AVX2: [AVX512F, AVX512DQ, AVX512IFMA, AVX512PF, AVX512ER,
AVX512CD,
+AVX512BW, AVX512VL, AVX512VBMI],
>>> I think this needs adjusting. AVX512F is the base feature and
>>> indication of extra xstate, while all other AVX512 features (e.g.
>>> AVX512DQ) are explicitly documented not needing to check for AVX512F if
>>> the AVX512DQ bit is present.
>> I think the "not" here is wrong? At least my copy (rev 024) requires
>> all involved feature bits to be checked (see e.g. table 2-2 or the
>> individual instruction pages).
>
> Hmm - yet another inconsistency. Some instructions specify a CPUID
> dependency for just AVX512F (EVEX.NDS.512.66.0F.W1 C2 /r ib VCMPPD k1
> {k2}, zmm2, zmm3/m512/m64bcst{sae}, imm8), some for AVX512F and a second
> feature (EVEX.256.66.0F38.W1 19 /r VBROADCASTSD ymm1 {k1}{z}, xmm2/m64)
> , and some only for the second feature (EVEX.512.66.0F.W0 79 /r
> VCVTPS2UQQ zmm1 {k1}{z}, ymm2/m256/m32bcst{er})
>
> FWIW, I still think the dependency expression is ok in its current form.
Oh, of course - I didn't mean to put that under question.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] repeating 'd1v0 Over-allocation for domain 1' messages in xen 4.7 Host logs on PVHVM Guest launch
fyi, per Verify Xen Project PVHVM drivers are working in the Linux HVM guest kernel http://wiki.xen.org/wiki/Xen_Linux_PV_on_HVM_drivers "Run "dmesg | egrep -i 'xen|front'" in the HVM guest VM." with Guest cmd line, ... systemd.log_level=debug systemd.log_target=kmsg earlyprintk=vga,keep loglevel=9 after guest reboot, output of dmesg | egrep -i 'xen|front' in the booted VM is http://pastebin.com/raw/N0FtTtfC With no mention of 'balloon' drivers as doc'd on that page ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions
On 29/06/16 15:31, Ross Lagerwall wrote:
> On 06/29/2016 02:00 PM, Juergen Gross wrote:
>> On 29/06/16 14:52, Andrew Cooper wrote:
>>> On 29/06/16 13:44, Juergen Gross wrote:
@@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
/* Tell the kernel we're up and running. */
xenbus_notify_running();
-#if defined(XEN_SYSTEMD_ENABLED)
-if (systemd) {
-sd_notify(1, "READY=1");
-fprintf(stderr, SD_NOTICE "xenstored is ready\n");
-}
-#endif
>>>
>>> Getting rid of the socket configuration for systemd is ok, but we should
>>> keep the sd_notify() calls for when the daemon is started by systemd.
>>>
>>> Socket activiation and sd_notify() are orthogonal, and sd_notify() is
>>> still required if we don't want systemd to treat xenstored as a legacy
>>> unix daemon.
>>
>> So what is the downside of xenstored being treated as a legacy daemon?
>> This question is especially interesting for the case of patch 2 being
>> considered: xenstored is no longer started by systemd, but by a wrapper
>> script which might decide to start the xenstore domain instead.
>>
>> Another problem: today xenstored decides whether to call sd_notify()
>> by testing the xenstore sockets being specified via systemd. This will
>> no longer work. So how to do it now?
>>
>>
>
> One problem with the patch as it currently is implemented is that the
> service type is not correct for when xenstored is a daemon. This makes
> it difficult to manage with systemd and difficult for other services to
> depend on it in a sensible fashion. The end result is subtle races and
> occasional failures.
Could you please educate me what's wrong? I'm no systemd expert.
> How about:
> * Maintain the existing service for xenstored
> * Have a separate service (with different a service type) for starting
> the xenstore domain
> * Switch between the two services
How could I specify e.g. in xendomains.service the dependency to
xenstore?
> Personally I think it is better and more uniform for the administrator
> to enable and disable services in the normal fashion, but if you want to
The two services would be mutually exclusive. Can I tell systemd this
is the case?
> make it configurable with /etc/sysconfig/xencommons, then you can add
> something like this to xenstored.service:
>
> ExecStartPre=/bin/grep -q XENSTORETYPE=daemon /etc/sysconfig/xencommons
>
> and to xenstore-domain.service:
>
> ExecStartPre=/bin/grep -q XENSTORETYPE=domain /etc/sysconfig/xencommons
That's no good idea. Someone commenting out the old line and adding the
other option would end in both variants to be tried. This would have to
be a little bit more sophisticated. :-)
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.3-testing test] 96355: regressions - FAIL
flight 96355 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/96355/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt5 libvirt-build fail REGR. vs. 87893 build-amd64-libvirt 5 libvirt-build fail REGR. vs. 87893 build-armhf 5 xen-build fail REGR. vs. 87893 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: test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a build-armhf-libvirt 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 build-i386-rumpuserxen6 xen-buildfail 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 91 days Failing since 92180 2016-04-20 17:49:21 Z 69 days 38 attempts Testing same since96017 2016-06-20 17:22:27 Z8 days 17 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 fail build-i386 pass build-amd64-libvirt fail build-armhf-libvirt blocked build-i386-libvirt fail 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 blocked 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 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i3
Re: [Xen-devel] [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table
On 2016年06月29日 17:42, Julien Grall wrote: > On 29/06/2016 10:29, Shannon Zhao wrote: >> >> >> On 2016/6/27 18:17, Julien Grall wrote: >>> On 27/06/16 02:44, Shannon Zhao wrote: On 2016/6/24 0:26, Julien Grall wrote: > On 23/06/16 04:16, Shannon Zhao wrote: >> From: Shannon Zhao >> >> Construct GTDT table with the interrupt information of timers. >> >> Signed-off-by: Shannon Zhao >> --- >>tools/libxl/libxl_arm_acpi.c | 28 >>1 file changed, 28 insertions(+) >> >> diff --git a/tools/libxl/libxl_arm_acpi.c >> b/tools/libxl/libxl_arm_acpi.c >> index d5ffedf..de863f4 100644 >> --- a/tools/libxl/libxl_arm_acpi.c >> +++ b/tools/libxl/libxl_arm_acpi.c >> @@ -39,6 +39,9 @@ typedef uint64_t u64; >>#define ACPI_BUILD_APPNAME6 "XenARM" >>#define ACPI_BUILD_APPNAME4 "Xen " >> >> +#define ACPI_LEVEL_SENSITIVE(u8) 0x00 >> +#define ACPI_ACTIVE_LOW (u8) 0x01 >> + > > Why did not you include actypes.h rather than define these two > defines? If we include actypes.h, there will be some compiling errors. ../../xen/include/acpi/actypes.h:55:2: error: #error ACPI_MACHINE_WIDTH not defined #error ACPI_MACHINE_WIDTH not defined ^ ../../xen/include/acpi/actypes.h:130:9: error: unknown type name 'COMPILER_DEPENDENT_UINT64' typedef COMPILER_DEPENDENT_UINT64 UINT64; ^ ../../xen/include/acpi/actypes.h:131:9: error: unknown type name 'COMPILER_DEPENDENT_INT64' typedef COMPILER_DEPENDENT_INT64 INT64; ^ ../../xen/include/acpi/actypes.h:202:2: error: #error unknown ACPI_MACHINE_WIDTH #error unknown ACPI_MACHINE_WIDTH ^ ../../xen/include/acpi/actypes.h:207:9: error: unknown type name 'acpi_native_uint' typedef acpi_native_uint acpi_size; ^ ../../xen/include/acpi/actypes.h:617:3: error: unknown type name 'acpi_io_address' acpi_io_address pblk_address; Yeah, it maybe can be solved by defining ACPI_MACHINE_WIDTH and COMPILER_DEPENDENT_INT64 here, but since we only needs ACPI_LEVEL_SENSITIVE and ACPI_ACTIVE_LOW, I think it's ok to define them here. >>> >>> We should avoid to redefine value as much as possible. The 2 missing >>> values are easy to define (see below) so there is no point to redefine >>> in a less obvious way: no comment to explain what the values are for, >>> and only a part of the set defined. >>> >>> #define ACPI_MACHINE_WIDTH BITS_PER_LONG >>> #define COMPILER_DEPENDENT_INT64 int64_t >>> >> Actually not work. I add below codes but get compiling errors as well. >> So it needs the BITS_PER_LONG but it exists asm-arm/config.h > > Give a look to bitperlongs.h in /usr/include. Although the name is > __BITS_PER_LONG. Oh, Thanks. I'm wondering why other codes define own BITS_PER_LONG rather than use __BITS_PER_LONG directly. -- Shannon ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions
On 06/29/2016 02:00 PM, Juergen Gross wrote:
On 29/06/16 14:52, Andrew Cooper wrote:
On 29/06/16 13:44, Juergen Gross wrote:
@@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
/* Tell the kernel we're up and running. */
xenbus_notify_running();
-#if defined(XEN_SYSTEMD_ENABLED)
- if (systemd) {
- sd_notify(1, "READY=1");
- fprintf(stderr, SD_NOTICE "xenstored is ready\n");
- }
-#endif
Getting rid of the socket configuration for systemd is ok, but we should
keep the sd_notify() calls for when the daemon is started by systemd.
Socket activiation and sd_notify() are orthogonal, and sd_notify() is
still required if we don't want systemd to treat xenstored as a legacy
unix daemon.
So what is the downside of xenstored being treated as a legacy daemon?
This question is especially interesting for the case of patch 2 being
considered: xenstored is no longer started by systemd, but by a wrapper
script which might decide to start the xenstore domain instead.
Another problem: today xenstored decides whether to call sd_notify()
by testing the xenstore sockets being specified via systemd. This will
no longer work. So how to do it now?
One problem with the patch as it currently is implemented is that the
service type is not correct for when xenstored is a daemon. This makes
it difficult to manage with systemd and difficult for other services to
depend on it in a sensible fashion. The end result is subtle races and
occasional failures.
How about:
* Maintain the existing service for xenstored
* Have a separate service (with different a service type) for starting
the xenstore domain
* Switch between the two services
Personally I think it is better and more uniform for the administrator
to enable and disable services in the normal fashion, but if you want to
make it configurable with /etc/sysconfig/xencommons, then you can add
something like this to xenstored.service:
ExecStartPre=/bin/grep -q XENSTORETYPE=daemon /etc/sysconfig/xencommons
and to xenstore-domain.service:
ExecStartPre=/bin/grep -q XENSTORETYPE=domain /etc/sysconfig/xencommons
Regards,
--
Ross Lagerwall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions
On 29/06/16 14:52, Andrew Cooper wrote:
> On 29/06/16 13:44, Juergen Gross wrote:
>> @@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
>> /* Tell the kernel we're up and running. */
>> xenbus_notify_running();
>>
>> -#if defined(XEN_SYSTEMD_ENABLED)
>> -if (systemd) {
>> -sd_notify(1, "READY=1");
>> -fprintf(stderr, SD_NOTICE "xenstored is ready\n");
>> -}
>> -#endif
>
> Getting rid of the socket configuration for systemd is ok, but we should
> keep the sd_notify() calls for when the daemon is started by systemd.
>
> Socket activiation and sd_notify() are orthogonal, and sd_notify() is
> still required if we don't want systemd to treat xenstored as a legacy
> unix daemon.
So what is the downside of xenstored being treated as a legacy daemon?
This question is especially interesting for the case of patch 2 being
considered: xenstored is no longer started by systemd, but by a wrapper
script which might decide to start the xenstore domain instead.
Another problem: today xenstored decides whether to call sd_notify()
by testing the xenstore sockets being specified via systemd. This will
no longer work. So how to do it now?
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] repeating 'd1v0 Over-allocation for domain 1' messages in xen 4.7 Host logs on PVHVM Guest launch
On 06/29/2016 03:07 AM, Jan Beulich wrote: What are these 'Over-allocation' messages? An indication of the guest trying to allocate more memory that the host admin has allowed. currently, each guest has allocated maxmem = 2048 memory = 2048 What needs to be fixed, or if of no concern, can these messages be silenced? Perhaps something wrong in the guest's balloon driver. I'm seeing these @host log-entries for Ubuntu, Arch & Opensuse guests. As a guest issue is suspected, a post of debug-level dmesg output from the guest would be useful? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions
On 29/06/16 13:44, Juergen Gross wrote:
> @@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
> /* Tell the kernel we're up and running. */
> xenbus_notify_running();
>
> -#if defined(XEN_SYSTEMD_ENABLED)
> - if (systemd) {
> - sd_notify(1, "READY=1");
> - fprintf(stderr, SD_NOTICE "xenstored is ready\n");
> - }
> -#endif
Getting rid of the socket configuration for systemd is ok, but we should
keep the sd_notify() calls for when the daemon is started by systemd.
Socket activiation and sd_notify() are orthogonal, and sd_notify() is
still required if we don't want systemd to treat xenstored as a legacy
unix daemon.
~Andrew
___
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
Andrew Cooper writes:
> On 29/06/16 13:16, Vitaly Kuznetsov wrote:
>> Andrew Cooper writes:
>>
>>> On 28/06/16 17:47, Vitaly Kuznetsov wrote:
@@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block
*self, unsigned long action,
int cpu = (long)hcpu;
switch (action) {
case CPU_UP_PREPARE:
+ /* vLAPIC_ID == Xen's vCPU_ID * 2 for HVM guests */
+ per_cpu(xen_vcpu_id, cpu) = cpu_physical_id(cpu) / 2;
>>> Please do not assume or propagate this brokenness. It is incorrect in
>>> the general case, and I will be fixing in the hypervisor in due course.
>>>
>>> Always read the APIC_ID from the LAPIC, per regular hardware.
>> (I'm probbaly missing something important - please bear with me)
>>
>> The problem here is that I need to get _other_ CPU's id before any code
>> is executed on that CPU (or, at least, this is the current state of
>> affairs if you look at xen_hvm_cpu_up()) so I can't use CPUID/do MSR
>> reads/... The only option I see here is to rely on ACPI (MADT) data
>> which is stored in x86_cpu_to_apicid (and that's what cpu_physical_id()
>> gives us). MADT also has processor id which connects it to DSDT but I'm
>> not sure Linux keeps this data. But this is something fixable I guess.
>
> Hmm yes - that is a tricky issue.
>
> It is not safe or correct to assume that xen_vcpu_id is APICID / 2.
>
> This is currently the case for most modern versions of Xen, but isn't
> the case for older versions, and won't be the case in the future when I
> (or someone else) fixes topology representation for guests.
>
> For this to work, we need one or more of:
>
> 1) to provide the guest a full mapping from APIC_ID to vcpu id at boot
> time.
So can we rely on ACPI data? Especially on MADT and processor ids there?
I think we can always guarantee that processor ids there match vCPU
ids. If yes I can try saving this data when we parse MADT.
> 2) add a new interface where the guest can explicitly query "what is the
> vcpu id for the entity with this APIC_ID".
> 3) Allow HVM guests to identify a vcpu in a hypercall by APIC_ID.
>
> 3 is the cleaner approach, but given that vcpu ids have already leaked
> into an HVM domains idea of the world, 1 or 2 is probably a better
> ladder to dig us out of this hole.
It would be nice to avoid hypervisor changes but if we have to modify it
we can fail all secondary CPUs for now when we detect that CPU0's vCPU
id is not 0 (and CPU0 gets its id with CPUID).
--
Vitaly
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen: xenbus: Remove create_workqueue
On 31/05/16 17:56, Bhaktipriya Shridhar wrote: > System workqueues have been able to handle high level of concurrency > for a long time now and there's no reason to use dedicated workqueues > just to gain concurrency. Replace dedicated xenbus_frontend_wq with the > use of system_wq. > > Unlike a dedicated per-cpu workqueue created with create_workqueue(), > system_wq allows multiple work items to overlap executions even on > the same CPU; however, a per-cpu workqueue doesn't have any CPU > locality or global ordering guarantees unless the target CPU is > explicitly specified and the increase of local concurrency shouldn't > make any difference. > > In this case, there is only a single work item, increase of concurrency > level by switching to system_wq should not make any difference. Applied to for-linus-4.8, thanks. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen: xen-pciback: Remove create_workqueue
On 01/06/16 15:15, Bhaktipriya Shridhar wrote: > System workqueues have been able to handle high level of concurrency > for a long time now and there's no reason to use dedicated workqueues > just to gain concurrency. Replace dedicated xen_pcibk_wq with the > use of system_wq. > > Unlike a dedicated per-cpu workqueue created with create_workqueue(), > system_wq allows multiple work items to overlap executions even on > the same CPU; however, a per-cpu workqueue doesn't have any CPU > locality or global ordering guarantees unless the target CPU is > explicitly specified and thus the increase of local concurrency shouldn't > make any difference. > > Since the work items could be pending, flush_work() has been used in > xen_pcibk_disconnect(). xen_pcibk_xenbus_remove() calls free_pdev() > which in turn calls xen_pcibk_disconnect() for every pdev to ensure that > there is no pending task while disconnecting the driver. Applied to for-linus-4.8, thanks. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] tools: make xenstore domain/daemon configurable
Add a configuration option to /etc/sysconfig/xencommons to let the user configure whether he wants to start xenstore service as a daemon or as a stubdom. Juergen Gross (2): tools: remove systemd xenstore socket definitions tools: make xenstore domain easy configurable tools/configure| 4 +- tools/hotplug/Linux/Makefile | 1 + tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 42 +- tools/hotplug/Linux/init.d/xencommons.in | 35 + tools/hotplug/Linux/launch-xenstore.in | 84 +++ tools/hotplug/Linux/systemd/Makefile | 5 - tools/hotplug/Linux/systemd/xenstored.service.in | 14 +- tools/hotplug/Linux/systemd/xenstored.socket.in| 13 -- tools/hotplug/Linux/systemd/xenstored_ro.socket.in | 13 -- tools/ocaml/xenstored/Makefile | 10 +- tools/ocaml/xenstored/systemd.ml | 17 --- tools/ocaml/xenstored/systemd.mli | 24 tools/ocaml/xenstored/systemd_stubs.c | 153 - tools/ocaml/xenstored/utils.ml | 21 +-- tools/ocaml/xenstored/xenstored.ml | 2 - tools/xenstore/Makefile| 3 - tools/xenstore/xenstored_core.c| 113 +-- 17 files changed, 143 insertions(+), 411 deletions(-) create mode 100644 tools/hotplug/Linux/launch-xenstore.in delete mode 100644 tools/hotplug/Linux/systemd/xenstored.socket.in delete mode 100644 tools/hotplug/Linux/systemd/xenstored_ro.socket.in delete mode 100644 tools/ocaml/xenstored/systemd.ml delete mode 100644 tools/ocaml/xenstored/systemd.mli delete mode 100644 tools/ocaml/xenstored/systemd_stubs.c -- 2.6.6 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] tools: make xenstore domain easy configurable
Add configuration entries to sysconfig.xencommons for selection of the
xenstore type (domain or daemon) and start the selected xenstore
service via a script called from sysvinit or systemd.
Signed-off-by: Juergen Gross
---
tools/configure| 2 +-
tools/hotplug/Linux/Makefile | 1 +
tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 42 ++-
tools/hotplug/Linux/init.d/xencommons.in | 35 ++---
tools/hotplug/Linux/launch-xenstore.in | 84 ++
tools/hotplug/Linux/systemd/xenstored.service.in | 11 +--
6 files changed, 132 insertions(+), 43 deletions(-)
create mode 100644 tools/hotplug/Linux/launch-xenstore.in
diff --git a/tools/configure b/tools/configure
index 0854271..b9b9f27 100755
--- a/tools/configure
+++ b/tools/configure
@@ -2410,7 +2410,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
-ac_config_files="$ac_config_files ../config/Tools.mk
hotplug/FreeBSD/rc.d/xencommons hotplug/FreeBSD/rc.d/xendriverdomain
hotplug/Linux/init.d/sysconfig.xencommons
hotplug/Linux/init.d/sysconfig.xendomains hotplug/Linux/init.d/xen-watchdog
hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains
hotplug/Linux/init.d/xendriverdomain hotplug/Linux/vif-setup
hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains
hotplug/NetBSD/rc.d/xencommons hotplug/NetBSD/rc.d/xendriverdomain
libxl/xenlight.pc.in libxl/xlutil.pc.in ocaml/xenstored/oxenstored.conf"
+ac_config_files="$ac_config_files ../config/Tools.mk
hotplug/FreeBSD/rc.d/xencommons hotplug/FreeBSD/rc.d/xendriverdomain
hotplug/Linux/init.d/sysconfig.xencommons
hotplug/Linux/init.d/sysconfig.xendomains hotplug/Linux/init.d/xen-watchdog
hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains
hotplug/Linux/init.d/xendriverdomain hotplug/Linux/launch-xenstore
hotplug/Linux/vif-setup hotplug/Linux/xen-hotplug-common.sh
hotplug/Linux/xendomains hotplug/NetBSD/rc.d/xencommons
hotplug/NetBSD/rc.d/xendriverdomain libxl/xenlight.pc.in libxl/xlutil.pc.in
ocaml/xenstored/oxenstored.conf"
ac_config_headers="$ac_config_headers config.h"
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index 6d6ccee..29280cb 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -30,6 +30,7 @@ XEN_SCRIPTS += block-drbd-probe
XEN_SCRIPTS += block-dummy
XEN_SCRIPTS += $(XEN_SCRIPTS-y)
XEN_SCRIPTS += colo-proxy-setup
+XEN_SCRIPTS += launch-xenstore
SUBDIRS-$(CONFIG_SYSTEMD) += systemd
diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
index c27a476..cc8185c 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
@@ -6,12 +6,24 @@
#XENCONSOLED_TRACE=[none|guest|hv|all]
## Type: string
+## Default: daemon
+#
+# Select type of xentore service.
+#
+# This can be either of:
+# * daemon
+# * domain
+#
+# Changing this requires a reboot to take effect.
+#
+#XENSTORETYPE=daemon
+
+## Type: string
## Default: xenstored
#
# Select xenstore implementation, this can be either
-# of these below. If using systemd it's preferred that you
-# just edit the xenstored.service unit file and change
-# the XENSTORED variable there.
+# of these below.
+# Only evaluated if XENSTORETYPE is "daemon".
#
# This can be either of:
# * @sbindir@/oxenstored
@@ -26,21 +38,45 @@
# Additional commandline arguments to start xenstored,
# like "--trace-file @XEN_LOG_DIR@/xenstored-trace.log"
# See "@sbindir@/xenstored --help" for possible options.
+# Only evaluated if XENSTORETYPE is "daemon".
XENSTORED_ARGS=
## Type: string
## Default: Not defined, tracing off
#
# Log xenstored messages
+# Only evaluated if XENSTORETYPE is "daemon".
#XENSTORED_TRACE=[yes|on|1]
## Type: string
## Default: "@XEN_LIB_STORED@"
#
# Running xenstored on XENSTORED_ROOTDIR
+# Only evaluated if XENSTORETYPE is "daemon".
#XENSTORED_ROOTDIR=@XEN_LIB_STORED@
## Type: string
+## Default: @LIBEXEC@/boot/xenstore-stubdom.gz
+#
+# xenstore domain kernel.
+# Only evaluated if XENSTORETYPE is "domain".
+#XENSTORE_DOMAIN_KERNEL=@LIBEXEC@/boot/xenstore-stubdom.gz
+
+## Type: integer
+## Default: 8
+#
+# xenstore domain memory size in MiB.
+# Only evaluated if XENSTORETYPE is "domain".
+#XENSTORE_DOMAIN_SIZE=8
+
+## Type: string
+## Default: ""
+#
+# Additional arguments for starting the xenstore domain.
+# Only evaluated if XENSTORETYPE is "domain".
+XENSTORE_DOMAIN_ARGS=
+
+## Type: string
## Default: Not defined, xenbackendd debug mode off
#
# Running xenbackendd in debug mode
diff --git a/tools/hotplug/Linux/init.d/xencommons.in
b/tools/hotplug/Linux/init.d/xencommons.in
index 7b69fc2..1f4f198 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -62,37 +62,10 @@ do_start () {
mkdir -p ${XEN_RUN_DIR}
mkdir -p ${XEN_LOCK_DIR}
-
[Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions
On a system with systemd the xenstore sockets are created via systemd. Remove the related configuration files in order to be able to decide at runtime whether the sockets should be created or not. This will enable Xen to start xenstore either via a daemon or via a stub domain. Signed-off-by: Juergen Gross --- tools/configure| 2 +- tools/hotplug/Linux/systemd/Makefile | 5 - tools/hotplug/Linux/systemd/xenstored.service.in | 3 +- tools/hotplug/Linux/systemd/xenstored.socket.in| 13 -- tools/hotplug/Linux/systemd/xenstored_ro.socket.in | 13 -- tools/ocaml/xenstored/Makefile | 10 +- tools/ocaml/xenstored/systemd.ml | 17 --- tools/ocaml/xenstored/systemd.mli | 24 tools/ocaml/xenstored/systemd_stubs.c | 153 - tools/ocaml/xenstored/utils.ml | 21 +-- tools/ocaml/xenstored/xenstored.ml | 2 - tools/xenstore/Makefile| 3 - tools/xenstore/xenstored_core.c| 113 +-- 13 files changed, 11 insertions(+), 368 deletions(-) delete mode 100644 tools/hotplug/Linux/systemd/xenstored.socket.in delete mode 100644 tools/hotplug/Linux/systemd/xenstored_ro.socket.in delete mode 100644 tools/ocaml/xenstored/systemd.ml delete mode 100644 tools/ocaml/xenstored/systemd.mli delete mode 100644 tools/ocaml/xenstored/systemd_stubs.c diff --git a/tools/configure b/tools/configure index 4c92fa2..0854271 100755 --- a/tools/configure +++ b/tools/configure @@ -9670,7 +9670,7 @@ fi if test "x$systemd" = "xy"; then : -ac_config_files="$ac_config_files hotplug/Linux/systemd/proc-xen.mount hotplug/Linux/systemd/var-lib-xenstored.mount hotplug/Linux/systemd/xen-init-dom0.service hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service hotplug/Linux/systemd/xen-watchdog.service hotplug/Linux/systemd/xenconsoled.service hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xenstored.service hotplug/Linux/systemd/xenstored.socket hotplug/Linux/systemd/xenstored_ro.socket" +ac_config_files="$ac_config_files hotplug/Linux/systemd/proc-xen.mount hotplug/Linux/systemd/var-lib-xenstored.mount hotplug/Linux/systemd/xen-init-dom0.service hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service hotplug/Linux/systemd/xen-watchdog.service hotplug/Linux/systemd/xenconsoled.service hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xenstored.service" fi diff --git a/tools/hotplug/Linux/systemd/Makefile b/tools/hotplug/Linux/systemd/Makefile index 83e3b32..e5144f1 100644 --- a/tools/hotplug/Linux/systemd/Makefile +++ b/tools/hotplug/Linux/systemd/Makefile @@ -6,9 +6,6 @@ XEN_SYSTEMD_MODULES = xen.conf XEN_SYSTEMD_MOUNT = proc-xen.mount XEN_SYSTEMD_MOUNT += var-lib-xenstored.mount -XEN_SYSTEMD_SOCKET = xenstored.socket -XEN_SYSTEMD_SOCKET += xenstored_ro.socket - XEN_SYSTEMD_SERVICE = xenstored.service XEN_SYSTEMD_SERVICE += xenconsoled.service XEN_SYSTEMD_SERVICE += xen-qemu-dom0-disk-backend.service @@ -18,7 +15,6 @@ XEN_SYSTEMD_SERVICE += xen-init-dom0.service ALL_XEN_SYSTEMD = $(XEN_SYSTEMD_MODULES) \ $(XEN_SYSTEMD_MOUNT)\ - $(XEN_SYSTEMD_SOCKET) \ $(XEN_SYSTEMD_SERVICE) .PHONY: all @@ -37,7 +33,6 @@ install: $(ALL_XEN_SYSTEMD) $(INSTALL_DIR) $(DESTDIR)$(XEN_SYSTEMD_DIR) [ -d $(DESTDIR)$(XEN_SYSTEMD_MODULES_LOAD) ] || \ $(INSTALL_DIR) $(DESTDIR)$(XEN_SYSTEMD_MODULES_LOAD) - $(INSTALL_DATA) *.socket $(DESTDIR)$(XEN_SYSTEMD_DIR) $(INSTALL_DATA) *.service $(DESTDIR)$(XEN_SYSTEMD_DIR) $(INSTALL_DATA) *.mount $(DESTDIR)$(XEN_SYSTEMD_DIR) $(INSTALL_DATA) *.conf $(DESTDIR)$(XEN_SYSTEMD_MODULES_LOAD) diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in index a5f836b..a1e1db1 100644 --- a/tools/hotplug/Linux/systemd/xenstored.service.in +++ b/tools/hotplug/Linux/systemd/xenstored.service.in @@ -1,6 +1,6 @@ [Unit] Description=The Xen xenstore -Requires=xenstored_ro.socket xenstored.socket proc-xen.mount var-lib-xenstored.mount +Requires=proc-xen.mount var-lib-xenstored.mount After=proc-xen.mount var-lib-xenstored.mount Before=libvirtd.service libvirt-guests.service RefuseManualStop=true @@ -19,6 +19,5 @@ ExecStart=/bin/sh -c "exec $XENSTORED --no-fork $XENSTORED_ARGS" [Install] WantedBy=multi-user.target -Also=xenstored_ro.socket xenstored.socket Also=proc-xen.mount Also=var-lib-xenstored.mount diff --git a/tools/hotplug/Linux/systemd/xenstored.socket.in b/tools/hotplug/Linux/systemd/xenstored.socket.in deleted file mode 100644 index 375c4b7..000 --- a/tools/hotplug/Linux/systemd/xenstored.socket.in +++ /dev/null @@ -1,13 +0,0 @@ -[Unit] -Description=xenstore socket -Requires=proc-xen.mount var-lib-xen
Re: [Xen-devel] [PATCH v2 2/2] xen-pciback: clean up {bar, rom}_init()
On 27/06/16 08:24, Jan Beulich wrote: On 24.06.16 at 17:01, wrote: >> On 07/06/16 07:31, Jan Beulich wrote: >>> - drop unused function parameter of read_dev_bar() >>> - drop rom_init() (now identical to bar_init()) >>> - fold read_dev_bar() into its now single caller >>> - simplify determination of 64-bit memory resource >>> - use const and unsigned >> >> Please split this in 5 separate patches for easier review. >> >> Especially as often anyone writing "simplify" means "accidentally break". > > So this is directly opposite of what Boris had asked for - originally > there were two patches, which I folded upon his request (and > which he gave his R-b for already). May I ask the two of you to > first settle on a consistent set of expectations to patches like this? SubmittingPatches section 3 is clear on what is required. If your commit message is a list of bullet points it's a pretty big hint that none of the changes are related. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 96373: regressions - FAIL
flight 96373 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96373/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 94748 build-amd64-xsm 5 xen-build fail REGR. vs. 94748 build-amd64 5 xen-build fail REGR. vs. 94748 build-i3865 xen-build fail REGR. vs. 94748 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 89b206573965e9604c534cc1ef468ecd58e1b4d4 baseline version: ovmf dc99315b8732b6e3032d01319d3f534d440b43d0 Last test of basis94748 2016-05-24 22:43:25 Z 35 days Failing since 94750 2016-05-25 03:43:08 Z 35 days 64 attempts Testing same since96368 2016-06-29 08:45:08 Z0 days2 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 fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7593 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH linux 0/8] xen: pvhvm: support bootup on secondary vCPUs
On 29/06/16 10:16, Vitaly Kuznetsov wrote: > David Vrabel writes: > >> On 28/06/16 17:47, Vitaly Kuznetsov wrote: >>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In >>> particular, when we crash on a secondary vCPU we may want to do kdump >>> and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting >>> on the vCPU which crashed. This doesn't work very well for PVHVM guests as >>> we have a number of hypercalls where we pass vCPU id as a parameter. These >>> hypercalls either fail or do something unexpected. To solve the issue we >>> need to have a mapping between Linux's and Xen's vCPU ids. >> >> Could the soft-reboot hypercall (optionally) return on vcpu 0? >> > > In theory, yes, I think we can re-arrange vCPUs inside the hypervisor so > Linux will get them in the natural order after soft reset. The series is straight forwards and the concept of the guest having to map its idea of CPU to VCPU is fine, so unless you think a hypervisor based solution is better we can take this series once it's fixed up. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH linux 4/8] x86/xen: use xen_vcpu_id mapping when pointing vcpu_info to the shared_info page
On 28/06/16 17:47, Vitaly Kuznetsov wrote:
> 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
> ---
> arch/x86/xen/enlighten.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 69f4c0c..1596626 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -189,6 +189,7 @@ static void xen_vcpu_setup(int cpu)
> struct vcpu_register_vcpu_info info;
> int err;
> struct vcpu_info *vcpup;
> + int xen_cpu = per_cpu(xen_vcpu_id, cpu);
I think there should be a
static inline int xen_vcpu_nr(int cpu)
{
return per_cpu(xen_vcpu_id, cpu);
}
helper function.
David
___
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
On 29/06/16 13:16, Vitaly Kuznetsov wrote:
> Andrew Cooper writes:
>
>> On 28/06/16 17:47, Vitaly Kuznetsov wrote:
>>> @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block
>>> *self, unsigned long action,
>>> int cpu = (long)hcpu;
>>> switch (action) {
>>> case CPU_UP_PREPARE:
>>> + /* vLAPIC_ID == Xen's vCPU_ID * 2 for HVM guests */
>>> + per_cpu(xen_vcpu_id, cpu) = cpu_physical_id(cpu) / 2;
>> Please do not assume or propagate this brokenness. It is incorrect in
>> the general case, and I will be fixing in the hypervisor in due course.
>>
>> Always read the APIC_ID from the LAPIC, per regular hardware.
> (I'm probbaly missing something important - please bear with me)
>
> The problem here is that I need to get _other_ CPU's id before any code
> is executed on that CPU (or, at least, this is the current state of
> affairs if you look at xen_hvm_cpu_up()) so I can't use CPUID/do MSR
> reads/... The only option I see here is to rely on ACPI (MADT) data
> which is stored in x86_cpu_to_apicid (and that's what cpu_physical_id()
> gives us). MADT also has processor id which connects it to DSDT but I'm
> not sure Linux keeps this data. But this is something fixable I guess.
Hmm yes - that is a tricky issue.
It is not safe or correct to assume that xen_vcpu_id is APICID / 2.
This is currently the case for most modern versions of Xen, but isn't
the case for older versions, and won't be the case in the future when I
(or someone else) fixes topology representation for guests.
For this to work, we need one or more of:
1) to provide the guest a full mapping from APIC_ID to vcpu id at boot time.
2) add a new interface where the guest can explicitly query "what is the
vcpu id for the entity with this APIC_ID".
3) Allow HVM guests to identify a vcpu in a hypercall by APIC_ID.
3 is the cleaner approach, but given that vcpu ids have already leaked
into an HVM domains idea of the world, 1 or 2 is probably a better
ladder to dig us out of this hole.
~Andrew.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH linux 3/8] x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op
On 28/06/16 17:47, Vitaly Kuznetsov wrote:
> 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.
>
> There is an issue, however. PV guests do VCPUOP_is_up very early
> (see xen_fill_possible_map() and xen_filter_cpu_maps()) when we don't have
> perpu areas initialized. While it could be solved with 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.
[...]
> static inline int
> HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args)
> {
> - return _hypercall3(int, vcpu_op, cmd, vcpuid, extra_args);
> + /*
> + * PV guests call HYPERVISOR_vcpu_op before percpu areas are
> + * initialized. As we always use direct mapping for vCPU ids
> + * for them we can simply use Linux vcpuid here.
> + */
> + return _hypercall3(int, vcpu_op, cmd,
> +per_cpu(xen_vcpu_id, vcpuid) != -1 ?
> +per_cpu(xen_vcpu_id, vcpuid) : vcpuid,
> +extra_args);
> }
HYPERVISOR_vcpu_op() should take Xen VCPUs, with the callers doing the
mapping.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 13/17] xen/arm: Use the typesafes mfn and gfn in map_dev_mmio_region...
Hi Andrew,
On 28/06/2016 18:21, Andrew Cooper wrote:
On 28/06/16 17:17, Julien Grall wrote:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index f11094e..5ffc3df 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1211,20 +1211,20 @@ int unmap_mmio_regions(struct domain *d,
}
int map_dev_mmio_region(struct domain *d,
-unsigned long start_gfn,
+gfn_t gfn,
unsigned long nr,
-unsigned long mfn)
+mfn_t mfn)
{
int res;
-if ( !(nr && iomem_access_permitted(d, mfn, mfn + nr - 1)) )
+if ( !(nr && iomem_access_permitted(d, mfn_x(mfn), mfn_x(mfn) + nr - 1)) )
return 0;
-res = map_mmio_regions(d, _gfn(start_gfn), nr, _mfn(mfn));
+res = map_mmio_regions(d, gfn, nr, mfn);
if ( res < 0 )
{
printk(XENLOG_G_ERR "Unable to map [%#lx - %#lx] in Dom%d\n",
%PRImfn
I would also recommend qualifying what is being mapped, so "to map mfns
[...".
Good idea, I will modify it in the next version.
Cheers,
--
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
Andrew Cooper writes:
> On 28/06/16 17:47, Vitaly Kuznetsov wrote:
>> @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block
>> *self, unsigned long action,
>> int cpu = (long)hcpu;
>> switch (action) {
>> case CPU_UP_PREPARE:
>> +/* vLAPIC_ID == Xen's vCPU_ID * 2 for HVM guests */
>> +per_cpu(xen_vcpu_id, cpu) = cpu_physical_id(cpu) / 2;
>
> Please do not assume or propagate this brokenness. It is incorrect in
> the general case, and I will be fixing in the hypervisor in due course.
>
> Always read the APIC_ID from the LAPIC, per regular hardware.
(I'm probbaly missing something important - please bear with me)
The problem here is that I need to get _other_ CPU's id before any code
is executed on that CPU (or, at least, this is the current state of
affairs if you look at xen_hvm_cpu_up()) so I can't use CPUID/do MSR
reads/... The only option I see here is to rely on ACPI (MADT) data
which is stored in x86_cpu_to_apicid (and that's what cpu_physical_id()
gives us). MADT also has processor id which connects it to DSDT but I'm
not sure Linux keeps this data. But this is something fixable I guess.
--
Vitaly
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] xen: arm: Update arm64 image header
On 29/06/2016 12:55, Dirk Behme wrote: On 29.06.2016 13:47, Julien Grall wrote: To be honest, the device-tree bindings does not mention any estimation (see [2]). I have noticed that some pages on the wiki use hardcoded DT (see [3]). So the documentation needs to be fixed. Which ignores the fact that it silently fails if the sizes don't match ;) The only thing I'm looking for is a helpful warning message :) Whilst I am usually happy to see helpful warning message. I don't want to see a warning message when the behavior is actually valid. There is no way to know whether the device tree has been crafted by the developer or generated by the firmware. So the only solution is to update the documentation about the device-tree bindings and hope that people will read the doc starting to boot Xen. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] xen: arm: Update arm64 image header
On 29.06.2016 13:47, Julien Grall wrote:
On 29/06/2016 12:31, Dirk Behme wrote:
On 29.06.2016 13:08, Dirk Behme wrote:
Hi Julien,
On 29.06.2016 12:32, Julien Grall wrote:
Hi Dirk,
On 27/06/2016 08:53, Dirk Behme wrote:
+if ( (end - start) > size ) {
+printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes >
bootmodule size: %lu bytes\n",
+ zimage.image_size, (uint64_t)size);
+printk(XENLOG_ERR "The field 'size' does not match the size
of blob!\n");
return -EINVAL;
+}
This patch is breaking boot on any ARM64 platform (UEFI and
bootwrapper).
Well, I wonder if it breaks because the kernel is too large? As
intended?
You are the expert on this, so I just can give my (limited?)
understanding:
In my use case, starting with the Xen development and not really knowing
the details, taking a random example from the net I had configured 10MB
in the device tree:
module@0x4820 {
compatible = "xen,linux-zimage", "xen,multiboot-module";
reg = <0x4820 0x00A0>; /* Max Image size 10MB */
};
This failed silently. No error message.
Without knowing any details, my first workaround was to make the kernel
smaller. Having a kernel Image smaller than 10MB worked, then.
While debugging it, I found that these 0x00A0 are used for 'size'.
And increasing it to 0x00F0 (15MB) does work for me, now.
I don't know anything aobut UEFI and bootwrapper,
Just a question: In case of UEFI and bootwrapper, does Xen know the
exact real file size of the Image file?
Yes.
Then that's the difference to the device tree case, where we don't know
the Image file size and use a max size estimation from the device tree.
What do you mean by "device tree case"? UEFI and bootwrapper are device
tree based. The latter will create the node in the device tree with the
correct size, whilst the former will directly fill Xen internal
structure (see arch/arm/efi).
Then we should limit the image_size error message to the device tree
case only. Ignoring the BSS overhead issue, as the size given by the
device tree is an estimation, anyhow.
Which firmware are you using? If you use u-boot, there are runes to
create the proper device-tree node on the wiki [1].
I'm trying to get it working with ATF. Therefore I think I used the hard
coded example from [3].
To be honest, the device-tree bindings does not mention any estimation
(see [2]). I have noticed that some pages on the wiki use hardcoded DT
(see [3]). So the documentation needs to be fixed.
Which ignores the fact that it silently fails if the sizes don't match ;)
The only thing I'm looking for is a helpful warning message :)
Regards,
[1]
http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions#Boot_Modules
[2]
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=8da1e0b8fcf9c9ed63cd45bd11f1a880288b;hb=HEAD
[3]
http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Lager
Best regards
Dirk
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] xen: arm: Update arm64 image header
On 29/06/2016 12:31, Dirk Behme wrote:
On 29.06.2016 13:08, Dirk Behme wrote:
Hi Julien,
On 29.06.2016 12:32, Julien Grall wrote:
Hi Dirk,
On 27/06/2016 08:53, Dirk Behme wrote:
+if ( (end - start) > size ) {
+printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes >
bootmodule size: %lu bytes\n",
+ zimage.image_size, (uint64_t)size);
+printk(XENLOG_ERR "The field 'size' does not match the size
of blob!\n");
return -EINVAL;
+}
This patch is breaking boot on any ARM64 platform (UEFI and
bootwrapper).
Well, I wonder if it breaks because the kernel is too large? As intended?
You are the expert on this, so I just can give my (limited?)
understanding:
In my use case, starting with the Xen development and not really knowing
the details, taking a random example from the net I had configured 10MB
in the device tree:
module@0x4820 {
compatible = "xen,linux-zimage", "xen,multiboot-module";
reg = <0x4820 0x00A0>; /* Max Image size 10MB */
};
This failed silently. No error message.
Without knowing any details, my first workaround was to make the kernel
smaller. Having a kernel Image smaller than 10MB worked, then.
While debugging it, I found that these 0x00A0 are used for 'size'.
And increasing it to 0x00F0 (15MB) does work for me, now.
I don't know anything aobut UEFI and bootwrapper,
Just a question: In case of UEFI and bootwrapper, does Xen know the
exact real file size of the Image file?
Yes.
Then that's the difference to the device tree case, where we don't know
the Image file size and use a max size estimation from the device tree.
What do you mean by "device tree case"? UEFI and bootwrapper are device
tree based. The latter will create the node in the device tree with the
correct size, whilst the former will directly fill Xen internal
structure (see arch/arm/efi).
Then we should limit the image_size error message to the device tree
case only. Ignoring the BSS overhead issue, as the size given by the
device tree is an estimation, anyhow.
Which firmware are you using? If you use u-boot, there are runes to
create the proper device-tree node on the wiki [1].
To be honest, the device-tree bindings does not mention any estimation
(see [2]). I have noticed that some pages on the wiki use hardcoded DT
(see [3]). So the documentation needs to be fixed.
Regards,
[1]
http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions#Boot_Modules
[2]
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=8da1e0b8fcf9c9ed63cd45bd11f1a880288b;hb=HEAD
[3]
http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Lager
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [V3] x86/cpuid: AVX-512 Feature Detection
From table 2-2 I can see that
AVX512F = AVX512F & AVX512VL
AVX512CD = AVX512F & AVX512VL & AVX512CD
AVX512DQ = AVX512F & AVX512VL & AVX512DQ
AVX512BW = AVX512F & AVX512VL & AVX512BW
AVX512IFMA = AVX512F & AVX512VL & AVX512IFMA
AVX512VBMI = AVX512F & AVX512VL & AVX512VBMI
From this depends list some AVX512 feature also depends on AVX512VL.
So the depends may like this:
AVX2: [AVX512F],
AVX512F: [AVX512DQ, AVX512IFMA, AVX512CD, AVX512BW, AVX512VBMI],
AVX512VL:[AVX512F, AVX512DQ, AVX512IFMA, AVX512CD, AVX512BW, AVX512VBMI]
But I have test on current hardware, this machine support AVX512F, AVX512PF,
AVX512ER and AVX512CD,
do not support AVX512VL. I think there may have some conflict between spec and
hardware.
The depends about AVX512VL should not add, or the AVX512 feature will not work.
So I think below depends is ok.
AVX2: [AVX512F],
AVX512F: [AVX512DQ, AVX512IFMA, AVX512PF, AVX512ER, AVX512CD,
AVX512BW, AVX512VL, AVX512VBMI],
Thanks,
Luwei Kang
-Original Message-
From: Kang, Luwei
Sent: Wednesday, June 29, 2016 7:28 PM
To: xen-devel@lists.xen.org
Cc: jbeul...@suse.com; andrew.coop...@citrix.com; Wang, Yong Y
; Peng, Chao P ; Kang, Luwei
Subject: [V3] x86/cpuid: AVX-512 Feature Detection
AVX-512 is an extention of AVX2. Its spec can be found at:
https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
This patch detects AVX-512 features by CPUID.
Signed-off-by: Luwei Kang
---
[V3]
1.adjust dependencies between features.
[V2]
1.one per bit, change from
> + xstate_size = max(xstate_size,
> + xstate_offsets[_XSTATE_HI_ZMM] +
> + xstate_sizes[_XSTATE_HI_ZMM]);
to
xstate_size = max(xstate_size,
xstate_offsets[_XSTATE_OPMASK] +
xstate_sizes[_XSTATE_OPMASK]);
xstate_size = max(xstate_size,
xstate_offsets[_XSTATE_ZMM] +
xstate_sizes[_XSTATE_ZMM]);
xstate_size = max(xstate_size,
xstate_offsets[_XSTATE_HI_ZMM] +
xstate_sizes[_XSTATE_HI_ZMM]); 2.change form
domain_cpuid(currd, 0x07, 0, &tmp, &_ebx, &tmp, &tmp);
to
domain_cpuid(currd, 7, 0, &tmp, &_ebx, &tmp, &tmp); 3.add dependencies
between features in xen/tools/gen-cpuid.py 4.split the cpuid call just like the
way the hvm_cpuid() side works.
xen/arch/x86/hvm/hvm.c | 14 ++
xen/arch/x86/traps.c| 22 +-
xen/include/public/arch-x86/cpufeatureset.h | 9 +
xen/tools/gen-cpuid.py | 11 +++
4 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index
c89ab6e..7696b1e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3474,6 +3474,20 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
unsigned int *ebx,
xstate_sizes[_XSTATE_BNDCSR]);
}
+if ( _ebx & cpufeat_mask(X86_FEATURE_AVX512F) )
+{
+xfeature_mask |= XSTATE_OPMASK | XSTATE_ZMM | XSTATE_HI_ZMM;
+xstate_size = max(xstate_size,
+ xstate_offsets[_XSTATE_OPMASK] +
+ xstate_sizes[_XSTATE_OPMASK]);
+xstate_size = max(xstate_size,
+ xstate_offsets[_XSTATE_ZMM] +
+ xstate_sizes[_XSTATE_ZMM]);
+xstate_size = max(xstate_size,
+ xstate_offsets[_XSTATE_HI_ZMM] +
+ xstate_sizes[_XSTATE_HI_ZMM]);
+}
+
if ( _ecx & cpufeat_mask(X86_FEATURE_PKU) )
{
xfeature_mask |= XSTATE_PKRU; diff --git
a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index 767d0b0..8fb697b 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -975,7 +975,7 @@ void pv_cpuid(struct cpu_user_regs *regs)
switch ( leaf )
{
-uint32_t tmp, _ecx;
+uint32_t tmp, _ecx, _ebx;
case 0x0001:
c &= pv_featureset[FEATURESET_1c]; @@ -1157,6 +1157,26 @@ void
pv_cpuid(struct cpu_user_regs *regs)
xstate_sizes[_XSTATE_YMM]);
}
+if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
+domain_cpuid(currd, 7, 0, &tmp, &_ebx, &tmp, &tmp);
+else
+cpuid_count(7, 0, &tmp, &_ebx, &tmp, &tmp);
+_ebx &= pv_featureset[FEATURESET_7b0];
+
+if ( _ebx & cpufeat_mask(X86_FEATURE_AVX512F) )
+{
+xfeature_mask |= XSTATE_OPMASK | XSTATE_ZMM | XSTATE_HI_ZMM;
+xstate_size = max(xstate_size,
+ xstate_offsets[_XSTATE_OPMASK] +
+ xstate_sizes[_XS
[Xen-devel] [qemu-upstream-4.3-testing test] 96353: regressions - FAIL
flight 96353 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/96353/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-build fail REGR. vs. 80927 build-i386-libvirt5 libvirt-build fail REGR. vs. 80927 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 96335 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 96335 like 80927 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 80927 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass version targeted for testing: qemuu12e8fccf5b5460be7aecddc71d27eceaba6e1f15 baseline version: qemuu10c1b763c26feb645627a1639e722515f3e1e876 Last test of basis80927 2016-02-06 13:30:02 Z 143 days Failing since 93977 2016-05-10 11:09:16 Z 50 days 155 attempts Testing same since95534 2016-06-11 00:59:46 Z 18 days 35 attempts People who touched revisions under test: Anthony PERARD Gerd Hoffmann Ian Jackson Stefano Stabellini Wei Liu jobs: build-amd64 pass build-i386 pass build-amd64-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-qemuu-rhel6hvm-amd 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-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-credit2 pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-xl-multivcpupass test-amd64-amd64-pairpass test-amd64-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-amd64-pvgrubpass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2pass test-amd64-i386-xl-raw pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-libvirt-vhd blocked test-amd64-amd64-xl-qemuu-winxpsp3 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit 12e8fccf5b5460be7aecddc71d27eceaba6e1f15 Author: Ian Jackson Date: Thu May 26 16:21:56 2016 +0100 main loop: Big hammer to fix logfile disk DoS in Xen setups Each t
Re: [Xen-devel] [PATCH v4] xen: arm: Update arm64 image header
Hi Julien,
On 29.06.2016 13:33, Julien Grall wrote:
On 29/06/2016 12:08, Dirk Behme wrote:
On 29.06.2016 12:32, Julien Grall wrote:
Hi Dirk,
On 27/06/2016 08:53, Dirk Behme wrote:
+if ( (end - start) > size ) {
+printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes >
bootmodule size: %lu bytes\n",
+ zimage.image_size, (uint64_t)size);
+printk(XENLOG_ERR "The field 'size' does not match the size
of blob!\n");
return -EINVAL;
+}
This patch is breaking boot on any ARM64 platform (UEFI and
bootwrapper).
Well, I wonder if it breaks because the kernel is too large? As intended?
Please read my previous e-mail, I gave an explanation why it breaks on
UEFI/bootwrapper.
To summarize, the field 'image_size' is the total size of the kernel in
memory BSS included. The section BSS is not included in the blob because
it is all zeros and it is a waste of disk space.
You are the expert on this, so I just can give my (limited?)
understanding:
In my use case, starting with the Xen development and not really knowing
the details, taking a random example from the net I had configured 10MB
in the device tree:
module@0x4820 {
compatible = "xen,linux-zimage", "xen,multiboot-module";
reg = <0x4820 0x00A0>; /* Max Image size 10MB */
};
This failed silently. No error message.
Without knowing any details, my first workaround was to make the kernel
smaller. Having a kernel Image smaller than 10MB worked, then.
While debugging it, I found that these 0x00A0 are used for 'size'.
And increasing it to 0x00F0 (15MB) does work for me, now.
I don't know anything aobut UEFI and bootwrapper, but could you check
the size given for 'size' and the real size of the kernel Image? What's
about if you increase 'size'?
(XEN) Loading kernel from boot module @ 8008
(XEN) Error: Kernel Image size: 16482304 bytes > bootmodule size:
15925760bytes
(XEN) The field 'size' does not match the size of blob!
For both UEFI and Bootwrapper, the bootmodule is created automatically
and the size of the Image on the disk (e.g BSS not included) is used.
Ok, yes, that answers my question from the previous mail. Thanks!
Yes, this check is there just to avoid the silent failing I observed. If
we have the error message, as I have implemented it, it would have saved
some debugging time for me ;) So it's not about using the size for real
loading, its just used for checking.
A short term workaround would be to convert the ERR into WARN and remove
the return.
This warning will always be printed for all the platform where the size
is retrieved from the firmware (e.g UEFI, GRUB).
As mentioned in my previous mail, we should not copy more than the size
of the bootmodule. Otherwise we may copy sensitive data in DOM0.
It's somehow my feeling that there might be an issue regarding the sizes
if the warning is there.
No, there is no issue. We misinterpreted the meaning of the field
'image_size'. In the case of Xen, the size should only be used for
placing the module.
Yes.
Then the device tree case I like to cover is special.
Would it be the solution to add an additional
if ( device_tree )
and maybe convert it to a warning?
Best regards
Dirk
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/cpuid: AVX-512 Feature Detection
On 29/06/16 11:03, Jan Beulich wrote:
On 29.06.16 at 11:50, wrote:
>> On 29/06/16 03:20, Luwei Kang wrote:
>>> --- a/xen/tools/gen-cpuid.py
>>> +++ b/xen/tools/gen-cpuid.py
>>> @@ -235,6 +235,10 @@ def crunch_numbers(state):
>>> # subsequent instruction groups may only be VEX encoded.
>>> AVX: [FMA, FMA4, F16C, AVX2, XOP],
>>>
>>> +# AVX-512 is an extention of AVX2 and it depends on AVX2 available.
>>> +AVX2: [AVX512F, AVX512DQ, AVX512IFMA, AVX512PF, AVX512ER, AVX512CD,
>>> +AVX512BW, AVX512VL, AVX512VBMI],
>> I think this needs adjusting. AVX512F is the base feature and
>> indication of extra xstate, while all other AVX512 features (e.g.
>> AVX512DQ) are explicitly documented not needing to check for AVX512F if
>> the AVX512DQ bit is present.
> I think the "not" here is wrong? At least my copy (rev 024) requires
> all involved feature bits to be checked (see e.g. table 2-2 or the
> individual instruction pages).
Hmm - yet another inconsistency. Some instructions specify a CPUID
dependency for just AVX512F (EVEX.NDS.512.66.0F.W1 C2 /r ib VCMPPD k1
{k2}, zmm2, zmm3/m512/m64bcst{sae}, imm8), some for AVX512F and a second
feature (EVEX.256.66.0F38.W1 19 /r VBROADCASTSD ymm1 {k1}{z}, xmm2/m64)
, and some only for the second feature (EVEX.512.66.0F.W0 79 /r
VCVTPS2UQQ zmm1 {k1}{z}, ymm2/m256/m32bcst{er})
FWIW, I still think the dependency expression is ok in its current form.
>
>> I think it wants to look something like:
>>
>> # AVX2 is an extension to AVX, providing mainly new integer instructions.
>> # In principle, AVX512 only depends on YMM register state, but many AVX2
> DYM ZMM register state here?
No. AVX512 introduces ZMM registers.
To enable ZMM registers (and opmask) , YMM must be enabled in %xcr0, and
this is the dependency I am talking about.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] xen: arm: Update arm64 image header
On 29/06/2016 12:08, Dirk Behme wrote:
On 29.06.2016 12:32, Julien Grall wrote:
Hi Dirk,
On 27/06/2016 08:53, Dirk Behme wrote:
+if ( (end - start) > size ) {
+printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes >
bootmodule size: %lu bytes\n",
+ zimage.image_size, (uint64_t)size);
+printk(XENLOG_ERR "The field 'size' does not match the size
of blob!\n");
return -EINVAL;
+}
This patch is breaking boot on any ARM64 platform (UEFI and
bootwrapper).
Well, I wonder if it breaks because the kernel is too large? As intended?
Please read my previous e-mail, I gave an explanation why it breaks on
UEFI/bootwrapper.
To summarize, the field 'image_size' is the total size of the kernel in
memory BSS included. The section BSS is not included in the blob because
it is all zeros and it is a waste of disk space.
You are the expert on this, so I just can give my (limited?) understanding:
In my use case, starting with the Xen development and not really knowing
the details, taking a random example from the net I had configured 10MB
in the device tree:
module@0x4820 {
compatible = "xen,linux-zimage", "xen,multiboot-module";
reg = <0x4820 0x00A0>; /* Max Image size 10MB */
};
This failed silently. No error message.
Without knowing any details, my first workaround was to make the kernel
smaller. Having a kernel Image smaller than 10MB worked, then.
While debugging it, I found that these 0x00A0 are used for 'size'.
And increasing it to 0x00F0 (15MB) does work for me, now.
I don't know anything aobut UEFI and bootwrapper, but could you check
the size given for 'size' and the real size of the kernel Image? What's
about if you increase 'size'?
(XEN) Loading kernel from boot module @ 8008
(XEN) Error: Kernel Image size: 16482304 bytes > bootmodule size:
15925760bytes
(XEN) The field 'size' does not match the size of blob!
For both UEFI and Bootwrapper, the bootmodule is created automatically
and the size of the Image on the disk (e.g BSS not included) is used.
Yes, this check is there just to avoid the silent failing I observed. If
we have the error message, as I have implemented it, it would have saved
some debugging time for me ;) So it's not about using the size for real
loading, its just used for checking.
A short term workaround would be to convert the ERR into WARN and remove
the return.
This warning will always be printed for all the platform where the size
is retrieved from the firmware (e.g UEFI, GRUB).
As mentioned in my previous mail, we should not copy more than the size
of the bootmodule. Otherwise we may copy sensitive data in DOM0.
It's somehow my feeling that there might be an issue regarding the sizes
if the warning is there.
No, there is no issue. We misinterpreted the meaning of the field
'image_size'. In the case of Xen, the size should only be used for
placing the module.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] xen: arm: Update arm64 image header
On 29.06.2016 13:08, Dirk Behme wrote:
Hi Julien,
On 29.06.2016 12:32, Julien Grall wrote:
Hi Dirk,
On 27/06/2016 08:53, Dirk Behme wrote:
+if ( (end - start) > size ) {
+printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes >
bootmodule size: %lu bytes\n",
+ zimage.image_size, (uint64_t)size);
+printk(XENLOG_ERR "The field 'size' does not match the size
of blob!\n");
return -EINVAL;
+}
This patch is breaking boot on any ARM64 platform (UEFI and
bootwrapper).
Well, I wonder if it breaks because the kernel is too large? As intended?
You are the expert on this, so I just can give my (limited?) understanding:
In my use case, starting with the Xen development and not really knowing
the details, taking a random example from the net I had configured 10MB
in the device tree:
module@0x4820 {
compatible = "xen,linux-zimage", "xen,multiboot-module";
reg = <0x4820 0x00A0>; /* Max Image size 10MB */
};
This failed silently. No error message.
Without knowing any details, my first workaround was to make the kernel
smaller. Having a kernel Image smaller than 10MB worked, then.
While debugging it, I found that these 0x00A0 are used for 'size'.
And increasing it to 0x00F0 (15MB) does work for me, now.
I don't know anything aobut UEFI and bootwrapper,
Just a question: In case of UEFI and bootwrapper, does Xen know the
exact real file size of the Image file?
Then that's the difference to the device tree case, where we don't know
the Image file size and use a max size estimation from the device tree.
Then we should limit the image_size error message to the device tree
case only. Ignoring the BSS overhead issue, as the size given by the
device tree is an estimation, anyhow.
Best regards
Dirk
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [V3] x86/cpuid: AVX-512 Feature Detection
AVX-512 is an extention of AVX2. Its spec can be found at:
https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
This patch detects AVX-512 features by CPUID.
Signed-off-by: Luwei Kang
---
[V3]
1.adjust dependencies between features.
[V2]
1.one per bit, change from
> + xstate_size = max(xstate_size,
> + xstate_offsets[_XSTATE_HI_ZMM] +
> + xstate_sizes[_XSTATE_HI_ZMM]);
to
xstate_size = max(xstate_size,
xstate_offsets[_XSTATE_OPMASK] +
xstate_sizes[_XSTATE_OPMASK]);
xstate_size = max(xstate_size,
xstate_offsets[_XSTATE_ZMM] +
xstate_sizes[_XSTATE_ZMM]);
xstate_size = max(xstate_size,
xstate_offsets[_XSTATE_HI_ZMM] +
xstate_sizes[_XSTATE_HI_ZMM]);
2.change form
domain_cpuid(currd, 0x07, 0, &tmp, &_ebx, &tmp, &tmp);
to
domain_cpuid(currd, 7, 0, &tmp, &_ebx, &tmp, &tmp);
3.add dependencies between features in xen/tools/gen-cpuid.py
4.split the cpuid call just like the way the hvm_cpuid() side works.
xen/arch/x86/hvm/hvm.c | 14 ++
xen/arch/x86/traps.c| 22 +-
xen/include/public/arch-x86/cpufeatureset.h | 9 +
xen/tools/gen-cpuid.py | 11 +++
4 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c89ab6e..7696b1e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3474,6 +3474,20 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
unsigned int *ebx,
xstate_sizes[_XSTATE_BNDCSR]);
}
+if ( _ebx & cpufeat_mask(X86_FEATURE_AVX512F) )
+{
+xfeature_mask |= XSTATE_OPMASK | XSTATE_ZMM | XSTATE_HI_ZMM;
+xstate_size = max(xstate_size,
+ xstate_offsets[_XSTATE_OPMASK] +
+ xstate_sizes[_XSTATE_OPMASK]);
+xstate_size = max(xstate_size,
+ xstate_offsets[_XSTATE_ZMM] +
+ xstate_sizes[_XSTATE_ZMM]);
+xstate_size = max(xstate_size,
+ xstate_offsets[_XSTATE_HI_ZMM] +
+ xstate_sizes[_XSTATE_HI_ZMM]);
+}
+
if ( _ecx & cpufeat_mask(X86_FEATURE_PKU) )
{
xfeature_mask |= XSTATE_PKRU;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 767d0b0..8fb697b 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -975,7 +975,7 @@ void pv_cpuid(struct cpu_user_regs *regs)
switch ( leaf )
{
-uint32_t tmp, _ecx;
+uint32_t tmp, _ecx, _ebx;
case 0x0001:
c &= pv_featureset[FEATURESET_1c];
@@ -1157,6 +1157,26 @@ void pv_cpuid(struct cpu_user_regs *regs)
xstate_sizes[_XSTATE_YMM]);
}
+if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
+domain_cpuid(currd, 7, 0, &tmp, &_ebx, &tmp, &tmp);
+else
+cpuid_count(7, 0, &tmp, &_ebx, &tmp, &tmp);
+_ebx &= pv_featureset[FEATURESET_7b0];
+
+if ( _ebx & cpufeat_mask(X86_FEATURE_AVX512F) )
+{
+xfeature_mask |= XSTATE_OPMASK | XSTATE_ZMM | XSTATE_HI_ZMM;
+xstate_size = max(xstate_size,
+ xstate_offsets[_XSTATE_OPMASK] +
+ xstate_sizes[_XSTATE_OPMASK]);
+xstate_size = max(xstate_size,
+ xstate_offsets[_XSTATE_ZMM] +
+ xstate_sizes[_XSTATE_ZMM]);
+xstate_size = max(xstate_size,
+ xstate_offsets[_XSTATE_HI_ZMM] +
+ xstate_sizes[_XSTATE_HI_ZMM]);
+}
+
a = (uint32_t)xfeature_mask;
d = (uint32_t)(xfeature_mask >> 32);
c = xstate_size;
diff --git a/xen/include/public/arch-x86/cpufeatureset.h
b/xen/include/public/arch-x86/cpufeatureset.h
index 39acf8c..9320c9e 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -206,15 +206,24 @@ XEN_CPUFEATURE(PQM, 5*32+12) /* Platform QoS
Monitoring */
XEN_CPUFEATURE(NO_FPU_SEL,5*32+13) /*! FPU CS/DS stored as zero */
XEN_CPUFEATURE(MPX, 5*32+14) /*S Memory Protection Extensions */
XEN_CPUFEATURE(PQE, 5*32+15) /* Platform QoS Enforcement */
+XEN_CPUFEATURE(AVX512F, 5*32+16) /*A AVX-512 Foundation Instructions */
+XEN_CPUFEATURE(AVX512DQ, 5*32+17) /*A AVX-512 Doubleword & Quadword
Instrs */
XEN_CPUFEATURE(RDSEED,5*32+18) /*A RD
Re: [Xen-devel] [PATCH v4] xen: arm: Update arm64 image header
On 29.06.2016 13:08, Dirk Behme wrote:
Hi Julien,
On 29.06.2016 12:32, Julien Grall wrote:
Hi Dirk,
On 27/06/2016 08:53, Dirk Behme wrote:
+if ( (end - start) > size ) {
+printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes >
bootmodule size: %lu bytes\n",
+ zimage.image_size, (uint64_t)size);
+printk(XENLOG_ERR "The field 'size' does not match the size
of blob!\n");
return -EINVAL;
+}
This patch is breaking boot on any ARM64 platform (UEFI and
bootwrapper).
Well, I wonder if it breaks because the kernel is too large? As intended?
You are the expert on this, so I just can give my (limited?) understanding:
In my use case, starting with the Xen development and not really knowing
the details, taking a random example from the net I had configured 10MB
in the device tree:
module@0x4820 {
compatible = "xen,linux-zimage", "xen,multiboot-module";
reg = <0x4820 0x00A0>; /* Max Image size 10MB */
};
This failed silently. No error message.
Without knowing any details, my first workaround was to make the kernel
smaller. Having a kernel Image smaller than 10MB worked, then.
While debugging it, I found that these 0x00A0 are used for 'size'.
And increasing it to 0x00F0 (15MB) does work for me, now.
I don't know anything aobut UEFI and bootwrapper, but could you check
the size given for 'size' and the real size of the kernel Image? What's
about if you increase 'size'?
Yes, this check is there just to avoid the silent failing I observed. If
we have the error message, as I have implemented it, it would have saved
some debugging time for me ;) So it's not about using the size for real
loading, its just used for checking.
A short term workaround would be to convert the ERR into WARN and remove
the return.
It's somehow my feeling that there might be an issue regarding the sizes
if the warning is there.
Just fyi, with
13517824 arch/arm64/boot/Image
and a quick printk I get
(XEN) -> image_size: 13807616 bytes
So, yes, image_size is ~300k larger than the file size. Yes, that might
be due to the BSS.
Best regards
Dirk
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Domain creation errors
On 29/06/16 12:11, Tim Deegan wrote: > At 03:55 -0600 on 29 Jun (1467172554), Jan Beulich wrote: > On 28.06.16 at 20:56, wrote: >>> Using PTR_ERR() is less disruptive to the code, but will cause >>> collateral damage for anyone with out-of-tree patches, as the code will >>> compile but the error logic will be wrong. The use of PTR_ERR() is also >>> quite dangerous in the context of a PV guest, as the resulting pointer >>> is under 64bit guest ABI control. >>> >>> I am leaning towards the first option, which at least has the advantage >>> that any out-of-tree code will break in an obvious way. >>> >>> Any opinions or alternate suggestions? >> To be honest I'm not worried much about out of tree code, and >> the err.h abstractions are precisely for cases like this. So I'm for >> the PTR_ERR() variant. > +1, FWIW. Can the x86_64/PV problem be avoided by using non-canonical > error addresses? I can look into that, but it will definitely complicate the PTR_ERR() handling. Linux gets away with the status quo as the pointers which are actually error integers fall into kernel-controlled memory. The other reason I am hesitant about PTR_ERR() is that it obfuscates the semantics sufficiently for Coverity to give up. As Coverity has found legitimate issues with the use of alloc_domheap_pages() in the past, I am hesitant to make things harder to interpret. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 96364: tolerable FAIL - PUSHED
flight 96364 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96364/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
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-libvirt-qcow2 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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
version targeted for testing:
libvirt ca5d51df27567ef8d77c126815d01c484deb359f
baseline version:
libvirt 0b4645a7e061abc8a4be71fe89865cf248ce6e56
Last test of basis96299 2016-06-27 04:21:09 Z2 days
Failing since 96333 2016-06-28 04:21:58 Z1 days2 attempts
Testing same since96364 2016-06-29 04:26:58 Z0 days1 attempts
People who touched revisions under test:
Andrea Bolognani
Jaroslav Suchanek
Jiri Denemark
Ján Tomko
Michal Privoznik
Olga Krishtal
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=ca5d51df27567ef8d77c126815d01c484deb359f
+ . ./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
++ e
Re: [Xen-devel] Domain creation errors
At 03:55 -0600 on 29 Jun (1467172554), Jan Beulich wrote: > >>> On 28.06.16 at 20:56, wrote: > > Using PTR_ERR() is less disruptive to the code, but will cause > > collateral damage for anyone with out-of-tree patches, as the code will > > compile but the error logic will be wrong. The use of PTR_ERR() is also > > quite dangerous in the context of a PV guest, as the resulting pointer > > is under 64bit guest ABI control. > > > > I am leaning towards the first option, which at least has the advantage > > that any out-of-tree code will break in an obvious way. > > > > Any opinions or alternate suggestions? > > To be honest I'm not worried much about out of tree code, and > the err.h abstractions are precisely for cases like this. So I'm for > the PTR_ERR() variant. +1, FWIW. Can the x86_64/PV problem be avoided by using non-canonical error addresses? Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] xen: arm: Update arm64 image header
Hi Julien,
On 29.06.2016 12:32, Julien Grall wrote:
Hi Dirk,
On 27/06/2016 08:53, Dirk Behme wrote:
+if ( (end - start) > size ) {
+printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes >
bootmodule size: %lu bytes\n",
+ zimage.image_size, (uint64_t)size);
+printk(XENLOG_ERR "The field 'size' does not match the size
of blob!\n");
return -EINVAL;
+}
This patch is breaking boot on any ARM64 platform (UEFI and
bootwrapper).
Well, I wonder if it breaks because the kernel is too large? As intended?
You are the expert on this, so I just can give my (limited?) understanding:
In my use case, starting with the Xen development and not really knowing
the details, taking a random example from the net I had configured 10MB
in the device tree:
module@0x4820 {
compatible = "xen,linux-zimage", "xen,multiboot-module";
reg = <0x4820 0x00A0>; /* Max Image size 10MB */
};
This failed silently. No error message.
Without knowing any details, my first workaround was to make the kernel
smaller. Having a kernel Image smaller than 10MB worked, then.
While debugging it, I found that these 0x00A0 are used for 'size'.
And increasing it to 0x00F0 (15MB) does work for me, now.
I don't know anything aobut UEFI and bootwrapper, but could you check
the size given for 'size' and the real size of the kernel Image? What's
about if you increase 'size'?
Yes, this check is there just to avoid the silent failing I observed. If
we have the error message, as I have implemented it, it would have saved
some debugging time for me ;) So it's not about using the size for real
loading, its just used for checking.
A short term workaround would be to convert the ERR into WARN and remove
the return.
It's somehow my feeling that there might be an issue regarding the sizes
if the warning is there.
But maybe I'm totally wrong ;)
Best regards
Dirk
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 96330: regressions - trouble: blocked/broken/fail/pass
Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 96330: regressions -
trouble: blocked/broken/fail/pass"):
> On 28.06.16 at 21:16, wrote:
> This latter one is
>
> objcopy -S -I binary -O elf64-little --rename-section=.data=.init.xsm_policy
> policy.bin policy.o
...
> :policy.o: Invalid bfd target
> Makefile:45: recipe for target 'policy.o' failed
> make[5]: Leaving directory
> '/home/osstest/build.96330.build-armhf-xsm/xen/xen/xsm/flask'
> make[5]: *** [policy.o] Error 1
>
> which looks to be the not really suitable use of elf64-little in
> commit 08cffe6696 ("xsm: add a default policy to .init.data").
> Since it's not immediately clear how to fix this preferably
> without ugly ifdef-ery in the makefile, I think we better revert
> this for now. Opinions?
Yes, I think reverting it for now is the right answer.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 96368: regressions - FAIL
flight 96368 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96368/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 94748 build-amd64-xsm 5 xen-build fail REGR. vs. 94748 build-amd64 5 xen-build fail REGR. vs. 94748 build-i3865 xen-build fail REGR. vs. 94748 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 89b206573965e9604c534cc1ef468ecd58e1b4d4 baseline version: ovmf dc99315b8732b6e3032d01319d3f534d440b43d0 Last test of basis94748 2016-05-24 22:43:25 Z 35 days Failing since 94750 2016-05-25 03:43:08 Z 35 days 63 attempts Testing same since96368 2016-06-29 08:45:08 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 fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7593 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-coverity test] 96369: all pass - PUSHED
flight 96369 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96369/
Perfect :-)
All tests in this flight passed
version targeted for testing:
xen 3cdad93704aaa8bf1f274969e401ca21152bc4a2
baseline version:
xen 8384dc2d95538c5910d98db3df3ff5448bf0af48
Last test of basis96284 2016-06-26 09:26:17 Z3 days
Testing same since96369 2016-06-29 09:19:11 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:
coverity-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-coverity
+ revision=3cdad93704aaa8bf1f274969e401ca21152bc4a2
+ . ./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-coverity 3cdad93704aaa8bf1f274969e401ca21152bc4a2
+ branch=xen-unstable-coverity
+ revision=3cdad93704aaa8bf1f274969e401ca21152bc4a2
+ . ./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-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-4.7-testing
+ '[' x3cdad93704aaa8bf1f274969e401ca21152bc4a2 = 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
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ :
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/
Re: [Xen-devel] [PATCH v4] xen: arm: Update arm64 image header
Hi Dirk,
On 27/06/2016 08:53, Dirk Behme wrote:
+if ( (end - start) > size ) {
+printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes > bootmodule size:
%lu bytes\n",
+ zimage.image_size, (uint64_t)size);
+printk(XENLOG_ERR "The field 'size' does not match the size of
blob!\n");
return -EINVAL;
+}
This patch is breaking boot on any ARM64 platform (UEFI and
bootwrapper). The 'image_size' is the size of the kernel with BSS
included. So the bootmodule will always be smaller than 'image_size'.
(XEN) Loading kernel from boot module @ 8008
(XEN) Error: Kernel Image size: 16482304 bytes > bootmodule size:
15925760bytes
(XEN) The field 'size' does not match the size of blob!
So I think this field is intended to be used to tell the bootloader that
kernel footprint will "image_size". So the bootloader will not attempt
to place any modules (DT, ramdisk...) within this region.
We don't want to use this field to copy the kernel because we may end up
to copy extra memory which could contain sensitive data.
Given that the main purpose of this patch is to use the field
'image_size', I would just revert the patch until we figured out what to do.
Dirk, as this patch is meant to be ARM64 only, I am wondering how you
were able to boot DOM0 with the patch applied.
Currently the pushgate for ARM64 is only build testing, so I should have
tested this patch before giving my ack. I am sorry for that.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 96351: regressions - FAIL
flight 96351 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/96351/ 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-credit2 15 guest-start/debian.repeat fail REGR. vs. 96296 Regressions which are regarded as allowable (not blocking): 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-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-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 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-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 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-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-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-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: xen 9b15b2e367a8565c73d5ba975e05c89c99078e60 baseline version: xen 8384dc2d95538c5910d98db3df3ff5448bf0af48 Last test of basis96296 2016-06-27 01:55:48 Z2 days Failing since 96315 2016-06-27 14:13:25 Z1 days3 attempts Testing same since96351 2016-06-28 19:45:10 Z0 days1 attempts People who touched revisions under test: Daniel De Graaf Julien Grall Kevin Tian Quan Xu Razvan Cojocaru 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 pass build-armhf-libvirt pass build-i386-libvirt pass
Re: [Xen-devel] repeating 'd1v0 Over-allocation for domain 1' messages in xen 4.7 Host logs on PVHVM Guest launch
>>> On 29.06.16 at 02:06, wrote: > What are these 'Over-allocation' messages? An indication of the guest trying to allocate more memory that the host admin has allowed. > What needs to be fixed, or if of no concern, can these messages be silenced? Perhaps something wrong in the guest's balloon driver. As to silencing - the message already is a guest one at info level, i.e. not going to get issued at all with default settings. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/cpuid: AVX-512 Feature Detection
>>> On 29.06.16 at 11:50, wrote: > On 29/06/16 03:20, Luwei Kang wrote: >> --- a/xen/tools/gen-cpuid.py >> +++ b/xen/tools/gen-cpuid.py >> @@ -235,6 +235,10 @@ def crunch_numbers(state): >> # subsequent instruction groups may only be VEX encoded. >> AVX: [FMA, FMA4, F16C, AVX2, XOP], >> >> +# AVX-512 is an extention of AVX2 and it depends on AVX2 available. >> +AVX2: [AVX512F, AVX512DQ, AVX512IFMA, AVX512PF, AVX512ER, AVX512CD, >> +AVX512BW, AVX512VL, AVX512VBMI], > > I think this needs adjusting. AVX512F is the base feature and > indication of extra xstate, while all other AVX512 features (e.g. > AVX512DQ) are explicitly documented not needing to check for AVX512F if > the AVX512DQ bit is present. I think the "not" here is wrong? At least my copy (rev 024) requires all involved feature bits to be checked (see e.g. table 2-2 or the individual instruction pages). > I think it wants to look something like: > > # AVX2 is an extension to AVX, providing mainly new integer instructions. > # In principle, AVX512 only depends on YMM register state, but many AVX2 DYM ZMM register state here? Jan > # instructions are extended by AVX512F to 512-bit forms. > AVX2: [AVX512F], > > # AVX512F is taken to mean hardware support for EVEX encoded instructions, > # 512bit registers, and the instructions themselves. All further AVX512 > features > # are built on top of AVX512F. > AVX512F: [AVX512DQ, AVX512IFMA, AVX512PF, AVX512ER, AVX512CD, > AVX512BW, AVX512VL, AVX512VBMI], > > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Domain creation errors
>>> On 28.06.16 at 20:56, wrote:
> On 28/06/16 18:56, Andrew Cooper wrote:
>>
>>
>> This is the first in a number of changes trying to clean up error reporting
> of
>> memory conditions.
>
> One area which is constantly causing problems is creation of domains in
> low memory conditions. In the case where the toolstack gets its
> calculations wrong, it is very difficult to diagnose what precicely went
> wrong, for a number of reasons.
>
> The error handling in xc_domain_populate_physmap_exact() looks like
>
> if ( err >= 0 )
> {
> DPRINTF("Failed allocation for dom %d: %ld extents of order %d\n",
> domid, nr_extents, extent_order);
> errno = EBUSY;
> err = -1;
> }
>
> which hides any error whatsoever behind an -EBUSY.
>
> The reason for this is that the hypercall interface for
> XENMEM_populate_physmap identifies which extent failed, but not why it
> failed. (Actually, there are plenty of errors which are accounted
> against "the next extent", rather than being directly caused by that
> extent).
>
>
> The error conditions I want to be able to distinguish are "Xen is
> completely out of memory", and "You are trying to add memory to a domain
> beyond its allotted limit". The former indicates that a toolstacks
> logic to account overall memory is problematic, while the latter
> indicates a mismatch between different toolstack areas. Sadly, both end
> up as -EBUSY.
>
> The first problem to solve is that alloc_domheap_pages() can't
> distinguish the errors. Two returns from it are legitimately an
> indication of ENOMEM, but the assign_pages() failure is specifically
> not. Returning a struct page_info pointer is unhelpful at
> distinguishing the issues.
>
> I have thought of two approaches, but its hard to decide between them.
>
> First is to change alloc_domheap_pages() prototype to
>
> int alloc_domheap_pages(struct domain *d, unsigned int order, unsigned
> int memflags, struct page_info *out);
>
> while the second is to use PTR_ERR().
>
> Using PTR_ERR() is less disruptive to the code, but will cause
> collateral damage for anyone with out-of-tree patches, as the code will
> compile but the error logic will be wrong. The use of PTR_ERR() is also
> quite dangerous in the context of a PV guest, as the resulting pointer
> is under 64bit guest ABI control.
>
> I am leaning towards the first option, which at least has the advantage
> that any out-of-tree code will break in an obvious way.
>
> Any opinions or alternate suggestions?
To be honest I'm not worried much about out of tree code, and
the err.h abstractions are precisely for cases like this. So I'm for
the PTR_ERR() variant.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/cpuid: AVX-512 Feature Detection
On 29/06/16 10:50, Andrew Cooper wrote: > On 29/06/16 03:20, Luwei Kang wrote: >> diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py >> index 7c45eca..897e660 100755 >> --- a/xen/tools/gen-cpuid.py >> +++ b/xen/tools/gen-cpuid.py >> @@ -235,6 +235,10 @@ def crunch_numbers(state): >> # subsequent instruction groups may only be VEX encoded. >> AVX: [FMA, FMA4, F16C, AVX2, XOP], >> >> +# AVX-512 is an extention of AVX2 and it depends on AVX2 available. >> +AVX2: [AVX512F, AVX512DQ, AVX512IFMA, AVX512PF, AVX512ER, AVX512CD, >> +AVX512BW, AVX512VL, AVX512VBMI], > I think this needs adjusting. AVX512F is the base feature and > indication of extra xstate, while all other AVX512 features (e.g. > AVX512DQ) are explicitly documented not needing to check for AVX512F if > the AVX512DQ bit is present. > > I think it wants to look something like: > > # AVX2 is an extension to AVX, providing mainly new integer instructions. > # In principle, AVX512 only depends on YMM register state, but many AVX2 > # instructions are extended by AVX512F to 512-bit forms. > AVX2: [AVX512F], > > # AVX512F is taken to mean hardware support for EVEX encoded instructions, > # 512bit registers, and the instructions themselves. All further AVX512 > features > # are built on top of AVX512F. > AVX512F: [AVX512DQ, AVX512IFMA, AVX512PF, AVX512ER, AVX512CD, > AVX512BW, AVX512VL, AVX512VBMI], P.S. Please sort that dictionary by the integer value of the key, so AVX2 and AVX512F should be after _3DNOW. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/page_alloc: Distinguish different errors from assign_pages()
>>> On 28.06.16 at 19:58, wrote: > On 28/06/16 18:56, Andrew Cooper wrote: >> assign_pages() has a return type of int, but uses for a boolean value. As >> there are two distinct failure cases, return a more meaningful error. > > Sorry - sent an out of date version. This sentence actually reads > > assign_pages() has a return type of int, but only returns 0 or -1. As there > are two distinct failure cases, return a more meaningful error. Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/cpuid: AVX-512 Feature Detection
On 29/06/16 03:20, Luwei Kang wrote:
> AVX-512 is an extention of AVX2. Its spec can be found at:
> https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
> This patch detects AVX-512 features by CPUID.
>
> Signed-off-by: Luwei Kang
> ---
> xen/arch/x86/hvm/hvm.c | 14 ++
> xen/arch/x86/traps.c| 22 +-
> xen/include/public/arch-x86/cpufeatureset.h | 9 +
> xen/tools/gen-cpuid.py | 4
> 4 files changed, 48 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index c89ab6e..7696b1e 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3474,6 +3474,20 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
> unsigned int *ebx,
>xstate_sizes[_XSTATE_BNDCSR]);
> }
>
> +if ( _ebx & cpufeat_mask(X86_FEATURE_AVX512F) )
> +{
> +xfeature_mask |= XSTATE_OPMASK | XSTATE_ZMM | XSTATE_HI_ZMM;
> +xstate_size = max(xstate_size,
> + xstate_offsets[_XSTATE_OPMASK] +
> + xstate_sizes[_XSTATE_OPMASK]);
> +xstate_size = max(xstate_size,
> + xstate_offsets[_XSTATE_ZMM] +
> + xstate_sizes[_XSTATE_ZMM]);
> +xstate_size = max(xstate_size,
> + xstate_offsets[_XSTATE_HI_ZMM] +
> + xstate_sizes[_XSTATE_HI_ZMM]);
> +}
> +
> if ( _ecx & cpufeat_mask(X86_FEATURE_PKU) )
> {
> xfeature_mask |= XSTATE_PKRU;
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 767d0b0..8fb697b 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -975,7 +975,7 @@ void pv_cpuid(struct cpu_user_regs *regs)
>
> switch ( leaf )
> {
> -uint32_t tmp, _ecx;
> +uint32_t tmp, _ecx, _ebx;
>
> case 0x0001:
> c &= pv_featureset[FEATURESET_1c];
> @@ -1157,6 +1157,26 @@ void pv_cpuid(struct cpu_user_regs *regs)
> xstate_sizes[_XSTATE_YMM]);
> }
>
> +if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
> +domain_cpuid(currd, 7, 0, &tmp, &_ebx, &tmp, &tmp);
> +else
> +cpuid_count(7, 0, &tmp, &_ebx, &tmp, &tmp);
> +_ebx &= pv_featureset[FEATURESET_7b0];
> +
> +if ( _ebx & cpufeat_mask(X86_FEATURE_AVX512F) )
> +{
> +xfeature_mask |= XSTATE_OPMASK | XSTATE_ZMM | XSTATE_HI_ZMM;
> +xstate_size = max(xstate_size,
> + xstate_offsets[_XSTATE_OPMASK] +
> + xstate_sizes[_XSTATE_OPMASK]);
> +xstate_size = max(xstate_size,
> + xstate_offsets[_XSTATE_ZMM] +
> + xstate_sizes[_XSTATE_ZMM]);
> +xstate_size = max(xstate_size,
> + xstate_offsets[_XSTATE_HI_ZMM] +
> + xstate_sizes[_XSTATE_HI_ZMM]);
> +}
> +
> a = (uint32_t)xfeature_mask;
> d = (uint32_t)(xfeature_mask >> 32);
> c = xstate_size;
> diff --git a/xen/include/public/arch-x86/cpufeatureset.h
> b/xen/include/public/arch-x86/cpufeatureset.h
> index 39acf8c..9320c9e 100644
> --- a/xen/include/public/arch-x86/cpufeatureset.h
> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> @@ -206,15 +206,24 @@ XEN_CPUFEATURE(PQM, 5*32+12) /* Platform
> QoS Monitoring */
> XEN_CPUFEATURE(NO_FPU_SEL,5*32+13) /*! FPU CS/DS stored as zero */
> XEN_CPUFEATURE(MPX, 5*32+14) /*S Memory Protection Extensions */
> XEN_CPUFEATURE(PQE, 5*32+15) /* Platform QoS Enforcement */
> +XEN_CPUFEATURE(AVX512F, 5*32+16) /*A AVX-512 Foundation Instructions
> */
> +XEN_CPUFEATURE(AVX512DQ, 5*32+17) /*A AVX-512 Doubleword & Quadword
> Instrs */
> XEN_CPUFEATURE(RDSEED,5*32+18) /*A RDSEED instruction */
> XEN_CPUFEATURE(ADX, 5*32+19) /*A ADCX, ADOX instructions */
> XEN_CPUFEATURE(SMAP, 5*32+20) /*S Supervisor Mode Access
> Prevention */
> +XEN_CPUFEATURE(AVX512IFMA,5*32+21) /*A AVX-512 Integer Fused Multiply
> Add */
> XEN_CPUFEATURE(CLFLUSHOPT,5*32+23) /*A CLFLUSHOPT instruction */
> XEN_CPUFEATURE(CLWB, 5*32+24) /*A CLWB instruction */
> +XEN_CPUFEATURE(AVX512PF, 5*32+26) /*A AVX-512 Prefetch Instructions */
> +XEN_CPUFEATURE(AVX512ER, 5*32+27) /*A AVX-512 Exponent & Reciprocal
> Instrs */
> +XEN_CPUFEATURE(AVX512CD, 5*32+28) /*A AVX-512 Conflict Detection
> Instrs */
> XEN_CPUFEATURE(SHA, 5*32+29) /*A SHA1 &
