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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 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-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1)

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf e18792566c7fb1335e705c3b19334db9271eac90
baseline version:
 ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb

Last test of basis   145767  2020-01-08 00:39:09 Z2 days
Failing since145774  2020-01-08 02:50:20 Z2 days   11 attempts
Testing same since   145902  2020-01-10 02:52:50 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Ashish Singhal 
  Eric Dong 
  Laszlo Ersek 
  Pavana.K 
  Philippe Mathieu-Daud? 
  Philippe Mathieu-Daude 
  Siyuan Fu 
  Siyuan, Fu 

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



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

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

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

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


Not pushing.


commit e18792566c7fb1335e705c3b19334db9271eac90
Author: Eric Dong 
Date:   Thu Jan 9 13:21:36 2020 +0800

UefiCpuPkg/PiSmmCpuDxeSmm: Add missed comments for parameter.

This issue caused by below change:
  SHA-1: b948a496150f4ae4f656c0f0ab672608723c80e6
  * UefiCpuPkg/PiSmmCpuDxeSmm: Pre-allocate PROCEDURE_TOKEN buffer
  REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2388

Reviewed-by: Ray Ni 
Acked-by: Laszlo Ersek 
Signed-off-by: Eric Dong 

commit f55477fe2d62687ae0b91e3c5e68db2c22cbaf5c
Author: Ard Biesheuvel 
Date:   Wed Jan 8 15:38:43 2020 +0100

OvmfPkg: use HII type PCDs for TPM2 config related variables

The HII pages that are part of Tcg2ConfigDxe expect the following PCDs
to be of dynamic HII type, so declare them as such.

  gEfiSecurityPkgTokenSpaceGuid.PcdTcgPhysicalPresenceInterfaceVer
  gEfiSecurityPkgTokenSpaceGuid.PcdTpm2AcpiTableRev

Currently, the TPM2 ACPI table is not produced, since we do not
incorporate the Tcg2Smm module, which implements the SMI based
physical presence interface exposed to the OS.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 

commit cf3ad972a2105ffa3795ddb1d9c149c7fc369f9b
Author: Ard Biesheuvel 
Date:   Wed Jan 8 15:38:42 2020 +0100

OvmfPkg: reorganize TPM2 support in DSC/FDF files

Put the TPM2 related DXE modules together in the DSC, and add a
TPM2 support header comment while at it.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 

commit 2649a735b249e54a4ddd7bd2b8d62bfe77e8d6da
Author: Philippe Mathieu-Daud? 
Date:   Thu Jan 2 20:16:56 2020 +0800

BaseTools/PatchCheck.py: Ignore CR and LF characters in subject length

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=113

Strip the trailing characters before checking the subject line is
less than 72 characters.

Fixes: e61406708c83f
Cc: Liming Gao 
Cc: Jordan Justen 
Reviewed-by: Jordan Justen 
Reviewed-by: Bob Feng 

Signed-off-by: Philippe Mathieu-Daude 

commit 972d88726410e21b1fff1a528854202c67e97ef1
Author: Ashish Singhal 
Date:   Tue Dec 24 10:57:47 2019 +0800

MdeModulePkg: Add EDK2 Platform Boot Manager Protocol

Add edk2 platform boot manager protocol which would have platform
specific refreshes to the auto enumerated as well as NV boot options
for the platform.

Signed-off-by: Ashish Singhal 
Reviewed-by: Ray Ni 

commit c9d72628432126cbce58a48b440e4944baa4beab
Author: Pavana.K 
Date:   Thu Jan 2 20:30:27 2020 +

CryptoPkg: 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 145851

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10  fail blocked in 145851
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 145851
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 145851
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 145851
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 145851
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 145851
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 145851
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 145851
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 145851
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 145851
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  fae249d23413b2bf7d98a97d8f649cf7d102c1ae
baseline version:
 xen  c6c63b6dbffcdf32a59efa1fd6e578437fba06ff

Last test of basis   145851  2020-01-09 07:53:33 Z0 days
Testing same since   145879  2020-01-09 18:36:39 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Juergen Gross 
  Tao Xu 

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

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf f55477fe2d62687ae0b91e3c5e68db2c22cbaf5c
baseline version:
 ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb

Last test of basis   145767  2020-01-08 00:39:09 Z2 days
Failing since145774  2020-01-08 02:50:20 Z1 days   10 attempts
Testing same since   145873  2020-01-09 16:09:14 Z0 days2 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Ashish Singhal 
  Pavana.K 
  Philippe Mathieu-Daud? 
  Philippe Mathieu-Daude 
  Siyuan Fu 
  Siyuan, Fu 

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



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

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

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

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


Not pushing.


commit f55477fe2d62687ae0b91e3c5e68db2c22cbaf5c
Author: Ard Biesheuvel 
Date:   Wed Jan 8 15:38:43 2020 +0100

OvmfPkg: use HII type PCDs for TPM2 config related variables

The HII pages that are part of Tcg2ConfigDxe expect the following PCDs
to be of dynamic HII type, so declare them as such.

  gEfiSecurityPkgTokenSpaceGuid.PcdTcgPhysicalPresenceInterfaceVer
  gEfiSecurityPkgTokenSpaceGuid.PcdTpm2AcpiTableRev

Currently, the TPM2 ACPI table is not produced, since we do not
incorporate the Tcg2Smm module, which implements the SMI based
physical presence interface exposed to the OS.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 

commit cf3ad972a2105ffa3795ddb1d9c149c7fc369f9b
Author: Ard Biesheuvel 
Date:   Wed Jan 8 15:38:42 2020 +0100

OvmfPkg: reorganize TPM2 support in DSC/FDF files

Put the TPM2 related DXE modules together in the DSC, and add a
TPM2 support header comment while at it.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 

commit 2649a735b249e54a4ddd7bd2b8d62bfe77e8d6da
Author: Philippe Mathieu-Daud? 
Date:   Thu Jan 2 20:16:56 2020 +0800

BaseTools/PatchCheck.py: Ignore CR and LF characters in subject length

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=113

Strip the trailing characters before checking the subject line is
less than 72 characters.

Fixes: e61406708c83f
Cc: Liming Gao 
Cc: Jordan Justen 
Reviewed-by: Jordan Justen 
Reviewed-by: Bob Feng 

Signed-off-by: Philippe Mathieu-Daude 

commit 972d88726410e21b1fff1a528854202c67e97ef1
Author: Ashish Singhal 
Date:   Tue Dec 24 10:57:47 2019 +0800

MdeModulePkg: Add EDK2 Platform Boot Manager Protocol

Add edk2 platform boot manager protocol which would have platform
specific refreshes to the auto enumerated as well as NV boot options
for the platform.

Signed-off-by: Ashish Singhal 
Reviewed-by: Ray Ni 

commit c9d72628432126cbce58a48b440e4944baa4beab
Author: Pavana.K 
Date:   Thu Jan 2 20:30:27 2020 +

CryptoPkg: Support for SHA384 & SHA512 RSA signing schemes

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2389

Currently RSA signing scheme support is available for MD5, SHA-1 or
SHA-256 algorithms.The fix is to extend this support for SHA384 and
SHA512.

Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Bob Feng 

Signed-off-by: Pavana.K 
Reviewed-by: Jian J Wang 

commit 396e791059f37062cbee85696e2b4186ec72a9e3
Author: Siyuan, Fu 
Date:   Fri Jan 3 14:59:27 2020 +0800

UefiCpuPkg: 

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 

[Xen-devel] [PATCH 2/2] Remove undocumented and unmaintained tools/memshr library

[Tamas K Lengyel]

The library has been largely untouched for over a decade at this point, it is
undocumented and it's unclear what it was originally used for. Remove it from
tree, if anyone needs it in the future it can be carved out from git history.

Signed-off-by: Tamas K Lengyel 
---
 tools/Makefile|1 -
 tools/memshr/Makefile |   49 --
 tools/memshr/bidir-daemon.c   |  103 ---
 tools/memshr/bidir-daemon.h   |   24 -
 tools/memshr/bidir-hash.c | 1355 -
 tools/memshr/bidir-hash.h |  114 ---
 tools/memshr/bidir-namedefs.h |   79 --
 tools/memshr/interface.c  |  224 --
 tools/memshr/memshr-priv.h|   33 -
 tools/memshr/memshr.h |   51 --
 tools/memshr/shm.c|  262 ---
 tools/memshr/shm.h|   49 --
 12 files changed, 2344 deletions(-)
 delete mode 100644 tools/memshr/Makefile
 delete mode 100644 tools/memshr/bidir-daemon.c
 delete mode 100644 tools/memshr/bidir-daemon.h
 delete mode 100644 tools/memshr/bidir-hash.c
 delete mode 100644 tools/memshr/bidir-hash.h
 delete mode 100644 tools/memshr/bidir-namedefs.h
 delete mode 100644 tools/memshr/interface.c
 delete mode 100644 tools/memshr/memshr-priv.h
 delete mode 100644 tools/memshr/memshr.h
 delete mode 100644 tools/memshr/shm.c
 delete mode 100644 tools/memshr/shm.h

diff --git a/tools/Makefile b/tools/Makefile
index 7b1f6c4d28..c10946e3b1 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -19,7 +19,6 @@ SUBDIRS-$(CONFIG_X86) += firmware
 SUBDIRS-y += console
 SUBDIRS-y += xenmon
 SUBDIRS-y += xenstat
-SUBDIRS-$(CONFIG_Linux) += memshr 
 SUBDIRS-$(CONFIG_NetBSD) += xenbackendd
 SUBDIRS-y += libfsimage
 SUBDIRS-$(CONFIG_Linux) += libvchan
diff --git a/tools/memshr/Makefile b/tools/memshr/Makefile
deleted file mode 100644
index 31d2dd7ada..00
--- a/tools/memshr/Makefile
+++ /dev/null
@@ -1,49 +0,0 @@
-XEN_ROOT = $(CURDIR)/../..
-include $(XEN_ROOT)/tools/Rules.mk
-
-LIBMEMSHR-BUILD := libmemshr.a
-
-CFLAGS  += -Werror
-CFLAGS  += -Wno-unused
-CFLAGS  += $(CFLAGS_xeninclude)
-CFLAGS  += $(CFLAGS_libxenctrl)
-CFLAGS  += -D_GNU_SOURCE
-CFLAGS  += -fPIC
-
-LIB-SRCS:= interface.c
-LIB-SRCS+= shm.c
-LIB-SRCS+= bidir-daemon.c
-LIB-SRCS+= bidir-hash.c
-
-LIB-OBJS:= interface.o
-LIB-OBJS+= shm.o
-LIB-OBJS+= bidir-daemon.o
-LIB-OBJS+= bidir-hash-fgprtshr.o
-LIB-OBJS+= bidir-hash-blockshr.o
-
-all: build
-
-build: $(LIBMEMSHR-BUILD)
-
-bidir-hash-fgprtshr.o: bidir-hash.c
-   $(CC) $(CFLAGS) -DFINGERPRINT_MAP -c -o $*.o bidir-hash.c 
-
-bidir-hash-blockshr.o: bidir-hash.c
-   $(CC) $(CFLAGS) -DBLOCK_MAP -c -o $*.o bidir-hash.c 
-
-libmemshr.a: $(LIB-OBJS)
-   $(AR) rc $@ $^
-
-install: all
-
-uninstall:
-
-clean:
-   rm -rf *.a *.o *~ $(DEPS_RM)
-
-.PHONY: distclean
-distclean: clean
-
-.PHONY: all build clean install distclean uninstall
-
--include $(DEPS_INCLUDE)
diff --git a/tools/memshr/bidir-daemon.c b/tools/memshr/bidir-daemon.c
deleted file mode 100644
index ddb7c00319..00
--- a/tools/memshr/bidir-daemon.c
+++ /dev/null
@@ -1,103 +0,0 @@
-/**
- *
- * Copyright (c) 2009 Citrix Systems, Inc. (Grzegorz Milos)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; If not, see .
- */
-#include 
-#include 
-#include 
-#include 
-
-#include "bidir-hash.h"
-#include "memshr-priv.h"
-
-static struct blockshr_hash *blks_hash;
-
-/* Callback in the iterator, remember this value, and leave */
-int find_one(vbdblk_t k, share_tuple_t v, void *priv)
-{
-share_tuple_t *rv = (share_tuple_t *) priv;
-*rv = v;
-/* Break out of iterator loop */
-return 1;
-}
-
-void* bidir_daemon(void *unused)
-{
-uint32_t nr_ent, max_nr_ent, tab_size, max_load, min_load;
-
-while(1)
-{
-blockshr_hash_sizes( blks_hash, 
-_ent, 
-_nr_ent,
-_size, 
-_load, 
-_load);
-/* Remove some hints as soon as we get to 90% capacity */ 
-if(10 * nr_ent > 9 * max_nr_ent)
-{
-share_tuple_t next_remove;
-int to_remove;
-int ret;
-
-to_remove = 0.1 * max_nr_ent; 
-   

[Xen-devel] [PATCH 1/2] MAINTAINERS: adjust path of actually maintained memshr code in tools

[Tamas K Lengyel]

Only tools/tests/mem-sharing is maintained under the tools folder.

Signed-off-by: Tamas K Lengyel 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a42fef6ab9..21744ace6d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -504,7 +504,7 @@ X86 MEMORY SHARING
 M: Tamas K Lengyel 
 S: Odd Fixes
 F: xen/arch/x86/mm/mem_sharing.c
-F: tools/memshr
+F: tools/tests/mem-sharing/
 
 X86 SHADOW PAGETABLES
 M: Tim Deegan 
-- 
2.20.1


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

[Xen-devel] [ovmf bisection] complete test-amd64-i386-xl-qemuu-ovmf-amd64

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ovmf-amd64
testid debian-hvm-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.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:  999463c865d3768a8432a89508096ae6a43873a5
  Bug not present: a5abd9cc2cebe7fac001f7bb7b647c47cf54af1a
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/145893/


  commit 999463c865d3768a8432a89508096ae6a43873a5
  Author: Hao A Wu 
  Date:   Thu Dec 19 13:36:24 2019 +0800
  
  UefiCpuPkg/MpInitLib: Collect processors' CPUID & Platform ID info
  
  REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2429
  
  This commit will collect the CPUID and Platform ID information for each
  processor within system. They will be stored in the CPU_AP_DATA structure.
  
  These information will be used in the next commit to decide whether a
  microcode patch will be loaded into memory.
  
  Cc: Eric Dong 
  Cc: Ray Ni 
  Cc: Laszlo Ersek 
  Cc: Star Zeng 
  Cc: Siyuan Fu 
  Cc: Michael D Kinney 
  Signed-off-by: Hao A Wu 
  Reviewed-by: Ray Ni 
  Reviewed-by: Eric Dong 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/ovmf/test-amd64-i386-xl-qemuu-ovmf-amd64.debian-hvm-install
 --summary-out=tmp/145893.bisection-summary --basis-template=145767 
--blessings=real,real-bisect ovmf test-amd64-i386-xl-qemuu-ovmf-amd64 
debian-hvm-install
Searching for failure / basis pass:
 145873 fail [host=rimava1] / 145767 [host=chardonnay0] 145699 [host=albana1] 
145678 [host=fiano1] 145668 [host=huxelrebe1] 145658 [host=italia0] 145480 
[host=fiano0] 145476 [host=albana0] 145179 [host=debina1] 145172 [host=pinot0] 
145129 [host=chardonnay1] 145032 [host=albana1] 145000 ok.
Failure / basis pass flights: 145873 / 145000
(tree with no url: minios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest b98aebd298246df37b472c52a2ee1023256d02e3 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
f55477fe2d62687ae0b91e3c5e68db2c22cbaf5c 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
f21b5a4aeb020f2a5e2c6503f906a9349dd2f069 
00691c6c90b2fd28d7b7037baeb288f6801e6182
Basis pass b98aebd298246df37b472c52a2ee1023256d02e3 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
796b380ca7d263ca504b82fe5317a78d3546d537 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
f21b5a4aeb020f2a5e2c6503f906a9349dd2f069 
5c13ed79f3cba200f21e7dfd6ed7f3aa08e4dada
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#b98aebd298246df37b472c52a2ee1023256d02e3-b98aebd298246df37b472c52a2ee1023256d02e3
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
https://github.com/tianocore/edk2.git#796b380ca7d263ca504b82fe5317a78d3546d537-f55477fe2d62687ae0b91e3c5e68db2c22cbaf5c
 git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484f\
 e09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798 
git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e410bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef
 
git://xenbits.xen.org/osstest/seabios.git#f21b5a4aeb020f2a5e2c6503f906a9349dd2f069-f21b5a4aeb020f2a5e2c6503f906a9349dd2f069
 
git://xenbits.xen.org/xen.git#5c13ed79f3cba200f21e7dfd6ed7f3aa08e4dada-00691c6c90b2fd28d7b7037baeb288f6801e6182
Loaded 19785 nodes in revision graph
Searching for test results:
 145000 pass b98aebd298246df37b472c52a2ee1023256d02e3 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
796b380ca7d263ca504b82fe5317a78d3546d537 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
f21b5a4aeb020f2a5e2c6503f906a9349dd2f069 
5c13ed79f3cba200f21e7dfd6ed7f3aa08e4dada
 145032 [host=albana1]
 145129 [host=chardonnay1]
 145172 [host=pinot0]
 145179 [host=debina1]
 145480 [host=fiano0]
 145476 [host=albana0]
 145668 [host=huxelrebe1]
 145658 [host=italia0]
 

[Xen-devel] [RFC 2/2] smmu: add support for generic DT bindings

[Brian Woods]

Restructure some of the code and add supporting functions for adding
generic device tree (DT) binding support.  The normal add_device and
dt_xlate functions are wrappers of the legacy functions due to legacy
calls needing more arguments because the find_smmu can't a smmu that
isn't initialized.

Signed-off-by: Brian Woods 
---
RFC especially on:
   - Checks for the: arm_smmu_dt_add_device* and arm_smmu_dt_xlate*
 functions.

 xen/drivers/passthrough/arm/smmu.c| 118 +-
 xen/drivers/passthrough/device_tree.c |  17 +
 2 files changed, 87 insertions(+), 48 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index c5db5be..08787cd 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -251,6 +251,8 @@ struct iommu_group
atomic_t ref;
 };
 
+static const struct arm_smmu_device *find_smmu(const struct device *dev);
+
 static struct iommu_group *iommu_group_alloc(void)
 {
struct iommu_group *group = xzalloc(struct iommu_group);
@@ -775,64 +777,114 @@ static int insert_smmu_master(struct arm_smmu_device 
*smmu,
return 0;
 }
 
-static int register_smmu_master(struct arm_smmu_device *smmu,
-   struct device *dev,
-   struct of_phandle_args *masterspec)
+/*
+ * Since smmu isn't done initializing before this is run in the legacy
+ * case, create a function where that's passed and then have the generic
+ * function just be a simple wrapper.
+ */
+static int arm_smmu_dt_xlate_legacy(struct device *dev,
+   const struct of_phandle_args *spec,
+   struct iommu_fwspec *fwspec)
+{
+   if ((spec->args_count + fwspec->num_ids) > MAX_MASTER_STREAMIDS) {
+   dev_err(dev,
+   "reached maximum number (%d) of stream IDs for master 
device %s\n",
+   MAX_MASTER_STREAMIDS, spec->np->name);
+   return -ENOSPC;
+   }
+
+   /* adding the ids here */
+   return iommu_fwspec_add_ids(dev,
+   spec->args,
+   spec->args_count);
+}
+
+static int arm_smmu_dt_xlate(struct device *dev,
+const struct dt_phandle_args *spec)
+{
+   return arm_smmu_dt_xlate_legacy(dev,
+   spec,
+   dev_iommu_fwspec_get(dev));
+}
+
+static int arm_smmu_dt_add_device_legacy(struct arm_smmu_device *smmu,
+struct device *dev,
+struct iommu_fwspec *fwspec)
 {
-   int i, ret = 0;
+   int i;
struct arm_smmu_master *master;
+   struct device_node *dev_node = dev_get_dev_node(dev);
+
+   BUG_ON(dev == NULL);
+   BUG_ON(dev_node == NULL);
 
-   master = find_smmu_master(smmu, masterspec->np);
+   master = find_smmu_master(smmu, dev_node);
if (master) {
dev_err(dev,
"rejecting multiple registrations for master device 
%s\n",
-   masterspec->np->name);
+   dev_node->name);
return -EBUSY;
}
 
-   if (masterspec->args_count > MAX_MASTER_STREAMIDS) {
-   dev_err(dev,
-   "reached maximum number (%d) of stream IDs for master 
device %s\n",
-   MAX_MASTER_STREAMIDS, masterspec->np->name);
-   return -ENOSPC;
-   }
-
master = devm_kzalloc(dev, sizeof(*master), GFP_KERNEL);
if (!master) {
return -ENOMEM;
}
-   master->of_node = masterspec->np;
-
-   ret = iommu_fwspec_init(>of_node->dev, smmu->dev);
-   if (ret) {
-   kfree(master);
-   return ret;
-   }
-   master->cfg.fwspec = dev_iommu_fwspec_get(>of_node->dev);
+   master->of_node = dev_node;
 
-   /* adding the ids here */
-   ret = iommu_fwspec_add_ids(>np->dev,
-  masterspec->args,
-  masterspec->args_count);
-   if (ret)
-   return ret;
+   master->cfg.fwspec = fwspec;
 
/* Xen: Let Xen know that the device is protected by an SMMU */
-   dt_device_set_protected(masterspec->np);
+   dt_device_set_protected(dev_node);
 
if (!(smmu->features & ARM_SMMU_FEAT_STREAM_MATCH)) {
-   for (i = 0; i < master->cfg.fwspec->num_ids; ++i) {
-   if (masterspec->args[i] >= smmu->num_mapping_groups) {
+   for (i = 0; i < fwspec->num_ids; ++i) {
+   if (fwspec->ids[i] >= smmu->num_mapping_groups) {
dev_err(dev,
"stream ID for master device %s greater 
than maximum allowed (%d)\n",
-   

[Xen-devel] [RFC 0/2] Generic DT Support for SMMU

[Brian Woods]

I'd like some feedback on these patches.  Parts I particularly want
feedback on are listed below and each patch will have a copy of the
relevant parts requesting feedback.  Any feedback is welcomed though.
Also, the commit messages are a little rough.

Patch 1:
  - Check in device_tree.c.  This is needed, otherwise it won't boot due
to dev_iommu_fwspec_get(dev) being true and returning EEXIST.  I'm
not completely sure what type of check is best here.

Patch 2:
   - Checks for the: arm_smmu_dt_add_device* and arm_smmu_dt_xlate*
 functions.

These patches have been tested with device passthrough on a Xilinx
ZCU102 with passing the on board ethernet to a guest via the SMMU.

Brian Woods (2):
  arm,smmu: add support for iommu_fwspec functions
  smmu: add support for generic DT bindings

 xen/drivers/passthrough/arm/smmu.c| 156 +-
 xen/drivers/passthrough/device_tree.c |  20 +
 2 files changed, 118 insertions(+), 58 deletions(-)

-- 
2.7.4


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

[Xen-devel] [RFC 1/2] arm, smmu: add support for iommu_fwspec functions

[Brian Woods]

Modify the smmu driver so that it uses the iommu_fwspec helper
functions.  This means both ARM IOMMU drivers will both use the
iommu_fwspec helper functions, making enabling generic device tree
bindings in the SMMU driver much cleaner.

Signed-off-by: Brian Woods 
---
RFC especially wanted on:
  - Check in device_tree.c.  This is needed, otherwise it won't boot due
to dev_iommu_fwspec_get(dev) being true and returning EEXIST.  I'm
not completely sure what type of check is best here.

 xen/drivers/passthrough/arm/smmu.c| 74 ++-
 xen/drivers/passthrough/device_tree.c |  3 ++
 2 files changed, 49 insertions(+), 28 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 94662a8..c5db5be 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* Xen: The below defines are redefined within the file. Undef it */
@@ -597,8 +598,7 @@ struct arm_smmu_smr {
 };
 
 struct arm_smmu_master_cfg {
-   int num_streamids;
-   u16 streamids[MAX_MASTER_STREAMIDS];
+   struct iommu_fwspec *fwspec;
struct arm_smmu_smr *smrs;
 };
 
@@ -779,7 +779,7 @@ static int register_smmu_master(struct arm_smmu_device 
*smmu,
struct device *dev,
struct of_phandle_args *masterspec)
 {
-   int i;
+   int i, ret = 0;
struct arm_smmu_master *master;
 
master = find_smmu_master(smmu, masterspec->np);
@@ -798,26 +798,37 @@ static int register_smmu_master(struct arm_smmu_device 
*smmu,
}
 
master = devm_kzalloc(dev, sizeof(*master), GFP_KERNEL);
-   if (!master)
+   if (!master) {
return -ENOMEM;
+   }
+   master->of_node = masterspec->np;
+
+   ret = iommu_fwspec_init(>of_node->dev, smmu->dev);
+   if (ret) {
+   kfree(master);
+   return ret;
+   }
+   master->cfg.fwspec = dev_iommu_fwspec_get(>of_node->dev);
 
-   master->of_node = masterspec->np;
-   master->cfg.num_streamids   = masterspec->args_count;
+   /* adding the ids here */
+   ret = iommu_fwspec_add_ids(>np->dev,
+  masterspec->args,
+  masterspec->args_count);
+   if (ret)
+   return ret;
 
/* Xen: Let Xen know that the device is protected by an SMMU */
dt_device_set_protected(masterspec->np);
 
-   for (i = 0; i < master->cfg.num_streamids; ++i) {
-   u16 streamid = masterspec->args[i];
-
-   if (!(smmu->features & ARM_SMMU_FEAT_STREAM_MATCH) &&
-(streamid >= smmu->num_mapping_groups)) {
-   dev_err(dev,
-   "stream ID for master device %s greater than 
maximum allowed (%d)\n",
-   masterspec->np->name, smmu->num_mapping_groups);
-   return -ERANGE;
+   if (!(smmu->features & ARM_SMMU_FEAT_STREAM_MATCH)) {
+   for (i = 0; i < master->cfg.fwspec->num_ids; ++i) {
+   if (masterspec->args[i] >= smmu->num_mapping_groups) {
+   dev_err(dev,
+   "stream ID for master device %s greater 
than maximum allowed (%d)\n",
+   masterspec->np->name, 
smmu->num_mapping_groups);
+   return -ERANGE;
+   }
}
-   master->cfg.streamids[i] = streamid;
}
return insert_smmu_master(smmu, master);
 }
@@ -1397,15 +1408,15 @@ static int arm_smmu_master_configure_smrs(struct 
arm_smmu_device *smmu,
if (cfg->smrs)
return -EEXIST;
 
-   smrs = kmalloc_array(cfg->num_streamids, sizeof(*smrs), GFP_KERNEL);
+   smrs = kmalloc_array(cfg->fwspec->num_ids, sizeof(*smrs), GFP_KERNEL);
if (!smrs) {
dev_err(smmu->dev, "failed to allocate %d SMRs\n",
-   cfg->num_streamids);
+   cfg->fwspec->num_ids);
return -ENOMEM;
}
 
/* Allocate the SMRs on the SMMU */
-   for (i = 0; i < cfg->num_streamids; ++i) {
+   for (i = 0; i < cfg->fwspec->num_ids; ++i) {
int idx = __arm_smmu_alloc_bitmap(smmu->smr_map, 0,
  smmu->num_mapping_groups);
if (IS_ERR_VALUE(idx)) {
@@ -1416,12 +1427,12 @@ static int arm_smmu_master_configure_smrs(struct 
arm_smmu_device *smmu,
smrs[i] = (struct arm_smmu_smr) {
.idx= idx,
.mask   = 0, /* We don't currently share SMRs */
-   .id = 

[Xen-devel] [qemu-mainline bisection] complete build-i386-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build

Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  b0b74e1f17508cb8cef8afd698558db1bd8999cc
  Bug not present: f17783e706ab9c7b3a2b69cf48e4f0ba40664f54
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/145894/


  commit b0b74e1f17508cb8cef8afd698558db1bd8999cc
  Merge: f17783e706 ddf9069963
  Author: Peter Maydell 
  Date:   Mon Jan 6 11:39:55 2020 +
  
  Merge remote-tracking branch 
'remotes/ehabkost/tags/python-next-pull-request' into staging
  
  Require Python >= 3.5 to build QEMU
  
  Python 2 EOL is 11 days away, we will stop supporting
  it in QEMU 5.0.
  
  # gpg: Signature made Fri 20 Dec 2019 16:49:02 GMT
  # gpg:using RSA key 
5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6
  # gpg:issuer "ehabk...@redhat.com"
  # gpg: Good signature from "Eduardo Habkost " [full]
  # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF  D1AA 2807 936F 984D 
C5A6
  
  * remotes/ehabkost/tags/python-next-pull-request:
configure: Require Python >= 3.5
travis: Replace Python 3.4 build with 3.5
  
  Signed-off-by: Peter Maydell 
  
  commit ddf90699631db53c981b6a5a63d31c08e0eaeec7
  Author: Eduardo Habkost 
  Date:   Wed Oct 16 19:42:37 2019 -0300
  
  configure: Require Python >= 3.5
  
  Python 3.5 is the oldest Python version available on our
  supported build platforms, and Python 2 end of life will be 3
  weeks after the planned release date of QEMU 4.2.0.  Drop Python
  2 support from configure completely, and require Python 3.5 or
  newer.
  
  Signed-off-by: Eduardo Habkost 
  Message-Id: <20191016224237.26180-1-ehabk...@redhat.com>
  Reviewed-by: John Snow 
  Signed-off-by: Eduardo Habkost 
  
  commit 49233804f5c458d61d8eb903c19d62edb3434db2
  Author: Eduardo Habkost 
  Date:   Fri Dec 20 13:45:27 2019 -0300
  
  travis: Replace Python 3.4 build with 3.5
  
  We'll start requiring Python 3.5 to build QEMU.
  
  Signed-off-by: Eduardo Habkost 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/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/qemu-mainline/build-i386-xsm.xen-build 
--summary-out=tmp/145894.bisection-summary --basis-template=144861 
--blessings=real,real-bisect qemu-mainline build-i386-xsm xen-build
Searching for failure / basis pass:
 145888 fail [host=italia0] / 145664 [host=debina1] 145649 [host=elbling1] 
145624 [host=pinot1] 145592 ok.
Failure / basis pass flights: 145888 / 145592
(tree with no url: minios)
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 70911f1f4aee0366b6122f2b90d367ec0f066beb 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
035eed4c0d257c905a556fa0f4865a0c077b4e7f 
f21b5a4aeb020f2a5e2c6503f906a9349dd2f069 
c6c63b6dbffcdf32a59efa1fd6e578437fba06ff
Basis pass b948a496150f4ae4f656c0f0ab672608723c80e6 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
f0dcfddecee8b860e015bb07d67cfcbdfbfd51d9 
f21b5a4aeb020f2a5e2c6503f906a9349dd2f069 
7b3c5b70a32303b46d0d051e695f18d72cce5ed0
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/osstest/ovmf.git#b948a496150f4ae4f656c0f0ab672608723c80e6-70911f1f4aee0366b6122f2b90d367ec0f066beb
 
git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 
git://git.qemu.org/qemu.git#f0dcfddecee8b860e015bb07d67cfcbdfbfd51d9-035eed4c0d257c905a556fa0f4865a0c077b4e7f
 
git://xenbits.xen.org/osstest/seabios.git#f21b5a4aeb020f2a5e2c6503f906a9349dd2f069-f21\
 b5a4aeb020f2a5e2c6503f906a9349dd2f069 
git://xenbits.xen.org/xen.git#7b3c5b70a32303b46d0d051e695f18d72cce5ed0-c6c63b6dbffcdf32a59efa1fd6e578437fba06ff
Loaded 84562 nodes in revision graph
Searching for test results:
 145547 [host=elbling1]
 145535 [host=elbling1]
 145573 [host=elbling1]
 145592 pass b948a496150f4ae4f656c0f0ab672608723c80e6 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
f0dcfddecee8b860e015bb07d67cfcbdfbfd51d9 
f21b5a4aeb020f2a5e2c6503f906a9349dd2f069 
7b3c5b70a32303b46d0d051e695f18d72cce5ed0
 145624 [host=pinot1]
 145698 fail irrelevant
 145664 [host=debina1]
 145649 [host=elbling1]
 145692 fail 

Re: [Xen-devel] Updating https://wiki.xenproject.org/wiki/Outreach_Program_Projects

[Stefano Stabellini]

On Wed, 8 Jan 2020, Lars Kurth wrote:
> @Stefano, @Julien: the 5 projects below are against you - are these still 
> valid?
> @Julien: these are against your Arm address
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Xen_Hypervisor
> - 
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Xen_on_ARM:_Trap_.26_sanitize_ID_registers_.28ID_PFR0.2C_ID_DFR0.2C_etc.29
> - 
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Xen_on_ARM.2C_dom0less:_configurable_memory_layout_for_guests
> - https://wiki.xenproject.org/wiki/Outreach_Program_Projects#ARMv8.1_atomics
> - 
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Xen_on_ARM:_dynamic_virtual_memory_layout
> - 
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Xen_on_ARM:_Performance_Counters_Virtualization

They are still valid.

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

Re: [Xen-devel] [RFC PATCH V2 01/11] xen/manage: keep track of the on-going suspend mode

[Anchal Agarwal]

On Thu, Jan 09, 2020 at 06:49:07PM -0500, Boris Ostrovsky wrote:
> 
> 
> On 1/9/20 6:46 PM, Boris Ostrovsky wrote:
> >
> >
> >On 1/7/20 6:37 PM, Anchal Agarwal wrote:
> >>+
> >>+static int xen_setup_pm_notifier(void)
> >>+{
> >>+    if (!xen_hvm_domain())
> >>+    return -ENODEV;
> >
> >ARM guests are also HVM domains. Is it OK for them to register the
> >notifier? The diffstat suggests that you are supporting ARM.
> 
> I obviously meant *not* supporting ARM, sorry.
> 
> -boris
> 
> >
> >-boris
> >

TBH, I have not yet experimented with these patches on
ARM guest yet but that will be the next step. The same 
code with changes as needed should be made to work for ARM.
Currently I am focussed on getting a sane set of 
patches into mainline for x86 guests.

Thanks,

Anchal

> >>+
> >>+    return register_pm_notifier(_pm_notifier_block);
> >>+}
> >>
> >
> 

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   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-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 

Re: [Xen-devel] [RFC PATCH V2 01/11] xen/manage: keep track of the on-going suspend mode

[Boris Ostrovsky]

On 1/9/20 6:46 PM, Boris Ostrovsky wrote:



On 1/7/20 6:37 PM, Anchal Agarwal wrote:

+
+static int xen_setup_pm_notifier(void)
+{
+    if (!xen_hvm_domain())
+    return -ENODEV;


ARM guests are also HVM domains. Is it OK for them to register the 
notifier? The diffstat suggests that you are supporting ARM.


I obviously meant *not* supporting ARM, sorry.

-boris



-boris


+
+    return register_pm_notifier(_pm_notifier_block);
+}






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

Re: [Xen-devel] [RFC PATCH V2 01/11] xen/manage: keep track of the on-going suspend mode

[Boris Ostrovsky]

On 1/7/20 6:37 PM, Anchal Agarwal wrote:

+
+static int xen_setup_pm_notifier(void)
+{
+   if (!xen_hvm_domain())
+   return -ENODEV;


ARM guests are also HVM domains. Is it OK for them to register the 
notifier? The diffstat suggests that you are supporting ARM.


-boris


+
+   return register_pm_notifier(_pm_notifier_block);
+}




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

Re: [Xen-devel] [RFC PATCH V2 09/11] xen: Clear IRQD_IRQ_STARTED flag during shutdown PIRQs

[Anchal Agarwal]

On Thu, Jan 09, 2020 at 01:07:27PM +0100, Thomas Gleixner wrote:
> Anchal Agarwal  writes:
> > On Wed, Jan 08, 2020 at 04:23:25PM +0100, Thomas Gleixner wrote:
> >> Anchal Agarwal  writes:
> >> > +void irq_state_clr_started(struct irq_desc *desc)
> >> >  {
> >> >  irqd_clear(>irq_data, IRQD_IRQ_STARTED);
> >> >  }
> >> > +EXPORT_SYMBOL_GPL(irq_state_clr_started);
> >> 
> >> This is core internal state and not supposed to be fiddled with by
> >> drivers.
> >> 
> >> irq_chip has irq_suspend/resume/pm_shutdown callbacks for a reason.
> >>
> > I agree, as its mentioned in the previous patch {[RFC PATCH V2 08/11]} this 
> > is 
> > one way of explicitly shutting down legacy devices without introducing too 
> > much 
> > code for each of the legacy devices. . for eg. in case of floppy there 
> > is no suspend/freeze handler which should have done the needful.
> > .
> > Either we implement them for all the legacy devices that have them missing 
> > or
> > explicitly shutdown pirqs. I have choosen later for simplicity. I understand
> > that ideally we should enable/disable devices interrupts in suspend/resume 
> > devices but that requires adding code for doing that to few drivers[and I 
> > may
> > not know all of them either]
> >
> > Now I discovered during the flow in hibernation_platform_enter under resume 
> > devices that for such devices irq_startup is called which checks for 
> > IRQD_IRQ_STARTED flag and based on that it calls irq_enable or irq_startup.
> > They are only restarted if the flag is not set which is cleared during 
> > shutdown. 
> > shutdown_pirq does not do that. Only masking/unmasking of evtchn does not 
> > work 
> > as pirq needs to be restarted.
> > xen-pirq.enable_irq is called rather than stratup_pirq. On resume if these 
> > pirqs
> > are not restarted in this case ACPI SCI interrupts, I do not see receiving 
> > any interrupts under cat /proc/interrupts even though host keeps generating 
> > S4 ACPI events. 
> > Does that makes sense?
> 
> No. You still violate all abstraction boundaries. On one hand you use a
> XEN specific suspend function to shut down interrupts, but then you want
> the core code to reestablish them on resume. That's just bad hackery which
> abuses partial knowledge of core internals. The state flag is only one
> part of the core internal state and just clearing it does not make the
> rest consistent. It just works by chance and not by design and any
> change of the core code will break it in colourful ways.
> 
> So either you can handle it purely on the XEN side without touching any
> core state or you need to come up with some way of letting the core code
> know that it should invoke shutdown instead of disable.
> 
> Something like the completely untested patch below.
> 
> Thanks,
> 
>tglx
Understandable. Really appreciate the patch suggestion below and i will test it
for sure and see if things can be fixed properly in irq core if thats the only
option. In the meanwhile, I tried to fix it on xen side unless it gives you the 
same feeling as above? MSI-x are just fine, just ioapic ones don't get any event
channel asssigned hence enable_dynirq does nothing. Those needs to be restarted.

Thanks,
Anchal

<---

diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 1bb0b522d004..2ed152f35816 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -575,6 +575,11 @@ static void shutdown_pirq(struct irq_data *data)

static void enable_pirq(struct irq_data *data)
{
+/*ioapic interrupts don't get event channel assigned
   + * after being explicitly shutdown during guest
   + * hibernation. They need to be restarted*/
+   if(!evtchn_from_irq(data->irq))
+   startup_pirq(data);
enable_dynirq(data);
 }

> 
> 8<
> 
> diff --git a/include/linux/irq.h b/include/linux/irq.h
> index 7853eb9301f2..50f2057bc339 100644
> --- a/include/linux/irq.h
> +++ b/include/linux/irq.h
> @@ -511,6 +511,7 @@ struct irq_chip {
>   * IRQCHIP_EOI_THREADED: Chip requires eoi() on unmask in threaded mode
>   * IRQCHIP_SUPPORTS_LEVEL_MSIChip can provide two doorbells for 
> Level MSIs
>   * IRQCHIP_SUPPORTS_NMI: Chip can deliver NMIs, only for root irqchips
> + * IRQCHIP_SHUTDOWN_ON_SUSPEND:  Shutdown non wake irqs in the suspend 
> path
>   */
>  enum {
>   IRQCHIP_SET_TYPE_MASKED = (1 <<  0),
> @@ -522,6 +523,7 @@ enum {
>   IRQCHIP_EOI_THREADED= (1 <<  6),
>   IRQCHIP_SUPPORTS_LEVEL_MSI  = (1 <<  7),
>   IRQCHIP_SUPPORTS_NMI= (1 <<  8),
> + IRQCHIP_SHUTDOWN_ON_SUSPEND = (1 <<  9),
>  };
>  
>  #include 
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index b3fa2d87d2f3..0fe355f72a15 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -233,7 +233,7 @@ __irq_startup_managed(struct irq_desc *desc, struct 
> cpumask *aff, bool force)
>  }

Re: [Xen-devel] [PATCH v1 2/4] x86/xen: add basic KASAN support for PV kernel

[Boris Ostrovsky]

On 1/8/20 10:20 AM, Sergey Dyasli wrote:

@@ -1943,6 +1973,15 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, 
unsigned long max_pfn)
if (i && i < pgd_index(__START_KERNEL_map))
init_top_pgt[i] = ((pgd_t *)xen_start_info->pt_base)[i];
  
+#ifdef CONFIG_KASAN

+   /*
+* Copy KASAN mappings
+* ec00 - fbff (=44 bits) kasan shadow memory 
(16TB)
+*/
+   for (i = 0xec0 >> 3; i < 0xfc0 >> 3; i++)


Are you referring here to  KASAN_SHADOW_START and KASAN_SHADOW_END? If 
so, can you use them instead?


-boris


+   init_top_pgt[i] = ((pgd_t *)xen_start_info->pt_base)[i];
+#endif
+
  



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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 

Re: [Xen-devel] [BUG] xenstat_vcpu_ns returns invalid value

[Andrew Cooper]

On 09/01/2020 20:09, Richard Kojedzinszky wrote:
> 2020-01-09 20:50 időpontban Andrew Cooper ezt írta:
>> On 09/01/2020 19:40, Richard Kojedzinszky wrote:
>>> Dear Xen Devs,
>>>
>>> commit 2529c850ea48f036727ca2f148caed89391311b8 introduces the
>>> XEN_RUNSTATE_UPDATE marker bit, which is not handled in
>>> vcpu_runstate_get() in xen/common/schedule.c. Relevant code:
>>>
>>>     delta = NOW() - runstate->state_entry_time;
>>>     if ( delta > 0 )
>>>     runstate->time[runstate->state] += delta;
>>
>> That was found and fixed a while ago.  c/s f28c4c4c10 "sched: don't let
>> XEN_RUNSTATE_UPDATE leak into vcpu_runstate_get()".
>>
>> No changes in userspace should be necessary, although you might need to
>> pester your distro for backports.
>>
>> ~Andrew
>
> Hi,
>
> Thanks for the quick reply,
>
> Then, as it is just a leak, until a backport arrives to my distro, I
> can mask out that bit from the results with no other side-effects, am
> I right?

Yes - that should be safe.

~Andrew

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

Re: [Xen-devel] [BUG] xenstat_vcpu_ns returns invalid value

[Richard Kojedzinszky]

2020-01-09 21:10 időpontban Andrew Cooper ezt írta:

On 09/01/2020 20:09, Richard Kojedzinszky wrote:

2020-01-09 20:50 időpontban Andrew Cooper ezt írta:

On 09/01/2020 19:40, Richard Kojedzinszky wrote:

Dear Xen Devs,

commit 2529c850ea48f036727ca2f148caed89391311b8 introduces the
XEN_RUNSTATE_UPDATE marker bit, which is not handled in
vcpu_runstate_get() in xen/common/schedule.c. Relevant code:

    delta = NOW() - runstate->state_entry_time;
    if ( delta > 0 )
    runstate->time[runstate->state] += delta;


That was found and fixed a while ago.  c/s f28c4c4c10 "sched: don't 
let

XEN_RUNSTATE_UPDATE leak into vcpu_runstate_get()".

No changes in userspace should be necessary, although you might need 
to

pester your distro for backports.

~Andrew


Hi,

Thanks for the quick reply,

Then, as it is just a leak, until a backport arrives to my distro, I
can mask out that bit from the results with no other side-effects, am
I right?


Yes - that should be safe.

~Andrew


Hi,

Many thanks, I will do that.

Regards,
Richard

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

Re: [Xen-devel] [BUG] xenstat_vcpu_ns returns invalid value

[Richard Kojedzinszky]

2020-01-09 20:50 időpontban Andrew Cooper ezt írta:

On 09/01/2020 19:40, Richard Kojedzinszky wrote:

Dear Xen Devs,

commit 2529c850ea48f036727ca2f148caed89391311b8 introduces the
XEN_RUNSTATE_UPDATE marker bit, which is not handled in
vcpu_runstate_get() in xen/common/schedule.c. Relevant code:

    delta = NOW() - runstate->state_entry_time;
    if ( delta > 0 )
    runstate->time[runstate->state] += delta;


That was found and fixed a while ago.  c/s f28c4c4c10 "sched: don't let
XEN_RUNSTATE_UPDATE leak into vcpu_runstate_get()".

No changes in userspace should be necessary, although you might need to
pester your distro for backports.

~Andrew


Hi,

Thanks for the quick reply,

Then, as it is just a leak, until a backport arrives to my distro, I can 
mask out that bit from the results with no other side-effects, am I 
right?


Regards,
Richard Kojedzinszky

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

Re: [Xen-devel] [BUG] xenstat_vcpu_ns returns invalid value

[Andrew Cooper]

On 09/01/2020 19:40, Richard Kojedzinszky wrote:
> Dear Xen Devs,
>
> commit 2529c850ea48f036727ca2f148caed89391311b8 introduces the
> XEN_RUNSTATE_UPDATE marker bit, which is not handled in
> vcpu_runstate_get() in xen/common/schedule.c. Relevant code:
>
>     delta = NOW() - runstate->state_entry_time;
>     if ( delta > 0 )
>     runstate->time[runstate->state] += delta;

That was found and fixed a while ago.  c/s f28c4c4c10 "sched: don't let
XEN_RUNSTATE_UPDATE leak into vcpu_runstate_get()".

No changes in userspace should be necessary, although you might need to
pester your distro for backports.

~Andrew

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

[Xen-devel] [BUG] xenstat_vcpu_ns returns invalid value

[Richard Kojedzinszky]

Dear Xen Devs,

commit 2529c850ea48f036727ca2f148caed89391311b8 introduces the 
XEN_RUNSTATE_UPDATE marker bit, which is not handled in

vcpu_runstate_get() in xen/common/schedule.c. Relevant code:

delta = NOW() - runstate->state_entry_time;
if ( delta > 0 )
runstate->time[runstate->state] += delta;

If state_entry_time has the bit set, it will be a negative value, so 
delta will be greater than 0, actually the marker bit
will appear in runstate->time too. This causes the MSB bit set in the 
return of xenstat_vcpu_ns(). Is it true, that when reading these values 
through xenstat, the user should take care of this bit, and reread, or 
is it a bug in the relevant code?


I am using xenstat.h interface, where I can only request statistics for 
the whole node. So, basically, walking through all vcpu of all domain, 
and checking that no one

contains this bit seems a bit ugly solution.

Thanks in advance,
Richard Kojedzinszky

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

[Xen-devel] [PATCH v2 4/4] x86/boot: Drop INVALID_VCPU

[Andrew Cooper]

Now that NULL will fault at boot, there is no need for a special constant to
signify "current not set up yet".

Since c/s fae249d23413 "x86/boot: Rationalise stack handling during early
boot", the BSP cpu_info block is now consistently zero, so drop the adjacent
re-zeroing.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 

v2:
 * Drop re-zeroign of the cpu_info block
---
 xen/arch/x86/cpu/mcheck/mce.c | 2 +-
 xen/arch/x86/domain_page.c| 2 +-
 xen/arch/x86/setup.c  | 3 ---
 xen/arch/x86/tboot.c  | 2 +-
 xen/include/asm-x86/setup.h   | 3 ---
 5 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 29f3f9c5e3..198595ff97 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -260,7 +260,7 @@ static int mca_init_global(uint32_t flags, struct 
mcinfo_global *mig)
 >mc_coreid, >mc_core_threadid,
 >mc_apicid, NULL, NULL, NULL);
 
-if ( curr != INVALID_VCPU )
+if ( curr )
 {
 mig->mc_domid = curr->domain->domain_id;
 mig->mc_vcpuid = curr->vcpu_id;
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 4a07cfb18e..dd32712d2f 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -29,7 +29,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
  * When current isn't properly set up yet, this is equivalent to
  * running in an idle vCPU (callers must check for NULL).
  */
-if ( v == INVALID_VCPU )
+if ( !v )
 return NULL;
 
 /*
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 62adc9e2a8..1b6ca4a47d 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -707,9 +707,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
 /* Critical region without IDT or TSS.  Any fault is deadly! */
 
-set_processor_id(0);
-set_current(INVALID_VCPU); /* debug sanity. */
-idle_vcpu[0] = current;
 init_shadow_spec_ctrl_state();
 
 percpu_init_areas();
diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c
index 3e828fe204..5020c4ad49 100644
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -392,7 +392,7 @@ void tboot_shutdown(uint32_t shutdown_type)
  * During early boot, we can be called by panic before idle_vcpu[0] is
  * setup, but in that case we don't need to change page tables.
  */
-if ( idle_vcpu[0] != INVALID_VCPU )
+if ( idle_vcpu[0] )
 write_ptbase(idle_vcpu[0]);
 
 ((void(*)(void))(unsigned long)g_tboot_shared->shutdown_entry)();
diff --git a/xen/include/asm-x86/setup.h b/xen/include/asm-x86/setup.h
index 861d46d6ac..28257bc5c8 100644
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -4,9 +4,6 @@
 #include 
 #include 
 
-/* vCPU pointer used prior to there being a valid one around */
-#define INVALID_VCPU ((struct vcpu *)0xc000UL)
-
 extern const char __2M_text_start[], __2M_text_end[];
 extern const char __2M_rodata_start[], __2M_rodata_end[];
 extern char __2M_init_start[], __2M_init_end[];
-- 
2.11.0


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

[Xen-devel] [PATCH v2 3/4] x86/boot: Don't map 0 during boot

[Andrew Cooper]

In particular, it causes accidental NULL pointer dereferences to go unnoticed.

The majority of the early operation takes place either in Real mode, or
Protected Unpaged mode.  The only bit which requires pagetable mappings is the
trampoline transition into Long mode and jump to the higher mappings, so there
is no need for the whole bottom 2M to be mapped.

Introduce a new l1_bootmap in .init.data, and use it instead of l1_identmap.
The EFI boot path doesn't pass through the trampoline, so doesn't need any
adjustment.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
---
 xen/arch/x86/boot/head.S   | 14 --
 xen/arch/x86/boot/x86_64.S |  4 
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 0b75d33a25..d246e374f1 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -689,12 +689,14 @@ trampoline_setup:
 sub $(L2_PAGETABLE_ENTRIES*8),%eax
 loop1b
 
-/*
- * During boot, hook 4kB mappings of first 2MB of memory into L2.
- * This avoids mixing cachability for the legacy VGA region.
- */
-lea __PAGE_HYPERVISOR+sym_esi(l1_identmap),%edi
-mov %edi,sym_fs(l2_bootmap)
+/* Map the permanent trampoline page into l{1,2}_bootmap[]. */
+mov sym_esi(trampoline_phys), %ecx
+lea __PAGE_HYPERVISOR_RX(%ecx), %edx /* %edx = PTE to write  */
+shr $PAGE_SHIFT, %ecx/* %ecx = Slot to write */
+mov %edx, sym_offs(l1_bootmap)(%esi, %ecx, 8)
+
+lea __PAGE_HYPERVISOR + sym_esi(l1_bootmap), %edx
+mov %edx, sym_esi(l2_bootmap)
 
 /* Apply relocations to bootstrap trampoline. */
 mov sym_fs(trampoline_phys),%edx
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index de555f87f4..af62850589 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -155,6 +155,10 @@ GLOBAL(__page_tables_end)
 .section .init.data, "aw", @progbits
 .align PAGE_SIZE, 0
 
+l1_bootmap:
+.fill L1_PAGETABLE_ENTRIES, 8, 0
+.size l1_bootmap, . - l1_bootmap
+
 GLOBAL(l2_bootmap)
 .fill 4 * L2_PAGETABLE_ENTRIES, 8, 0
 .size l2_bootmap, . - l2_bootmap
-- 
2.11.0


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

[Xen-devel] [PATCH v2 2/4] x86/boot: Clean up l?_bootmap[] construction

[Andrew Cooper]

The need for Xen to be identity mapped into the bootmap is not obvious, and
differs between the MB and EFI boot paths.

The EFI side is further complicated by an attempt to cope with with l2_bootmap
only being 4k long.  This is undocumented, confusing, only works if Xen is the
single object wanting mapping.

The pageables are common to both the MB and EFI builds, so simplify the EFI
bootmap construction code to make exactly one identity-map of Xen, which now
makes the two paths consistent.  Comment both pieces of logic, explaining what
the mappings are needed for.

Finally, leave a linker assert covering the fact that plenty of code blindly
assumes that Xen is less that 16M.  This wants fixing in due course.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 

v2:
 * Extra BUILD_BUG_ON()'s
---
 xen/arch/x86/boot/head.S|  8 ++--
 xen/arch/x86/efi/efi-boot.h | 20 +---
 xen/arch/x86/xen.lds.S  |  3 +++
 3 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index d152af4542..0b75d33a25 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -668,7 +668,11 @@ trampoline_setup:
 add %esi,sym_fs(__page_tables_start)-8(,%ecx,8)
 2:  loop1b
 
-/* Initialize L2 boot-map/direct map page table entries (16MB). */
+/*
+ * Map Xen into the directmap (needed for early-boot pagetable
+ * handling/walking), and identity map Xen into bootmap (needed for
+ * the transition into long mode), using 2M superpages.
+ */
 lea sym_esi(start),%ebx
 lea 
(1<> L2_PAGETABLE_SHIFT) + i;
 paddr_t addr = slot << L2_PAGETABLE_SHIFT;
 
 l2_identmap[slot] = l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_PSE);
-slot &= L2_PAGETABLE_ENTRIES - 1;
 l2_bootmap[slot] = l2e_from_paddr(addr, __PAGE_HYPERVISOR|_PAGE_PSE);
 }
-/* Initialise L3 boot-map page directory entries. */
-l3_bootmap[l3_table_offset(xen_phys_start)] =
-l3e_from_paddr((UINTN)l2_bootmap, __PAGE_HYPERVISOR);
-l3_bootmap[l3_table_offset(xen_phys_start + (8 << L2_PAGETABLE_SHIFT) - 
1)] =
-l3e_from_paddr((UINTN)l2_bootmap, __PAGE_HYPERVISOR);
 }
 
 static void __init efi_arch_handle_module(struct file *file, const CHAR16 
*name,
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 111edb5360..7f82f64078 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -381,3 +381,6 @@ ASSERT((trampoline_end - trampoline_start) < 
TRAMPOLINE_SPACE - MBI_SPACE_MIN,
 "not enough room for trampoline and mbi data")
 ASSERT((wakeup_stack - wakeup_stack_start) >= WAKEUP_STACK_MIN,
 "wakeup stack too small")
+
+/* Plenty of boot code assumes that Xen isn't larger than 16M. */
+ASSERT(_end - _start <= MB(16), "Xen too large for early-boot assumptions")
-- 
2.11.0


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

[Xen-devel] [PATCH v2 1/4] x86/boot: Remove the preconstructed low 16M superpage mappings

[Andrew Cooper]

These are left over from c/s b2804422 "x86: make Xen early boot code
relocatable", which made it possible for Xen not to be in the bottom 16M.

Nothing using the mappings any more.  Build them in the directmap when walking
the E820 table along with everything else.

Furthermore, it is undefined to have superpages and MTRRs disagree on
cacheability boundaries, and nothing actually checks.  While we don't fix this
explicitly, we do at least honour the E820 now if it says there are boundaries
in this range.

As a consequence, there are now no _PAGE_PRESENT entries between
__page_tables_{start,end} which need to skip relocation.  This simplifies the
MB1/2 entry path logic to remove the l2_identmap[] special case.

The low 2M (using 4k pages) is retained for now.  Amongst other things, it
matters for console logging while the legacy VGA hole is in use.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 

v2:
 * Update commit message to explain what the low 16M used to be used for
 * Add PREBUILT_MAP_LIMIT
---
 xen/arch/x86/boot/head.S  | 10 ++
 xen/arch/x86/boot/x86_64.S| 17 ++---
 xen/arch/x86/setup.c  | 13 -
 xen/arch/x86/x86_64/asm-offsets.c |  3 ---
 4 files changed, 16 insertions(+), 27 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 250587fdf0..d152af4542 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -661,15 +661,9 @@ trampoline_setup:
 mov %eax,sym_fs(boot_tsc_stamp)
 mov %edx,sym_fs(boot_tsc_stamp)+4
 
-/*
- * Update frame addresses in page tables excluding l2_identmap
- * without its first entry which points to l1_identmap.
- */
+/* Relocate pagetables to point at Xen's current location in memory. */
 mov $((__page_tables_end-__page_tables_start)/8),%ecx
-mov $(((l2_identmap-__page_tables_start)/8)+1),%edx
-1:  cmp $((l2_identmap+l2_identmap_sizeof-__page_tables_start)/8),%ecx
-cmove   %edx,%ecx
-testl   $_PAGE_PRESENT,sym_fs(__page_tables_start)-8(,%ecx,8)
+1:  testl   $_PAGE_PRESENT,sym_fs(__page_tables_start)-8(,%ecx,8)
 jz  2f
 add %esi,sym_fs(__page_tables_start)-8(,%ecx,8)
 2:  loop1b
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 0acf5e860c..de555f87f4 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -65,24 +65,19 @@ l1_identmap:
 .size l1_identmap, . - l1_identmap
 
 /*
- * __page_tables_start does not cover l1_identmap because it (l1_identmap)
- * contains 1-1 mappings. This means that frame addresses of these mappings
- * are static and should not be updated at runtime.
+ * __page_tables_{start,end} cover the range of pagetables which need
+ * relocating as Xen moves around physical memory.  i.e. each sym_offs()
+ * reference to a different pagetable in the Xen image.
  */
 GLOBAL(__page_tables_start)
 
 /*
- * Space for mapping the first 4GB of memory, with the first 16 megabytes
- * actualy mapped (mostly using superpages).  Uses 4x 4k pages.
+ * Space for 4G worth of 2M mappings, first 2M actually mapped via
+ * l1_identmap[].  Uses 4x 4k pages.
  */
 GLOBAL(l2_identmap)
 .quad sym_offs(l1_identmap) + __PAGE_HYPERVISOR
-idx = 1
-.rept 7
-.quad (idx << L2_PAGETABLE_SHIFT) | PAGE_HYPERVISOR | _PAGE_PSE
-idx = idx + 1
-.endr
-.fill 4 * L2_PAGETABLE_ENTRIES - 8, 8, 0
+.fill 4 * L2_PAGETABLE_ENTRIES - 1, 8, 0
 .size l2_identmap, . - l2_identmap
 
 /*
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index ed54f79fea..62adc9e2a8 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -678,6 +678,9 @@ static unsigned int __init copy_bios_e820(struct e820entry 
*map, unsigned int li
 return n;
 }
 
+/* How much of the directmap is prebuilt at compile time. */
+#define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT)
+
 void __init noreturn __start_xen(unsigned long mbi_p)
 {
 char *memmap_type = NULL;
@@ -1020,7 +1023,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
  *
  * We require superpage alignment because the boot allocator is
  * not yet initialised. Hence we can only map superpages in the
- * address range BOOTSTRAP_MAP_BASE to 4GB, as this is guaranteed
+ * address range PREBUILT_MAP_LIMIT to 4GB, as this is guaranteed
  * not to require dynamic allocation of pagetables.
  *
  * As well as mapping superpages in that range, in preparation for
@@ -1036,10 +1039,10 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 if ( boot_e820.map[i].type != E820_RAM )
 continue;
 
-/* Superpage-aligned chunks from BOOTSTRAP_MAP_BASE. */
+/* Superpage-aligned chunks from PREBUILT_MAP_LIMIT. */
 s = (boot_e820.map[i].addr + mask) & ~mask;
 e = 

[Xen-devel] [PATCH v2 0/4] x86/boot: Remove mappings at 0

[Andrew Cooper]

This is the (long overdue) series which finally removes the mapping at 0
during early boot, which has bitten us in the past.  It also removes an RWX
gadget which persists past boot in the idle pagetables.

Most of the complexity was down to the differing (and hard-to-follow) uses of
the bootmap.  I first opted to get rid of the bootmap entirely.  While this is
possible for the current Multiboot paths, it is incompatible with the EFI boot
path, and works against David's existing plans to not use the trampoline at
all.

Further ideas: (not addressed here because -ETIME on my behalf.)

1) Get PV-shim to use hypercalls for AP startup, at which point we can compile
   out the trampoline entirely.  This is probably helpful for robustness
   testing in combination with David's plans.

2) Drop BOOTSTRAP_MAP_{BASE,LIMIT} and have bootstrap_map() populate into the
   directmap, as we only request RAM mappings.  This would allow us to drop 3
   of the bootmap pagetables.  However, I'm not entirely convinced the later
   logic will cope with cacheability boundaries forcing the use of small
   mappings.

This series has had complete testing for MB and EFI boot paths.  It turns out
that grub can chainload xen.efi and test those paths.

v2:
  * Two patches already committed.  See individual patches for other changes.

Andrew Cooper (4):
  x86/boot: Remove the preconstructed low 16M superpage mappings
  x86/boot: Clean up l?_bootmap[] construction
  x86/boot: Don't map 0 during boot
  x86/boot: Drop INVALID_VCPU

 xen/arch/x86/boot/head.S  | 32 
 xen/arch/x86/boot/x86_64.S| 21 ++---
 xen/arch/x86/cpu/mcheck/mce.c |  2 +-
 xen/arch/x86/domain_page.c|  2 +-
 xen/arch/x86/efi/efi-boot.h   | 20 +---
 xen/arch/x86/setup.c  | 16 
 xen/arch/x86/tboot.c  |  2 +-
 xen/arch/x86/x86_64/asm-offsets.c |  3 ---
 xen/arch/x86/xen.lds.S|  3 +++
 xen/include/asm-x86/setup.h   |  3 ---
 10 files changed, 53 insertions(+), 51 deletions(-)

-- 
2.11.0


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

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf f55477fe2d62687ae0b91e3c5e68db2c22cbaf5c
baseline version:
 ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb

Last test of basis   145767  2020-01-08 00:39:09 Z1 days
Failing since145774  2020-01-08 02:50:20 Z1 days9 attempts
Testing same since   145873  2020-01-09 16:09:14 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Ashish Singhal 
  Pavana.K 
  Philippe Mathieu-Daud? 
  Philippe Mathieu-Daude 
  Siyuan Fu 
  Siyuan, Fu 

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



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

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

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

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


Not pushing.


commit f55477fe2d62687ae0b91e3c5e68db2c22cbaf5c
Author: Ard Biesheuvel 
Date:   Wed Jan 8 15:38:43 2020 +0100

OvmfPkg: use HII type PCDs for TPM2 config related variables

The HII pages that are part of Tcg2ConfigDxe expect the following PCDs
to be of dynamic HII type, so declare them as such.

  gEfiSecurityPkgTokenSpaceGuid.PcdTcgPhysicalPresenceInterfaceVer
  gEfiSecurityPkgTokenSpaceGuid.PcdTpm2AcpiTableRev

Currently, the TPM2 ACPI table is not produced, since we do not
incorporate the Tcg2Smm module, which implements the SMI based
physical presence interface exposed to the OS.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 

commit cf3ad972a2105ffa3795ddb1d9c149c7fc369f9b
Author: Ard Biesheuvel 
Date:   Wed Jan 8 15:38:42 2020 +0100

OvmfPkg: reorganize TPM2 support in DSC/FDF files

Put the TPM2 related DXE modules together in the DSC, and add a
TPM2 support header comment while at it.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 

commit 2649a735b249e54a4ddd7bd2b8d62bfe77e8d6da
Author: Philippe Mathieu-Daud? 
Date:   Thu Jan 2 20:16:56 2020 +0800

BaseTools/PatchCheck.py: Ignore CR and LF characters in subject length

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=113

Strip the trailing characters before checking the subject line is
less than 72 characters.

Fixes: e61406708c83f
Cc: Liming Gao 
Cc: Jordan Justen 
Reviewed-by: Jordan Justen 
Reviewed-by: Bob Feng 

Signed-off-by: Philippe Mathieu-Daude 

commit 972d88726410e21b1fff1a528854202c67e97ef1
Author: Ashish Singhal 
Date:   Tue Dec 24 10:57:47 2019 +0800

MdeModulePkg: Add EDK2 Platform Boot Manager Protocol

Add edk2 platform boot manager protocol which would have platform
specific refreshes to the auto enumerated as well as NV boot options
for the platform.

Signed-off-by: Ashish Singhal 
Reviewed-by: Ray Ni 

commit c9d72628432126cbce58a48b440e4944baa4beab
Author: Pavana.K 
Date:   Thu Jan 2 20:30:27 2020 +

CryptoPkg: Support for SHA384 & SHA512 RSA signing schemes

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2389

Currently RSA signing scheme support is available for MD5, SHA-1 or
SHA-256 algorithms.The fix is to extend this support for SHA384 and
SHA512.

Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Bob Feng 

Signed-off-by: Pavana.K 
Reviewed-by: Jian J Wang 

commit 396e791059f37062cbee85696e2b4186ec72a9e3
Author: Siyuan, Fu 
Date:   Fri Jan 3 14:59:27 2020 +0800

UefiCpuPkg: 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 145826

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

version targeted for testing:
 xen  c6c63b6dbffcdf32a59efa1fd6e578437fba06ff
baseline version:
 xen  00691c6c90b2fd28d7b7037baeb288f6801e6182

Last test of basis   145826  2020-01-08 22:06:27 Z0 days
Testing same since   145851  2020-01-09 07:53:33 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Juergen Gross 

jobs:
 build-amd64-xsm  

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  fae249d23413b2bf7d98a97d8f649cf7d102c1ae
baseline version:
 xen  09488b2bb76da2c78b9e25c7041e004baba1ca6a

Last test of basis   145858  2020-01-09 11:01:55 Z0 days
Testing same since   145867  2020-01-09 15:00:38 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 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 :

To xenbits.xen.org:/home/xen/git/xen.git
   09488b2bb7..fae249d234  fae249d23413b2bf7d98a97d8f649cf7d102c1ae -> smoke

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  

Re: [Xen-devel] [PATCH v2 2/2] libxl: Add new "notify-only" childproc mode

[George Dunlap]

On 1/9/20 12:12 PM, George Dunlap wrote:
> libxl needs to be able to know when processes it forks have completed.
> 
> At the moment, libxl has two basic mode (with some variations).  In
> one mode -- libxl_sigchld_owner_libxl* -- libxl sets up its own
> SIGCHLD signal handler, and also handles the event loop that allows
> libxl to safely block until the child in question is finished (using a
> self-pipe for the SIGCHLD handler to notify the waiters that it's time
> to look for reaped children).
> 
> In the other mode, libxl does not set up the SIGCHLD handler, nor does
> it do anything with processing the event loop; it expects the library
> caller to handle the event loop itself.
> 
> The golang runtime manages its own processes, and thus must use
> SIGCHLD itself; and it has an easy way for other users to get SIGCHLD
> notifications.  However, because its event loop is hidden away behind
> abstractions, it's not easy to hook into; and there's no need -- the
> golang runtime assumes that C function calls may block, and handles
> everything behind the scenes.

FWIW, attached is a C program that behaves as I think golang would
behave, which hangs in `mainloop` mode.

It's actually got two modes: Run it without any arguments, and it will
run in "default" mode (not setting up a SIGCHLD nor setting
childproc_mode);  run with at least one argument (whatever it is), it
will run in `mainloop` mode, and hang after the second SIGCHLD event.

 -George
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

char * malloc_copy(const char *src) {
  int len = strlen(src);
  char * dst = malloc(strlen(src)+1);

  strncpy(dst, src, len);

  return dst;
}

libxl_ctx *ctx;

int self_pipe_wakeup(int fd)
{
/* Called from signal handlers, so needs to be async-signal-safe */
static const char buf[1] = "";

for (;;) {
int r = write(fd, buf, 1);
if (r==1) return 0;
assert(r==-1);
if (errno == EINTR) continue;
if (errno == EWOULDBLOCK) return 0;
if (!errno) abort();
return errno;
}
}

int self_pipe_eatall(int fd)
{
char buf[256];
for (;;) {
int r = read(fd, buf, sizeof(buf));
if (r == sizeof(buf)) continue;
if (r >= 0) return 0;
assert(r == -1);
if (errno == EINTR) continue;
if (errno == EWOULDBLOCK) return 0;
assert(errno);
return errno;
}
}

int sigchld_selfpipe[2];

static void *sigchld_helper(void *fd) {
struct pollfd pfd;
int r;

pfd.fd = (int)(unsigned long)fd;
pfd.events = POLLIN | POLLHUP;

while (true) {
// Wait for a sigchld on [0]
fprintf(stderr, "Waiting for self-pipe\n");
r = poll(, 1, -1);
if (r < 0) {
if (errno == EINTR)
continue;
perror("poll");
return NULL;
}
if (pfd.revents == POLLHUP) {
fprintf(stderr, "Received POLLHUP, closing helper\n");
return NULL;
}
fprintf(stderr, "Self-pipe received, calling libxl_childproc_sigchld_occurred\n");
self_pipe_eatall(pfd.fd);
libxl_childproc_sigchld_occurred(ctx);
}

return NULL;
}

static void sigchld_handler(int signo) {
// Signal on pipe [1]
fprintf(stderr, "SIGCHLD received, self-signaling\n");
self_pipe_wakeup(sigchld_selfpipe[1]);
}

void setup_sigchld(void) {
struct sigaction ours, old;
pthread_t t;
int i, flags, r;

// Get self-signal pipe
if (pipe(sigchld_selfpipe) < 0) {
perror("Failed to create a pipe");
exit(1);
}

r = pthread_create(, NULL, sigchld_helper, (void *)(unsigned long)sigchld_selfpipe[0]);
if (r < 0) {
perror("Creating helper thread");
exit(1);
}

// Make non-blocking
for (i = 0; i < 2; i++) {
int fd = sigchld_selfpipe[i];
flags = fcntl(fd, F_GETFL);
if (flags == -1) {
perror("Getting block flags");
exit(1);
}

flags |= O_NONBLOCK;

r = fcntl(fd, F_SETFL, flags);
if (flags == -1) {
perror("Setting pipe non-blocking");
exit(1);
}
}

memset(,0,sizeof(ours));
ours.sa_handler = sigchld_handler;
sigemptyset(_mask);
ours.sa_flags = SA_NOCLDSTOP | SA_RESTART;
r = sigaction(SIGCHLD, , );
assert(!r);
}

int main(int argc, char * argv[]) {
int rc;
xentoollog_logger_stdiostream * xtl;
libxl_domain_config cconfig;
uint32_t domid;
bool mainloop = false;

if (argc > 1)
mainloop=true;

if (mainloop)
setup_sigchld();

xtl = xtl_createlogger_stdiostream(stderr, XTL_DEBUG, 0);
rc = libxl_ctx_alloc(, LIBXL_VERSION, 0, (xentoollog_logger*)xtl);
if (rc) {
fprintf(stderr, "Getting libxl_ctx: %d", rc);
exit(1);
}

if (mainloop) {
libxl_childproc_hooks *cp = malloc(sizeof(*cp));

cp->chldowner = 

Re: [Xen-devel] [PATCH] tools/Rules.mk: fix distclean

[Wei Liu]

On Thu, Jan 09, 2020 at 02:02:55PM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Wei Liu 
> > Sent: 09 January 2020 13:52
> > To: Durrant, Paul 
> > Cc: xen-devel@lists.xenproject.org; Ian Jackson
> > ; Wei Liu ; Anthony PERARD
> > 
> > Subject: Re: [PATCH] tools/Rules.mk: fix distclean
> > 
> > On Thu, Jan 09, 2020 at 11:15:05AM +, Paul Durrant wrote:
> > > Running 'make distclean' under tools will currently result in:
> > >
> > > tools/Rules.mk:245: *** You have to run ./configure before building or
> > installing the tools.  Stop.
> > >
> > > This patch adds 'distclean', 'subdir-distclean%' and 'subdir-clean%' to
> > > no-configure-targets, which allows 'make distclean' to run to
> > completion.
> > >
> > > Signed-off-by: Paul Durrant 
> > 
> > Fixes: 00691c6c90b
> > 
> > Sorry for not noticing the breakage while reviewing that patch.
> > 
> 
> Ok. I'm sure that could be added at commit if there are no other changes 
> needed.

Yes. Sure.

> 
> > Is there a way to pattern match all targets containing "clean"?
> > 
> > (Would have looked into it myself but -ETIME today)
> 
> I couldn't persuade filter to match against patterns with multiple %
> so this was the best I could come up with.
> 

OK.

Wei.

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

Re: [Xen-devel] [PATCH v2] arm64: xen: Use modern annotations for assembly functions

[Will Deacon]

On Thu, Jan 09, 2020 at 08:33:37AM -0800, Stefano Stabellini wrote:
> On Thu, 9 Jan 2020, Catalin Marinas wrote:
> > On Wed, Jan 08, 2020 at 03:55:52PM +, Will Deacon wrote:
> > > On Thu, Dec 19, 2019 at 01:07:50PM -0800, Stefano Stabellini wrote:
> > > > On Thu, 19 Dec 2019, Mark Brown wrote:
> > > > > In an effort to clarify and simplify the annotation of assembly 
> > > > > functions
> > > > > in the kernel new macros have been introduced. These replace ENTRY and
> > > > > ENDPROC. Update the annotations in the xen code to the new macros.
> > > > > 
> > > > > Signed-off-by: Mark Brown 
> > > > > Reviewed-by: Julien Grall 
> > > > > Reviewed-by: Stefano Stabellini 
> > > > 
> > > > Thank you!
> > > > 
> > > > > ---
> > > > >  arch/arm64/xen/hypercall.S | 8 
> > > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > 
> > > Is this going via the Xen tree, or shall I queue it along with the other
> > > asm annotation patches in the arm64 tree? I don't see it in -next yet.
> > 
> > Since it has been reviewed by the Xen maintainers, just queue it via the
> > arm64 tree.
> 
> Yes, that's fine by me

Done. Will update the branch tomorrow.

Cheers,

Will

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

Re: [Xen-devel] [PATCH v2] arm64: xen: Use modern annotations for assembly functions

[Stefano Stabellini]

On Thu, 9 Jan 2020, Catalin Marinas wrote:
> On Wed, Jan 08, 2020 at 03:55:52PM +, Will Deacon wrote:
> > On Thu, Dec 19, 2019 at 01:07:50PM -0800, Stefano Stabellini wrote:
> > > On Thu, 19 Dec 2019, Mark Brown wrote:
> > > > In an effort to clarify and simplify the annotation of assembly 
> > > > functions
> > > > in the kernel new macros have been introduced. These replace ENTRY and
> > > > ENDPROC. Update the annotations in the xen code to the new macros.
> > > > 
> > > > Signed-off-by: Mark Brown 
> > > > Reviewed-by: Julien Grall 
> > > > Reviewed-by: Stefano Stabellini 
> > > 
> > > Thank you!
> > > 
> > > > ---
> > > >  arch/arm64/xen/hypercall.S | 8 
> > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > Is this going via the Xen tree, or shall I queue it along with the other
> > asm annotation patches in the arm64 tree? I don't see it in -next yet.
> 
> Since it has been reviewed by the Xen maintainers, just queue it via the
> arm64 tree.

Yes, that's fine by me

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

[Xen-devel] [PATCH] x86/smp: use APIC ALLBUT destination shorthand when possible

[Roger Pau Monne]

If the IPI destination mask matches the mask of online CPUs use the
APIC ALLBUT destination shorthand in order to send an IPI to all CPUs
on the system except the current one. This can only be safely used
when no CPU hotplug or unplug operations are taking place, no offline
CPUs or those have been onlined and parked and finally when all CPUs
in the system have been accounted for (ie: the number of CPUs doesn't
exceed NR_CPUS and APIC IDs are below MAX_APICS).

This is specially beneficial when using the PV shim, since using the
shorthand avoids performing an APIC register write (or multiple ones
if using xAPIC mode) for each destination when doing a global TLB
flush.

The lock time of flush_lock on a 32 vCPU guest using the shim without
the shorthand is:

Global lock flush_lock: addr=82d0804b21c0, lockval=f602f602, not locked
  lock:228455938(79406065573135), block:205908580(556416605761539)

Average lock time: 347577ns

While the same guest using the shorthand:

Global lock flush_lock: addr=82d0804b41c0, lockval=d9c4d9bc, cpu=12
  lock:1890775(416719148054), block:1663958(2500161282949)

Average lock time: 220395ns

Approximately a 1/3 improvement in the lock time.

Note that this requires locking the CPU maps (get_cpu_maps) which uses
a trylock. This is currently safe as all users of cpu_add_remove_lock
do a trylock, but will need reevaluating if non-trylock users appear.

Also there's some code movement of __prepare_ICR and
__default_send_IPI_shortcut, which is a non-functional change but I
didn't feel like it should be split to a separate patch.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Move the shorthand logic to send_IPI_mask.
 - Check interrupts are enabled before trying to get the cpu maps
   lock.
 - Move __prepare_ICR and __default_send_IPI_shortcut.
---
 xen/arch/x86/acpi/boot.c  |  1 +
 xen/arch/x86/mpparse.c|  5 +++
 xen/arch/x86/smp.c| 86 +++
 xen/include/asm-x86/smp.h |  2 +
 4 files changed, 68 insertions(+), 26 deletions(-)

diff --git a/xen/arch/x86/acpi/boot.c b/xen/arch/x86/acpi/boot.c
index 15542a9bdf..88e1a89ff0 100644
--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -103,6 +103,7 @@ acpi_parse_x2apic(struct acpi_subtable_header *header, 
const unsigned long end)
   processor->lapic_flags & ACPI_MADT_ENABLED
   ? KERN_WARNING "WARNING: " : KERN_INFO,
   processor->local_apic_id, processor->uid);
+   cpu_overflow = true;
/*
 * Must not return an error here, to prevent
 * acpi_table_parse_entries() from terminating early.
diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
index f057d9162f..8d7739fbf4 100644
--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -66,6 +66,9 @@ static unsigned int __initdata disabled_cpus;
 /* Bitmask of physically existing CPUs */
 physid_mask_t phys_cpu_present_map;
 
+/* Record whether CPUs haven't been added due to overflows. */
+bool __read_mostly cpu_overflow;
+
 void __init set_nr_cpu_ids(unsigned int max_cpus)
 {
unsigned int tot_cpus = num_processors + disabled_cpus;
@@ -160,6 +163,7 @@ static int MP_processor_info_x(struct mpc_config_processor 
*m,
printk_once(XENLOG_WARNING
"WARNING: NR_CPUS limit of %u reached - ignoring 
further processors\n",
nr_cpu_ids);
+   cpu_overflow = true;
return -ENOSPC;
}
 
@@ -167,6 +171,7 @@ static int MP_processor_info_x(struct mpc_config_processor 
*m,
&& genapic.name == apic_default.name) {
printk_once(XENLOG_WARNING
"WARNING: CPUs limit of 8 reached - ignoring futher 
processors\n");
+   cpu_overflow = true;
return -ENOSPC;
}
 
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index c8e5913e47..6510dd84ab 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -8,6 +8,7 @@
  * later.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -23,6 +24,31 @@
 #include 
 #include 
 
+static inline int __prepare_ICR(unsigned int shortcut, int vector)
+{
+return APIC_DM_FIXED | shortcut | vector;
+}
+
+static void __default_send_IPI_shortcut(unsigned int shortcut, int vector,
+unsigned int dest)
+{
+unsigned int cfg;
+
+/*
+ * Wait for idle.
+ */
+apic_wait_icr_idle();
+
+/*
+ * prepare target chip field
+ */
+cfg = __prepare_ICR(shortcut, vector) | dest;
+/*
+ * Send the IPI. The write to APIC_ICR fires this off.
+ */
+apic_write(APIC_ICR, cfg);
+}
+
 /*
  * send_IPI_mask(cpumask, vector): sends @vector IPI to CPUs in @cpumask,
  * excluding the local CPU. @cpumask may be empty.
@@ -30,7 +56,40 @@
 
 void send_IPI_mask(const cpumask_t *mask, int vector)
 {
-

Re: [Xen-devel] [PATCH v4 15/18] xen/mem_sharing: VM forking

[Tamas K Lengyel]

On Thu, Jan 9, 2020 at 9:03 AM Jan Beulich  wrote:
>
> On 09.01.2020 16:57, Tamas K Lengyel wrote:
> > On Thu, Jan 9, 2020 at 8:34 AM Jan Beulich  wrote:
> >>
> >> On 09.01.2020 16:10, Roger Pau Monné wrote:
> >>> On Thu, Jan 09, 2020 at 06:41:12AM -0700, Tamas K Lengyel wrote:
>  On Thu, Jan 9, 2020 at 3:29 AM Julien Grall  wrote:
> >
> > Hi Tamas,
> >
> > On 08/01/2020 17:14, Tamas K Lengyel wrote:
> >> +static int mem_sharing_fork(struct domain *d, struct domain *cd)
> >> +{
> >> +int rc;
> >> +
> >> +if ( !d->controller_pause_count &&
> >> + (rc = domain_pause_by_systemcontroller(d)) )
> >
> > AFAIU, the parent domain will be paused if it wasn't paused before and
> > this will not be unpaused by the same hypercall. Right?
> 
>  Yes, it needs to remain paused as long as there are forks active from
>  it. Afterwards it can be unpaused.
> >>>
> >>> If you want the parent domain to remain paused for as long as the
> >>> forks are active, shouldn't each fork increment the pause count on
> >>> creation and decrement it when the fork is destroyed?
> >>>
> >>> How can you assure no other operation or entity has incremented
> >>> controller_pause_count temporary and is likely to decrement it at some
> >>> point while forks are still active?
> >>
> >> The _by_systemcontroller variants look wrong to be used here anyway.
> >> Why is this not simply domain_{,un}pause()?
> >>
> >
> > My reasoning was that by default the user should pause the parent VM
> > before forking. This sanity checks just mimicks that step in case the
> > user didn't do that already. But I guess either would work, I don't
> > really see much difference between the two.
>
> The main difference is that the one you currently use updates
> d->controller_pause_count, which can be updated by other domctls, but
> which shouldn't be updated behind the back of a component in Xen which
> needs the entity paused.
>

Alright, I'll switch it.

Thanks,
Tamas

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

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 2649a735b249e54a4ddd7bd2b8d62bfe77e8d6da
baseline version:
 ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb

Last test of basis   145767  2020-01-08 00:39:09 Z1 days
Failing since145774  2020-01-08 02:50:20 Z1 days8 attempts
Testing same since   145854  2020-01-09 08:39:33 Z0 days1 attempts


People who touched revisions under test:
  Ashish Singhal 
  Pavana.K 
  Philippe Mathieu-Daud? 
  Philippe Mathieu-Daude 
  Siyuan Fu 
  Siyuan, Fu 

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



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

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

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

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


Not pushing.


commit 2649a735b249e54a4ddd7bd2b8d62bfe77e8d6da
Author: Philippe Mathieu-Daud? 
Date:   Thu Jan 2 20:16:56 2020 +0800

BaseTools/PatchCheck.py: Ignore CR and LF characters in subject length

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=113

Strip the trailing characters before checking the subject line is
less than 72 characters.

Fixes: e61406708c83f
Cc: Liming Gao 
Cc: Jordan Justen 
Reviewed-by: Jordan Justen 
Reviewed-by: Bob Feng 

Signed-off-by: Philippe Mathieu-Daude 

commit 972d88726410e21b1fff1a528854202c67e97ef1
Author: Ashish Singhal 
Date:   Tue Dec 24 10:57:47 2019 +0800

MdeModulePkg: Add EDK2 Platform Boot Manager Protocol

Add edk2 platform boot manager protocol which would have platform
specific refreshes to the auto enumerated as well as NV boot options
for the platform.

Signed-off-by: Ashish Singhal 
Reviewed-by: Ray Ni 

commit c9d72628432126cbce58a48b440e4944baa4beab
Author: Pavana.K 
Date:   Thu Jan 2 20:30:27 2020 +

CryptoPkg: Support for SHA384 & SHA512 RSA signing schemes

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2389

Currently RSA signing scheme support is available for MD5, SHA-1 or
SHA-256 algorithms.The fix is to extend this support for SHA384 and
SHA512.

Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Bob Feng 

Signed-off-by: Pavana.K 
Reviewed-by: Jian J Wang 

commit 396e791059f37062cbee85696e2b4186ec72a9e3
Author: Siyuan, Fu 
Date:   Fri Jan 3 14:59:27 2020 +0800

UefiCpuPkg: Always load microcode patch on AP processor.

This patch updates the microcode loader to always perform a microcode
detect and load on both BSP and AP processor. This is to fix a potential
microcode revision mismatch issue in below situation:
1. Assume there are two microcode co-exists in flash: one production
   version and one debug version microcode.
2. FIT loads production microcode to BSP and all AP.
3. UefiCpuPkg loader loads debug microcode to BSP, and skip the loading
   on AP.
As a result, different microcode patches are loaded to BSP and AP, and
trigger microcode mismatch error during OS boot.

BZ link: https://bugzilla.tianocore.org/show_bug.cgi?id=2431

Cc: Eric Dong 
Cc: Ray Ni 
Signed-off-by: Siyuan Fu 
Reviewed-by: Eric Dong 

commit 08a475df10b75f84cdeb9b11e38f8eee9b5c048d
Author: Siyuan Fu 
Date:   Fri Jan 3 15:11:51 2020 +0800

UefiCpuPkg: Remove alignment check when calculate microcode size.

This patch removes the unnecessary alignment check on microcode patch
   

Re: [Xen-devel] [PATCH v4 15/18] xen/mem_sharing: VM forking

[Jan Beulich]

On 09.01.2020 16:57, Tamas K Lengyel wrote:
> On Thu, Jan 9, 2020 at 8:34 AM Jan Beulich  wrote:
>>
>> On 09.01.2020 16:10, Roger Pau Monné wrote:
>>> On Thu, Jan 09, 2020 at 06:41:12AM -0700, Tamas K Lengyel wrote:
 On Thu, Jan 9, 2020 at 3:29 AM Julien Grall  wrote:
>
> Hi Tamas,
>
> On 08/01/2020 17:14, Tamas K Lengyel wrote:
>> +static int mem_sharing_fork(struct domain *d, struct domain *cd)
>> +{
>> +int rc;
>> +
>> +if ( !d->controller_pause_count &&
>> + (rc = domain_pause_by_systemcontroller(d)) )
>
> AFAIU, the parent domain will be paused if it wasn't paused before and
> this will not be unpaused by the same hypercall. Right?

 Yes, it needs to remain paused as long as there are forks active from
 it. Afterwards it can be unpaused.
>>>
>>> If you want the parent domain to remain paused for as long as the
>>> forks are active, shouldn't each fork increment the pause count on
>>> creation and decrement it when the fork is destroyed?
>>>
>>> How can you assure no other operation or entity has incremented
>>> controller_pause_count temporary and is likely to decrement it at some
>>> point while forks are still active?
>>
>> The _by_systemcontroller variants look wrong to be used here anyway.
>> Why is this not simply domain_{,un}pause()?
>>
> 
> My reasoning was that by default the user should pause the parent VM
> before forking. This sanity checks just mimicks that step in case the
> user didn't do that already. But I guess either would work, I don't
> really see much difference between the two.

The main difference is that the one you currently use updates
d->controller_pause_count, which can be updated by other domctls, but
which shouldn't be updated behind the back of a component in Xen which
needs the entity paused.

Jan

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

Re: [Xen-devel] [PATCH v2] arm64: xen: Use modern annotations for assembly functions

[Catalin Marinas]

On Wed, Jan 08, 2020 at 03:55:52PM +, Will Deacon wrote:
> On Thu, Dec 19, 2019 at 01:07:50PM -0800, Stefano Stabellini wrote:
> > On Thu, 19 Dec 2019, Mark Brown wrote:
> > > In an effort to clarify and simplify the annotation of assembly functions
> > > in the kernel new macros have been introduced. These replace ENTRY and
> > > ENDPROC. Update the annotations in the xen code to the new macros.
> > > 
> > > Signed-off-by: Mark Brown 
> > > Reviewed-by: Julien Grall 
> > > Reviewed-by: Stefano Stabellini 
> > 
> > Thank you!
> > 
> > > ---
> > >  arch/arm64/xen/hypercall.S | 8 
> > >  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> Is this going via the Xen tree, or shall I queue it along with the other
> asm annotation patches in the arm64 tree? I don't see it in -next yet.

Since it has been reviewed by the Xen maintainers, just queue it via the
arm64 tree.

-- 
Catalin

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

Re: [Xen-devel] [PATCH v4 15/18] xen/mem_sharing: VM forking

[Tamas K Lengyel]

On Thu, Jan 9, 2020 at 8:34 AM Jan Beulich  wrote:
>
> On 09.01.2020 16:10, Roger Pau Monné wrote:
> > On Thu, Jan 09, 2020 at 06:41:12AM -0700, Tamas K Lengyel wrote:
> >> On Thu, Jan 9, 2020 at 3:29 AM Julien Grall  wrote:
> >>>
> >>> Hi Tamas,
> >>>
> >>> On 08/01/2020 17:14, Tamas K Lengyel wrote:
>  +static int mem_sharing_fork(struct domain *d, struct domain *cd)
>  +{
>  +int rc;
>  +
>  +if ( !d->controller_pause_count &&
>  + (rc = domain_pause_by_systemcontroller(d)) )
> >>>
> >>> AFAIU, the parent domain will be paused if it wasn't paused before and
> >>> this will not be unpaused by the same hypercall. Right?
> >>
> >> Yes, it needs to remain paused as long as there are forks active from
> >> it. Afterwards it can be unpaused.
> >
> > If you want the parent domain to remain paused for as long as the
> > forks are active, shouldn't each fork increment the pause count on
> > creation and decrement it when the fork is destroyed?
> >
> > How can you assure no other operation or entity has incremented
> > controller_pause_count temporary and is likely to decrement it at some
> > point while forks are still active?
>
> The _by_systemcontroller variants look wrong to be used here anyway.
> Why is this not simply domain_{,un}pause()?
>

My reasoning was that by default the user should pause the parent VM
before forking. This sanity checks just mimicks that step in case the
user didn't do that already. But I guess either would work, I don't
really see much difference between the two.

Tamas

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

Re: [Xen-devel] [PATCH v4 15/18] xen/mem_sharing: VM forking

[Tamas K Lengyel]

On Thu, Jan 9, 2020 at 8:10 AM Roger Pau Monné  wrote:
>
> On Thu, Jan 09, 2020 at 06:41:12AM -0700, Tamas K Lengyel wrote:
> > On Thu, Jan 9, 2020 at 3:29 AM Julien Grall  wrote:
> > >
> > > Hi Tamas,
> > >
> > > On 08/01/2020 17:14, Tamas K Lengyel wrote:
> > > > +static int mem_sharing_fork(struct domain *d, struct domain *cd)
> > > > +{
> > > > +int rc;
> > > > +
> > > > +if ( !d->controller_pause_count &&
> > > > + (rc = domain_pause_by_systemcontroller(d)) )
> > >
> > > AFAIU, the parent domain will be paused if it wasn't paused before and
> > > this will not be unpaused by the same hypercall. Right?
> >
> > Yes, it needs to remain paused as long as there are forks active from
> > it. Afterwards it can be unpaused.
>
> If you want the parent domain to remain paused for as long as the
> forks are active, shouldn't each fork increment the pause count on
> creation and decrement it when the fork is destroyed?

That would work.

>
> How can you assure no other operation or entity has incremented
> controller_pause_count temporary and is likely to decrement it at some
> point while forks are still active?

Right now we don't do sanity checks. It is just expected that the user
is not doing anything insane like that - I would argue that for an
experimental system (one that is even hidden behind CONFIG_EXPERT) an
assumption like that is safe to make. But doing the pause/unpause
combo you describe above is pretty simple and should get the job done.

Tamas

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

Re: [Xen-devel] Xen 4.14 and future work

[Xia, Hongyan]

On Mon, 2019-12-02 at 19:51 +, Andrew Cooper wrote:
> ...
> 
> Other areas in need of work is the boot time directmap at 0 (which
> hides
> NULL pointer deferences during boot), and the correct handling of
> %dr6
> for all kinds of guests.
> 

Sorry for the late reply to this thread. Talking about the directmap,
will we have time and engineering power to look at the direct map
removal series? I have been maintaining, testing and benchmarking it
since late 4.13 and it would be nice to have (part of) it in 4.14.

The bulk of the series is moving things from xenheap to domheap site by
site, which should not be difficult to review. The direct map is only
removed at the final stage of the series, so before that comes in,
domheap is still mapped via the direct map and there will not even be
performance differences. I am thinking that we could at least merge
most of the transitions to domheap in 4.14.

Hongyan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 15/18] xen/mem_sharing: VM forking

[Jan Beulich]

On 09.01.2020 16:10, Roger Pau Monné wrote:
> On Thu, Jan 09, 2020 at 06:41:12AM -0700, Tamas K Lengyel wrote:
>> On Thu, Jan 9, 2020 at 3:29 AM Julien Grall  wrote:
>>>
>>> Hi Tamas,
>>>
>>> On 08/01/2020 17:14, Tamas K Lengyel wrote:
 +static int mem_sharing_fork(struct domain *d, struct domain *cd)
 +{
 +int rc;
 +
 +if ( !d->controller_pause_count &&
 + (rc = domain_pause_by_systemcontroller(d)) )
>>>
>>> AFAIU, the parent domain will be paused if it wasn't paused before and
>>> this will not be unpaused by the same hypercall. Right?
>>
>> Yes, it needs to remain paused as long as there are forks active from
>> it. Afterwards it can be unpaused.
> 
> If you want the parent domain to remain paused for as long as the
> forks are active, shouldn't each fork increment the pause count on
> creation and decrement it when the fork is destroyed?
> 
> How can you assure no other operation or entity has incremented
> controller_pause_count temporary and is likely to decrement it at some
> point while forks are still active?

The _by_systemcontroller variants look wrong to be used here anyway.
Why is this not simply domain_{,un}pause()?

Jan

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

Re: [Xen-devel] [PATCH 10/12] docs/migration: Specify X86_{CPUID, MSR}_POLICY records

[Andrew Cooper]

On 03/01/2020 15:30, Jan Beulich wrote:
> On 03.01.2020 15:55, Andrew Cooper wrote:
>> On 03/01/2020 14:49, Jan Beulich wrote:
>>> On 24.12.2019 16:19, Andrew Cooper wrote:
 @@ -439,6 +449,34 @@ def verify_record_static_data_end(self, content):
  raise RecordError("Static data end record found in v2 stream")
  
  
 +def verify_record_x86_cpuid_policy(self, content):
 +""" x86 CPUID policy record """
 +
 +if self.version < 3:
 +raise RecordError("x86 CPUID policy record found in v2 
 stream")
 +
 +sz = calcsize(X86_CPUID_POLICY_FORMAT)
 +contentsz = len(content)
 +
 +if contentsz < sz or (contentsz % sz) != 0:
 +raise RecordError("Record length %u, expected multiple of %u" 
 %
 +  (contentsz, sz))
 +
 +
 +def verify_record_x86_msr_policy(self, content):
 +""" x86 MSR policy record """
 +
 +if self.version < 3:
 +raise RecordError("x86 MSR policy record found in v2 stream")
 +
 +sz = calcsize(X86_MSR_POLICY_FORMAT)
 +contentsz = len(content)
 +
 +if contentsz < sz or (contentsz % sz) != 0:
 +raise RecordError("Record length %u, expected multiple of %u" 
 %
 +  (contentsz, sz))
>>> While I can't even see a theoretical case of the CPUID array
>>> having zero elements, is it really entirely implausible to have
>>> an empty MSRs array? I.e. wouldn't the left side of the "or"
>>> better go away?
>> MSRs will never have 0 entries, because unlike CPUID, we can't omit
>> records with 0s as their content.  This becomes ambiguous when the
>> policy default is nonzero.
> Isn't the same true for CPUID, in particular some of the non-boolean
> fields?

I perhaps misspoke.  We can omit CPUID leave(s) based on information
already sent (max_leaf and/or the absence of an enumerating feature). 
In these cases, the destination side can still fill the remainder in
with 0's.

Top level leaves without an encompassing feature do need sending in full.

The best practical example is for not sending all 63 subleaves of the
xsave state leaf, when most of them are outside of the policy XCR0|XSS bits.

>
>> When we do gain more MSRs, I will see about organising elision based on
>> CPUID features, so we don't have to send a 0 for every single MSR in the
>> policy, but MSRs without CPUID enumeration must always be sent.
>>
>> This means that the one MSR we have currently (MSR_INTEL_PLATFORM_INFO
>> for CPUID Faulting, which we also virtualise on AMD hardware) shall
>> unconditionally be present forever more.
> Hmm, yes. Still the special casing of there needing to be at least
> one entry looks a little odd here (and also for CPUID). I would
> find it more logical if there was just the remainder-must-be-zero
> check. But this is libxc code, so I'm not the one to really judge
> anyway.

The migration stream is split into records with no playload (markers
with external control flow meaning), and data records, which have a payload.

It is an error for a data record to have no payload, because it means
there is a source side generation bug.  In the case of Xen returning 0
MSRs, the record would be omitted entirely, rather than be sent with 0
MSRs worth of data.

~Andrew

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 

Re: [Xen-devel] [PATCH v4 15/18] xen/mem_sharing: VM forking

[Roger Pau Monné]

On Thu, Jan 09, 2020 at 06:41:12AM -0700, Tamas K Lengyel wrote:
> On Thu, Jan 9, 2020 at 3:29 AM Julien Grall  wrote:
> >
> > Hi Tamas,
> >
> > On 08/01/2020 17:14, Tamas K Lengyel wrote:
> > > +static int mem_sharing_fork(struct domain *d, struct domain *cd)
> > > +{
> > > +int rc;
> > > +
> > > +if ( !d->controller_pause_count &&
> > > + (rc = domain_pause_by_systemcontroller(d)) )
> >
> > AFAIU, the parent domain will be paused if it wasn't paused before and
> > this will not be unpaused by the same hypercall. Right?
> 
> Yes, it needs to remain paused as long as there are forks active from
> it. Afterwards it can be unpaused.

If you want the parent domain to remain paused for as long as the
forks are active, shouldn't each fork increment the pause count on
creation and decrement it when the fork is destroyed?

How can you assure no other operation or entity has incremented
controller_pause_count temporary and is likely to decrement it at some
point while forks are still active?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 06/12] docs/migration Specify migration v3 and STATIC_DATA_END

[Andrew Cooper]

On 03/01/2020 14:44, Jan Beulich wrote:
> On 24.12.2019 16:19, Andrew Cooper wrote:
>> Migration data can be split into two parts - that which is invariant of
>> guest execution, and that which is not.  Separate these two with the
>> STATIC_DATA_END record.
>>
>> The short term, we want to move the x86 CPU Policy data into the stream.
>> In the longer term, we want to provisionally send the static data only
>> to the destination as a more robust compatibility check.  In both cases,
>> we will want a callback into the higher level toolstack.
>>
>> Mandate the presence of the STATIC_DATA_END record, and declare this v3,
>> along with instructions for how to compatibly interpret a v2 stream.
> What doesn't become clear (to me) from all of the above is why this
> record is needed (wanted), and hence why it is to be mandatory.
> After all ...
>
>> @@ -675,9 +694,23 @@ A typical save record for an x86 HVM guest image would 
>> look like:
>>  HVM_PARAMS must precede HVM_CONTEXT, as certain parameters can affect
>>  the validity of architectural state in the context.
>>  
>> +Compatibility with older versions
>> +=
>> +
>> +v3 compat with v2
>> +-
>> +
>> +A v3 stream is compatible with a v2 stream, but mandates the presense of a
>> +STATIC_DATA_END record ahead of any memory/register content.  This is to 
>> ease
>> +the introduction of new static configuration records over time.
>> +
>> +A v3-compatible reciever interpreting a v2 stream should infer the position 
>> of
>> +STATIC_DATA_END based on finding the first X86_PV_P2M_FRAMES record (for PV
>> +guests), or PAGE_DATA record (for HVM guests) and behave as if 
>> STATIC_DATA_END
>> +had been sent.
> ... you already imply a v3 receiver can deal with its absence.

It provides an easier way to reason about the stream, as new features
get added, and this is helpful when debugging.

Most importantly however, it offers a clean way to deprecate/remove
support for obsolete senders.

~Andrew

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

Re: [Xen-devel] [PATCH v2] x86/boot: Rationalise stack handling during early boot

[Jan Beulich]

On 09.01.2020 12:51, Andrew Cooper wrote:
> The top (numerically higher addresses) of cpu0_stack[] contains the BSP's
> cpu_info block.  Logic in Xen expects this to be initialised to 0, but this
> area of stack is also used during early boot.
> 
> Update the head.S code to avoid using the cpu_info block.  Additionally,
> update the stack_start variable to match, which avoids __high_start() and
> efi_arch_post_exit_boot() needing to make the adjustment manually.
> 
> Finally, leave a big warning by the BIOS BSS initialisation, because it is by
> no means obvious that the stack doesn't survive the REP STOS.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 

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

Re: [Xen-devel] [PATCH v2 2/2] xen: make CONFIG_DEBUG_LOCKS usable without CONFIG_DEBUG

[Jan Beulich]

On 09.01.2020 14:48, Juergen Gross wrote:
> In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
> having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
> as it is using ASSERT(), however.
> 
> Fix that by using BUG_ON() instead of ASSERT() in rel_lock().
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jan Beulich 

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

Re: [Xen-devel] [PATCH] tools/Rules.mk: fix distclean

[Durrant, Paul]

> -Original Message-
> From: Wei Liu 
> Sent: 09 January 2020 13:52
> To: Durrant, Paul 
> Cc: xen-devel@lists.xenproject.org; Ian Jackson
> ; Wei Liu ; Anthony PERARD
> 
> Subject: Re: [PATCH] tools/Rules.mk: fix distclean
> 
> On Thu, Jan 09, 2020 at 11:15:05AM +, Paul Durrant wrote:
> > Running 'make distclean' under tools will currently result in:
> >
> > tools/Rules.mk:245: *** You have to run ./configure before building or
> installing the tools.  Stop.
> >
> > This patch adds 'distclean', 'subdir-distclean%' and 'subdir-clean%' to
> > no-configure-targets, which allows 'make distclean' to run to
> completion.
> >
> > Signed-off-by: Paul Durrant 
> 
> Fixes: 00691c6c90b
> 
> Sorry for not noticing the breakage while reviewing that patch.
> 

Ok. I'm sure that could be added at commit if there are no other changes needed.

> Is there a way to pattern match all targets containing "clean"?
> 
> (Would have looked into it myself but -ETIME today)

I couldn't persuade filter to match against patterns with multiple % so this 
was the best I could come up with.

  Paul

> 
> > ---
> > Cc: Ian Jackson 
> > Cc: Wei Liu 
> > ---
> >  tools/Rules.mk | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/Rules.mk b/tools/Rules.mk
> > index 31cf419ef4..52f47be3f8 100644
> > --- a/tools/Rules.mk
> > +++ b/tools/Rules.mk
> > @@ -239,7 +239,7 @@ subdir-all-% subdir-clean-% subdir-install-% subdir-
> uninstall-%: .phony
> >  subdir-distclean-%: .phony
> > $(MAKE) -C $* distclean
> >
> > -no-configure-targets := clean subtree-force-update-all %-dir-force-
> update
> > +no-configure-targets := distclean subdir-distclean% clean subdir-clean%
> subtree-force-update-all %-dir-force-update
> >  ifeq (,$(filter $(no-configure-targets),$(MAKECMDGOALS)))
> >  $(XEN_ROOT)/config/Tools.mk:
> > $(error You have to run ./configure before building or installing
> the tools)
> > --
> > 2.20.1
> >

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 

Re: [Xen-devel] [PATCH net-next] xen-netback: get rid of old udev related code

[Rich Persaud]

> On Dec 16, 2019, at 03:31, Jürgen Groß  wrote:
> 
> On 16.12.19 09:18, Durrant, Paul wrote:
>>> -Original Message-
>>> From: Jürgen Groß 
>>> Sent: 16 December 2019 08:10
>>> To: Durrant, Paul ; David Miller
>>> 
>>> Cc: xen-devel@lists.xenproject.org; wei@kernel.org; linux-
>>> ker...@vger.kernel.org; net...@vger.kernel.org
>>> Subject: Re: [Xen-devel] [PATCH net-next] xen-netback: get rid of old udev
>>> related code
 On 13.12.19 11:12, Durrant, Paul wrote:
>> -Original Message-
>> From: Jürgen Groß 
>> Sent: 13 December 2019 10:02
>> To: Durrant, Paul ; David Miller
>> 
>> Cc: xen-devel@lists.xenproject.org; wei@kernel.org; linux-
>> ker...@vger.kernel.org; net...@vger.kernel.org
>> Subject: Re: [Xen-devel] [PATCH net-next] xen-netback: get rid of old
>>> udev
> related code
> On 13.12.19 10:24, Durrant, Paul wrote:
>>> -Original Message-
>>> From: Jürgen Groß 
>>> Sent: 13 December 2019 05:41
>>> To: David Miller ; Durrant, Paul
>>> 
>>> Cc: xen-devel@lists.xenproject.org; wei@kernel.org; linux-
>>> ker...@vger.kernel.org; net...@vger.kernel.org
>>> Subject: Re: [Xen-devel] [PATCH net-next] xen-netback: get rid of old
> udev
>>> related code
 On 12.12.19 20:05, David Miller wrote:
> From: Paul Durrant 
> Date: Thu, 12 Dec 2019 13:54:06 +
>> In the past it used to be the case that the Xen toolstack relied
 upon
>> udev to execute backend hotplug scripts. However this has not been
>> the
>> case for many releases now and removal of the associated code in
>> xen-netback shortens the source by more than 100 lines, and removes
 much
>> complexity in the interaction with the xenstore backend state.
>> NOTE: xen-netback is the only xenbus driver to have a functional
 uevent()
>> method. The only other driver to have a method at all is
>> pvcalls-back, and currently pvcalls_back_uevent() simply
>> returns
 0.
>> Hence this patch also facilitates further cleanup.
>> Signed-off-by: Paul Durrant 
> If userspace ever used this stuff, I seriously doubt you can remove
>> this
> even if it hasn't been used in 5+ years.
 Hmm, depends.
 This has been used by Xen tools in dom0 only. If the last usage has
>> been
 in a Xen version which is no longer able to run with current Linux in
 dom0 it could be removed. But I guess this would have to be a rather
>> old
 version of Xen (like 3.x?).
 Paul, can you give a hint since which Xen version the toolstack no
 longer relies on udev to start the hotplug scripts?
>>> The udev rules were in a file called tools/hotplug/Linux/xen-
>> backend.rules (in xen.git), and a commit from Roger removed the NIC
 rules
>> in 2012:
>>> commit 57ad6afe2a08a03c40bcd336bfb27e008e1d3e53
>> Xen 4.2
>>> The last commit I could find to that file modified its name to xen-
>> backend.rules.in, and this was finally removed by George in 2015:
>>> commit 2ba368d13893402b2f1fb3c283ddcc714659dd9b
>> Xen 4.6
>>> So, I think this means anyone using a version of the Xen tools within
>> recent memory will be having their hotplug scripts called directly by
>> libxl (and having udev rules present would actually be counter-
 productive,
>> as George's commit states and as I discovered the hard way when the
 change
>> was originally made).
>> The problem are systems with either old Xen versions (before Xen 4.2)
 or
>> with other toolstacks (e.g. Xen 4.4 with xend) which want to use a new
>> dom0 kernel.
>> And I'm not sure there aren't such systems (especially in case someone
>> wants to stick with xend).
> But would someone sticking with such an old toolstack expect to run on
 an unmodified upstream dom0? There has to be some way in which we can
 retire old code.
 As long as there are no hypervisor interface related issues
 prohibiting running dom0 unmodified I think the expectation to be
 able to use the kernel in that environment is fine.
>> I think we need a better policy in future then otherwise we will only 
>> collect baggage.
> 
> The Linux kernel policy regarding user interfaces and existing use cases
> is rather clear and we should not deviate without very strong reasons.
> 
>>> Another question coming up would be: how is this handled in a driver
>>> domain running netback? Which component is starting the hotplug script
>>> there? I don't think we can assume a standard Xen toolset in this case.
>>> So I'd rather leave this code as it is instead of breaking some rare
>>> but valid use cases.
>> I am not sure there is a standard. Do we 'support' driver domains with any 
>> sort of tools API or do they really just have to 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  09488b2bb76da2c78b9e25c7041e004baba1ca6a
baseline version:
 xen  c6c63b6dbffcdf32a59efa1fd6e578437fba06ff

Last test of basis   145822  2020-01-08 21:03:04 Z0 days
Testing same since   145858  2020-01-09 11:01:55 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Juergen Gross 
  Tao Xu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 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 :

To xenbits.xen.org:/home/xen/git/xen.git
   c6c63b6dbf..09488b2bb7  09488b2bb76da2c78b9e25c7041e004baba1ca6a -> smoke

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

Re: [Xen-devel] [PATCH] tools/Rules.mk: fix distclean

[Wei Liu]

On Thu, Jan 09, 2020 at 11:15:05AM +, Paul Durrant wrote:
> Running 'make distclean' under tools will currently result in:
> 
> tools/Rules.mk:245: *** You have to run ./configure before building or 
> installing the tools.  Stop.
> 
> This patch adds 'distclean', 'subdir-distclean%' and 'subdir-clean%' to
> no-configure-targets, which allows 'make distclean' to run to completion.
> 
> Signed-off-by: Paul Durrant 

Fixes: 00691c6c90b

Sorry for not noticing the breakage while reviewing that patch.

Is there a way to pattern match all targets containing "clean"?

(Would have looked into it myself but -ETIME today)

> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/Rules.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/Rules.mk b/tools/Rules.mk
> index 31cf419ef4..52f47be3f8 100644
> --- a/tools/Rules.mk
> +++ b/tools/Rules.mk
> @@ -239,7 +239,7 @@ subdir-all-% subdir-clean-% subdir-install-% 
> subdir-uninstall-%: .phony
>  subdir-distclean-%: .phony
>   $(MAKE) -C $* distclean
>  
> -no-configure-targets := clean subtree-force-update-all %-dir-force-update
> +no-configure-targets := distclean subdir-distclean% clean subdir-clean% 
> subtree-force-update-all %-dir-force-update
>  ifeq (,$(filter $(no-configure-targets),$(MAKECMDGOALS)))
>  $(XEN_ROOT)/config/Tools.mk:
>   $(error You have to run ./configure before building or installing the 
> tools)
> -- 
> 2.20.1
> 

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

[Xen-devel] [PATCH v2 0/2] xen: fix CONFIG_DEBUG_LOCKS

[Juergen Gross]

CONFIG_DEBUG_LOCKS is using ASSERT() for catching issues making it
depend on CONFIG_DEBUG.

This series fixes that by using BUG_ON() instead. In order not to lose
the rather nice debugging information which condition was hit add a
config option to include a message similar to the one ASSERT() is
printing in case of BUG_OM() triggering.

Juergen Gross (2):
  xen: add config option to include failing condition in BUG_ON()
message
  xen: make CONFIG_DEBUG_LOCKS usable without CONFIG_DEBUG

 xen/Kconfig.debug | 6 ++
 xen/common/spinlock.c | 2 +-
 xen/include/asm-x86/bug.h | 5 +++--
 xen/include/xen/lib.h | 5 +
 4 files changed, 15 insertions(+), 3 deletions(-)

-- 
2.16.4


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

[Xen-devel] [PATCH v2 2/2] xen: make CONFIG_DEBUG_LOCKS usable without CONFIG_DEBUG

[Juergen Gross]

In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
as it is using ASSERT(), however.

Fix that by using BUG_ON() instead of ASSERT() in rel_lock().

Signed-off-by: Juergen Gross 
---
 xen/common/spinlock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 286f916bca..344981c54a 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -86,7 +86,7 @@ static void got_lock(union lock_debug *debug)
 static void rel_lock(union lock_debug *debug)
 {
 if ( atomic_read(_debug) > 0 )
-ASSERT(debug->cpu == smp_processor_id());
+BUG_ON(debug->cpu != smp_processor_id());
 debug->cpu = SPINLOCK_NO_CPU;
 }
 
-- 
2.16.4


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

[Xen-devel] [PATCH v2 1/2] xen: add config option to include failing condition in BUG_ON() message

[Juergen Gross]

Today a triggering BUG_ON() will only print source file and line
information. Add the possibility to print the triggering condition like
ASSERT().

Do that by introducing BUG_ON_VERBOSE() and add a Kconfig option to
make BUG_ON use BUG_ON_VERBOSE().

Signed-off-by: Juergen Gross 
---
 xen/Kconfig.debug | 6 ++
 xen/include/asm-x86/bug.h | 5 +++--
 xen/include/xen/lib.h | 5 +
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index b3511e81a2..dfbcac575a 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -81,6 +81,12 @@ config PERF_ARRAYS
---help---
  Enables software performance counter array histograms.
 
+config DEBUG_BUGVERBOSE
+   bool "Verbose BUG_ON messages"
+   default DEBUG
+   ---help---
+ In case a BUG_ON triggers additionally print the triggering
+ condition on the console.
 
 config VERBOSE_DEBUG
bool "Verbose debug messages"
diff --git a/xen/include/asm-x86/bug.h b/xen/include/asm-x86/bug.h
index 9bb4a19420..46d282777f 100644
--- a/xen/include/asm-x86/bug.h
+++ b/xen/include/asm-x86/bug.h
@@ -60,10 +60,11 @@ struct bug_frame {
 
 
 #define WARN() BUG_FRAME(BUGFRAME_warn, __LINE__, __FILE__, 0, NULL)
-#define BUG() do {  \
-BUG_FRAME(BUGFRAME_bug,  __LINE__, __FILE__, 0, NULL);  \
+#define BUG_VERBOSE(msg) do {   \
+BUG_FRAME(BUGFRAME_bug,  __LINE__, __FILE__, 0, msg);   \
 unreachable();  \
 } while (0)
+#define BUG() BUG_VERBOSE(NULL)
 
 #define run_in_exception_handler(fn) BUG_FRAME(BUGFRAME_run_fn, 0, fn, 0, NULL)
 
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 8fbe84032d..e7770b0d24 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -8,7 +8,12 @@
 #include 
 #include 
 
+#define BUG_ON_VERBOSE(p) do { if (unlikely(p)) BUG_VERBOSE(#p);  } while (0)
+#ifdef CONFIG_DEBUG_BUGVERBOSE
+#define BUG_ON(p)  BUG_ON_VERBOSE(p)
+#else
 #define BUG_ON(p)  do { if (unlikely(p)) BUG();  } while (0)
+#endif
 #define WARN_ON(p) do { if (unlikely(p)) WARN(); } while (0)
 
 #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
-- 
2.16.4


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

Re: [Xen-devel] [PATCH v3 1/5] x86/hyperv: setup hypercall page

[Wei Liu]

On Wed, Jan 08, 2020 at 05:53:36PM +, Andrew Cooper wrote:
> On 08/01/2020 17:43, Wei Liu wrote:
> > On Tue, Jan 07, 2020 at 03:42:14PM +, Wei Liu wrote:
> >> On Sun, Jan 05, 2020 at 09:57:56PM +, Andrew Cooper wrote:
> >> [...]
> > The locked bit is probably a good idea, but one aspect missing here is
> > the check to see whether the hypercall page is already enabled, which I
> > expect is for a kexec crash scenario.
> >
> > However, the most important point is the one which describes the #GP
> > properties of the guest trying to modify the page.  This can only be
> > achieved with an EPT/NPT mapping lacking the W permission, which will
> > shatter host superpages.   Therefore, putting it in .text is going to be
> > rather poor, perf wise.
> >
> > I also note that Xen's implementation of the Viridian hypercall page
> > doesn't conform to these properties, and wants fixing.  It is going to
> > need a new kind identification of the page (probably a new p2m type)
> > which injects #GP if we ever see an EPT_VIOLATION/NPT_FAULT against it.
> >
> > As for suggestions here, I'm struggling to find any memory map details
> > exposed in the Viridian interface, and therefore which gfn is best to
> > choose.  I have a sinking feeling that the answer is ACPI...
>  TLFS only says "go find one suitable page yourself" without further
>  hints.
> 
>  Since we're still quite far away from a functioning system, finding a
>  most suitable page isn't my top priority at this point. If there is a
>  simple way to extrapolate suitable information from ACPI, that would be
>  great. If it requires writing a set of functionalities, than that will
>  need to wait till later.
> >>> To cope with the "one is already established and it is already locked"
> >>> case, the only option is to have a fixmap entry which can be set
> >>> dynamically.  The problem is that the fixmap region is marked NX and 64G
> >>> away from .text.
> >>>
> >>> Possibly the least bad option is to have some build-time space (so 0 or
> >>> 4k depending on CONFIG_HYPERV) between the per-cpu stubs and
> >>> XEN_VIRT_END, which operates like the fixmap, but ends up as X/RO 
> >>> mappings.
> >>>
> >> OK. This is probably not too difficult. 
> >>
> > I have a closer look at this today and want to make sure I understand
> > what you had in mind.
> >
> > Suppose we set aside some space in linker script. Using the following
> > will give you a WAX section. I still need to add CONFIG_GUEST around it,
> > but you get the idea.
> >
> >
> > diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> > index 111edb5360..a7af321139 100644
> > --- a/xen/arch/x86/xen.lds.S
> > +++ b/xen/arch/x86/xen.lds.S
> > @@ -305,6 +305,15 @@ SECTIONS
> > . = ALIGN(POINTER_ALIGN);
> > __bss_end = .;
> >} :text
> > +
> > +  . = ALIGN(SECTION_ALIGN);
> > +  DECL_SECTION(.text.hypercall_page) {
> > +   . = ALIGN(PAGE_SIZE);
> > +   __hypercall_page_start = .;
> > +   . = . + PAGE_SIZE;
> > +   __hypercall_page_end = .;
> > +  } :text=0x9090
> > +
> >_end = . ;
> >  
> >. = ALIGN(SECTION_ALIGN);
> >
> >
> > And then? Use map_pages_to_xen(..., PAGE_HYPERVISOR_RX) to point that
> > address to (MAXPHYSADDR-PAGE_SIZE)?
> 
> Ah no.  This still puts the hypercall page (or at least, space for it)
> in the Xen image itself, which is something we are trying to avoid.
> 
> What I meant was to basically copy(/extend) the existing fixmap
> implementation, calling it fixmap_x() (or something better), and put
> FIXMAP_X_SIZE as an additional gap in the calculation
> alloc_stub_page().  Even the current fixmap code has an ifdef example
> for CONFIG_XEN_GUEST.

Not just alloc_stub_page, but also livepatch infrastructure's address
space arrangement -- see arch/x86/liveptch.c:arch_livepatch_init.

Suppose I copy the existing fixmap mechanism, to get the uniform
experience for these two variants for fixmap, I will also need to
statically allocate its l2 and l1 page tables. This ends up putting two
more pages into Xen's image.  I want to make sure this is what you want
because you seemed to be concern about enlarging image size.

Wei.


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

Re: [Xen-devel] [PATCH v4 15/18] xen/mem_sharing: VM forking

[Tamas K Lengyel]

On Thu, Jan 9, 2020 at 3:29 AM Julien Grall  wrote:
>
> Hi Tamas,
>
> On 08/01/2020 17:14, Tamas K Lengyel wrote:
> > +static int mem_sharing_fork(struct domain *d, struct domain *cd)
> > +{
> > +int rc;
> > +
> > +if ( !d->controller_pause_count &&
> > + (rc = domain_pause_by_systemcontroller(d)) )
>
> AFAIU, the parent domain will be paused if it wasn't paused before and
> this will not be unpaused by the same hypercall. Right?

Yes, it needs to remain paused as long as there are forks active from
it. Afterwards it can be unpaused.

>
> If so, this brings two questions:
>  - What would happen if the toolstack decide to unpause the domain?

The forks eventually would end up misbehaving since the memory they
haven't touched yet would start changing underneath their feat. If
they never use those pages, then they are safe. If they are, and they
expect them to be in the same state when they were created, it will
lead to issues. Depends really on what is running in the fork.

>  - How does the caller knows whether this was paused by the
> hypercall or not?

Well, if they paused the VM before then the hypercall doesn't pause it
again. If it wasn't paused, it will be now.

>
> I would also suggest to document the behavior of the hypercall as this
> is not entirely obvious that the domain will be paused here.

Sure.

>
> > +return rc;
> > +
> > +cd->max_pages = d->max_pages;
> > +cd->max_vcpus = d->max_vcpus;
> > +
> > +/* this is preemptible so it's the first to get done */
> > +if ( (rc = fork_hap_allocation(d, cd)) )
> > +return rc;
> > +
> > +if ( (rc = bring_up_vcpus(cd, d->cpupool)) )
> > +return rc;
> > +
> > +if ( (rc = hvm_copy_context_and_params(d, cd)) )
> > +return rc;
> > +
> > +fork_tsc(d, cd);
> > +
> > +cd->parent = d;
>
> How do you ensure that the parent domain will not get destroyed before
> the forked domain? Do you have a refcount somewhere?

We don't. At this point we expect the user to keep the parent VM alive
but paused. Is there such a thing as a domain refcount we could use
for this?

Tamas

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

Re: [Xen-devel] [PATCH v1 4/4] xen/netback: Fix grant copy across page boundary with KASAN

[Paul Durrant]

On Wed, 8 Jan 2020 at 15:21, Sergey Dyasli  wrote:
>
> From: Ross Lagerwall 
>
> When KASAN (or SLUB_DEBUG) is turned on, the normal expectation that
> allocations are aligned to the next power of 2 of the size does not
> hold. Therefore, handle grant copies that cross page boundaries.
>
> Signed-off-by: Ross Lagerwall 
> Signed-off-by: Sergey Dyasli 
> ---
> RFC --> v1:
> - Added BUILD_BUG_ON to the netback patch
> - xenvif_idx_release() now located outside the loop
>
> CC: Wei Liu 
> CC: Paul Durrant 
[snip]
>
> +static void __init __maybe_unused build_assertions(void)
> +{
> +   BUILD_BUG_ON(sizeof(struct xenvif_tx_cb) > 48);

FIELD_SIZEOF(struct sk_buff, cb) rather than a magic '48' I think.

  Paul

> +}
> +
>  MODULE_LICENSE("Dual BSD/GPL");
>  MODULE_ALIAS("xen-backend:vif");
> --
> 2.17.1
>

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

Re: [Xen-devel] [PATCH v2 00/20] VM forking

[Tamas K Lengyel]

On Thu, Jan 9, 2020 at 2:48 AM Roger Pau Monné  wrote:
>
> On Wed, Jan 08, 2020 at 12:51:35PM -0700, Tamas K Lengyel wrote:
> > On Wed, Jan 8, 2020 at 11:37 AM Roger Pau Monné  
> > wrote:
> > >
> > > On Wed, Jan 08, 2020 at 11:14:46AM -0700, Tamas K Lengyel wrote:
> > > > On Wed, Jan 8, 2020 at 11:01 AM Roger Pau Monné  
> > > > wrote:
> > > > >
> > > > > On Wed, Jan 08, 2020 at 08:32:22AM -0700, Tamas K Lengyel wrote:
> > > > > > On Wed, Jan 8, 2020 at 8:08 AM Roger Pau Monné 
> > > > > >  wrote:
> > > > > > > I think you also need something like:
> > > > > > >
> > > > > > > # xl fork-vm --launch-dm late  
> > > > > > >
> > > > > > > So that a user doesn't need to pass a qemu-save-file?
> > > > > >
> > > > > > This doesn't make much sense to me. To launch QEMU you need the 
> > > > > > config
> > > > > > file to wire things up correctly. Like in order to launch QEMU you
> > > > > > need to tell it the name of the VM, disk path, etc. that are all
> > > > > > contained in the config.
> > > > >
> > > > > You could get all this information from the parent VM, IIRC libxl has
> > > > > a json version of the config. For example for migration there's no
> > > > > need to pass any config file, since the incoming VM can be recreated
> > > > > from the data in the source VM.
> > > > >
> > > >
> > > > But again, creating a fork with the exact config of the parent is not
> > > > possible. Even if the tool would rename the fork on-the-fly as it does
> > > > during the migration, the fork would end up thrashing the parent VM's
> > > > disk and making it impossible to create any additional forks. It would
> > > > also mean that at no point can the original VM be unpaused after the
> > > > forks are gone. I don't see any usecase in which that would make any
> > > > sense at all.
> > >
> > > You could have the disk(s) as read-only and the VM running completely
> > > from RAM. Alpine-linux has (or had) a mode where it was completely
> > > stateless and running from RAM. I think it's fine to require passing a
> > > config file for the time being, we can look at other options
> > > afterwards.
> > >
> >
> > OK, there is that. But I would say that's a fairly niche use-case. You
> > wouldn't have any network access in that fork, no disk, no way to get
> > information in or out beside the serial console.
>
> Why won't the fork have network access?

If you have multiple forks you end up having MAC-address collision. I
don't see what would be the point of creating a single fork when the
parent remains paused - you could just keep running the parent since
you aren't gaining anything by creating the fork. The main reason to
create a fork would be to create multiples of them.

>
> If the parent VM is left paused the fork should behave like a local
> migration regarding network access, and thus be fully functional.
>
> > So I wouldn't want
> > that setup to be considered the default. If someone wants to that I
> > would rather have an option that tells xl to automatically name the
> > fork for you instead of the other way around.
>
> Ack, I just want to make sure that whatever interface we end up using
> is designed taking into account other use cases apart from the one at
> hand.
>
> On an unrelated note, does forking work when using PV interfaces?

As I recall yes, but In my Linux tests these were the config options I
tested and work with the fork. Not sure if the vif device by default
is PV or emulated:

vnc=1
vnclisten="0.0.0.0:1"

usb=1
usbdevice=['tablet']

disk = ['phy:/dev/t0vg/debian-stretch,xvda,w']
vif = ['bridge=xenbr0,mac=00:07:5B:BB:00:01']

Tamas

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

[Xen-devel] [qemu-mainline bisection] complete build-amd64

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-amd64
testid xen-build

Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  b0b74e1f17508cb8cef8afd698558db1bd8999cc
  Bug not present: f17783e706ab9c7b3a2b69cf48e4f0ba40664f54
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/145856/


  commit b0b74e1f17508cb8cef8afd698558db1bd8999cc
  Merge: f17783e706 ddf9069963
  Author: Peter Maydell 
  Date:   Mon Jan 6 11:39:55 2020 +
  
  Merge remote-tracking branch 
'remotes/ehabkost/tags/python-next-pull-request' into staging
  
  Require Python >= 3.5 to build QEMU
  
  Python 2 EOL is 11 days away, we will stop supporting
  it in QEMU 5.0.
  
  # gpg: Signature made Fri 20 Dec 2019 16:49:02 GMT
  # gpg:using RSA key 
5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6
  # gpg:issuer "ehabk...@redhat.com"
  # gpg: Good signature from "Eduardo Habkost " [full]
  # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF  D1AA 2807 936F 984D 
C5A6
  
  * remotes/ehabkost/tags/python-next-pull-request:
configure: Require Python >= 3.5
travis: Replace Python 3.4 build with 3.5
  
  Signed-off-by: Peter Maydell 
  
  commit ddf90699631db53c981b6a5a63d31c08e0eaeec7
  Author: Eduardo Habkost 
  Date:   Wed Oct 16 19:42:37 2019 -0300
  
  configure: Require Python >= 3.5
  
  Python 3.5 is the oldest Python version available on our
  supported build platforms, and Python 2 end of life will be 3
  weeks after the planned release date of QEMU 4.2.0.  Drop Python
  2 support from configure completely, and require Python 3.5 or
  newer.
  
  Signed-off-by: Eduardo Habkost 
  Message-Id: <20191016224237.26180-1-ehabk...@redhat.com>
  Reviewed-by: John Snow 
  Signed-off-by: Eduardo Habkost 
  
  commit 49233804f5c458d61d8eb903c19d62edb3434db2
  Author: Eduardo Habkost 
  Date:   Fri Dec 20 13:45:27 2019 -0300
  
  travis: Replace Python 3.4 build with 3.5
  
  We'll start requiring Python 3.5 to build QEMU.
  
  Signed-off-by: Eduardo Habkost 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/qemu-mainline/build-amd64.xen-build 
--summary-out=tmp/145861.bisection-summary --basis-template=144861 
--blessings=real,real-bisect qemu-mainline build-amd64 xen-build
Searching for failure / basis pass:
 145852 fail [host=godello1] / 145664 ok.
Failure / basis pass flights: 145852 / 145664
(tree with no url: minios)
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 70911f1f4aee0366b6122f2b90d367ec0f066beb 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
035eed4c0d257c905a556fa0f4865a0c077b4e7f 
f21b5a4aeb020f2a5e2c6503f906a9349dd2f069 
00691c6c90b2fd28d7b7037baeb288f6801e6182
Basis pass b948a496150f4ae4f656c0f0ab672608723c80e6 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
f17783e706ab9c7b3a2b69cf48e4f0ba40664f54 
f21b5a4aeb020f2a5e2c6503f906a9349dd2f069 
7b3c5b70a32303b46d0d051e695f18d72cce5ed0
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/osstest/ovmf.git#b948a496150f4ae4f656c0f0ab672608723c80e6-70911f1f4aee0366b6122f2b90d367ec0f066beb
 
git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 
git://git.qemu.org/qemu.git#f17783e706ab9c7b3a2b69cf48e4f0ba40664f54-035eed4c0d257c905a556fa0f4865a0c077b4e7f
 
git://xenbits.xen.org/osstest/seabios.git#f21b5a4aeb020f2a5e2c6503f906a9349dd2f069-f21\
 b5a4aeb020f2a5e2c6503f906a9349dd2f069 
git://xenbits.xen.org/xen.git#7b3c5b70a32303b46d0d051e695f18d72cce5ed0-00691c6c90b2fd28d7b7037baeb288f6801e6182
Loaded 74798 nodes in revision graph
Searching for test results:
 145529 [host=rimava1]
 145530 [host=fiano0]
 145532 [host=fiano1]
 145533 [host=italia0]
 145534 fail irrelevant
 145536 [host=godello0]
 145547 [host=pinot1]
 145537 fail irrelevant
 145562 fail irrelevant
 145539 fail irrelevant
 145605 [host=italia0]
 145564 fail irrelevant
 145541 [host=godello0]
 145581 fail irrelevant
 145543 [host=huxelrebe0]
 145566 fail irrelevant
 145535 pass irrelevant
 145544 fail irrelevant
 145573 [host=huxelrebe0]
 145548 [host=huxelrebe0]
 145585 

Re: [Xen-devel] [PATCH] x86/flush: use APIC ALLBUT destination shorthand when possible

[Roger Pau Monné]

On Thu, Jan 09, 2020 at 12:24:05PM +0100, Roger Pau Monné wrote:
> On Thu, Jan 09, 2020 at 10:43:01AM +0100, Jan Beulich wrote:
> > On 08.01.2020 19:14, Roger Pau Monné wrote:
> > > On Wed, Jan 08, 2020 at 02:54:57PM +0100, Jan Beulich wrote:
> > >> On 08.01.2020 14:30, Roger Pau Monné  wrote:
> > >>> On Fri, Jan 03, 2020 at 01:55:51PM +0100, Jan Beulich wrote:
> >  On 03.01.2020 13:34, Roger Pau Monné wrote:
> > > On Fri, Jan 03, 2020 at 01:08:20PM +0100, Jan Beulich wrote:
> > >> On 24.12.2019 13:44, Roger Pau Monne wrote:
> > >> Further a question on lock nesting: Since the commit message
> > >> doesn't say anything in this regard, did you check there are no
> > >> TLB flush invocations with the get_cpu_maps() lock held?
> > >
> > > The CPU maps lock is a recursive one, so it should be fine to attempt
> > > a TLB flush with the lock already held.
> > 
> >  When already held by the same CPU - sure. It being a recursive
> >  one (which I paid attention to when writing my earlier reply)
> >  doesn't make it (together with any other one) immune against
> >  ABBA deadlocks, though.
> > >>>
> > >>> There's no possibility of a deadlock here because get_cpu_maps does a
> > >>> trylock, so if another cpu is holding the lock the flush will just
> > >>> fallback to not using the shorthand.
> > >>
> > >> Well, with the _exact_ arrangements (flush_lock used only in one
> > >> place, and cpu_add_remove_lock only used in ways similar to how it
> > >> is used now), there's no such risk, I agree. But there's nothing
> > >> at all making sure this doesn't change. Hence, as said, at the very
> > >> least this needs reasoning about in the description (or a code
> > >> comment).
> > > 
> > > I'm afraid you will have to bear with me, but I'm still not sure how
> > > the addition of get_cpu_maps in flush_area_mask can lead to deadlocks.
> > > As said above get_cpu_maps does a trylock, which means that it will
> > > never deadlock, and that's the only way to lock cpu_add_remove_lock.
> > 
> > That's why I said "cpu_add_remove_lock only used in ways similar to
> > how it is used now" - any non-trylock addition would break the
> > assumptions you make afaict. And you can't really expect people
> > adding another (slightly different) use of an existing lock to be
> > aware they now need to check whether this introduces deadlock
> > scenarios on unrelated pre-existing code paths. Hence my request to
> > at least discuss this in the description (raising awareness, and
> > hence allowing reviewers to judge whether further precautionary
> > measures should be taken).
> 
> Thanks for the clarification, I did indeed misunderstood your
> complain.
> 
> Regarding the generalization of the shorthand and integration into
> send_IPI_mask, I've found an issue related to locking. send_IPI_mask
> is called with both interrupts enabled and disabled, and so
> get_cpu_maps panics because of the lock checking.
> 
> I however don't think that such panic is accurate: the logic in
> check_lock specifically relates to the spinning done when picking a
> lock, but I would say the call to check_lock in
> _spin_trylock{_recursive} is not strictly needed, the scenario
> described in check_lock doesn't apply when using trylock.

Never mind, this is not actually true. You can still trigger the
deadlock if you mix trylock with regular locking, so I guess I will
leave the shorthand usage to flush_area_mask unless I can make all the
callers of send_IPI_mask use the same irq status.

Roger.

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

[Xen-devel] [PATCH v2 1/2] libxl: Get rid of some trailing whitespace

[George Dunlap]

No functional changes.

Signed-off-by: George Dunlap 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Anthony Perard 
---
 tools/libxl/libxl_event.h| 2 +-
 tools/libxl/libxl_fork.c | 4 ++--
 tools/libxl/libxl_internal.h | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index d1517f7456..41082ef2f4 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -441,7 +441,7 @@ void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void 
*for_libxl)
  *
  * A program which does this must call libxl_childproc_setmode.
  * There are three options:
- * 
+ *
  * libxl_sigchld_owner_libxl:
  *
  *   While any libxl operation which might use child processes
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 0f1b6b518c..c5b378c554 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -78,7 +78,7 @@ static void atfork_unlock(void)
 int libxl__atfork_init(libxl_ctx *ctx)
 {
 int r, rc;
-
+
 atfork_lock();
 if (atfork_registered) { rc = 0; goto out; }
 
@@ -326,7 +326,7 @@ static void sigchld_removehandler_core(void) /* idempotent 
*/
 {
 struct sigaction was;
 int r;
-
+
 if (!sigchld_installed)
 return;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b5adbfe4b7..bfbee9451e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -161,7 +161,7 @@
 #endif
   /* all of these macros preserve errno (saving and restoring) */
 
-/* 
+/*
  * A macro to help retain the first failure in "do as much as you can"
  * situations.  Note the hard-coded use of the variable name `rc`.
  */
@@ -1367,7 +1367,7 @@ typedef struct {
 const char *shim_cmdline;
 const char *pv_cmdline;
 
-/* 
+/*
  * dm_runas: If set, pass qemu the `-runas` parameter with this
  *  string as an argument
  * dm_kill_uid: If set, the devicemodel should be killed by
-- 
2.24.1


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

[Xen-devel] [PATCH v2 2/2] libxl: Add new "notify-only" childproc mode

[George Dunlap]

libxl needs to be able to know when processes it forks have completed.

At the moment, libxl has two basic mode (with some variations).  In
one mode -- libxl_sigchld_owner_libxl* -- libxl sets up its own
SIGCHLD signal handler, and also handles the event loop that allows
libxl to safely block until the child in question is finished (using a
self-pipe for the SIGCHLD handler to notify the waiters that it's time
to look for reaped children).

In the other mode, libxl does not set up the SIGCHLD handler, nor does
it do anything with processing the event loop; it expects the library
caller to handle the event loop itself.

The golang runtime manages its own processes, and thus must use
SIGCHLD itself; and it has an easy way for other users to get SIGCHLD
notifications.  However, because its event loop is hidden away behind
abstractions, it's not easy to hook into; and there's no need -- the
golang runtime assumes that C function calls may block, and handles
everything behind the scenes.

Introduce a new mode, libxl_sigchld_owner_notify, in which libxl sets
up the SIGCHLD event handling machinery, but relies on the caller to
tell it when a SIGCHLD happens.

Call these two actions "notify" (for the self-pipe notification
machinery) and "handler" (for the actual SIGCHLD handler).

Provide a new external function, libxl_childproc_sigchld_notify(), for
library users to call when a SIGCHLD happens.  Have this call
sigchld_handler().

Rename chldmode_ours() to chldmode_notify(), and use it to determine
whether to set up the notification chain.

When setting up the notification chain, do everything except setting
up the signal handler in "notify-only" mode.

defer_sigchld() and release_sigchld() do two things: they modify the
signal handler, and grab and release locks.  Refactor these so that
they grab and release the locks correctly in "notify-only" mode, but
don't tweak the signal handler unless it's been set up.

With the golang bindings ported to use this change, domain creation
works.

NB an alternate approach would be to make libxl_sigchld_owner_mainloop
*always* set up and tear down the self-pipe notification mechanisms,
and then simply expose libxl_childproc_sigchld_notify().  However,
this would entail grabbing a libxl-wide global lock (across all libxl
ctx's) twice on every fork.  This should be avoided for callers which
don't need it.

Signed-off-by: George Dunlap 
---
v2:
- Make libxl_childproc_sigchld_notify() reentrant by simply calling
  sigchld_handler directly.  Mention this in the documentation to prompt
  people to think about saving and restoring errno themselves.
- Move whitespace fixes to another patch
- Make braces snuggly in line with libxl coding style.
- Remove XXX comment.

CC: Ian Jackson 
CC: Wei Liu 
CC: Anthony Perard 
CC: Nick Rosbrook 
---
 tools/libxl/libxl_event.h | 31 +
 tools/libxl/libxl_fork.c  | 42 +++
 2 files changed, 60 insertions(+), 13 deletions(-)

diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 41082ef2f4..d6857d452e 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -466,6 +466,14 @@ void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void 
*for_libxl)
  *   has multiple libxl ctx's, it must call libxl_childproc_exited
  *   on each ctx.)
  *
+ * libxl_sigchld_owner_mainloop_notify:
+ *
+ *   The application must install a SIGCHLD handler, but will
+ *   notify libxl when a sigchld happened by calling
+ *   libxl_childproc_sigchld_notify.  libxl will arrange to reap
+ *   only its own children.  This needs to be called only once,
+ *   even for applications which have multiple libxl ctx's.
+ *
  * libxl_sigchld_owner_libxl_always:
  *
  *   The application expects this libxl ctx to reap all of the
@@ -494,6 +502,12 @@ typedef enum {
  * arrange to (un)block or catch SIGCHLD. */
 libxl_sigchld_owner_mainloop,
 
+/* Application promises to discover when SIGCHLD occurs and call
+ * libxl_childproc_sigchld_notify (perhaps from within a signal
+ * handler).  libxl will not itself arrange to (un)block or catch
+ * SIGCHLD. */
+libxl_sigchld_owner_mainloop_notify,
+
 /* libxl owns SIGCHLD all the time, and the application is
  * relying on libxl's event loop for reaping its children too. */
 libxl_sigchld_owner_libxl_always,
@@ -590,6 +604,23 @@ int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int 
status)
 void libxl_childproc_sigchld_occurred(libxl_ctx *ctx)
LIBXL_EXTERNAL_CALLERS_ONLY;
 
+/*
+ * This function is for an application which owns SIGCHLD but still
+ * expects libxl to handle its own event loops.
+ *
+ * Such an the application must notify libxl, by calling this
+ * function, that a SIGCHLD occurred.  libxl will then notify all
+ * appropriate event loops to check for reaped children..
+ *
+ * May be called only by an application which has called 

Re: [Xen-devel] [RFC PATCH V2 09/11] xen: Clear IRQD_IRQ_STARTED flag during shutdown PIRQs

[Thomas Gleixner]

Anchal Agarwal  writes:
> On Wed, Jan 08, 2020 at 04:23:25PM +0100, Thomas Gleixner wrote:
>> Anchal Agarwal  writes:
>> > +void irq_state_clr_started(struct irq_desc *desc)
>> >  {
>> >irqd_clear(>irq_data, IRQD_IRQ_STARTED);
>> >  }
>> > +EXPORT_SYMBOL_GPL(irq_state_clr_started);
>> 
>> This is core internal state and not supposed to be fiddled with by
>> drivers.
>> 
>> irq_chip has irq_suspend/resume/pm_shutdown callbacks for a reason.
>>
> I agree, as its mentioned in the previous patch {[RFC PATCH V2 08/11]} this 
> is 
> one way of explicitly shutting down legacy devices without introducing too 
> much 
> code for each of the legacy devices. . for eg. in case of floppy there 
> is no suspend/freeze handler which should have done the needful.
> .
> Either we implement them for all the legacy devices that have them missing or
> explicitly shutdown pirqs. I have choosen later for simplicity. I understand
> that ideally we should enable/disable devices interrupts in suspend/resume 
> devices but that requires adding code for doing that to few drivers[and I may
> not know all of them either]
>
> Now I discovered during the flow in hibernation_platform_enter under resume 
> devices that for such devices irq_startup is called which checks for 
> IRQD_IRQ_STARTED flag and based on that it calls irq_enable or irq_startup.
> They are only restarted if the flag is not set which is cleared during 
> shutdown. 
> shutdown_pirq does not do that. Only masking/unmasking of evtchn does not 
> work 
> as pirq needs to be restarted.
> xen-pirq.enable_irq is called rather than stratup_pirq. On resume if these 
> pirqs
> are not restarted in this case ACPI SCI interrupts, I do not see receiving 
> any interrupts under cat /proc/interrupts even though host keeps generating 
> S4 ACPI events. 
> Does that makes sense?

No. You still violate all abstraction boundaries. On one hand you use a
XEN specific suspend function to shut down interrupts, but then you want
the core code to reestablish them on resume. That's just bad hackery which
abuses partial knowledge of core internals. The state flag is only one
part of the core internal state and just clearing it does not make the
rest consistent. It just works by chance and not by design and any
change of the core code will break it in colourful ways.

So either you can handle it purely on the XEN side without touching any
core state or you need to come up with some way of letting the core code
know that it should invoke shutdown instead of disable.

Something like the completely untested patch below.

Thanks,

   tglx

8<

diff --git a/include/linux/irq.h b/include/linux/irq.h
index 7853eb9301f2..50f2057bc339 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -511,6 +511,7 @@ struct irq_chip {
  * IRQCHIP_EOI_THREADED:   Chip requires eoi() on unmask in threaded mode
  * IRQCHIP_SUPPORTS_LEVEL_MSI  Chip can provide two doorbells for Level MSIs
  * IRQCHIP_SUPPORTS_NMI:   Chip can deliver NMIs, only for root irqchips
+ * IRQCHIP_SHUTDOWN_ON_SUSPEND:Shutdown non wake irqs in the suspend 
path
  */
 enum {
IRQCHIP_SET_TYPE_MASKED = (1 <<  0),
@@ -522,6 +523,7 @@ enum {
IRQCHIP_EOI_THREADED= (1 <<  6),
IRQCHIP_SUPPORTS_LEVEL_MSI  = (1 <<  7),
IRQCHIP_SUPPORTS_NMI= (1 <<  8),
+   IRQCHIP_SHUTDOWN_ON_SUSPEND = (1 <<  9),
 };
 
 #include 
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index b3fa2d87d2f3..0fe355f72a15 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -233,7 +233,7 @@ __irq_startup_managed(struct irq_desc *desc, struct cpumask 
*aff, bool force)
 }
 #endif
 
-static int __irq_startup(struct irq_desc *desc)
+int __irq_startup(struct irq_desc *desc)
 {
struct irq_data *d = irq_desc_get_irq_data(desc);
int ret = 0;
diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
index 3924fbe829d4..11c7c55bda63 100644
--- a/kernel/irq/internals.h
+++ b/kernel/irq/internals.h
@@ -80,6 +80,7 @@ extern void __enable_irq(struct irq_desc *desc);
 extern int irq_activate(struct irq_desc *desc);
 extern int irq_activate_and_startup(struct irq_desc *desc, bool resend);
 extern int irq_startup(struct irq_desc *desc, bool resend, bool force);
+extern int __irq_startup(struct irq_desc *desc);
 
 extern void irq_shutdown(struct irq_desc *desc);
 extern void irq_shutdown_and_deactivate(struct irq_desc *desc);
diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
index 8f557fa1f4fe..597f0602510a 100644
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -85,16 +85,22 @@ static bool suspend_device_irq(struct irq_desc *desc)
}
 
desc->istate |= IRQS_SUSPENDED;
-   __disable_irq(desc);
-
-   /*
-* Hardware which has no wakeup source configuration facility
-* requires that the non wakeup interrupts are masked at the
-* chip level. The chip implementation indicates that with
-* 

[Xen-devel] [PATCH v2] x86/boot: Rationalise stack handling during early boot

[Andrew Cooper]

The top (numerically higher addresses) of cpu0_stack[] contains the BSP's
cpu_info block.  Logic in Xen expects this to be initialised to 0, but this
area of stack is also used during early boot.

Update the head.S code to avoid using the cpu_info block.  Additionally,
update the stack_start variable to match, which avoids __high_start() and
efi_arch_post_exit_boot() needing to make the adjustment manually.

Finally, leave a big warning by the BIOS BSS initialisation, because it is by
no means obvious that the stack doesn't survive the REP STOS.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 

v2:
 * Use 'i' rather than 'ir' for [cs]
 * Adjust stack_base[0] calculation in smp_prepare_cpus()
---
 xen/arch/x86/boot/head.S| 10 +++---
 xen/arch/x86/boot/x86_64.S  |  3 +--
 xen/arch/x86/efi/efi-boot.h | 15 ---
 xen/arch/x86/smpboot.c  |  4 ++--
 4 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index c730810461..250587fdf0 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -400,7 +400,7 @@ __pvh_start:
 sub $sym_offs(1b), %esi
 
 /* Set up stack. */
-lea STACK_SIZE + sym_esi(cpu0_stack), %esp
+lea STACK_SIZE - CPUINFO_sizeof + sym_esi(cpu0_stack), %esp
 
 mov %ebx, sym_esi(pvh_start_info_pa)
 
@@ -447,7 +447,7 @@ __start:
 sub $sym_offs(1b), %esi
 
 /* Set up stack. */
-lea STACK_SIZE + sym_esi(cpu0_stack), %esp
+lea STACK_SIZE - CPUINFO_sizeof + sym_esi(cpu0_stack), %esp
 
 /* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
 xor %edx,%edx
@@ -616,7 +616,11 @@ trampoline_setup:
 cmpb$0,sym_fs(efi_platform)
 jnz 1f
 
-/* Initialize BSS (no nasty surprises!). */
+/*
+ * Initialise the BSS.
+ *
+ * !!! WARNING - also zeroes the current stack !!!
+ */
 lea sym_esi(__bss_start), %edi
 lea sym_esi(__bss_end), %ecx
 sub %edi,%ecx
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index b54d3aceea..0acf5e860c 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -16,7 +16,6 @@ ENTRY(__high_start)
 mov %rcx,%cr4
 
 mov stack_start(%rip),%rsp
-or  $(STACK_SIZE-CPUINFO_sizeof),%rsp
 
 /* Reset EFLAGS (subsumes CLI and CLD). */
 pushq   $0
@@ -42,7 +41,7 @@ multiboot_ptr:
 .long   0
 
 GLOBAL(stack_start)
-.quad   cpu0_stack
+.quad   cpu0_stack + STACK_SIZE - CPUINFO_sizeof
 
 .section .data.page_aligned, "aw", @progbits
 .align PAGE_SIZE, 0
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 676d616ff8..9c036d5f4c 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -249,23 +249,24 @@ static void __init noreturn efi_arch_post_exit_boot(void)
"or $"__stringify(X86_CR4_PGE)", %[cr4]\n\t"
"mov%[cr4], %%cr4\n\t"
 #endif
-   "movabs $__start_xen, %[rip]\n\t"
"lgdt   boot_gdtr(%%rip)\n\t"
-   "movstack_start(%%rip), %%rsp\n\t"
"mov%[ds], %%ss\n\t"
"mov%[ds], %%ds\n\t"
"mov%[ds], %%es\n\t"
"mov%[ds], %%fs\n\t"
"mov%[ds], %%gs\n\t"
-   "movl   %[cs], 8(%%rsp)\n\t"
-   "mov%[rip], (%%rsp)\n\t"
-   "lretq  %[stkoff]-16"
+
+   /* Jump to higher mappings. */
+   "movstack_start(%%rip), %%rsp\n\t"
+   "movabs $__start_xen, %[rip]\n\t"
+   "push   %[cs]\n\t"
+   "push   %[rip]\n\t"
+   "lretq"
: [rip] "=" (efer/* any dead 64-bit variable */),
  [cr4] "+" (cr4)
: [cr3] "r" (idle_pg_table),
- [cs] "ir" (__HYPERVISOR_CS),
+ [cs] "i" (__HYPERVISOR_CS),
  [ds] "r" (__HYPERVISOR_DS),
- [stkoff] "i" (STACK_SIZE - sizeof(struct cpu_info)),
  "D" ()
: "memory" );
 unreachable();
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 301f746979..c9d1ab4423 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -554,7 +554,7 @@ static int do_boot_cpu(int apicid, int cpu)
 printk("Booting processor %d/%d eip %lx\n",
cpu, apicid, start_eip);
 
-stack_start = stack_base[cpu];
+stack_start = stack_base[cpu] + STACK_SIZE - sizeof(struct cpu_info);
 
 /* This grunge runs the startup process for the targeted processor. */
 
@@ -1084,7 +1084,7 @@ void __init 

[Xen-devel] [PATCH v2 3/6] libxl: add infrastructure to track and query 'retired' domids

[Paul Durrant]

A domid is considered retired if the domain it represents was destroyed
less than a specified number of seconds ago. The number can be set using
the environment variable LIBXL_DOMID_MAX_RETIREMENT. If the variable does
not exist then a default value of 60s is used.

Whenever a domain is destroyed, a time-stamped record will be written into
a history file (/var/run/xen/domid-history). To avoid the history file
growing too large, any records with time-stamps that indicate that the
domid has exceeded maximum retirement will also be purged.

A new utility function, libxl__is_retired_domid(), has been added. This
function reads the same history file checking whether a specified domid
has a record that does not exceed maximum retirement. Since this utility
function does not write to the file, no records are actually purged by it.

NOTE: Since the history file is hosted by a tmpfs file system, it is
  automatically purged on boot thus allowing safe use of
  CLOCK_MONOTONIC as a time source.

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Anthony PERARD 

v2:
 - New in v2
---
 tools/libxl/libxl_domain.c   | 132 +++
 tools/libxl/libxl_internal.h |  10 +++
 2 files changed, 142 insertions(+)

diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 5714501778..7f255f184c 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -1268,6 +1268,137 @@ static void dm_destroy_cb(libxl__egc *egc,
 libxl__devices_destroy(egc, >drs);
 }
 
+static unsigned int libxl__get_max_retirement(void)
+{
+const char *env_max_retirement = getenv("LIBXL_DOMID_MAX_RETIREMENT");
+
+return env_max_retirement ? strtol(env_max_retirement, NULL, 0) :
+LIBXL_DOMID_MAX_RETIREMENT;
+}
+
+static int libxl__open_domid_history(libxl__gc *gc)
+{
+const char *name;
+int fd;
+int ret;
+
+name = GCSPRINTF("%s/domid-history", libxl__run_dir_path());
+
+fd = open(name, O_RDWR|O_CREAT, 0644);
+if (fd < 0) {
+LOGE(ERROR, "unexpected error while trying open %s, errno=%d",
+ name, errno);
+goto fail;
+}
+
+for (;;) {
+ret = flock(fd, LOCK_EX);
+if (!ret)
+break;
+if (errno != EINTR) {
+/* All other errno: EBADF, EINVAL, ENOLCK, EWOULDBLOCK */
+LOGE(ERROR,
+ "unexpected error while trying to lock %s, fd=%d, errno=%d",
+ name, fd, errno);
+goto fail;
+}
+}
+
+return fd;
+
+fail:
+if (fd >= 0)
+close(fd);
+
+return -1;
+}
+
+/* Write a domid retirement record */
+static void libxl__retire_domid(libxl__gc *gc, uint32_t domid)
+{
+long max_retirement = libxl__get_max_retirement();
+int fd;
+FILE *f;
+long roff, woff;
+char line[64];
+struct timespec ts;
+
+fd = libxl__open_domid_history(gc);
+if (fd < 0)
+return;
+
+clock_gettime(CLOCK_MONOTONIC, );
+
+/* Purge old retirement records */
+
+f = fdopen(fd, "r+");
+woff = ftell(f);
+
+while (fgets(line, sizeof(line), f)) {
+unsigned long sec;
+unsigned int ignored;
+
+roff = ftell(f);
+
+if (sscanf(line, "%lu %u", , ) != 2)
+continue; /* Purge malformed lines */
+
+if (ts.tv_sec - sec > max_retirement)
+continue;
+
+fseek(f, woff, SEEK_SET);
+fputs(line, f);
+woff = ftell(f);
+
+fseek(f, roff, SEEK_SET);
+}
+
+fseek(f, woff, SEEK_SET);
+fprintf(f, "%lu %u\n", ts.tv_sec, domid);
+woff = ftell(f);
+fflush(f);
+
+ftruncate(fd, woff); /* may now be fewer records */
+
+close(fd);
+}
+
+bool libxl__is_retired_domid(libxl__gc *gc, uint32_t domid)
+{
+long max_retirement = libxl__get_max_retirement();
+bool retired = false;
+int fd;
+FILE *f;
+char line[64];
+struct timespec ts;
+
+fd = libxl__open_domid_history(gc);
+if (fd < 0)
+return false;
+
+clock_gettime(CLOCK_MONOTONIC, );
+
+f = fdopen(fd, "r");
+
+while (fgets(line, sizeof(line), f)) {
+unsigned long sec;
+unsigned int check;
+
+if (sscanf(line, "%lu %u", , ) != 2)
+continue;
+
+if (check == domid &&
+ts.tv_sec - sec <= max_retirement) {
+retired = true;
+break;
+}
+}
+
+close(fd);
+
+return retired;
+}
+
 static void devices_destroy_cb(libxl__egc *egc,
libxl__devices_remove_state *drs,
int rc)
@@ -1331,6 +1462,7 @@ static void devices_destroy_cb(libxl__egc *egc,
 if (!ctx->xch) goto badchild;
 
 if (!dis->soft_reset) {
+libxl__retire_domid(gc, domid);
 rc = xc_domain_destroy(ctx->xch, domid);
 } else {
 rc = xc_domain_pause(ctx->xch, domid);
diff --git a/tools/libxl/libxl_internal.h 

[Xen-devel] [PATCH v2 4/6] libxl: allow creation of domains with a specified or random domid

[Paul Durrant]

This patch adds a 'domid' field to libxl_domain_create_info and then
modifies do_domain_create() to use that value if it is valid. Any valid
domid will be checked against the retired domid list before being passed
to libxl__domain_make().
If the domid value is invalid then Xen will choose the domid, as before,
unless the value is the new special RANDOM_DOMID value added to the API.
This value instructs libxl__domain_make() to select a random domid value,
check it for validity, verify it does not match a retired domain, and then
pass it to Xen's XEN_DOMCTL_createdomain operation. If Xen determines that
it co-incides with an existing domain, a new random value will be
selected and the operation will be re-tried.

NOTE: libxl__logv() is also modified to only log valid domid values in
  messages rather than any domid, valid or otherwise, that is not
  INVALID_DOMID.

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Anthony PERARD 

v2:
 - Re-worked to use a value from libxl_domain_create_info
---
 tools/libxl/libxl.h  |  9 +
 tools/libxl/libxl_create.c   | 32 +++-
 tools/libxl/libxl_internal.c |  2 +-
 tools/libxl/libxl_types.idl  |  1 +
 4 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 18c1a2d6bf..7e60ee1c8b 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1268,6 +1268,14 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, 
const libxl_mac *src);
  */
 #define LIBXL_HAVE_DOMAIN_NEED_MEMORY_CONFIG
 
+/*
+ * LIBXL_HAVE_CREATEINFO_DOMID
+ *
+ * libxl_domain_create_new() and libxl_domain_create_restore() will use
+ * a domid specified in libxl_domain_create_info().
+ */
+#define LIBXL_HAVE_CREATEINFO_DOMID
+
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
 int libxl_string_list_length(const libxl_string_list *sl);
@@ -1528,6 +1536,7 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 /* domain related functions */
 
 #define INVALID_DOMID ~0
+#define RANDOM_DOMID (INVALID_DOMID - 1)
 
 /* If the result is ERROR_ABORTED, the domain may or may not exist
  * (in a half-created state).  *domid will be valid and will be the
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1835a5502c..ee76dee364 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -600,9 +600,39 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
 goto out;
 }
 
-ret = xc_domain_create(ctx->xch, domid, );
+if (libxl_domid_valid_guest(info->domid)) {
+*domid = info->domid;
+
+if (libxl__is_retired_domid(gc, *domid)) {
+LOGED(ERROR, *domid, "domain id is retired");
+rc = ERROR_FAIL;
+goto out;
+}
+} else if (info->domid == RANDOM_DOMID) {
+*domid = 0; /* Zero-out initial value */
+}
+
+for (;;) {
+if (info->domid == RANDOM_DOMID) {
+/* Randomize lower order bytes */
+ret = libxl__random_bytes(gc, (void *)domid,
+  sizeof(uint16_t));
+if (ret < 0)
+break;
+
+if (!libxl_domid_valid_guest(*domid) ||
+libxl__is_retired_domid(gc, *domid))
+continue;
+}
+
+ret = xc_domain_create(ctx->xch, domid, );
+if (ret == 0 || errno != EEXIST || info->domid != RANDOM_DOMID)
+break;
+}
+
 if (ret < 0) {
 LOGED(ERROR, *domid, "domain creation fail");
+*domid = INVALID_DOMID;
 rc = ERROR_FAIL;
 goto out;
 }
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index ba5637358e..dc6aaa9c9f 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -234,7 +234,7 @@ void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, 
int errnoval,
 fileline[sizeof(fileline)-1] = 0;
 
 domain[0] = 0;
-if (domid != INVALID_DOMID)
+if (libxl_domid_valid_guest(domid))
 snprintf(domain, sizeof(domain), "Domain %"PRIu32":", domid);
  x:
 xtl_log(ctx->lg, msglevel, errnoval, "libxl",
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 7921950f6a..d0d431614f 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -409,6 +409,7 @@ libxl_domain_create_info = Struct("domain_create_info",[
 ("ssidref",  uint32),
 ("ssid_label",   string),
 ("name", string),
+("domid",libxl_domid),
 ("uuid", libxl_uuid),
 ("xsdata",   libxl_key_value_list),
 ("platformdata", libxl_key_value_list),
-- 
2.20.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org

[Xen-devel] [PATCH v2 5/6] xl.conf: introduce 'domid_policy'

[Paul Durrant]

This patch adds a new global 'domid_policy' configuration option to decide
how domain id values are allocated for new domains. It may be set to one of
two values:

"xen", the default value, will cause an invalid domid value to be passed
to do_domain_create() preserving the existing behaviour of having Xen
choose the domid value during domain_create().

"random" will cause the special RANDOM_DOMID value to be passed to
do_domain_create() such that libxl__domain_make() will select a random
domid value.

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 

v2:
 - New in v2
---
 docs/man/xl.conf.5.pod  | 10 ++
 tools/examples/xl.conf  |  4 
 tools/xl/xl.c   | 10 ++
 tools/xl/xl.h   |  1 +
 tools/xl/xl_vmcontrol.c |  2 ++
 5 files changed, 27 insertions(+)

diff --git a/docs/man/xl.conf.5.pod b/docs/man/xl.conf.5.pod
index 207ab3e77a..41ee428744 100644
--- a/docs/man/xl.conf.5.pod
+++ b/docs/man/xl.conf.5.pod
@@ -45,6 +45,16 @@ The semantics of each C defines which form of C 
is required.
 
 =over 4
 
+=item B
+
+Determines how domain-id is set when creating a new domain.
+
+If set to "xen" then the hypervisor will allocate new domain-id values on a 
sequential basis.
+
+If set to "random" then a random domain-id value will be chosen.
+
+Default: "xen"
+
 =item B
 
 If set to "on" then C will automatically reduce the amount of
diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf
index 0446deb304..95f2f442d3 100644
--- a/tools/examples/xl.conf
+++ b/tools/examples/xl.conf
@@ -1,5 +1,9 @@
 ## Global XL config file ##
 
+# Set domain-id policy. "xen" means that the hypervisor will choose the
+# id of a new domain. "random" means that a random value will be chosen.
+#domid_policy="xen"
+
 # Control whether dom0 is ballooned down when xen doesn't have enough
 # free memory to create a domain.  "auto" means only balloon if dom0
 # starts with all the host's memory.
diff --git a/tools/xl/xl.c b/tools/xl/xl.c
index 3d4390a46d..2a5ddd4390 100644
--- a/tools/xl/xl.c
+++ b/tools/xl/xl.c
@@ -54,6 +54,7 @@ int claim_mode = 1;
 bool progress_use_cr = 0;
 int max_grant_frames = -1;
 int max_maptrack_frames = -1;
+libxl_domid domid_policy = INVALID_DOMID;
 
 xentoollog_level minmsglevel = minmsglevel_default;
 
@@ -228,6 +229,15 @@ static void parse_global_config(const char *configfile,
 else
 libxl_bitmap_set_any(_pv_affinity_mask);
 
+if (!xlu_cfg_get_string (config, "domid_policy", , 0)) {
+if (!strcmp(buf, "xen"))
+domid_policy = INVALID_DOMID;
+else if (!strcmp(buf, "random"))
+domid_policy = RANDOM_DOMID;
+else
+fprintf(stderr, "invalid domid_policy option");
+}
+
 xlu_cfg_destroy(config);
 }
 
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 60bdad8ffb..2b4709efb2 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -283,6 +283,7 @@ extern int max_maptrack_frames;
 extern libxl_bitmap global_vm_affinity_mask;
 extern libxl_bitmap global_hvm_affinity_mask;
 extern libxl_bitmap global_pv_affinity_mask;
+extern libxl_domid domid_policy;
 
 enum output_format {
 OUTPUT_FORMAT_JSON,
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index e520b1da79..39292acfe6 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -899,6 +899,8 @@ start:
 autoconnect_console_how = 0;
 }
 
+d_config.c_info.domid = domid_policy;
+
 if ( restoring ) {
 libxl_domain_restore_params params;
 
-- 
2.20.1


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

[Xen-devel] [PATCH v2 0/6] xl/libxl: domid allocation/preservation changes

[Paul Durrant]

This series was previously named "xl/libxl: allow creation of domains with
a specified domid".

Paul Durrant (6):
  libxl: add definition of INVALID_DOMID to the API
  libxl_create: make 'soft reset' explicit
  libxl: add infrastructure to track and query 'retired' domids
  libxl: allow creation of domains with a specified or random domid
  xl.conf: introduce 'domid_policy'
  xl: allow domid to be preserved on save/restore or migrate

 docs/man/xl.1.pod.in |  14 
 docs/man/xl.conf.5.pod   |  10 +++
 tools/examples/xl.conf   |   4 ++
 tools/libxl/libxl.h  |  13 +++-
 tools/libxl/libxl_create.c   |  90 +---
 tools/libxl/libxl_dm.c   |   2 +-
 tools/libxl/libxl_domain.c   | 132 +++
 tools/libxl/libxl_internal.c |   2 +-
 tools/libxl/libxl_internal.h |  16 -
 tools/libxl/libxl_types.idl  |   1 +
 tools/xl/xl.c|  10 +++
 tools/xl/xl.h|   2 +
 tools/xl/xl_cmdtable.c   |   6 +-
 tools/xl/xl_migrate.c|  15 ++--
 tools/xl/xl_saverestore.c|  19 +++--
 tools/xl/xl_utils.h  |   2 -
 tools/xl/xl_vmcontrol.c  |   3 +
 17 files changed, 297 insertions(+), 44 deletions(-)
---
Cc: Anthony PERARD 
Cc: Ian Jackson 
Cc: Wei Liu 
-- 
2.20.1


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

[Xen-devel] [PATCH v2 2/6] libxl_create: make 'soft reset' explicit

[Paul Durrant]

The 'soft reset' code path in libxl__domain_make() is currently taken if a
valid domid is passed into the function. A subsequent patch will enable
higher levels of the toolstack to determine the domid of newly created or
restored domains and therefore this criteria for choosing 'soft reset'
will no longer be usable.

This patch adds an extra boolean option to libxl__domain_make() to specify
whether it is being invoked in soft reset context and appropriately
modifies callers to choose the right value. To facilitate this, a new
'soft_reset' boolean field is added to struct libxl__domain_create_state
and the 'domid_soft_reset' field is renamed to 'domid' in anticipation of
its wider remit. For the moment do_domain_create() will always set
domid to INVALID_DOMID and hence we can add an assertion into
libxl__domain_create() that, if it is not called in soft reset context,
the passed in domid is exactly that value.

Whilst in the neighbourhood, some checks of 'restore_fd > -1' have been
replaced by 'restore_fd >= 0' to be more conventional and consistent with
checks of 'restore_fd < 0'.

Signed-off-by: Paul Durrant 
Acked-by: Ian Jackson 
---
Cc: Wei Liu 
Cc: Anthony PERARD 
---
 tools/libxl/libxl_create.c   | 56 ++--
 tools/libxl/libxl_dm.c   |  2 +-
 tools/libxl/libxl_internal.h |  5 ++--
 3 files changed, 38 insertions(+), 25 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index bc425fee32..1835a5502c 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -538,7 +538,7 @@ out:
 
 int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
libxl__domain_build_state *state,
-   uint32_t *domid)
+   uint32_t *domid, bool soft_reset)
 {
 libxl_ctx *ctx = libxl__gc_owner(gc);
 int ret, rc, nb_vm;
@@ -555,14 +555,15 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
 libxl_domain_create_info *info = _config->c_info;
 libxl_domain_build_info *b_info = _config->b_info;
 
+assert(soft_reset || *domid == INVALID_DOMID);
+
 uuid_string = libxl__uuid2string(gc, info->uuid);
 if (!uuid_string) {
 rc = ERROR_NOMEM;
 goto out;
 }
 
-/* Valid domid here means we're soft resetting. */
-if (!libxl_domid_valid_guest(*domid)) {
+if (!soft_reset) {
 struct xen_domctl_createdomain create = {
 .ssidref = info->ssidref,
 .max_vcpus = b_info->max_vcpus,
@@ -611,6 +612,14 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
 goto out;
 }
 
+/*
+ * If soft_reset is set the the domid will have been valid on entry.
+ * If it was not set then xc_domain_create() should have assigned a
+ * valid value. Either way, if we reach this point, domid should be
+ * valid.
+ */
+assert(libxl_domid_valid_guest(*domid));
+
 ret = xc_cpupool_movedomain(ctx->xch, info->poolid, *domid);
 if (ret < 0) {
 LOGED(ERROR, *domid, "domain move fail");
@@ -1091,13 +1100,14 @@ static void initiate_domain_create(libxl__egc *egc,
 libxl_domain_config *const d_config = dcs->guest_config;
 const int restore_fd = dcs->restore_fd;
 
-domid = dcs->domid_soft_reset;
+domid = dcs->domid;
 libxl__domain_build_state_init(>build_state);
 
 ret = libxl__domain_config_setdefault(gc,d_config,domid);
 if (ret) goto error_out;
 
-ret = libxl__domain_make(gc, d_config, >build_state, );
+ret = libxl__domain_make(gc, d_config, >build_state, ,
+ dcs->soft_reset);
 if (ret) {
 LOGD(ERROR, domid, "cannot make domain: %d", ret);
 dcs->guest_domid = domid;
@@ -1141,7 +1151,7 @@ static void initiate_domain_create(libxl__egc *egc,
 if (ret)
 goto error_out;
 
-if (restore_fd >= 0 || dcs->domid_soft_reset != INVALID_DOMID) {
+if (restore_fd >= 0 || dcs->soft_reset) {
 LOGD(DEBUG, domid, "restoring, not running bootloader");
 domcreate_bootloader_done(egc, >bl, 0);
 } else  {
@@ -1217,7 +1227,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 dcs->sdss.dm.callback = domcreate_devmodel_started;
 dcs->sdss.callback = domcreate_devmodel_started;
 
-if (restore_fd < 0 && dcs->domid_soft_reset == INVALID_DOMID) {
+if (restore_fd < 0 && !dcs->soft_reset) {
 rc = libxl__domain_build(gc, d_config, domid, state);
 domcreate_rebuild_done(egc, dcs, rc);
 return;
@@ -1827,7 +1837,7 @@ static int do_domain_create(libxl_ctx *ctx, 
libxl_domain_config *d_config,
 libxl_domain_config_copy(ctx, >dcs.guest_config_saved, d_config);
 cdcs->dcs.restore_fd = cdcs->dcs.libxc_fd = restore_fd;
 cdcs->dcs.send_back_fd = send_back_fd;
-if (restore_fd > -1) {
+if (restore_fd >= 0) {
 cdcs->dcs.restore_params = *params;
 rc = libxl__fd_flags_modify_save(gc, 

[Xen-devel] [PATCH v2 1/6] libxl: add definition of INVALID_DOMID to the API

[Paul Durrant]

Currently both xl and libxl have internal definitions of INVALID_DOMID
which happen to be identical. However, for the purposes of describing the
behaviour of libxl_domain_create_new/restore() it is useful to have a
specified invalid value for a domain id.

This patch therefore moves the libxl definition from libxl_internal.h to
libxl.h and removes the internal definition from xl_utils.h. The hardcoded
'-1' passed back via domcreate_complete() is then updated to INVALID_DOMID
and comment above libxl_domain_create_new/restore() is accordingly
modified.

Signed-off-by: Paul Durrant 
Acked-by: Ian Jackson 
---
Cc: Wei Liu 
Cc: Anthony PERARD 
---
 tools/libxl/libxl.h  | 4 +++-
 tools/libxl/libxl_create.c   | 2 +-
 tools/libxl/libxl_internal.h | 1 -
 tools/xl/xl_utils.h  | 2 --
 4 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 54abb9db1f..18c1a2d6bf 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1527,9 +1527,11 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 
 /* domain related functions */
 
+#define INVALID_DOMID ~0
+
 /* If the result is ERROR_ABORTED, the domain may or may not exist
  * (in a half-created state).  *domid will be valid and will be the
- * domain id, or -1, as appropriate */
+ * domain id, or INVALID_DOMID, as appropriate */
 
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
 uint32_t *domid,
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 32d45dcef0..bc425fee32 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1773,7 +1773,7 @@ static void domcreate_complete(libxl__egc *egc,
 libxl__domain_destroy(egc, >dds);
 return;
 }
-dcs->guest_domid = -1;
+dcs->guest_domid = INVALID_DOMID;
 }
 dcs->callback(egc, dcs, rc, dcs->guest_domid);
 }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ba8c9b41ab..3b708fba8f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -121,7 +121,6 @@
 #define STUBDOM_SPECIAL_CONSOLES 3
 #define TAP_DEVICE_SUFFIX "-emu"
 #define DOMID_XS_PATH "domid"
-#define INVALID_DOMID ~0
 #define PVSHIM_BASENAME "xen-shim"
 #define PVSHIM_CMDLINE "pv-shim console=xen,pv"
 
diff --git a/tools/xl/xl_utils.h b/tools/xl/xl_utils.h
index 7b9ccca30a..d98b419f10 100644
--- a/tools/xl/xl_utils.h
+++ b/tools/xl/xl_utils.h
@@ -52,8 +52,6 @@
 #define STR_SKIP_PREFIX( a, b ) \
 ( STR_HAS_PREFIX(a, b) ? ((a) += strlen(b), 1) : 0 )
 
-#define INVALID_DOMID ~0
-
 #define LOG(_f, _a...)   dolog(__FILE__, __LINE__, __func__, _f "\n", ##_a)
 
 /*
-- 
2.20.1


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

[Xen-devel] [PATCH v2 6/6] xl: allow domid to be preserved on save/restore or migrate

[Paul Durrant]

This patch adds a '-D' command line option to save and migrate to allow
the domain id to be incorporated into the saved domain configuration and
hence be preserved.

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 

v2:
 - Heavily re-worked based on new libxl_domain_create_info
---
 docs/man/xl.1.pod.in  | 14 ++
 tools/xl/xl.h |  1 +
 tools/xl/xl_cmdtable.c|  6 --
 tools/xl/xl_migrate.c | 15 ++-
 tools/xl/xl_saverestore.c | 19 ++-
 tools/xl/xl_vmcontrol.c   |  3 ++-
 6 files changed, 45 insertions(+), 13 deletions(-)

diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
index d4b5e8e362..937eda690f 100644
--- a/docs/man/xl.1.pod.in
+++ b/docs/man/xl.1.pod.in
@@ -490,6 +490,13 @@ Display huge (!) amount of debug information during the 
migration process.
 
 Leave the domain on the receive side paused after migration.
 
+=item B<-D>
+
+Preserve the B in the domain coniguration that is transferred
+such that it will be identical on the destination host, unless that
+configuration is overridden using the B<-C> option. Note that it is not
+possible to use this option for a 'localhost' migration.
+
 =back
 
 =item B [I] I I
@@ -692,6 +699,13 @@ Leave the domain running after creating the snapshot.
 
 Leave the domain paused after creating the snapshot.
 
+=item B<-D>
+
+Preserve the B in the domain coniguration that is embedded in
+the state file such that it will be identical when the domain is restored,
+unless that configuration is overridden. (See the B operation
+above).
+
 =back
 
 =item B [I]
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 2b4709efb2..06569c6c4a 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -99,6 +99,7 @@ struct save_file_header {
 #define SAVEFILE_BYTEORDER_VALUE ((uint32_t)0x01020304UL)
 
 void save_domain_core_begin(uint32_t domid,
+int preserve_domid,
 const char *override_config_file,
 uint8_t **config_data_r,
 int *config_len_r);
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 3b302b2f20..08335394e5 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -153,7 +153,8 @@ struct cmd_spec cmd_table[] = {
   "[options]   []",
   "-h  Print this help.\n"
   "-c  Leave domain running after creating the snapshot.\n"
-  "-p  Leave domain paused after creating the snapshot."
+  "-p  Leave domain paused after creating the snapshot.\n"
+  "-D  Store the domain id in the configration."
 },
 { "migrate",
   _migrate, 0, 1,
@@ -167,7 +168,8 @@ struct cmd_spec cmd_table[] = {
   "-e  Do not wait in the background (on ) for the 
death\n"
   "of the domain.\n"
   "--debug Print huge (!) amount of debug during the migration 
process.\n"
-  "-p  Do not unpause domain after migrating it."
+  "-p  Do not unpause domain after migrating it.\n"
+  "-D  Preserve the domain id"
 },
 { "restore",
   _restore, 0, 1,
diff --git a/tools/xl/xl_migrate.c b/tools/xl/xl_migrate.c
index 22f0429b84..0813beb801 100644
--- a/tools/xl/xl_migrate.c
+++ b/tools/xl/xl_migrate.c
@@ -176,7 +176,8 @@ static void migrate_do_preamble(int send_fd, int recv_fd, 
pid_t child,
 
 }
 
-static void migrate_domain(uint32_t domid, const char *rune, int debug,
+static void migrate_domain(uint32_t domid, int preserve_domid,
+   const char *rune, int debug,
const char *override_config_file)
 {
 pid_t child = -1;
@@ -187,7 +188,7 @@ static void migrate_domain(uint32_t domid, const char 
*rune, int debug,
 uint8_t *config_data;
 int config_len, flags = LIBXL_SUSPEND_LIVE;
 
-save_domain_core_begin(domid, override_config_file,
+save_domain_core_begin(domid, preserve_domid, override_config_file,
_data, _len);
 
 if (!config_len) {
@@ -537,13 +538,14 @@ int main_migrate(int argc, char **argv)
 char *rune = NULL;
 char *host;
 int opt, daemonize = 1, monitor = 1, debug = 0, pause_after_migration = 0;
+int preserve_domid = 0;
 static struct option opts[] = {
 {"debug", 0, 0, 0x100},
 {"live", 0, 0, 0x200},
 COMMON_LONG_OPTS
 };
 
-SWITCH_FOREACH_OPT(opt, "FC:s:ep", opts, "migrate", 2) {
+SWITCH_FOREACH_OPT(opt, "FC:s:epD", opts, "migrate", 2) {
 case 'C':
 config_filename = optarg;
 break;
@@ -560,6 +562,9 @@ int main_migrate(int argc, char **argv)
 case 'p':
 pause_after_migration = 1;
 break;
+case 'D':
+preserve_domid = 1;
+break;
 case 0x100: /* --debug */
 debug = 1;
 break;
@@ -596,7 +601,7 @@ int main_migrate(int argc, char **argv)
   pause_after_migration ? " -p" : "");
 }
 
-migrate_domain(domid, rune, 

Re: [Xen-devel] [PATCH] x86/flush: use APIC ALLBUT destination shorthand when possible

[Roger Pau Monné]

On Thu, Jan 09, 2020 at 10:43:01AM +0100, Jan Beulich wrote:
> On 08.01.2020 19:14, Roger Pau Monné wrote:
> > On Wed, Jan 08, 2020 at 02:54:57PM +0100, Jan Beulich wrote:
> >> On 08.01.2020 14:30, Roger Pau Monné  wrote:
> >>> On Fri, Jan 03, 2020 at 01:55:51PM +0100, Jan Beulich wrote:
>  On 03.01.2020 13:34, Roger Pau Monné wrote:
> > On Fri, Jan 03, 2020 at 01:08:20PM +0100, Jan Beulich wrote:
> >> On 24.12.2019 13:44, Roger Pau Monne wrote:
> >> Further a question on lock nesting: Since the commit message
> >> doesn't say anything in this regard, did you check there are no
> >> TLB flush invocations with the get_cpu_maps() lock held?
> >
> > The CPU maps lock is a recursive one, so it should be fine to attempt
> > a TLB flush with the lock already held.
> 
>  When already held by the same CPU - sure. It being a recursive
>  one (which I paid attention to when writing my earlier reply)
>  doesn't make it (together with any other one) immune against
>  ABBA deadlocks, though.
> >>>
> >>> There's no possibility of a deadlock here because get_cpu_maps does a
> >>> trylock, so if another cpu is holding the lock the flush will just
> >>> fallback to not using the shorthand.
> >>
> >> Well, with the _exact_ arrangements (flush_lock used only in one
> >> place, and cpu_add_remove_lock only used in ways similar to how it
> >> is used now), there's no such risk, I agree. But there's nothing
> >> at all making sure this doesn't change. Hence, as said, at the very
> >> least this needs reasoning about in the description (or a code
> >> comment).
> > 
> > I'm afraid you will have to bear with me, but I'm still not sure how
> > the addition of get_cpu_maps in flush_area_mask can lead to deadlocks.
> > As said above get_cpu_maps does a trylock, which means that it will
> > never deadlock, and that's the only way to lock cpu_add_remove_lock.
> 
> That's why I said "cpu_add_remove_lock only used in ways similar to
> how it is used now" - any non-trylock addition would break the
> assumptions you make afaict. And you can't really expect people
> adding another (slightly different) use of an existing lock to be
> aware they now need to check whether this introduces deadlock
> scenarios on unrelated pre-existing code paths. Hence my request to
> at least discuss this in the description (raising awareness, and
> hence allowing reviewers to judge whether further precautionary
> measures should be taken).

Thanks for the clarification, I did indeed misunderstood your
complain.

Regarding the generalization of the shorthand and integration into
send_IPI_mask, I've found an issue related to locking. send_IPI_mask
is called with both interrupts enabled and disabled, and so
get_cpu_maps panics because of the lock checking.

I however don't think that such panic is accurate: the logic in
check_lock specifically relates to the spinning done when picking a
lock, but I would say the call to check_lock in
_spin_trylock{_recursive} is not strictly needed, the scenario
described in check_lock doesn't apply when using trylock.

So my question is whether you would be OK to remove the calls to
check_lock in the trylock variants, or would you rather keep the
shorthand usage limited to flush_area_mask.

Thanks, Roger.

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

[Xen-devel] [PATCH] tools/Rules.mk: fix distclean

[Paul Durrant]

Running 'make distclean' under tools will currently result in:

tools/Rules.mk:245: *** You have to run ./configure before building or 
installing the tools.  Stop.

This patch adds 'distclean', 'subdir-distclean%' and 'subdir-clean%' to
no-configure-targets, which allows 'make distclean' to run to completion.

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/Rules.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/Rules.mk b/tools/Rules.mk
index 31cf419ef4..52f47be3f8 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -239,7 +239,7 @@ subdir-all-% subdir-clean-% subdir-install-% 
subdir-uninstall-%: .phony
 subdir-distclean-%: .phony
$(MAKE) -C $* distclean
 
-no-configure-targets := clean subtree-force-update-all %-dir-force-update
+no-configure-targets := distclean subdir-distclean% clean subdir-clean% 
subtree-force-update-all %-dir-force-update
 ifeq (,$(filter $(no-configure-targets),$(MAKECMDGOALS)))
 $(XEN_ROOT)/config/Tools.mk:
$(error You have to run ./configure before building or installing the 
tools)
-- 
2.20.1


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

Re: [Xen-devel] [PATCH] x86/boot: Rationalise stack handling during early boot

[Andrew Cooper]

On 09/01/2020 10:52, Jan Beulich wrote:
 --- a/xen/arch/x86/smpboot.c
 +++ b/xen/arch/x86/smpboot.c
 @@ -554,7 +554,7 @@ static int do_boot_cpu(int apicid, int cpu)
  printk("Booting processor %d/%d eip %lx\n",
 cpu, apicid, start_eip);
  
 -stack_start = stack_base[cpu];
 +stack_start = stack_base[cpu] + STACK_SIZE - sizeof(struct cpu_info);
  
  /* This grunge runs the startup process for the targeted processor. */
>>> Further down smp_prepare_cpus() has
>>>
>>> stack_base[0] = stack_start;
>>>
>>> which I think you need to also adjust (or replace, e.g. by giving
>>> stack_base[] an initializer).
>> In practice, this variable is never used because we never offline the BSP.
> traps.c uses stack_base[], for example, and hence it needs to be
> correct also for the BSP. Even more important is perhaps
> get_cpu_current()'s use.
>
>> However, the code as-is is correct.  The value in stack_start has
>> changed in this patch, but is still the correct value for the BSP.
> But it's no longer the stack base (which is what stack_base[] holds
> for all other CPUs), or else you wouldn't have had a need to change
> do_boot_cpu().

Oh - of course.  I'm being dense.

To avoid a move into data, lets just go with & ~(STACK_SIZE - 1) here.

~Andrew

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

Re: [Xen-devel] [PATCH] xen: make CONFIG_DEBUG_LOCKS usable without CONFIG_DEBUG

[Jürgen Groß]

On 09.01.20 11:45, Jan Beulich wrote:

On 09.01.2020 11:39, George Dunlap wrote:

On 1/9/20 10:30 AM, Jan Beulich wrote:

On 09.01.2020 11:15, Jürgen Groß  wrote:

On 09.01.20 11:07, George Dunlap wrote:

On 1/9/20 5:40 AM, Juergen Gross wrote:

In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
as it is using ASSERT(), however.


Any reason not to use BUG_ON() in that case?


The main reason is the missing message which condition failed.

A rename ("BUG_ASSERT"?) could be an alternative to just dropping
the message. Both would be fine with me.


How about

 if ( ... )
 {
 printk(...);
 BUG();
 }


Is there a reason we can't make BUG_ON() print the condition?


Of course we could, in principle, at the price of a meaningful
growth of the .rodata section. If we do this, perhaps we'd want
something like Linux'es CONFIG_DEBUG_BUGVERBOSE to control this.


In case nobody objects I'll modify my patch to do that (well, split it
to introduce that option and then use it).


Juergen

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

Re: [Xen-devel] [PATCH] x86/boot: Rationalise stack handling during early boot

[Jan Beulich]

On 09.01.2020 11:43, Andrew Cooper wrote:
> On 09/01/2020 10:28, Jan Beulich wrote:
>> On 08.01.2020 18:00, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/efi/efi-boot.h
>>> +++ b/xen/arch/x86/efi/efi-boot.h
>>> @@ -249,23 +249,24 @@ static void __init noreturn 
>>> efi_arch_post_exit_boot(void)
>>> "or $"__stringify(X86_CR4_PGE)", %[cr4]\n\t"
>>> "mov%[cr4], %%cr4\n\t"
>>>  #endif
>>> -   "movabs $__start_xen, %[rip]\n\t"
>>> "lgdt   boot_gdtr(%%rip)\n\t"
>>> -   "movstack_start(%%rip), %%rsp\n\t"
>>> "mov%[ds], %%ss\n\t"
>>> "mov%[ds], %%ds\n\t"
>>> "mov%[ds], %%es\n\t"
>>> "mov%[ds], %%fs\n\t"
>>> "mov%[ds], %%gs\n\t"
>>> -   "movl   %[cs], 8(%%rsp)\n\t"
>>> -   "mov%[rip], (%%rsp)\n\t"
>>> -   "lretq  %[stkoff]-16"
>>> +
>>> +   /* Jump to higher mappings. */
>>> +   "movstack_start(%%rip), %%rsp\n\t"
>>> +   "movabs $__start_xen, %[rip]\n\t"
>>> +   "push   %[cs]\n\t"
>> Either you need %q[cs] here (assuming q gets ignored for
>> immediate operands, which I didn't check) or ...
>>
>>> +   "push   %[rip]\n\t"
>>> +   "lretq"
>>> : [rip] "=" (efer/* any dead 64-bit variable */),
>>>   [cr4] "+" (cr4)
>>> : [cr3] "r" (idle_pg_table),
>>>   [cs] "ir" (__HYPERVISOR_CS),
>> ... you need to use just "i" here, for there not being 32-bit
>> PUSH forms.
> 
> Lets just go with i.
> 
> "m" is also an option, and clang will probably find some way of pulling
> it out of the stringtable, but anything other than an immediate encoding
> here is going to be silly.

No, sadly "m" is not an option when the expression is a constant:
Gcc at least is unable to materialize a memory variable in this
case, and will give some funny error message instead.

>>> --- a/xen/arch/x86/smpboot.c
>>> +++ b/xen/arch/x86/smpboot.c
>>> @@ -554,7 +554,7 @@ static int do_boot_cpu(int apicid, int cpu)
>>>  printk("Booting processor %d/%d eip %lx\n",
>>> cpu, apicid, start_eip);
>>>  
>>> -stack_start = stack_base[cpu];
>>> +stack_start = stack_base[cpu] + STACK_SIZE - sizeof(struct cpu_info);
>>>  
>>>  /* This grunge runs the startup process for the targeted processor. */
>> Further down smp_prepare_cpus() has
>>
>> stack_base[0] = stack_start;
>>
>> which I think you need to also adjust (or replace, e.g. by giving
>> stack_base[] an initializer).
> 
> In practice, this variable is never used because we never offline the BSP.

traps.c uses stack_base[], for example, and hence it needs to be
correct also for the BSP. Even more important is perhaps
get_cpu_current()'s use.

> However, the code as-is is correct.  The value in stack_start has
> changed in this patch, but is still the correct value for the BSP.

But it's no longer the stack base (which is what stack_base[] holds
for all other CPUs), or else you wouldn't have had a need to change
do_boot_cpu().

> It could also be made into an initialiser, but that would cause
> stack_base[] to move from BSS into data, and it is a NR_CPUS sized
> datastructure.

I do realize this.

Jan

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

Re: [Xen-devel] [PATCH] x86/hvm: always expose x2APIC feature in max HVM cpuid policy

[Roger Pau Monné]

On Tue, Dec 24, 2019 at 07:17:52PM +0100, Roger Pau Monné wrote:
> On Tue, Dec 24, 2019 at 04:00:27PM +, Andrew Cooper wrote:
> > On 24/12/2019 12:42, Roger Pau Monné wrote:
> > > On Tue, Dec 24, 2019 at 12:23:12PM +, Andrew Cooper wrote:
> > >> On 24/12/2019 10:18, Roger Pau Monne wrote:
> > >>> On hardware without x2APIC support Xen emulated local APIC will
> > >>> provide such mode, and hence the feature should be set in the maximum
> > >>> HVM cpuid policy.
> > >>>
> > >>> Not exposing it in the maximum policy results in HVM domains not
> > >>> getting such feature exposed unless it's also supported by the
> > >>> underlying hardware.
> > >>>
> > >>> Signed-off-by: Roger Pau Monné 
> > >> x2apic has never been exposed via this mechanism, due to its effects on
> > >> topology calculations.
> > > Well, it's exposed in hvm_max_cpuid_policy if it's present in the
> > > hardware. IMO it's kind of weird that the presence of the x2APIC feature
> > > on the max policy depends on the underlying hardware, when it's always
> > > supported by the emulated vlapic.
> > >
> > > I think x2APIC must either always be part of the max policy, or never,
> > > or else it's very easy to cause regressions because it's not so easy
> > > to find a box without x2APIC.
> > 
> > Hmm - this does highlight the inconsistency in the existing logic.  I'm
> > not overly surprised - this is a remnant of the old model which hasn't
> > been rewritten yet.
> 
> I could do something like:
> 
> diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
> index 519d6d8bd0..a7adc41854 100644
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -641,6 +641,7 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t 
> domid,
>  p->extd.itsc = true;
>  p->basic.vmx = true;
>  p->extd.svm = true;
> +p->basic.x2apic = true;
>  }
>  
>  rc = x86_cpuid_copy_to_buffer(p, leaves, _leaves);
> 
> But it seems kind of bogus to me that such feature is not part of the
> hvm_max_cpuid_policy, at the end of day the toolstack has no knowledge
> of whether the hypervisor provides a x2APIC interface or not (apart
> from us hardcoding it in the tools like the above patch).

Ping?

I don't think we reached a conclusion as to whether x2APIC should be
forced from the toolstack side or part of the HVM max policy.

Thanks, Roger.

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1) 

[Xen-devel] [PATCH] libxl: Add new "notify-only" childproc mode

[George Dunlap]

libxl needs to be able to know when processes it forks have completed.

At the moment, libxl has two basic mode (with some variations).  In
one mode -- libxl_sigchld_owner_libxl* -- libxl sets up its own
SIGCHLD signal handler, and also handles the event loop that allows
libxl to safely block until the child in question is finished (using a
self-pipe for the SIGCHLD handler to notify the waiters that it's time
to look for reaped children).

In the other mode, libxl does not set up the SIGCHLD handler, nor does
it do anything with processing the event loop; it expects the library
caller to handle the event loop itself.

The golang runtime manages its own processes, and thus must use
SIGCHLD itself; and it has an easy way for other users to get SIGCHLD
notifications.  However, because its event loop is hidden away behind
abstractions, it's not easy to hook into; and there's no need -- the
golang runtime assumes that C function calls may block, and handles
everything behind the scenes.

Introduce a new mode, libxl_sigchld_owner_notify, in which libxl sets
up the SIGCHLD event handling machinery, but relies on the caller to
tell it when a SIGCHLD happens.

Call these two actions "notify" (for the self-pipe notification
machinery) and "handler" (for the actual SIGCHLD handler).

Move the actual notification handler into its own function.  Have
sigchld_handler() call this function, and provide a new external
function, libxl_childproc_sigchld_notify(), for library users to call
when a SIGCHLD happens.

Rename chldmode_ours() to chldmode_notify(), and use it to determine
whether to set up the notification chain.

When setting up the notification chain, do everything except setting
up the signal handler in "notify-only" mode.

defer_sigchld() and release_sigchld() do two things: they modify the
signal handler, and grab and release locks.  Refactor these so that
they grab and release the locks correctly in "notify-only" mode, but
don't tweak the signal handler unless it's been set up.

With the golang bindings ported to use this change, domain creation
works.

Signed-off-by: George Dunlap 
---


CC: Ian Jackson 
CC: Wei Liu 
CC: Anthony Perard 
CC: Nick Rosbrook 
---
 tools/libxl/libxl_event.h| 32 +-
 tools/libxl/libxl_fork.c | 64 +---
 tools/libxl/libxl_internal.h |  4 +--
 3 files changed, 78 insertions(+), 22 deletions(-)

diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index d1517f7456..8001571cf1 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -441,7 +441,7 @@ void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void 
*for_libxl)
  *
  * A program which does this must call libxl_childproc_setmode.
  * There are three options:
- * 
+ *
  * libxl_sigchld_owner_libxl:
  *
  *   While any libxl operation which might use child processes
@@ -466,6 +466,14 @@ void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void 
*for_libxl)
  *   has multiple libxl ctx's, it must call libxl_childproc_exited
  *   on each ctx.)
  *
+ * libxl_sigchld_owner_mainloop_notify:
+ *
+ *   The application must install a SIGCHLD handler, but will
+ *   notify libxl when a sigchld happened by calling
+ *   libxl_childproc_sigchld_notify.  libxl will arrange to reap
+ *   only its own children.  This needs to be called only once,
+ *   even for applications which have multiple libxl ctx's.
+ *
  * libxl_sigchld_owner_libxl_always:
  *
  *   The application expects this libxl ctx to reap all of the
@@ -494,6 +502,12 @@ typedef enum {
  * arrange to (un)block or catch SIGCHLD. */
 libxl_sigchld_owner_mainloop,
 
+/* Application promises to discover when SIGCHLD occurs and call
+ * libxl_childproc_sigchld_notify (perhaps from within a signal
+ * handler).  libxl will not itself arrange to (un)block or catch
+ * SIGCHLD. */
+libxl_sigchld_owner_mainloop_notify,
+
 /* libxl owns SIGCHLD all the time, and the application is
  * relying on libxl's event loop for reaping its children too. */
 libxl_sigchld_owner_libxl_always,
@@ -590,6 +604,22 @@ int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int 
status)
 void libxl_childproc_sigchld_occurred(libxl_ctx *ctx)
LIBXL_EXTERNAL_CALLERS_ONLY;
 
+/*
+ * This function is for an application which owns SIGCHLD but still
+ * expects libxl to handle its own event loops.
+ *
+ * Such an the application must notify libxl, by calling this
+ * function, that a SIGCHLD occurred.  libxl will then notify all
+ * appropriate event loops to check for reaped children..
+ *
+ * May be called only by an application which has called setmode with
+ * chldowner == libxl_sigchld_owner_mainloop_notify.
+ *
+ * MAY be called from within a signal handler.
+ */
+void libxl_childproc_sigchld_notify(void)
+   LIBXL_EXTERNAL_CALLERS_ONLY;
+
 
 /*
  * An application which initialises a 

Re: [Xen-devel] [PATCH] xen: make CONFIG_DEBUG_LOCKS usable without CONFIG_DEBUG

[Jan Beulich]

On 09.01.2020 11:39, George Dunlap wrote:
> On 1/9/20 10:30 AM, Jan Beulich wrote:
>> On 09.01.2020 11:15, Jürgen Groß  wrote:
>>> On 09.01.20 11:07, George Dunlap wrote:
 On 1/9/20 5:40 AM, Juergen Gross wrote:
> In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
> having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
> as it is using ASSERT(), however.

 Any reason not to use BUG_ON() in that case?
>>>
>>> The main reason is the missing message which condition failed.
>>>
>>> A rename ("BUG_ASSERT"?) could be an alternative to just dropping
>>> the message. Both would be fine with me.
>>
>> How about
>>
>> if ( ... )
>> {
>> printk(...);
>> BUG();
>> }
> 
> Is there a reason we can't make BUG_ON() print the condition?

Of course we could, in principle, at the price of a meaningful
growth of the .rodata section. If we do this, perhaps we'd want
something like Linux'es CONFIG_DEBUG_BUGVERBOSE to control this.

Jan

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

Re: [Xen-devel] [PATCH] x86/boot: Rationalise stack handling during early boot

[Andrew Cooper]

On 09/01/2020 10:28, Jan Beulich wrote:
> On 08.01.2020 18:00, Andrew Cooper wrote:
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.h
>> @@ -249,23 +249,24 @@ static void __init noreturn 
>> efi_arch_post_exit_boot(void)
>> "or $"__stringify(X86_CR4_PGE)", %[cr4]\n\t"
>> "mov%[cr4], %%cr4\n\t"
>>  #endif
>> -   "movabs $__start_xen, %[rip]\n\t"
>> "lgdt   boot_gdtr(%%rip)\n\t"
>> -   "movstack_start(%%rip), %%rsp\n\t"
>> "mov%[ds], %%ss\n\t"
>> "mov%[ds], %%ds\n\t"
>> "mov%[ds], %%es\n\t"
>> "mov%[ds], %%fs\n\t"
>> "mov%[ds], %%gs\n\t"
>> -   "movl   %[cs], 8(%%rsp)\n\t"
>> -   "mov%[rip], (%%rsp)\n\t"
>> -   "lretq  %[stkoff]-16"
>> +
>> +   /* Jump to higher mappings. */
>> +   "movstack_start(%%rip), %%rsp\n\t"
>> +   "movabs $__start_xen, %[rip]\n\t"
>> +   "push   %[cs]\n\t"
> Either you need %q[cs] here (assuming q gets ignored for
> immediate operands, which I didn't check) or ...
>
>> +   "push   %[rip]\n\t"
>> +   "lretq"
>> : [rip] "=" (efer/* any dead 64-bit variable */),
>>   [cr4] "+" (cr4)
>> : [cr3] "r" (idle_pg_table),
>>   [cs] "ir" (__HYPERVISOR_CS),
> ... you need to use just "i" here, for there not being 32-bit
> PUSH forms.

Lets just go with i.

"m" is also an option, and clang will probably find some way of pulling
it out of the stringtable, but anything other than an immediate encoding
here is going to be silly.

>
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -554,7 +554,7 @@ static int do_boot_cpu(int apicid, int cpu)
>>  printk("Booting processor %d/%d eip %lx\n",
>> cpu, apicid, start_eip);
>>  
>> -stack_start = stack_base[cpu];
>> +stack_start = stack_base[cpu] + STACK_SIZE - sizeof(struct cpu_info);
>>  
>>  /* This grunge runs the startup process for the targeted processor. */
> Further down smp_prepare_cpus() has
>
> stack_base[0] = stack_start;
>
> which I think you need to also adjust (or replace, e.g. by giving
> stack_base[] an initializer).

In practice, this variable is never used because we never offline the BSP.

However, the code as-is is correct.  The value in stack_start has
changed in this patch, but is still the correct value for the BSP.

It could also be made into an initialiser, but that would cause
stack_base[] to move from BSS into data, and it is a NR_CPUS sized
datastructure.

~Andrew

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

Re: [Xen-devel] [PATCH] xen: make CONFIG_DEBUG_LOCKS usable without CONFIG_DEBUG

[George Dunlap]

On 1/9/20 10:30 AM, Jan Beulich wrote:
> On 09.01.2020 11:15, Jürgen Groß  wrote:
>> On 09.01.20 11:07, George Dunlap wrote:
>>> On 1/9/20 5:40 AM, Juergen Gross wrote:
 In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
 having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
 as it is using ASSERT(), however.
>>>
>>> Any reason not to use BUG_ON() in that case?
>>
>> The main reason is the missing message which condition failed.
>>
>> A rename ("BUG_ASSERT"?) could be an alternative to just dropping
>> the message. Both would be fine with me.
> 
> How about
> 
> if ( ... )
> {
> printk(...);
> BUG();
> }

Is there a reason we can't make BUG_ON() print the condition?

 -George

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

Re: [Xen-devel] [PATCH v1 4/4] xen/netback: Fix grant copy across page boundary with KASAN

[Vlastimil Babka]

On 1/8/20 4:21 PM, Sergey Dyasli wrote:
> From: Ross Lagerwall 
> 
> When KASAN (or SLUB_DEBUG) is turned on, the normal expectation that
> allocations are aligned to the next power of 2 of the size does not
> hold.

Hmm, really? They should after 59bb47985c1d ("mm, sl[aou]b: guarantee
natural alignment for kmalloc(power-of-two)"), i.e. since 5.4.

But actually the guarantee is only for precise power of two sizes given
to kmalloc(). Allocations of sizes that end up using the 96 or 192 bytes
kmalloc cache have no such guarantee. But those might then cross page
boundary also without SLUB_DEBUG.

> Therefore, handle grant copies that cross page boundaries.
> 
> Signed-off-by: Ross Lagerwall 
> Signed-off-by: Sergey Dyasli 
> ---
> RFC --> v1:
> - Added BUILD_BUG_ON to the netback patch
> - xenvif_idx_release() now located outside the loop
> 
> CC: Wei Liu 
> CC: Paul Durrant 
> ---
>  drivers/net/xen-netback/common.h  |  2 +-
>  drivers/net/xen-netback/netback.c | 59 +--
>  2 files changed, 49 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/common.h 
> b/drivers/net/xen-netback/common.h
> index 05847eb91a1b..e57684415edd 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -155,7 +155,7 @@ struct xenvif_queue { /* Per-queue data for xenvif */
>   struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
>   grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
>  
> - struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
> + struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS * 2];
>   struct gnttab_map_grant_ref tx_map_ops[MAX_PENDING_REQS];
>   struct gnttab_unmap_grant_ref tx_unmap_ops[MAX_PENDING_REQS];
>   /* passed to gnttab_[un]map_refs with pages under (un)mapping */
> diff --git a/drivers/net/xen-netback/netback.c 
> b/drivers/net/xen-netback/netback.c
> index 0020b2e8c279..33b8f8d043e6 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -320,6 +320,7 @@ static int xenvif_count_requests(struct xenvif_queue 
> *queue,
>  
>  struct xenvif_tx_cb {
>   u16 pending_idx;
> + u8 copies;
>  };
>  
>  #define XENVIF_TX_CB(skb) ((struct xenvif_tx_cb *)(skb)->cb)
> @@ -439,6 +440,7 @@ static int xenvif_tx_check_gop(struct xenvif_queue *queue,
>  {
>   struct gnttab_map_grant_ref *gop_map = *gopp_map;
>   u16 pending_idx = XENVIF_TX_CB(skb)->pending_idx;
> + u8 copies = XENVIF_TX_CB(skb)->copies;
>   /* This always points to the shinfo of the skb being checked, which
>* could be either the first or the one on the frag_list
>*/
> @@ -450,23 +452,26 @@ static int xenvif_tx_check_gop(struct xenvif_queue 
> *queue,
>   int nr_frags = shinfo->nr_frags;
>   const bool sharedslot = nr_frags &&
>   frag_get_pending_idx(>frags[0]) == 
> pending_idx;
> - int i, err;
> + int i, err = 0;
>  
> - /* Check status of header. */
> - err = (*gopp_copy)->status;
> - if (unlikely(err)) {
> - if (net_ratelimit())
> - netdev_dbg(queue->vif->dev,
> + while (copies) {
> + /* Check status of header. */
> + int newerr = (*gopp_copy)->status;
> + if (unlikely(newerr)) {
> + if (net_ratelimit())
> + netdev_dbg(queue->vif->dev,
>  "Grant copy of header failed! status: %d 
> pending_idx: %u ref: %u\n",
>  (*gopp_copy)->status,
>  pending_idx,
>  (*gopp_copy)->source.u.ref);
> - /* The first frag might still have this slot mapped */
> - if (!sharedslot)
> - xenvif_idx_release(queue, pending_idx,
> -XEN_NETIF_RSP_ERROR);
> + err = newerr;
> + }
> + (*gopp_copy)++;
> + copies--;
>   }
> - (*gopp_copy)++;
> + /* The first frag might still have this slot mapped */
> + if (unlikely(err) && !sharedslot)
> + xenvif_idx_release(queue, pending_idx, XEN_NETIF_RSP_ERROR);
>  
>  check_frags:
>   for (i = 0; i < nr_frags; i++, gop_map++) {
> @@ -910,6 +915,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue 
> *queue,
>   xenvif_tx_err(queue, , extra_count, idx);
>   break;
>   }
> + XENVIF_TX_CB(skb)->copies = 0;
>  
>   skb_shinfo(skb)->nr_frags = ret;
>   if (data_len < txreq.size)
> @@ -933,6 +939,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue 
> *queue,
>  "Can't allocate the 
> frag_list skb.\n");
>   break;
>   }
> + XENVIF_TX_CB(nskb)->copies = 0;
>   }
>  

Re: [Xen-devel] [PATCH] xen: make CONFIG_DEBUG_LOCKS usable without CONFIG_DEBUG

[Jan Beulich]

On 09.01.2020 11:15, Jürgen Groß  wrote:
> On 09.01.20 11:07, George Dunlap wrote:
>> On 1/9/20 5:40 AM, Juergen Gross wrote:
>>> In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
>>> having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
>>> as it is using ASSERT(), however.
>>
>> Any reason not to use BUG_ON() in that case?
> 
> The main reason is the missing message which condition failed.
> 
> A rename ("BUG_ASSERT"?) could be an alternative to just dropping
> the message. Both would be fine with me.

How about

if ( ... )
{
printk(...);
BUG();
}

?

Jan

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

Re: [Xen-devel] [PATCH v4 17/18] x86/mem_sharing: reset a fork

[Julien Grall]

On 08/01/2020 17:14, Tamas K Lengyel wrote:

Implement hypercall that allows a fork to shed all memory that got allocated
for it during its execution and re-load its vCPU context from the parent VM.
This allows the forked VM to reset into the same state the parent VM is in a
faster way then creating a new fork would be. Measurements show about a 2x
speedup during normal fuzzing operations. Performance may vary depending how
much memory got allocated for the forked VM. If it has been completely
deduplicated from the parent VM then creating a new fork would likely be more
performant.

Signed-off-by: Tamas K Lengyel 
---
  xen/arch/x86/mm/mem_sharing.c | 79 +++
  xen/include/public/memory.h   |  1 +
  2 files changed, 80 insertions(+)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index d544801681..aaa678da14 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1607,6 +1607,62 @@ static int mem_sharing_fork(struct domain *d, struct 
domain *cd)
  return 0;
  }
  
+/*

+ * The fork reset operation is intended to be used on short-lived forks only.
+ * There is no hypercall continuation operation implemented for this reason.
+ * For forks that obtain a larger memory footprint it is likely going to be
+ * more performant to create a new fork instead of resetting an existing one.
+ *
+ * TODO: In case this hypercall would become useful on forks with larger memory
+ * footprints the hypercall continuation should be implemented.
+ */
+static int mem_sharing_fork_reset(struct domain *d, struct domain *cd)
+{
+int rc;
+struct p2m_domain* p2m = p2m_get_hostp2m(cd);
+struct page_info *page, *tmp;
+
+if ( !d->controller_pause_count &&
+ (rc = domain_pause_by_systemcontroller(d)) )
+return rc;


Similar question as patch #15 here.


+
+page_list_for_each_safe(page, tmp, >page_list)
+{
+p2m_type_t p2mt;
+p2m_access_t p2ma;
+gfn_t gfn;
+mfn_t mfn = page_to_mfn(page);
+
+if ( !mfn_valid(mfn) )
+continue;
+
+gfn = mfn_to_gfn(cd, mfn);
+mfn = __get_gfn_type_access(p2m, gfn_x(gfn), , ,
+0, NULL, false);
+
+if ( !p2m_is_ram(p2mt) || p2m_is_shared(p2mt) )
+continue;
+
+/* take an extra reference */
+if ( !get_page(page, cd) )
+continue;
+
+rc = p2m->set_entry(p2m, gfn, INVALID_MFN, PAGE_ORDER_4K,
+p2m_invalid, p2m_access_rwx, -1);
+ASSERT(!rc);
+
+put_page_alloc_ref(page);
+put_page(page);
+}
+
+if ( (rc = hvm_copy_context_and_params(d, cd)) )
+return rc;
+
+fork_tsc(d, cd);
+
+return 0;
+}
+
  int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
  {
  int rc;
@@ -1909,6 +1965,29 @@ int 
mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
  break;
  }
  
+case XENMEM_sharing_op_fork_reset:

+{
+struct domain *pd;
+
+rc = -EINVAL;
+if ( mso.u.fork._pad[0] || mso.u.fork._pad[1] ||
+ mso.u.fork._pad[2] )
+goto out;
+
+rc = -ENOSYS;
+if ( !d->parent )
+goto out;
+
+rc = rcu_lock_live_remote_domain_by_id(d->parent->domain_id, );
+if ( rc )
+goto out;
+
+rc = mem_sharing_fork_reset(pd, d);
+
+rcu_unlock_domain(pd);
+break;
+}
+
  default:
  rc = -ENOSYS;
  break;
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 90a3f4498e..e3d063e22e 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -483,6 +483,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_access_op_t);
  #define XENMEM_sharing_op_audit 7
  #define XENMEM_sharing_op_range_share   8
  #define XENMEM_sharing_op_fork  9
+#define XENMEM_sharing_op_fork_reset10
  
  #define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)

  #define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)



--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86/boot: Rationalise stack handling during early boot

[Jan Beulich]

On 08.01.2020 18:00, Andrew Cooper wrote:
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -249,23 +249,24 @@ static void __init noreturn 
> efi_arch_post_exit_boot(void)
> "or $"__stringify(X86_CR4_PGE)", %[cr4]\n\t"
> "mov%[cr4], %%cr4\n\t"
>  #endif
> -   "movabs $__start_xen, %[rip]\n\t"
> "lgdt   boot_gdtr(%%rip)\n\t"
> -   "movstack_start(%%rip), %%rsp\n\t"
> "mov%[ds], %%ss\n\t"
> "mov%[ds], %%ds\n\t"
> "mov%[ds], %%es\n\t"
> "mov%[ds], %%fs\n\t"
> "mov%[ds], %%gs\n\t"
> -   "movl   %[cs], 8(%%rsp)\n\t"
> -   "mov%[rip], (%%rsp)\n\t"
> -   "lretq  %[stkoff]-16"
> +
> +   /* Jump to higher mappings. */
> +   "movstack_start(%%rip), %%rsp\n\t"
> +   "movabs $__start_xen, %[rip]\n\t"
> +   "push   %[cs]\n\t"

Either you need %q[cs] here (assuming q gets ignored for
immediate operands, which I didn't check) or ...

> +   "push   %[rip]\n\t"
> +   "lretq"
> : [rip] "=" (efer/* any dead 64-bit variable */),
>   [cr4] "+" (cr4)
> : [cr3] "r" (idle_pg_table),
>   [cs] "ir" (__HYPERVISOR_CS),

... you need to use just "i" here, for there not being 32-bit
PUSH forms.

> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -554,7 +554,7 @@ static int do_boot_cpu(int apicid, int cpu)
>  printk("Booting processor %d/%d eip %lx\n",
> cpu, apicid, start_eip);
>  
> -stack_start = stack_base[cpu];
> +stack_start = stack_base[cpu] + STACK_SIZE - sizeof(struct cpu_info);
>  
>  /* This grunge runs the startup process for the targeted processor. */

Further down smp_prepare_cpus() has

stack_base[0] = stack_start;

which I think you need to also adjust (or replace, e.g. by giving
stack_base[] an initializer).

Jan

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

Re: [Xen-devel] [PATCH v4 15/18] xen/mem_sharing: VM forking

[Julien Grall]

Hi Tamas,

On 08/01/2020 17:14, Tamas K Lengyel wrote:

+static int mem_sharing_fork(struct domain *d, struct domain *cd)
+{
+int rc;
+
+if ( !d->controller_pause_count &&
+ (rc = domain_pause_by_systemcontroller(d)) )


AFAIU, the parent domain will be paused if it wasn't paused before and 
this will not be unpaused by the same hypercall. Right?


If so, this brings two questions:
- What would happen if the toolstack decide to unpause the domain?
- How does the caller knows whether this was paused by the 
hypercall or not?


I would also suggest to document the behavior of the hypercall as this 
is not entirely obvious that the domain will be paused here.



+return rc;
+
+cd->max_pages = d->max_pages;
+cd->max_vcpus = d->max_vcpus;
+
+/* this is preemptible so it's the first to get done */
+if ( (rc = fork_hap_allocation(d, cd)) )
+return rc;
+
+if ( (rc = bring_up_vcpus(cd, d->cpupool)) )
+return rc;
+
+if ( (rc = hvm_copy_context_and_params(d, cd)) )
+return rc;
+
+fork_tsc(d, cd);
+
+cd->parent = d;


How do you ensure that the parent domain will not get destroyed before 
the forked domain? Do you have a refcount somewhere?



+
+return 0;
+}
+


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen: make CONFIG_DEBUG_LOCKS usable without CONFIG_DEBUG

[Jan Beulich]

On 09.01.2020 11:07, George Dunlap wrote:
> On 1/9/20 5:40 AM, Juergen Gross wrote:
>> In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
>> having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
>> as it is using ASSERT(), however.
> 
> Any reason not to use BUG_ON() in that case?
> 
> Having two different asserts is almost certainly going to cause bugs.

Furthermore, assert() is a C standard library construct,
mandated to be controlled by NDEBUG. I.e. if anything at all,
ASSERT() could be made behave differently, but of course this
would be quite big a change to the code base. +1 to (continue)
using BUG_ON() anywhere we want more than just debug build
checking.

Jan

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

Re: [Xen-devel] [PATCH] xen: make CONFIG_DEBUG_LOCKS usable without CONFIG_DEBUG

[Jürgen Groß]

On 09.01.20 11:07, George Dunlap wrote:

On 1/9/20 5:40 AM, Juergen Gross wrote:

In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
as it is using ASSERT(), however.


Any reason not to use BUG_ON() in that case?


The main reason is the missing message which condition failed.

A rename ("BUG_ASSERT"?) could be an alternative to just dropping
the message. Both would be fine with me.



Having two different asserts is almost certainly going to cause bugs.


Obviously having only one is enough for bugs already. ;-)


Juergen


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

Re: [Xen-devel] [PATCH] xen: make CONFIG_DEBUG_LOCKS usable without CONFIG_DEBUG

[George Dunlap]

On 1/9/20 5:40 AM, Juergen Gross wrote:
> In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
> having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
> as it is using ASSERT(), however.

Any reason not to use BUG_ON() in that case?

Having two different asserts is almost certainly going to cause bugs.

 -George

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  832656fa8e6f7bfa6eb5f6f7de5ede697c6392e8
baseline version:
 libvirt  7f0b2f21627d7d81e7fbc0e4da17950a8bf54b59

Last test of basis   145779  2020-01-08 04:19:07 Z1 days
Testing same since   145842  2020-01-09 04:18:43 Z0 days1 attempts


People who touched revisions under test:
  Ján Tomko 
  Michal Privoznik 
  Peter Krempa 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/libvirt.git
   7f0b2f2162..832656fa8e  832656fa8e6f7bfa6eb5f6f7de5ede697c6392e8 -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH v2 00/20] VM forking

[Roger Pau Monné]

On Wed, Jan 08, 2020 at 12:51:35PM -0700, Tamas K Lengyel wrote:
> On Wed, Jan 8, 2020 at 11:37 AM Roger Pau Monné  wrote:
> >
> > On Wed, Jan 08, 2020 at 11:14:46AM -0700, Tamas K Lengyel wrote:
> > > On Wed, Jan 8, 2020 at 11:01 AM Roger Pau Monné  
> > > wrote:
> > > >
> > > > On Wed, Jan 08, 2020 at 08:32:22AM -0700, Tamas K Lengyel wrote:
> > > > > On Wed, Jan 8, 2020 at 8:08 AM Roger Pau Monné  
> > > > > wrote:
> > > > > > I think you also need something like:
> > > > > >
> > > > > > # xl fork-vm --launch-dm late  
> > > > > >
> > > > > > So that a user doesn't need to pass a qemu-save-file?
> > > > >
> > > > > This doesn't make much sense to me. To launch QEMU you need the config
> > > > > file to wire things up correctly. Like in order to launch QEMU you
> > > > > need to tell it the name of the VM, disk path, etc. that are all
> > > > > contained in the config.
> > > >
> > > > You could get all this information from the parent VM, IIRC libxl has
> > > > a json version of the config. For example for migration there's no
> > > > need to pass any config file, since the incoming VM can be recreated
> > > > from the data in the source VM.
> > > >
> > >
> > > But again, creating a fork with the exact config of the parent is not
> > > possible. Even if the tool would rename the fork on-the-fly as it does
> > > during the migration, the fork would end up thrashing the parent VM's
> > > disk and making it impossible to create any additional forks. It would
> > > also mean that at no point can the original VM be unpaused after the
> > > forks are gone. I don't see any usecase in which that would make any
> > > sense at all.
> >
> > You could have the disk(s) as read-only and the VM running completely
> > from RAM. Alpine-linux has (or had) a mode where it was completely
> > stateless and running from RAM. I think it's fine to require passing a
> > config file for the time being, we can look at other options
> > afterwards.
> >
> 
> OK, there is that. But I would say that's a fairly niche use-case. You
> wouldn't have any network access in that fork, no disk, no way to get
> information in or out beside the serial console.

Why won't the fork have network access?

If the parent VM is left paused the fork should behave like a local
migration regarding network access, and thus be fully functional.

> So I wouldn't want
> that setup to be considered the default. If someone wants to that I
> would rather have an option that tells xl to automatically name the
> fork for you instead of the other way around.

Ack, I just want to make sure that whatever interface we end up using
is designed taking into account other use cases apart from the one at
hand.

On an unrelated note, does forking work when using PV interfaces?

Thanks, Roger.

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