[Xen-devel] [linux-linus test] 118638: regressions - FAIL

[osstest service owner]

flight 118638 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118638/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 118324
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
118324
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 118324
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 118324
 test-amd64-amd64-xl-qemut-win10-i386  7 xen-boot fail REGR. vs. 118324
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 118324
 test-amd64-amd64-xl-qemut-win7-amd64  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail REGR. vs. 118324
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 118324
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 118324
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 118324
 test-amd64-amd64-xl-pvhv2-intel  7 xen-boot  fail REGR. vs. 118324
 test-amd64-amd64-xl-qemuu-win10-i386  7 xen-boot fail REGR. vs. 118324
 test-amd64-amd64-qemuu-nested-amd  7 xen-bootfail REGR. vs. 118324
 test-amd64-amd64-xl-pvhv2-amd  7 xen-bootfail REGR. vs. 118324
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 118324
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 118324
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 118324
 test-amd64-amd64-xl-qemut-ws16-amd64  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 118324
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 118324
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 118324
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 118324
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 118324
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 118324
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 118324
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 118324
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
118324
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 118324
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  7 xen-bootfail REGR. vs. 118324
 test-amd64-amd64-xl-qemuu-win7-amd64  7 xen-boot fail REGR. vs. 118324
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 118324
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 118324
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 118324
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 118324
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 118324
 test-amd64-amd64-xl-qemuu-ws16-amd64  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
118324
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 118630

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118630
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118630
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118630
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118630
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118630
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118630
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-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-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  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-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-amd64-amd64-libvirt-vhd 12 migrate-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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 qemuubc2943d6caf787e1c9a5f3109cdb98f37630b89e
baseline version:
 qemuu20e0d439a6ded635ec89f6135c08cd5541c68962

Last test of basis   118630  2018-02-06 23:42:48 Z1 days
Testing same since   118643  2018-02-07 12:46:45 Z0 days1 attempts


People who touched revisions under test:
  Amador Pahim 
  Daniel P. Berrange 
  Eduardo Habkost 
  Miika S 
  Peter Maydell 

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

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Alexey G]

On Wed, 7 Feb 2018 13:01:08 +
Igor Druzhinin  wrote:
>So far the issue confirmed:
>Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
>that it was tested on), Intel S2600XX, etc.
>
>Also see:
>https://bugs.xenserver.org/browse/XSO-774
>
>Well, no-watchdog is what we currently recommend in that case but we
>hoped there is a general solution here from Xen side. You have your
>point that they should fix this on their side because it's their fault
>indeed. But the user experience is also important for us I think.

Igor,

It would be nice to measure the actual SMI handling time on affected
systems (eg. via rdtsc before/after inb(0x61) + averaging for
multiple reads perhaps), is it really 10+ ms.

There might be a chance that perf counter frequency is calculated wrong
for some systems, resulting in a very high rate of NMI watchdog ticks
instead of long SMI handler execution time. >10ms just looks... too
extreme.

Huawei Server 2488 V5 BIOS -- similar SMI I/O trap handler for the port
61h found. Some differences with gigabyte H270 system though:

- no "allocated" I/O traps anymore, but one additional SMI I/O trap
  encountered: port 900h, dword size. Possibly related to PCIe PM
  facilities.

- port 61h SMI handler now has multiple calls to debug/assert stub
  functions -- there might be a chance that some of impacted systems
  had debug build on, resulting in those stubs expanded to some real
  debugging code with negative impact on SMI handling speed.

Few additional observations:

- port 61h I/O Trap SMI handler checks accessed I/O address/size to be
  equal to 61h/1byte. There might be some difference when reading port
  61h via inw(0x60)/inl(0x60)/etc

- looks like there exist an alternative way to read NMI status without
  triggering SMI -- via ports 63h/65h/67h, but this depends on
  undocumented bit in Generic Control and Status register

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

[Xen-devel] [seabios test] 118647: regressions - FAIL

[osstest service owner]

flight 118647 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118647/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 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-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 seabios  14d91c353e19b7085fdbb7b2dcc43f3355665670
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   96 days
Failing since115733  2017-11-10 17:19:59 Z   89 days  112 attempts
Testing same since   118140  2018-01-17 05:09:48 Z   21 days   33 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Marcel Apfelbaum 
  Michael S. Tsirkin 
  Paul Menzel 
  Stefan Berger 

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-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



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

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

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

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


Not pushing.


commit 14d91c353e19b7085fdbb7b2dcc43f3355665670
Author: Marcel Apfelbaum 
Date:   Thu Jan 11 22:15:12 2018 +0200

pci: fix 'io hints' capability for RedHat PCI bridges

Commit ec6cb17f (pci: enable RedHat PCI bridges to reserve additional
 resources on PCI init)
added a new vendor specific PCI capability for RedHat PCI bridges
allowing them to reserve additional buses and/or IO/MEM space.

When adding the IO hints PCI capability to the pcie-root-port
without specifying a value for bus reservation, the subordinate bus
computation is wrong and the guest kernel gets messed up.

Fix it by returning to prev code if the value for bus
reservation is not set.

Removed also a wrong debug print "PCI: invalid QEMU resource reserve
cap offset" which appears if the 'IO hints' capability is not present.

Acked-by: Michael S. Tsirkin 

[Xen-devel] [linux-next test] 118636: regressions - trouble: broken/fail/pass

[osstest service owner]

flight 118636 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118636/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-amd64 broken
 test-amd64-i386-freebsd10-amd64  4 host-install(4) broken REGR. vs. 118611
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 118611
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 118611
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 118611
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 118611
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 118611
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 118611
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 118611
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
118611
 test-amd64-amd64-xl-qemuu-ws16-amd64  7 xen-boot fail REGR. vs. 118611
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 118611
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 118611
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 118611
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 118611
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 118611
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
118611
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 118611
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 118611
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 118611
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118611
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 118611
 test-amd64-amd64-xl-pvhv2-intel  7 xen-boot  fail REGR. vs. 118611
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 118611
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 118611
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 118611
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 118611
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 118611
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 118611
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 118611
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-saverestore.2 fail REGR. 
vs. 118611
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 118611
 test-armhf-armhf-libvirt 12 guest-start  fail REGR. vs. 118611
 test-armhf-armhf-xl-credit2   7 xen-boot fail REGR. vs. 118611
 test-armhf-armhf-xl-xsm  10 debian-install   fail REGR. vs. 118611
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 118611
 test-armhf-armhf-xl  10 debian-install   fail REGR. vs. 118611

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 10 debian-install   fail REGR. vs. 118611

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot  fail blocked in 118611
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot  fail blocked in 118611
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail like 118611
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118611
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118611
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118611
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118611
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  

[Xen-devel] [PATCH] libxl: set channel devid when not provided by application

[Jim Fehlig]

Applications like libvirt may not populate a device devid field,
delegating that to libxl. If needed, the application can later
retrieve the libxl-produced devid. Indeed most devices are handled
this way in libvirt, channel devices included.

This works well when only one channel device is defined, but more
than one results in

qemu-system-i386: -chardev socket,id=libxl-channel-1,\
path=/tmp/test-org.qemu.guest_agent.00,server,nowait:
Duplicate ID 'libxl-channel-1' for chardev

Besides the odd '-1' value in the id, multiple channels have the same
id, causing qemu to fail. A simple fix is to set an uninitialized
devid (-1) to the dev_num passed to libxl__init_console_from_channel().

Signed-off-by: Jim Fehlig 
---

I get the feeling that if needed devid should be set earlier, but
this seems like the most opportune spot. Suggestions for improvements
welcome.

 tools/libxl/libxl_console.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index 39d8430df8..8faf3a24f3 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/libxl_console.c
@@ -401,6 +401,9 @@ int libxl__init_console_from_channel(libxl__gc *gc,
 
 /* Perform validation first, allocate second. */
 
+if (channel->devid == -1)
+channel->devid = dev_num;
+
 if (!channel->name) {
 LOG(ERROR, "channel %d has no name", channel->devid);
 return ERROR_INVAL;
-- 
2.16.0


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

Re: [Xen-devel] [PATCH] x86/xen: Calculate __max_logical_packages on PV domains

[Boris Ostrovsky]

On 02/07/2018 06:49 PM, Prarit Bhargava wrote:

The kernel panics on PV domains because native_smp_cpus_done() is
only called for HVM domains.

Calculate __max_logical_packages for PV domains.

Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate")
Signed-off-by: Prarit Bhargava 
Tested-and-reported-by: Simon Gaiser 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Dou Liyang 
Cc: Prarit Bhargava 
Cc: Kate Stewart 
Cc: Greg Kroah-Hartman 
Cc: Andy Lutomirski 
Cc: Andi Kleen 
Cc: Vitaly Kuznetsov 
Cc: xen-devel@lists.xenproject.org



Reviewed-by: Boris Ostrovsky 

(+ Simon)


---
  arch/x86/include/asm/smp.h |  1 +
  arch/x86/kernel/smpboot.c  | 10 --
  arch/x86/xen/smp.c |  2 ++
  3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index 461f53d27708..a4189762b266 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -129,6 +129,7 @@ static inline void arch_send_call_function_ipi_mask(const 
struct cpumask *mask)
  void cpu_disable_common(void);
  void native_smp_prepare_boot_cpu(void);
  void native_smp_prepare_cpus(unsigned int max_cpus);
+void calculate_max_logical_packages(void);
  void native_smp_cpus_done(unsigned int max_cpus);
  void common_cpu_up(unsigned int cpunum, struct task_struct *tidle);
  int native_cpu_up(unsigned int cpunum, struct task_struct *tidle);
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 6f27facbaa9b..767573b7f2db 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1281,11 +1281,10 @@ void __init native_smp_prepare_boot_cpu(void)
cpu_set_state_online(me);
  }
  
-void __init native_smp_cpus_done(unsigned int max_cpus)

+void __init calculate_max_logical_packages(void)
  {
int ncpus;
  
-	pr_debug("Boot done\n");

/*
 * Today neither Intel nor AMD support heterogenous systems so
 * extrapolate the boot cpu's data to all packages.
@@ -1293,6 +1292,13 @@ void __init native_smp_cpus_done(unsigned int max_cpus)
ncpus = cpu_data(0).booted_cores * topology_max_smt_threads();
__max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
pr_info("Max logical packages: %u\n", __max_logical_packages);
+}
+
+void __init native_smp_cpus_done(unsigned int max_cpus)
+{
+   pr_debug("Boot done\n");
+
+   calculate_max_logical_packages();
  
  	if (x86_has_numa_in_package)

set_sched_topology(x86_numa_in_package_topology);
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 77c959cf81e7..7a43b2ae19f1 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -122,6 +122,8 @@ void __init xen_smp_cpus_done(unsigned int max_cpus)
  
  	if (xen_hvm_domain())

native_smp_cpus_done(max_cpus);
+   else
+   calculate_max_logical_packages();
  
  	if (xen_have_vcpu_info_placement)

return;



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

[Xen-devel] [PATCH] x86/xen: Calculate __max_logical_packages on PV domains

[Prarit Bhargava]

The kernel panics on PV domains because native_smp_cpus_done() is
only called for HVM domains.

Calculate __max_logical_packages for PV domains.

Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate")
Signed-off-by: Prarit Bhargava 
Tested-and-reported-by: Simon Gaiser 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Dou Liyang 
Cc: Prarit Bhargava 
Cc: Kate Stewart 
Cc: Greg Kroah-Hartman 
Cc: Andy Lutomirski 
Cc: Andi Kleen 
Cc: Vitaly Kuznetsov 
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/include/asm/smp.h |  1 +
 arch/x86/kernel/smpboot.c  | 10 --
 arch/x86/xen/smp.c |  2 ++
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index 461f53d27708..a4189762b266 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -129,6 +129,7 @@ static inline void arch_send_call_function_ipi_mask(const 
struct cpumask *mask)
 void cpu_disable_common(void);
 void native_smp_prepare_boot_cpu(void);
 void native_smp_prepare_cpus(unsigned int max_cpus);
+void calculate_max_logical_packages(void);
 void native_smp_cpus_done(unsigned int max_cpus);
 void common_cpu_up(unsigned int cpunum, struct task_struct *tidle);
 int native_cpu_up(unsigned int cpunum, struct task_struct *tidle);
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 6f27facbaa9b..767573b7f2db 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1281,11 +1281,10 @@ void __init native_smp_prepare_boot_cpu(void)
cpu_set_state_online(me);
 }
 
-void __init native_smp_cpus_done(unsigned int max_cpus)
+void __init calculate_max_logical_packages(void)
 {
int ncpus;
 
-   pr_debug("Boot done\n");
/*
 * Today neither Intel nor AMD support heterogenous systems so
 * extrapolate the boot cpu's data to all packages.
@@ -1293,6 +1292,13 @@ void __init native_smp_cpus_done(unsigned int max_cpus)
ncpus = cpu_data(0).booted_cores * topology_max_smt_threads();
__max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
pr_info("Max logical packages: %u\n", __max_logical_packages);
+}
+
+void __init native_smp_cpus_done(unsigned int max_cpus)
+{
+   pr_debug("Boot done\n");
+
+   calculate_max_logical_packages();
 
if (x86_has_numa_in_package)
set_sched_topology(x86_numa_in_package_topology);
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 77c959cf81e7..7a43b2ae19f1 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -122,6 +122,8 @@ void __init xen_smp_cpus_done(unsigned int max_cpus)
 
if (xen_hvm_domain())
native_smp_cpus_done(max_cpus);
+   else
+   calculate_max_logical_packages();
 
if (xen_have_vcpu_info_placement)
return;
-- 
2.15.0.rc0.39.g2f0e14e64


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  c93014ad3aa6aa88dfa5e96f66e8adb561483b8d
baseline version:
 xen  6222e7cbaa1ed75dd8f9d90cfa394a49fed0be2c

Last test of basis   118660  2018-02-07 18:01:41 Z0 days
Testing same since   118665  2018-02-07 21:01:07 Z0 days1 attempts


People who touched revisions under test:
  Christian Lindig 
  Olaf Hering 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   6222e7cbaa..c93014ad3a  c93014ad3aa6aa88dfa5e96f66e8adb561483b8d -> smoke

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

[Xen-devel] [PATCH 2/2] xen: xenbus: WARN_ON XS_TRANSACTION_{START, END} misuse

[Simon Gaiser]

As the previous commit shows it's quite easy to confuse the transaction
reference counting by ending a transaction twice. So at least try to
detect and report it.

Signed-off-by: Simon Gaiser 
---
 drivers/xen/xenbus/xenbus_xs.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 3e59590c7254..aed954b09b9b 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -137,11 +137,20 @@ static uint32_t xs_request_enter(struct xb_req_data *req)
 
 void xs_request_exit(struct xb_req_data *req)
 {
+   unsigned int users_old;
+
spin_lock(_state_lock);
+   users_old = xs_state_users;
xs_state_users--;
if ((req->type == XS_TRANSACTION_START && req->msg.type == XS_ERROR) ||
req->type == XS_TRANSACTION_END)
xs_state_users--;
+   if (WARN_ON(xs_state_users > users_old))
+   /*
+* Someone misused XS_TRANSACTION_{START,END}. Reset the
+* reference counter so we might survive.
+*/
+   xs_state_users = 0;
spin_unlock(_state_lock);
 
if (xs_suspend_active && !xs_state_users)
-- 
2.15.1


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

[Xen-devel] [PATCH 1/2] xen: xenbus_dev_frontend: Fix XS_TRANSACTION_END handling

[Simon Gaiser]

Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
concurrent xenstore accesses") made a subtle change to the semantic of
xenbus_dev_request_and_reply() and xenbus_transaction_end().

Before on an error response to XS_TRANSACTION_END
xenbus_dev_request_and_reply() would not decrement the active
transaction counter. But xenbus_transaction_end() has always counted the
transaction as finished regardless of the response.

The new behavior is that xenbus_dev_request_and_reply() and
xenbus_transaction_end() will always count the transaction as finished
regardless the response code (handled in xs_request_exit()).

But xenbus_dev_frontend tries to end a transaction on closing of the
device if the XS_TRANSACTION_END failed before. Trying to close the
transaction twice corrupts the reference count. So fix this by also
considering a transaction closed if we have sent XS_TRANSACTION_END once
regardless of the return code.

Cc:  # 4.11
Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent 
xenstore accesses")
Signed-off-by: Simon Gaiser 
---
 drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c 
b/drivers/xen/xenbus/xenbus_dev_frontend.c
index f3b089b7c0b6..d2edbc79384a 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -365,7 +365,7 @@ void xenbus_dev_queue_reply(struct xb_req_data *req)
if (WARN_ON(rc))
goto out;
}
-   } else if (req->msg.type == XS_TRANSACTION_END) {
+   } else if (req->type == XS_TRANSACTION_END) {
trans = xenbus_get_transaction(u, req->msg.tx_id);
if (WARN_ON(!trans))
goto out;
-- 
2.15.1


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

Re: [Xen-devel] [PATCH v2 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

[Brian Woods]

If Andy wants to use his version of this, that's fine also.  This is
just a newer version based on Jan's input.

v1 -> v2
Got rid of "== X"s
Added an assert and got rid of a check in an if

-- 
Brian Woods

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

[Xen-devel] [PATCH v2 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

[Brian Woods]

Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.

Reported-by: Andrew Cooper 
Signed-off-by: Brian Woods 
---
 xen/arch/x86/hvm/svm/svm.c  | 71 +
 xen/arch/x86/hvm/svm/vmcb.c | 17 ---
 2 files changed, 71 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index c48fdfaa5d..3e9c81b0e4 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -601,6 +601,75 @@ void svm_update_guest_cr(struct vcpu *v, unsigned int cr)
 }
 }
 
+/*
+ * This runs on EFER change to see if nested features need to either be
+ * turned off or on.
+ */
+static void svm_nested_features_on_efer_update(struct vcpu *v)
+{
+struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+struct nestedsvm *svm = _nestedsvm(v);
+u32 general2_intercepts;
+vintr_t vintr;
+
+if ( !nestedhvm_enabled(v->domain) )
+ASSERT(!(v->arch.hvm_vcpu.guest_efer & EFER_SVME));
+
+/*
+ * Need state for transfering the nested gif status so only write on
+ * the hvm_vcpu EFER.SVME changing.
+ */
+if ( v->arch.hvm_vcpu.guest_efer & EFER_SVME )
+{
+if ( !vmcb->virt_ext.fields.vloadsave_enable &&
+ paging_mode_hap(v->domain) &&
+ cpu_has_svm_vloadsave )
+{
+vmcb->virt_ext.fields.vloadsave_enable = 1;
+general2_intercepts  = vmcb_get_general2_intercepts(vmcb);
+general2_intercepts &= ~(GENERAL2_INTERCEPT_VMLOAD |
+ GENERAL2_INTERCEPT_VMSAVE);
+vmcb_set_general2_intercepts(vmcb, general2_intercepts);
+}
+
+if ( !vmcb->_vintr.fields.vgif_enable &&
+ cpu_has_svm_vgif )
+{
+vintr = vmcb_get_vintr(vmcb);
+vintr.fields.vgif = svm->ns_gif;
+vintr.fields.vgif_enable = 1;
+vmcb_set_vintr(vmcb, vintr);
+general2_intercepts  = vmcb_get_general2_intercepts(vmcb);
+general2_intercepts &= ~(GENERAL2_INTERCEPT_STGI |
+ GENERAL2_INTERCEPT_CLGI);
+vmcb_set_general2_intercepts(vmcb, general2_intercepts);
+}
+}
+else
+{
+if ( vmcb->virt_ext.fields.vloadsave_enable )
+{
+vmcb->virt_ext.fields.vloadsave_enable = 0;
+general2_intercepts  = vmcb_get_general2_intercepts(vmcb);
+general2_intercepts |= (GENERAL2_INTERCEPT_VMLOAD |
+GENERAL2_INTERCEPT_VMSAVE);
+vmcb_set_general2_intercepts(vmcb, general2_intercepts);
+}
+
+if ( vmcb->_vintr.fields.vgif_enable )
+{
+vintr = vmcb_get_vintr(vmcb);
+svm->ns_gif = vintr.fields.vgif;
+vintr.fields.vgif_enable = 0;
+vmcb_set_vintr(vmcb, vintr);
+general2_intercepts  = vmcb_get_general2_intercepts(vmcb);
+general2_intercepts |= (GENERAL2_INTERCEPT_STGI |
+GENERAL2_INTERCEPT_CLGI);
+vmcb_set_general2_intercepts(vmcb, general2_intercepts);
+}
+}
+}
+
 static void svm_update_guest_efer(struct vcpu *v)
 {
 struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
@@ -611,6 +680,8 @@ static void svm_update_guest_efer(struct vcpu *v)
 if ( lma )
 new_efer |= EFER_LME;
 vmcb_set_efer(vmcb, new_efer);
+
+svm_nested_features_on_efer_update(v);
 }
 
 static void svm_cpuid_policy_changed(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 0e6cba5b7b..997e7597e0 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -200,29 +200,12 @@ static int construct_vmcb(struct vcpu *v)
 
 /* PAT is under complete control of SVM when using nested paging. */
 svm_disable_intercept_for_msr(v, MSR_IA32_CR_PAT);
-
-/* Use virtual VMLOAD/VMSAVE if available. */
-if ( cpu_has_svm_vloadsave )
-{
-vmcb->virt_ext.fields.vloadsave_enable = 1;
-vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_VMLOAD;
-vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_VMSAVE;
-}
 }
 else
 {
 vmcb->_exception_intercepts |= (1U << TRAP_page_fault);
 }
 
-/* if available, enable and configure virtual gif */
-if ( cpu_has_svm_vgif )
-{
-vmcb->_vintr.fields.vgif = 1;
-vmcb->_vintr.fields.vgif_enable = 1;
-vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_STGI;
-vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_CLGI;
-}
-
 if ( cpu_has_pause_filter )
 {
 vmcb->_pause_filter_count = SVM_PAUSEFILTER_INIT;
-- 
2.11.0


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  6222e7cbaa1ed75dd8f9d90cfa394a49fed0be2c
baseline version:
 xen  66c4f0c47fd80d1133c24865f95d4f0c59ef9bce

Last test of basis   118650  2018-02-07 15:01:17 Z0 days
Testing same since   118660  2018-02-07 18:01:41 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Roger Pau Monné 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   66c4f0c47f..6222e7cbaa  6222e7cbaa1ed75dd8f9d90cfa394a49fed0be2c -> smoke

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

[Xen-devel] update on the status of SP2 mitigations for Xen on Arm

[Stefano Stabellini]

Hi all,

This is the latest status of the SP2 mitigations for Xen on Arm. Please
note that arm32 and arm64 require different mitigations.

I have just backported the arm32 mitigation to 4.10, 4.9, 4.8 and 4.7:

- 4.10
bbd093c xen/arm32: entry: Document the purpose of r11 in the traps handler
a69a8b5 xen/arm32: Invalidate icache on guest exist for Cortex-A15
f167ebf xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
c4c0187 xen/arm32: Add skeleton to harden branch predictor aliasing attacks
19ad8a7 xen/arm32: entry: Add missing trap_reset entry
3caf32c xen/arm32: Add missing MIDR values for Cortex-A17 and A12
df7be94 xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros

- 4.9
4d01dbc xen/arm32: entry: Document the purpose of r11 in the traps handler
22379b6 xen/arm32: Invalidate icache on guest exist for Cortex-A15
6e13ad7 xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
0d32237 xen/arm32: Add skeleton to harden branch predictor aliasing attacks
4ba59bd xen/arm32: entry: Add missing trap_reset entry
2997c5e xen/arm32: Add missing MIDR values for Cortex-A17 and A12
751c879 xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros

- 4.8
11875b7 xen/arm32: entry: Document the purpose of r11 in the traps handler
1105f3a xen/arm32: Invalidate icache on guest exist for Cortex-A15
754345c xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
7336d0d xen/arm32: Add skeleton to harden branch predictor aliasing attacks
cf95bba xen/arm32: entry: Add missing trap_reset entry
a586cbd xen/arm32: Add missing MIDR values for Cortex-A17 and A12
6082e3b xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros

- 4.7
f50ea84 xen/arm32: entry: Document the purpose of r11 in the traps handler
de3bdaa xen/arm32: Invalidate icache on guest exist for Cortex-A15
766990b xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
4ac0229 xen/arm32: Add skeleton to harden branch predictor aliasing attacks
bafd63f xen/arm32: entry: Add missing trap_reset entry
d5bb425 xen/arm32: Add missing MIDR values for Cortex-A17 and A12
003ec3e xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros


The arm64 backports have been in the staging trees for a while, see:
https://marc.info/?l=xen-devel=151690105623579

Julien posted another series to improve the SP2 mitigation for arm64:
https://marc.info/?l=xen-devel=151783688420038
It is not yet reviewed. This second series is highly desirable, as it
uses better firmware interfaces for the mitigation.

At present, Xen is using a PSCI get_version call (it is a call to the
PSCI firmware) for the mitigation. It relies on the firmware cleaning
the branch predictor cache in the implementation of the get_version
call. However, it appers that get_version doesn't actually do the
expected task on most arm64 platforms. Hence, the need for a new series
and a better firmware call. Julien, feel free to add more details here.

Cheers,

Stefano

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

Re: [Xen-devel] [PATCH v2 1/7] x86: slightly reduce Meltdown band-aid overhead

[Andrew Cooper]

On 07/02/18 16:12, Jan Beulich wrote:
> I'm not sure why I didn't do this right away: By avoiding the use of
> global PTEs in the cloned directmap, there's no need to fiddle with
> CR4.PGE on any of the entry paths. Only the exit paths need to flush
> global mappings.
>
> The reduced flushing, however, implies that we now need to have
> interrupts off on all entry paths until after the page table switch, so
> that flush IPIs can't arrive with the restricted page tables still
> active, but only a non-global flush happening with the CR3 loads. Along
> those lines the "sync" IPI after L4 entry updates now needs to become a
> real (and global) flush IPI, so that inside Xen we'll also pick up such
> changes.

Actually, on second consideration, why does reenabling interrupts need
to be deferred?

The safety of the sync_guest path (which previously entered Xen, did
nothing, and exited again) relied on the entry part flushing global
mappings for safety, as the return-to-xen path doesn't necessarily
switch mappings.

However, the first hunk upgrading the "do nothing" to a proper global
flush, covers that case.

I don't see anything else which affects the safety of taking TLB flush
IPIs early in the entry-from-guest path.  What am I missing?

~Andrew

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

Re: [Xen-devel] [v6, 3/3] x86/smpboot: Fix __max_logical_packages estimate

[Prarit Bhargava]

On 02/07/2018 02:26 PM, Simon Gaiser wrote:
> Prarit Bhargava:
>> On 02/07/2018 01:44 PM, Simon Gaiser wrote:



>>> This breaks booting as Xen PV domain for me. The problem seems to be
>>> that native_smp_cpus_done() is never called on a PV domain. So
>>> __max_logical_packages is uninitialized and this leads to a NULL
>>> pointer dereference in coretemp.
>>>
>>
>> I'll see if I can figure out a way to test that.
> 
> Ok, thanks. If you need some logs, or if I should test something just
> ask.
> 

Thanks, I may send you a patch off-list to test.

>> Does 947134d9b00f
>> ("x86/smpboot: Do not use smp_num_siblings in __max_logical_packages
>> calculation") help?
> 
> No.
> 

Yeah, your description was absolutely correct.  native_smp_cpus_done() is only
called for HVM guests and not PV.  I'm going to think about that and send you a
patch in a bit.

P.

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

Re: [Xen-devel] [v6, 3/3] x86/smpboot: Fix __max_logical_packages estimate

[Simon Gaiser]

Prarit Bhargava:
> On 02/07/2018 01:44 PM, Simon Gaiser wrote:
>> Prarit Bhargava:
>>> A system booted with a small number of cores enabled per package
>>> panics because the estimate of __max_logical_packages is too low.
>>> This occurs when the total number of active cores across all packages
>>> is less than the maximum core count for a single package.
>>>
>>> ie) On a 4 package system with 20 cores/package where only 4 cores
>>> are enabled on each package, the value of __max_logical_packages is
>>> calculated as DIV_ROUND_UP(16 / 20) = 1 and not 4.
>>>
>>> Calculate __max_logical_packages after the cpu enumeration has completed.
>>> Use the boot cpu's data to extrapolate the number of packages.
>>>
>>> Signed-off-by: Prarit Bhargava 
>>> Cc: Thomas Gleixner 
>>> Cc: Ingo Molnar 
>>> Cc: "H. Peter Anvin" 
>>> Cc: x...@kernel.org
>>> Cc: Peter Zijlstra 
>>> Cc: Andi Kleen 
>>> Cc: Dave Hansen 
>>> Cc: Piotr Luc 
>>> Cc: Kan Liang 
>>> Cc: Borislav Petkov 
>>> Cc: Stephane Eranian 
>>> Cc: Prarit Bhargava 
>>> Cc: Arvind Yadav 
>>> Cc: Andy Lutomirski 
>>> Cc: Christian Borntraeger 
>>> Cc: "Kirill A. Shutemov" 
>>> Cc: Tom Lendacky 
>>> Cc: He Chen 
>>> Cc: Mathias Krause 
>>> Cc: Tim Chen 
>>> Cc: Vitaly Kuznetsov 
>>> ---
>>>  arch/x86/kernel/smpboot.c | 55 
>>> +--
>>>  1 file changed, 10 insertions(+), 45 deletions(-)
>>>
>>> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
>>> index 838d36ff7ba6..2e3c5a394e79 100644
>>> --- a/arch/x86/kernel/smpboot.c
>>> +++ b/arch/x86/kernel/smpboot.c
>>> @@ -308,12 +308,6 @@ int topology_update_package_map(unsigned int pkg, 
>>> unsigned int cpu)
>>> if (new >= 0)
>>> goto found;
>>>  
>>> -   if (logical_packages >= __max_logical_packages) {
>>> -   pr_warn("Package %u of CPU %u exceeds BIOS package data %u.\n",
>>> -   logical_packages, cpu, __max_logical_packages);
>>> -   return -ENOSPC;
>>> -   }
>>> -
>>> new = logical_packages++;
>>> if (new != pkg)
>>> pr_info("CPU %u Converting physical %u to logical package %u\n",
>>> @@ -323,44 +317,6 @@ int topology_update_package_map(unsigned int pkg, 
>>> unsigned int cpu)
>>> return 0;
>>>  }
>>>  
>>> -static void __init smp_init_package_map(struct cpuinfo_x86 *c, unsigned 
>>> int cpu)
>>> -{
>>> -   unsigned int ncpus;
>>> -
>>> -   /*
>>> -* Today neither Intel nor AMD support heterogenous systems. That
>>> -* might change in the future
>>> -*
>>> -* While ideally we'd want '* smp_num_siblings' in the below @ncpus
>>> -* computation, this won't actually work since some Intel BIOSes
>>> -* report inconsistent HT data when they disable HT.
>>> -*
>>> -* In particular, they reduce the APIC-IDs to only include the cores,
>>> -* but leave the CPUID topology to say there are (2) siblings.
>>> -* This means we don't know how many threads there will be until
>>> -* after the APIC enumeration.
>>> -*
>>> -* By not including this we'll sometimes over-estimate the number of
>>> -* logical packages by the amount of !present siblings, but this is
>>> -* still better than MAX_LOCAL_APIC.
>>> -*
>>> -* We use total_cpus not nr_cpu_ids because nr_cpu_ids can be limited
>>> -* on the command line leading to a similar issue as the HT disable
>>> -* problem because the hyperthreads are usually enumerated after the
>>> -* primary cores.
>>> -*/
>>> -   ncpus = boot_cpu_data.x86_max_cores;
>>> -   if (!ncpus) {
>>> -   pr_warn("x86_max_cores == zero !?!?");
>>> -   ncpus = 1;
>>> -   }
>>> -
>>> -   __max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);
>>> -   pr_info("Max logical packages: %u\n", __max_logical_packages);
>>> -
>>> -   topology_update_package_map(c->phys_proc_id, cpu);
>>> -}
>>> -
>>>  void __init smp_store_boot_cpu_info(void)
>>>  {
>>> int id = 0; /* CPU 0 */
>>> @@ -368,7 +324,7 @@ void __init smp_store_boot_cpu_info(void)
>>>  
>>> *c = boot_cpu_data;
>>> c->cpu_index = id;
>>> -   smp_init_package_map(c, id);
>>> +   topology_update_package_map(c->phys_proc_id, id);
>>> cpu_data(id).set = 1;
>>>  }
>>>  
>>> @@ -1371,7 +1327,16 @@ void __init native_smp_prepare_boot_cpu(void)
>>>  
>>>  void __init native_smp_cpus_done(unsigned int max_cpus)
>>>  {
>>> +   int ncpus;
>>> +
>>> pr_debug("Boot done\n");
>>> +   /*
>>> +* Today neither Intel nor AMD support heterogenous systems so
>>> +* 

Re: [Xen-devel] [v6, 3/3] x86/smpboot: Fix __max_logical_packages estimate

[Prarit Bhargava]

On 02/07/2018 01:44 PM, Simon Gaiser wrote:
> Prarit Bhargava:
>> A system booted with a small number of cores enabled per package
>> panics because the estimate of __max_logical_packages is too low.
>> This occurs when the total number of active cores across all packages
>> is less than the maximum core count for a single package.
>>
>> ie) On a 4 package system with 20 cores/package where only 4 cores
>> are enabled on each package, the value of __max_logical_packages is
>> calculated as DIV_ROUND_UP(16 / 20) = 1 and not 4.
>>
>> Calculate __max_logical_packages after the cpu enumeration has completed.
>> Use the boot cpu's data to extrapolate the number of packages.
>>
>> Signed-off-by: Prarit Bhargava 
>> Cc: Thomas Gleixner 
>> Cc: Ingo Molnar 
>> Cc: "H. Peter Anvin" 
>> Cc: x...@kernel.org
>> Cc: Peter Zijlstra 
>> Cc: Andi Kleen 
>> Cc: Dave Hansen 
>> Cc: Piotr Luc 
>> Cc: Kan Liang 
>> Cc: Borislav Petkov 
>> Cc: Stephane Eranian 
>> Cc: Prarit Bhargava 
>> Cc: Arvind Yadav 
>> Cc: Andy Lutomirski 
>> Cc: Christian Borntraeger 
>> Cc: "Kirill A. Shutemov" 
>> Cc: Tom Lendacky 
>> Cc: He Chen 
>> Cc: Mathias Krause 
>> Cc: Tim Chen 
>> Cc: Vitaly Kuznetsov 
>> ---
>>  arch/x86/kernel/smpboot.c | 55 
>> +--
>>  1 file changed, 10 insertions(+), 45 deletions(-)
>>
>> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
>> index 838d36ff7ba6..2e3c5a394e79 100644
>> --- a/arch/x86/kernel/smpboot.c
>> +++ b/arch/x86/kernel/smpboot.c
>> @@ -308,12 +308,6 @@ int topology_update_package_map(unsigned int pkg, 
>> unsigned int cpu)
>>  if (new >= 0)
>>  goto found;
>>  
>> -if (logical_packages >= __max_logical_packages) {
>> -pr_warn("Package %u of CPU %u exceeds BIOS package data %u.\n",
>> -logical_packages, cpu, __max_logical_packages);
>> -return -ENOSPC;
>> -}
>> -
>>  new = logical_packages++;
>>  if (new != pkg)
>>  pr_info("CPU %u Converting physical %u to logical package %u\n",
>> @@ -323,44 +317,6 @@ int topology_update_package_map(unsigned int pkg, 
>> unsigned int cpu)
>>  return 0;
>>  }
>>  
>> -static void __init smp_init_package_map(struct cpuinfo_x86 *c, unsigned int 
>> cpu)
>> -{
>> -unsigned int ncpus;
>> -
>> -/*
>> - * Today neither Intel nor AMD support heterogenous systems. That
>> - * might change in the future
>> - *
>> - * While ideally we'd want '* smp_num_siblings' in the below @ncpus
>> - * computation, this won't actually work since some Intel BIOSes
>> - * report inconsistent HT data when they disable HT.
>> - *
>> - * In particular, they reduce the APIC-IDs to only include the cores,
>> - * but leave the CPUID topology to say there are (2) siblings.
>> - * This means we don't know how many threads there will be until
>> - * after the APIC enumeration.
>> - *
>> - * By not including this we'll sometimes over-estimate the number of
>> - * logical packages by the amount of !present siblings, but this is
>> - * still better than MAX_LOCAL_APIC.
>> - *
>> - * We use total_cpus not nr_cpu_ids because nr_cpu_ids can be limited
>> - * on the command line leading to a similar issue as the HT disable
>> - * problem because the hyperthreads are usually enumerated after the
>> - * primary cores.
>> - */
>> -ncpus = boot_cpu_data.x86_max_cores;
>> -if (!ncpus) {
>> -pr_warn("x86_max_cores == zero !?!?");
>> -ncpus = 1;
>> -}
>> -
>> -__max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);
>> -pr_info("Max logical packages: %u\n", __max_logical_packages);
>> -
>> -topology_update_package_map(c->phys_proc_id, cpu);
>> -}
>> -
>>  void __init smp_store_boot_cpu_info(void)
>>  {
>>  int id = 0; /* CPU 0 */
>> @@ -368,7 +324,7 @@ void __init smp_store_boot_cpu_info(void)
>>  
>>  *c = boot_cpu_data;
>>  c->cpu_index = id;
>> -smp_init_package_map(c, id);
>> +topology_update_package_map(c->phys_proc_id, id);
>>  cpu_data(id).set = 1;
>>  }
>>  
>> @@ -1371,7 +1327,16 @@ void __init native_smp_prepare_boot_cpu(void)
>>  
>>  void __init native_smp_cpus_done(unsigned int max_cpus)
>>  {
>> +int ncpus;
>> +
>>  pr_debug("Boot done\n");
>> +/*
>> + * Today neither Intel nor AMD support heterogenous systems so
>> + * extrapolate the boot cpu's data to all packages.
>> + */
>> +ncpus = 

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

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsmbroken
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken REGR. 
vs. 118607

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118607
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118607
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118607
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118607
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118607
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118607
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118607
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 118607
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118607
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118607
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  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-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-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-amd64-amd64-libvirt-vhd 12 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-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-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-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail 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-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  30cbd0c83ef3d0edac2d5bcc41a9a2b7a843ae58
baseline version:
 xen  1c3545eeaf4ac6f8d5db5a52c29c112694bcd4f0

Last test of basis   118607  2018-02-06 05:47:11 Z1 days
Failing since118622  2018-02-06 19:15:37 Z0 days2 attempts
Testing same since   118633  2018-02-07 06:20:37 Z0 days1 

Re: [Xen-devel] [v6, 3/3] x86/smpboot: Fix __max_logical_packages estimate

[Simon Gaiser]

Prarit Bhargava:
> A system booted with a small number of cores enabled per package
> panics because the estimate of __max_logical_packages is too low.
> This occurs when the total number of active cores across all packages
> is less than the maximum core count for a single package.
> 
> ie) On a 4 package system with 20 cores/package where only 4 cores
> are enabled on each package, the value of __max_logical_packages is
> calculated as DIV_ROUND_UP(16 / 20) = 1 and not 4.
> 
> Calculate __max_logical_packages after the cpu enumeration has completed.
> Use the boot cpu's data to extrapolate the number of packages.
> 
> Signed-off-by: Prarit Bhargava 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: x...@kernel.org
> Cc: Peter Zijlstra 
> Cc: Andi Kleen 
> Cc: Dave Hansen 
> Cc: Piotr Luc 
> Cc: Kan Liang 
> Cc: Borislav Petkov 
> Cc: Stephane Eranian 
> Cc: Prarit Bhargava 
> Cc: Arvind Yadav 
> Cc: Andy Lutomirski 
> Cc: Christian Borntraeger 
> Cc: "Kirill A. Shutemov" 
> Cc: Tom Lendacky 
> Cc: He Chen 
> Cc: Mathias Krause 
> Cc: Tim Chen 
> Cc: Vitaly Kuznetsov 
> ---
>  arch/x86/kernel/smpboot.c | 55 
> +--
>  1 file changed, 10 insertions(+), 45 deletions(-)
> 
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 838d36ff7ba6..2e3c5a394e79 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -308,12 +308,6 @@ int topology_update_package_map(unsigned int pkg, 
> unsigned int cpu)
>   if (new >= 0)
>   goto found;
>  
> - if (logical_packages >= __max_logical_packages) {
> - pr_warn("Package %u of CPU %u exceeds BIOS package data %u.\n",
> - logical_packages, cpu, __max_logical_packages);
> - return -ENOSPC;
> - }
> -
>   new = logical_packages++;
>   if (new != pkg)
>   pr_info("CPU %u Converting physical %u to logical package %u\n",
> @@ -323,44 +317,6 @@ int topology_update_package_map(unsigned int pkg, 
> unsigned int cpu)
>   return 0;
>  }
>  
> -static void __init smp_init_package_map(struct cpuinfo_x86 *c, unsigned int 
> cpu)
> -{
> - unsigned int ncpus;
> -
> - /*
> -  * Today neither Intel nor AMD support heterogenous systems. That
> -  * might change in the future
> -  *
> -  * While ideally we'd want '* smp_num_siblings' in the below @ncpus
> -  * computation, this won't actually work since some Intel BIOSes
> -  * report inconsistent HT data when they disable HT.
> -  *
> -  * In particular, they reduce the APIC-IDs to only include the cores,
> -  * but leave the CPUID topology to say there are (2) siblings.
> -  * This means we don't know how many threads there will be until
> -  * after the APIC enumeration.
> -  *
> -  * By not including this we'll sometimes over-estimate the number of
> -  * logical packages by the amount of !present siblings, but this is
> -  * still better than MAX_LOCAL_APIC.
> -  *
> -  * We use total_cpus not nr_cpu_ids because nr_cpu_ids can be limited
> -  * on the command line leading to a similar issue as the HT disable
> -  * problem because the hyperthreads are usually enumerated after the
> -  * primary cores.
> -  */
> - ncpus = boot_cpu_data.x86_max_cores;
> - if (!ncpus) {
> - pr_warn("x86_max_cores == zero !?!?");
> - ncpus = 1;
> - }
> -
> - __max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);
> - pr_info("Max logical packages: %u\n", __max_logical_packages);
> -
> - topology_update_package_map(c->phys_proc_id, cpu);
> -}
> -
>  void __init smp_store_boot_cpu_info(void)
>  {
>   int id = 0; /* CPU 0 */
> @@ -368,7 +324,7 @@ void __init smp_store_boot_cpu_info(void)
>  
>   *c = boot_cpu_data;
>   c->cpu_index = id;
> - smp_init_package_map(c, id);
> + topology_update_package_map(c->phys_proc_id, id);
>   cpu_data(id).set = 1;
>  }
>  
> @@ -1371,7 +1327,16 @@ void __init native_smp_prepare_boot_cpu(void)
>  
>  void __init native_smp_cpus_done(unsigned int max_cpus)
>  {
> + int ncpus;
> +
>   pr_debug("Boot done\n");
> + /*
> +  * Today neither Intel nor AMD support heterogenous systems so
> +  * extrapolate the boot cpu's data to all packages.
> +  */
> + ncpus = cpu_data(0).booted_cores * smp_num_siblings;
> + __max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
> + pr_info("Max 

Re: [Xen-devel] [PATCH V3] x86/hvm: fix domain crash when CR3 has the noflush bit set

[Razvan Cojocaru]

On 02/07/2018 07:01 PM, Jan Beulich wrote:
 On 02.02.18 at 09:14,  wrote:
>> @@ -2313,6 +2314,12 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
>>  }
>>  }
>>  
>> +if ( hvm_pcid_enabled(v) ) /* Clear the noflush bit. */
>> +{
>> +noflush = !!(value & X86_CR3_NOFLUSH);
> 
> Pointless !!.

I'll change it.

>> --- a/xen/include/asm-x86/hvm/hvm.h
>> +++ b/xen/include/asm-x86/hvm/hvm.h
>> @@ -34,6 +34,9 @@ extern bool_t opt_hvm_fep;
>>  #define opt_hvm_fep 0
>>  #endif
>>  
>> +#define X86_CR3_NOFLUSH (1ull << 63)
> 
> This belongs in x86-defs.h

I'll move it.

>> +#define X86_CR3_NOFLUSH_DISABLE_MASK (X86_CR3_NOFLUSH - 1)
> 
> This shouldn't be needed (use ~X86_CR3_NOFLUSH instead).

Agreed.

>> @@ -322,9 +325,10 @@ hvm_update_host_cr3(struct vcpu *v)
>>  hvm_funcs.update_host_cr3(v);
>>  }
>>  
>> -static inline void hvm_update_guest_cr(struct vcpu *v, unsigned int cr)
>> +static inline void hvm_update_guest_cr(struct vcpu *v, unsigned int cr,
>> +   bool noflush)
>>  {
>> -hvm_funcs.update_guest_cr(v, cr);
>> +hvm_funcs.update_guest_cr(v, cr, noflush);
>>  }
> 
> Instead of altering this function (and a lot of callers), how about
> introducing
> 
> static inline void hvm_update_guest_cr3(struct vcpu *v, bool noflush)
> {
> hvm_funcs.update_guest_cr(v, 3, noflush);
> }
> 
> ? I'm also not convinced of the update_guest_cr() hook taking a
> bool which is meaningless for all other CRs. Perhaps a more general
> flags parameter would be better, with CR-specific meaning (you'd
> then e.g. introduce HVM_UPDATE_GUEST_CR3_NO_FLUSH).

Very true. I'll change the patch.


Thanks for the review,
Razvan

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

Re: [Xen-devel] [PATCH 1/2] ocaml/xb: update xb.mli in accordance with df1e4c6e7f8

[Christian Lindig]

> On 7. Feb 2018, at 17:09, Wei Liu  wrote:
> 
> Signed-off-by: Wei Liu 
> ---
> tools/ocaml/libs/xb/xb.mli | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/ocaml/libs/xb/xb.mli b/tools/ocaml/libs/xb/xb.mli
> index b4d705201f..95d1c6f840 100644
> --- a/tools/ocaml/libs/xb/xb.mli
> +++ b/tools/ocaml/libs/xb/xb.mli
> @@ -76,10 +76,10 @@ type t = {
> val init_partial_in : unit -> partial_buf
> val reconnect : t -> unit
> val queue : t -> Packet.t -> unit
> -val read_fd : backend_fd -> 'a -> string -> int -> int
> +val read_fd : backend_fd -> 'a -> bytes -> int -> int
> val read_mmap : backend_mmap -> 'a -> string -> int -> int
> val read : t -> string -> int -> int
> -val write_fd : backend_fd -> 'a -> string -> int -> int
> +val write_fd : backend_fd -> 'a -> bytes -> int -> int
> val write_mmap : backend_mmap -> 'a -> string -> int -> int
> val write : t -> string -> int -> int
> val output : t -> bool
> -- 
> 2.11.0
> 

Acked-by: Christian Lindig 

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

Re: [Xen-devel] [PATCH 2/2] ocaml/libs/xb: don't generate *.mli automatically

[Christian Lindig]

> On 7. Feb 2018, at 17:09, Wei Liu  wrote:
> 
> To stay in line with other parts of the ocaml code base.
> 
> This requires committing a bunch of mli files in tree.
> 
> Signed-off-by: Wei Liu 
> ---
> tools/ocaml/libs/xb/Makefile|  4 
> tools/ocaml/libs/xb/op.mli  | 29 +
> tools/ocaml/libs/xb/packet.mli  | 13 +
> tools/ocaml/libs/xb/partial.mli | 14 ++
> 4 files changed, 56 insertions(+), 4 deletions(-)
> create mode 100644 tools/ocaml/libs/xb/op.mli
> create mode 100644 tools/ocaml/libs/xb/packet.mli
> create mode 100644 tools/ocaml/libs/xb/partial.mli
> 
> diff --git a/tools/ocaml/libs/xb/Makefile b/tools/ocaml/libs/xb/Makefile
> index 09d1bc8946..be4499147e 100644
> --- a/tools/ocaml/libs/xb/Makefile
> +++ b/tools/ocaml/libs/xb/Makefile
> @@ -39,10 +39,6 @@ xenbus.cmo : $(foreach obj, $(OBJS), $(obj).cmo)
>   $(E) " CMO  $@"
>   $(OCAMLC) -pack -o $@ $^
> 
> -%.mli: %.ml
> - $(E) " MLI  $@"
> - $(Q)$(OCAMLC) $(OCAMLINCLUDE) -i $< $o
> -
> .PHONY: install
> install: $(LIBS) META
>   mkdir -p $(OCAMLDESTDIR)
> diff --git a/tools/ocaml/libs/xb/op.mli b/tools/ocaml/libs/xb/op.mli
> new file mode 100644
> index 00..ecabfff0d1
> --- /dev/null
> +++ b/tools/ocaml/libs/xb/op.mli
> @@ -0,0 +1,29 @@
> +type operation =
> +Debug
> +  | Directory
> +  | Read
> +  | Getperms
> +  | Watch
> +  | Unwatch
> +  | Transaction_start
> +  | Transaction_end
> +  | Introduce
> +  | Release
> +  | Getdomainpath
> +  | Write
> +  | Mkdir
> +  | Rm
> +  | Setperms
> +  | Watchevent
> +  | Error
> +  | Isintroduced
> +  | Resume
> +  | Set_target
> +  | Reset_watches
> +  | Invalid
> +val operation_c_mapping : operation array
> +val size : int
> +val array_search : 'a -> 'a array -> int
> +val of_cval : int -> operation
> +val to_cval : operation -> int
> +val to_string : operation -> string
> diff --git a/tools/ocaml/libs/xb/packet.mli b/tools/ocaml/libs/xb/packet.mli
> new file mode 100644
> index 00..f4e53c73a8
> --- /dev/null
> +++ b/tools/ocaml/libs/xb/packet.mli
> @@ -0,0 +1,13 @@
> +type t = { tid : int; rid : int; ty : Op.operation; data : string; }
> +exception Error of string
> +exception DataError of string
> +external string_of_header : int -> int -> int -> int -> string
> +  = "stub_string_of_header"
> +val create : int -> int -> Op.operation -> string -> t
> +val of_partialpkt : Partial.pkt -> t
> +val to_string : t -> string
> +val unpack : t -> int * int * Op.operation * string
> +val get_tid : t -> int
> +val get_ty : t -> Op.operation
> +val get_data : t -> string
> +val get_rid : t -> int
> diff --git a/tools/ocaml/libs/xb/partial.mli b/tools/ocaml/libs/xb/partial.mli
> new file mode 100644
> index 00..359a75e88d
> --- /dev/null
> +++ b/tools/ocaml/libs/xb/partial.mli
> @@ -0,0 +1,14 @@
> +type pkt = {
> +  tid : int;
> +  rid : int;
> +  ty : Op.operation;
> +  len : int;
> +  buf : Buffer.t;
> +}
> +external header_size : unit -> int = "stub_header_size"
> +external header_of_string_internal : string -> int * int * int * int
> +  = "stub_header_of_string"
> +val xenstore_payload_max : int
> +val of_string : string -> pkt
> +val append : pkt -> string -> int -> unit
> +val to_complete : pkt -> int
> -- 
> 2.11.0
> 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  66c4f0c47fd80d1133c24865f95d4f0c59ef9bce
baseline version:
 xen  30cbd0c83ef3d0edac2d5bcc41a9a2b7a843ae58

Last test of basis   118626  2018-02-06 20:01:03 Z0 days
Failing since118641  2018-02-07 12:19:12 Z0 days2 attempts
Testing same since   118650  2018-02-07 15:01:17 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christian Lindig 
  George Dunlap 
  Jan Beulich 
  Michael Young 
  Olaf Hering 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   30cbd0c83e..66c4f0c47f  66c4f0c47fd80d1133c24865f95d4f0c59ef9bce -> smoke

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

Re: [Xen-devel] [PATCH] stubdom: install firmware files as data

[Wei Liu]

On Wed, Feb 07, 2018 at 04:11:17PM +0100, Olaf Hering wrote:
> Remove the executable bits of vtpm files by using _DATA instead of _PROG.
> 
> Signed-off-by: Olaf Hering 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Andrew Cooper]

On 07/02/18 15:06, Jan Beulich wrote:
 On 07.02.18 at 14:24,  wrote:
>> On 07/02/18 13:08, Jan Beulich wrote:
>> On 07.02.18 at 14:01,  wrote:
 So far the issue confirmed:
 Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
 that it was tested on), Intel S2600XX, etc.

 Also see:
 https://bugs.xenserver.org/browse/XSO-774 

 Well, no-watchdog is what we currently recommend in that case but we
 hoped there is a general solution here from Xen side. You have your
 point that they should fix this on their side because it's their fault
 indeed. But the user experience is also important for us I think.
>>> Of course, hence the suggestion of possible alternative workarounds.
>>> Impacting everyone is, as said, not a desirable approach in a case
>>> like this one. I also continue to dislike the seemingly random division
>>> by 10.
>> Xen's usability is crap, which is in large part due to attitude like
>> this.  It is not ok to expect the end user to know diagnose/debug issues
>> like this, and it is entirely unreasonable to expect the end user to
>> have to manually work around it.
> Excuse me? The watchdog is off by default. Anyone turning it on
> ought to know what they do. You (iirc) turning it on unilaterally in
> XenServer puts the burden of avoidng users to have to diagnose
> the issue on you.

And we have taken the burden of diagnosing the issue, as well as
proposing a fix.

>
>> This particular issue does want feeding back to Intel so they can try
>> and fix it, but whatever is wrong is present in a large amount of
>> Skylake systems in the field.  Xen needs to be able to cope.
> But in a reasonable way.
>
>> Finally, as to boot times, your argument is backwards seeing as you care
>> about elapsed boot time.  Slowing the frequency will speed everything
>> up, as we aren't executing a large chunk of the BSP boot path with 100hz
>> NMI constantly interrupting.
> How long does handling a single NMI take? Microseconds, I assume.
> Contrast this with waiting for two NMIs to arrive in wait_for_nmis(),
> which goes up from 20ms to 200ms with this change.

So you're argument is to not change the frequency because an
off-by-default option will *in the best case* add a few hundred
milliseconds extra to the boot time?  Times to boot computers are
measured in minutes, not milliseconds.

I don't know how long servicing an NMI takes, at a minimum of a rdmsr,
wrmsr and then a further mmio write or wrmsr, I doubt it is that quick.

> Also you completely ignore my argument against the seemingly
> random division by 10, including the resulting question of what you
> mean to do once 10Hz also turns out too high a frequency.

We've got to pick a frequency.  The current 100Hz is just as arbitrary
as the proposed new 10Hz.

> I wouldn't, btw, mind an attempt to avoid the high rate NMIs
> during early boot (if those occur in the first place, which from
> two successive replies by Igor yesterday I wasn't sure anymore
> is an actual fact), but that's independent of the issue at hand.

The 100Hz NMI is active from BSP APIC init, IO-APIC, deadline timer
calibration, mwait idle, the entirety of HVM setup and full AP bringup. 
On one of my fastest boxes, it is about 1 second of wallclock time.

~Andrew

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

[Xen-devel] [PATCH 0/2] Ocaml: misc fixes

[Wei Liu]

Wei Liu (2):
  ocaml/xb: update xb.mli in accordance with df1e4c6e7f8
  ocaml/libs/xb: don't generate *.mli automatically

 tools/ocaml/libs/xb/Makefile|  4 
 tools/ocaml/libs/xb/op.mli  | 29 +
 tools/ocaml/libs/xb/packet.mli  | 13 +
 tools/ocaml/libs/xb/partial.mli | 14 ++
 tools/ocaml/libs/xb/xb.mli  |  4 ++--
 5 files changed, 58 insertions(+), 6 deletions(-)
 create mode 100644 tools/ocaml/libs/xb/op.mli
 create mode 100644 tools/ocaml/libs/xb/packet.mli
 create mode 100644 tools/ocaml/libs/xb/partial.mli

-- 
2.11.0


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

[Xen-devel] [PATCH 2/2] ocaml/libs/xb: don't generate *.mli automatically

[Wei Liu]

To stay in line with other parts of the ocaml code base.

This requires committing a bunch of mli files in tree.

Signed-off-by: Wei Liu 
---
 tools/ocaml/libs/xb/Makefile|  4 
 tools/ocaml/libs/xb/op.mli  | 29 +
 tools/ocaml/libs/xb/packet.mli  | 13 +
 tools/ocaml/libs/xb/partial.mli | 14 ++
 4 files changed, 56 insertions(+), 4 deletions(-)
 create mode 100644 tools/ocaml/libs/xb/op.mli
 create mode 100644 tools/ocaml/libs/xb/packet.mli
 create mode 100644 tools/ocaml/libs/xb/partial.mli

diff --git a/tools/ocaml/libs/xb/Makefile b/tools/ocaml/libs/xb/Makefile
index 09d1bc8946..be4499147e 100644
--- a/tools/ocaml/libs/xb/Makefile
+++ b/tools/ocaml/libs/xb/Makefile
@@ -39,10 +39,6 @@ xenbus.cmo : $(foreach obj, $(OBJS), $(obj).cmo)
$(E) " CMO  $@"
$(OCAMLC) -pack -o $@ $^
 
-%.mli: %.ml
-   $(E) " MLI  $@"
-   $(Q)$(OCAMLC) $(OCAMLINCLUDE) -i $< $o
-
 .PHONY: install
 install: $(LIBS) META
mkdir -p $(OCAMLDESTDIR)
diff --git a/tools/ocaml/libs/xb/op.mli b/tools/ocaml/libs/xb/op.mli
new file mode 100644
index 00..ecabfff0d1
--- /dev/null
+++ b/tools/ocaml/libs/xb/op.mli
@@ -0,0 +1,29 @@
+type operation =
+Debug
+  | Directory
+  | Read
+  | Getperms
+  | Watch
+  | Unwatch
+  | Transaction_start
+  | Transaction_end
+  | Introduce
+  | Release
+  | Getdomainpath
+  | Write
+  | Mkdir
+  | Rm
+  | Setperms
+  | Watchevent
+  | Error
+  | Isintroduced
+  | Resume
+  | Set_target
+  | Reset_watches
+  | Invalid
+val operation_c_mapping : operation array
+val size : int
+val array_search : 'a -> 'a array -> int
+val of_cval : int -> operation
+val to_cval : operation -> int
+val to_string : operation -> string
diff --git a/tools/ocaml/libs/xb/packet.mli b/tools/ocaml/libs/xb/packet.mli
new file mode 100644
index 00..f4e53c73a8
--- /dev/null
+++ b/tools/ocaml/libs/xb/packet.mli
@@ -0,0 +1,13 @@
+type t = { tid : int; rid : int; ty : Op.operation; data : string; }
+exception Error of string
+exception DataError of string
+external string_of_header : int -> int -> int -> int -> string
+  = "stub_string_of_header"
+val create : int -> int -> Op.operation -> string -> t
+val of_partialpkt : Partial.pkt -> t
+val to_string : t -> string
+val unpack : t -> int * int * Op.operation * string
+val get_tid : t -> int
+val get_ty : t -> Op.operation
+val get_data : t -> string
+val get_rid : t -> int
diff --git a/tools/ocaml/libs/xb/partial.mli b/tools/ocaml/libs/xb/partial.mli
new file mode 100644
index 00..359a75e88d
--- /dev/null
+++ b/tools/ocaml/libs/xb/partial.mli
@@ -0,0 +1,14 @@
+type pkt = {
+  tid : int;
+  rid : int;
+  ty : Op.operation;
+  len : int;
+  buf : Buffer.t;
+}
+external header_size : unit -> int = "stub_header_size"
+external header_of_string_internal : string -> int * int * int * int
+  = "stub_header_of_string"
+val xenstore_payload_max : int
+val of_string : string -> pkt
+val append : pkt -> string -> int -> unit
+val to_complete : pkt -> int
-- 
2.11.0


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

[Xen-devel] [PATCH 1/2] ocaml/xb: update xb.mli in accordance with df1e4c6e7f8

[Wei Liu]

Signed-off-by: Wei Liu 
---
 tools/ocaml/libs/xb/xb.mli | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/ocaml/libs/xb/xb.mli b/tools/ocaml/libs/xb/xb.mli
index b4d705201f..95d1c6f840 100644
--- a/tools/ocaml/libs/xb/xb.mli
+++ b/tools/ocaml/libs/xb/xb.mli
@@ -76,10 +76,10 @@ type t = {
 val init_partial_in : unit -> partial_buf
 val reconnect : t -> unit
 val queue : t -> Packet.t -> unit
-val read_fd : backend_fd -> 'a -> string -> int -> int
+val read_fd : backend_fd -> 'a -> bytes -> int -> int
 val read_mmap : backend_mmap -> 'a -> string -> int -> int
 val read : t -> string -> int -> int
-val write_fd : backend_fd -> 'a -> string -> int -> int
+val write_fd : backend_fd -> 'a -> bytes -> int -> int
 val write_mmap : backend_mmap -> 'a -> string -> int -> int
 val write : t -> string -> int -> int
 val output : t -> bool
-- 
2.11.0


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

Re: [Xen-devel] [PATCH V3] x86/hvm: fix domain crash when CR3 has the noflush bit set

[Jan Beulich]

>>> On 02.02.18 at 09:14,  wrote:
> @@ -2313,6 +2314,12 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
>  }
>  }
>  
> +if ( hvm_pcid_enabled(v) ) /* Clear the noflush bit. */
> +{
> +noflush = !!(value & X86_CR3_NOFLUSH);

Pointless !!.

> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -34,6 +34,9 @@ extern bool_t opt_hvm_fep;
>  #define opt_hvm_fep 0
>  #endif
>  
> +#define X86_CR3_NOFLUSH (1ull << 63)

This belongs in x86-defs.h

> +#define X86_CR3_NOFLUSH_DISABLE_MASK (X86_CR3_NOFLUSH - 1)

This shouldn't be needed (use ~X86_CR3_NOFLUSH instead).

> @@ -322,9 +325,10 @@ hvm_update_host_cr3(struct vcpu *v)
>  hvm_funcs.update_host_cr3(v);
>  }
>  
> -static inline void hvm_update_guest_cr(struct vcpu *v, unsigned int cr)
> +static inline void hvm_update_guest_cr(struct vcpu *v, unsigned int cr,
> +   bool noflush)
>  {
> -hvm_funcs.update_guest_cr(v, cr);
> +hvm_funcs.update_guest_cr(v, cr, noflush);
>  }

Instead of altering this function (and a lot of callers), how about
introducing

static inline void hvm_update_guest_cr3(struct vcpu *v, bool noflush)
{
hvm_funcs.update_guest_cr(v, 3, noflush);
}

? I'm also not convinced of the update_guest_cr() hook taking a
bool which is meaningless for all other CRs. Perhaps a more general
flags parameter would be better, with CR-specific meaning (you'd
then e.g. introduce HVM_UPDATE_GUEST_CR3_NO_FLUSH).

Jan


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

Re: [Xen-devel] [PATCH v4 5/7] libxl: support unmapping static shared memory areas during domain destruction

[Julien Grall]

On 07/02/18 16:27, Zhongze Liu wrote:

Hi Wei and Julien,


Hi,


2018-02-07 2:06 GMT+08:00 Wei Liu :

On Tue, Feb 06, 2018 at 01:24:30PM +, Julien Grall wrote:

   if (libxl__device_pci_destroy_all(gc, domid) < 0)
   LOGD(ERROR, domid, "Pci shutdown failed");
   rc = xc_domain_pause(ctx->xch, domid);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2cfe4c08a7..c398b6a6b8 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4424,6 +4424,8 @@ static inline bool libxl__string_is_default(char **s)
   _hidden int libxl__sshm_add(libxl__gc *gc, uint32_t domid,
   libxl_static_shm *sshm, int len);
+_hidden int libxl__sshm_del(libxl__gc *gc, uint32_t domid);
+
   _hidden int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
 libxl_static_shm *sshms, int len);
   _hidden int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
diff --git a/tools/libxl/libxl_sshm.c b/tools/libxl/libxl_sshm.c
index 562f46f299..1bf4d4c2dc 100644
--- a/tools/libxl/libxl_sshm.c
+++ b/tools/libxl/libxl_sshm.c
@@ -86,6 +86,112 @@ int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
   return 0;
   }
+/* Decrease the refcount of an sshm. When refcount reaches 0,


NIT: Libxl coding style regarding the comment seems to be uncleared (Ian,
Wei?). But I feel keep /* and */ in separate line is nicer.


I don't have an opinion here.




+ * clean up the whole sshm path.
+ */
+static void libxl__sshm_decref(libxl__gc *gc, xs_transaction_t xt,
+   const char *sshm_path)
+static void libxl__sshm_del_slave(libxl__gc *gc, xs_transaction_t xt,
+  uint32_t domid, const char *id, bool isretry)
+{
+const char *slave_path, *begin_str, *end_str;
+uint64_t begin, end;
+
+slave_path = GCSPRINTF("%s/slaves/%"PRIu32, SSHM_PATH(id), domid);
+
+begin_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/begin", slave_path));
+end_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/end", slave_path));
+begin = strtoull(begin_str, NULL, 16);
+end = strtoull(end_str, NULL, 16);
+
+/* Avoid calling do_unmap many times in case of xs transaction retry */
+if (!isretry)
+libxl__sshm_do_unmap(gc, domid, id, begin, end);


IHMO, by unmapping the regions in middle of the transaction, you increase
the potential failure of it. I would move that out of the transaction path.

I would be interested to hear the opinion of the tools maintainers here.



If you move the unmap after the loop you create a window in which
the pages are still mapped but the toolstack thinks they are unmapped.

While the code as-is now makes sure (assuming no error in unmap) the
pages are unmapped no later than the transaction is committed. I think
this can be done by moving unmap before the transaction.

Zhongze, do you think the unmap must be done inside the loop? What kind
of invariants do you have in mind?

Then there is the question of "what do we do if unmap fails". Honestly I
don't have an answer. It seems rather screwed up in that case and I
doubt there is much libxl can do to rectify things.



I put the unmap inside the transaction because I want to make the whole
read_mapping_info->unmap->update_mapping_info process atomic. If
I put unmap outside the transaction:  after I read out the information
that I need to do the unmap, and before I do the unmap and decrease the
refcnt, there could be another instance of this code trying to do the same
thing, which might lead to race condition.


AFAIU, the transaction is not a "global" lock. You will just not see the 
the change from the others during the transactions. Your changes will be 
only be visible at the end. So two transaction can be happily started 
concurrently, and try to do the unmap together. Not even your code will 
protect against that.


So can you give a bit more details here?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 3/4] firmware/shim: better filtering of intermediate files during Xen tree setup

[Jan Beulich]

>>> On 07.02.18 at 17:12,  wrote:
> On Wed, Feb 07, 2018 at 08:08:15AM -0700, Jan Beulich wrote:
>> I have no idea what *.1 is meant to cover. Instead also exclude
>> preprocessed and non-source assembly files.
> 
> Oh, I guess that answers my question in 2/4 then. I don't seem to have
> neither .i or .a files, but certainly .s should be excluded.

.s and .i can both be generated for the case someone has a need to
look at them (I need to from time to time). As we have rules for both,
we should also exclude what those rules can generate.

Jan


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

Re: [Xen-devel] [PATCH 2/4] firmware/shim: better filtering of dependency files during Xen tree setup

[Jan Beulich]

>>> On 07.02.18 at 17:05,  wrote:
> On Wed, Feb 07, 2018 at 08:07:40AM -0700, Jan Beulich wrote:
>> I have no idea what *.d1 is supposed to refer to - we only have .*.d
>> and .*.d2 files (note also the leading dot).
>> 
>> Signed-off-by: Jan Beulich 
>> 
>> --- a/tools/firmware/xen-dir/Makefile
>> +++ b/tools/firmware/xen-dir/Makefile
>> @@ -26,7 +26,7 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES)
>>  $(foreach d, $(LINK_DIRS), \
>>  (cd $(XEN_ROOT); \
>>   find $(d) ! -type l -type f \
>> - $(addprefix ! -path , '*.[oda1]' '*.d[12]')) \
>> + $(addprefix ! -path , '*.[oa1]' '.*.d' '.*.d2')) \
> 
> Don't you want -name here instead of -path?
> 
> AFAICT using '.*.d' is not going to work with path, because that's the
> full path, not the name of the file. This used to work before because
> the patterns started with '*'.

Oh, good point. Once again I have no idea why -path was used in
the first place.

> Also I cannot find any .a or .1 files, but maybe that's just because
> of my build system (I don't build EFI).

The .1 part goes away in patch 3. I suppose .a is just to cover
archives even if we don't use any right now.

Jan


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

Re: [Xen-devel] [PATCH v4 5/7] libxl: support unmapping static shared memory areas during domain destruction

[Zhongze Liu]

Hi Wei and Julien,

2018-02-07 2:06 GMT+08:00 Wei Liu :
> On Tue, Feb 06, 2018 at 01:24:30PM +, Julien Grall wrote:
>> >   if (libxl__device_pci_destroy_all(gc, domid) < 0)
>> >   LOGD(ERROR, domid, "Pci shutdown failed");
>> >   rc = xc_domain_pause(ctx->xch, domid);
>> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
>> > index 2cfe4c08a7..c398b6a6b8 100644
>> > --- a/tools/libxl/libxl_internal.h
>> > +++ b/tools/libxl/libxl_internal.h
>> > @@ -4424,6 +4424,8 @@ static inline bool libxl__string_is_default(char **s)
>> >   _hidden int libxl__sshm_add(libxl__gc *gc, uint32_t domid,
>> >   libxl_static_shm *sshm, int len);
>> > +_hidden int libxl__sshm_del(libxl__gc *gc, uint32_t domid);
>> > +
>> >   _hidden int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
>> > libxl_static_shm *sshms, int len);
>> >   _hidden int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
>> > diff --git a/tools/libxl/libxl_sshm.c b/tools/libxl/libxl_sshm.c
>> > index 562f46f299..1bf4d4c2dc 100644
>> > --- a/tools/libxl/libxl_sshm.c
>> > +++ b/tools/libxl/libxl_sshm.c
>> > @@ -86,6 +86,112 @@ int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t 
>> > domid,
>> >   return 0;
>> >   }
>> > +/* Decrease the refcount of an sshm. When refcount reaches 0,
>>
>> NIT: Libxl coding style regarding the comment seems to be uncleared (Ian,
>> Wei?). But I feel keep /* and */ in separate line is nicer.
>
> I don't have an opinion here.
>
>>
>> > + * clean up the whole sshm path.
>> > + */
>> > +static void libxl__sshm_decref(libxl__gc *gc, xs_transaction_t xt,
>> > +   const char *sshm_path)
>> > +static void libxl__sshm_del_slave(libxl__gc *gc, xs_transaction_t xt,
>> > +  uint32_t domid, const char *id, bool 
>> > isretry)
>> > +{
>> > +const char *slave_path, *begin_str, *end_str;
>> > +uint64_t begin, end;
>> > +
>> > +slave_path = GCSPRINTF("%s/slaves/%"PRIu32, SSHM_PATH(id), domid);
>> > +
>> > +begin_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/begin", slave_path));
>> > +end_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/end", slave_path));
>> > +begin = strtoull(begin_str, NULL, 16);
>> > +end = strtoull(end_str, NULL, 16);
>> > +
>> > +/* Avoid calling do_unmap many times in case of xs transaction retry 
>> > */
>> > +if (!isretry)
>> > +libxl__sshm_do_unmap(gc, domid, id, begin, end);
>>
>> IHMO, by unmapping the regions in middle of the transaction, you increase
>> the potential failure of it. I would move that out of the transaction path.
>>
>> I would be interested to hear the opinion of the tools maintainers here.
>>
>
> If you move the unmap after the loop you create a window in which
> the pages are still mapped but the toolstack thinks they are unmapped.
>
> While the code as-is now makes sure (assuming no error in unmap) the
> pages are unmapped no later than the transaction is committed. I think
> this can be done by moving unmap before the transaction.
>
> Zhongze, do you think the unmap must be done inside the loop? What kind
> of invariants do you have in mind?
>
> Then there is the question of "what do we do if unmap fails". Honestly I
> don't have an answer. It seems rather screwed up in that case and I
> doubt there is much libxl can do to rectify things.
>

I put the unmap inside the transaction because I want to make the whole
read_mapping_info->unmap->update_mapping_info process atomic. If
I put unmap outside the transaction:  after I read out the information
that I need to do the unmap, and before I do the unmap and decrease the
refcnt, there could be another instance of this code trying to do the same
thing, which might lead to race condition.

And yes, I don't think we can do much in case of something go wrong, so
what I'm doing here is just to do as best as I can -- unmapping all that pages
that can be unmapped and cleanup the xs entries.

Cheers,

Zhongze Liu

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

Re: [Xen-devel] [PATCH v4 4/7] kconfig/gcov: rename to coverage

[Roger Pau Monné]

On Wed, Feb 07, 2018 at 08:37:13AM -0700, Jan Beulich wrote:
> >>> On 07.02.18 at 11:53,  wrote:
> >  docs/misc/coverage.markdown  | 2 +-
> >  xen/Kconfig.debug| 6 +++---
> >  xen/Rules.mk | 9 +++--
> >  xen/arch/x86/efi/Makefile| 2 +-
> >  xen/common/Makefile  | 2 +-
> >  xen/common/coverage/Makefile | 5 -
> >  xen/common/sysctl.c  | 2 --
> >  xen/include/xen/coverage.h   | 7 ++-
> >  8 files changed, 23 insertions(+), 12 deletions(-)
> 
> I've taken the liberty to also adjust the shim's stored config while
> committing.

Thanks. This shim config is going to be a PITA.

Roger.

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

Re: [Xen-devel] [PATCH 4/4] firmware/shim: avoid mkdir error during Xen tree setup

[Roger Pau Monné]

On Wed, Feb 07, 2018 at 08:08:47AM -0700, Jan Beulich wrote:
> "mkdir -p" reports a missing operand, as config/ has no subdirs. Oddly
> enough this doesn't cause the whole command (and hence the build to
> fail), despite the "set -e" now covering the entire set of commands -
> perhaps a quirk of the relatively old bash I've seen this with (a few
> simple experiments suggest that commands inside () producing a non-
> success status would exit the inner shell, but not the outer one).
> 
> Add a dummy . argument to the invocation.
> 
> Suggested-by: Wei Liu 
> Signed-off-by: Jan Beulich 

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 3/4] firmware/shim: better filtering of intermediate files during Xen tree setup

[Roger Pau Monné]

On Wed, Feb 07, 2018 at 08:08:15AM -0700, Jan Beulich wrote:
> I have no idea what *.1 is meant to cover. Instead also exclude
> preprocessed and non-source assembly files.

Oh, I guess that answers my question in 2/4 then. I don't seem to have
neither .i or .a files, but certainly .s should be excluded.

Roger.

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

[Xen-devel] [PATCH v2 6/7] x86: disable XPTI when RDCL_NO

[Jan Beulich]

Use the respective ARCH_CAPABILITIES MSR bit, but don't expose the MSR
to guests yet.

Signed-off-by: Jan Beulich 
---
v2: New.

--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -204,6 +204,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
 {"avx512-4fmaps",0x0007,  0, CPUID_REG_EDX,  3,  1},
 {"ibrsb",0x0007,  0, CPUID_REG_EDX, 26,  1},
 {"stibp",0x0007,  0, CPUID_REG_EDX, 27,  1},
+{"arch-caps",0x0007,  0, CPUID_REG_EDX, 29,  1},
 
 {"lahfsahf", 0x8001, NA, CPUID_REG_ECX,  0,  1},
 {"cmplegacy",0x8001, NA, CPUID_REG_ECX,  1,  1},
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -166,7 +166,9 @@ static const char *str_7d0[32] =
 
 [26] = "ibrsb", [27] = "stibp",
 
-[28 ... 31] = "REZ",
+[28] = "REZ",   [29] = "arch_caps",
+
+[30 ... 31] = "REZ",
 };
 
 static struct {
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1545,7 +1545,16 @@ void __init noreturn __start_xen(unsigne
 cr4_pv32_mask = mmu_cr4_features & XEN_CR4_PV32_BITS;
 
 if ( opt_xpti < 0 )
-opt_xpti = boot_cpu_data.x86_vendor != X86_VENDOR_AMD;
+{
+uint64_t caps = 0;
+
+if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+caps = ARCH_CAPABILITIES_RDCL_NO;
+else if ( boot_cpu_has(X86_FEATURE_ARCH_CAPS) )
+rdmsrl(MSR_ARCH_CAPABILITIES, caps);
+
+opt_xpti = !(caps & ARCH_CAPABILITIES_RDCL_NO);
+}
 if ( opt_xpti )
 setup_clear_cpu_cap(X86_FEATURE_NO_XPTI);
 else
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -40,6 +40,8 @@
 #define PRED_CMD_IBPB  (_AC(1, ULL) << 0)
 
 #define MSR_ARCH_CAPABILITIES  0x010a
+#define ARCH_CAPABILITIES_RDCL_NO  (_AC(1, ULL) << 0)
+#define ARCH_CAPABILITIES_IBRS_ALL (_AC(1, ULL) << 1)
 
 /* Intel MSRs. Some also available on other CPUs */
 #define MSR_IA32_PERFCTR0  0x00c1
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -244,6 +244,7 @@ XEN_CPUFEATURE(AVX512_4VNNIW, 9*32+ 2) /
 XEN_CPUFEATURE(AVX512_4FMAPS, 9*32+ 3) /*A  AVX512 Multiply Accumulation 
Single Precision */
 XEN_CPUFEATURE(IBRSB, 9*32+26) /*A  IBRS and IBPB support (used by 
Intel) */
 XEN_CPUFEATURE(STIBP, 9*32+27) /*A! STIBP */
+XEN_CPUFEATURE(ARCH_CAPS, 9*32+29) /*   IA32_ARCH_CAPABILITIES MSR */
 
 #endif /* XEN_CPUFEATURE */
 




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

[Xen-devel] [PATCH v2 5/7] x86: avoid double CR3 reload when switching to guest user mode

[Jan Beulich]

When XPTI is active, the CR3 load in restore_all_guest is sufficient
when switching to user mode, improving in particular system call and
page fault exit paths for the guest.

Signed-off-by: Jan Beulich 
---
v2: Add ASSERT(!in_irq()).

--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -220,10 +220,22 @@ int pv_domain_initialise(struct domain *
 return rc;
 }
 
-static void _toggle_guest_pt(struct vcpu *v)
+static void _toggle_guest_pt(struct vcpu *v, bool force_cr3)
 {
+ASSERT(!in_irq());
+
 v->arch.flags ^= TF_kernel_mode;
 update_cr3(v);
+
+/*
+ * There's no need to load CR3 here when it is going to be loaded on the
+ * way out to guest mode again anyway, and when the page tables we're
+ * currently on are the kernel ones (whereas when switching to kernel
+ * mode we need to be able to write a bounce frame onto the kernel stack).
+ */
+if ( !force_cr3 && !(v->arch.flags & TF_kernel_mode) )
+return;
+
 /* Don't flush user global mappings from the TLB. Don't tick TLB clock. */
 asm volatile ( "mov %0, %%cr3" : : "r" (v->arch.cr3) : "memory" );
 
@@ -253,13 +265,13 @@ void toggle_guest_mode(struct vcpu *v)
 }
 asm volatile ( "swapgs" );
 
-_toggle_guest_pt(v);
+_toggle_guest_pt(v, cpu_has_no_xpti);
 }
 
 void toggle_guest_pt(struct vcpu *v)
 {
 if ( !is_pv_32bit_vcpu(v) )
-_toggle_guest_pt(v);
+_toggle_guest_pt(v, true);
 }
 
 /*




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

[Xen-devel] [PATCH v2 4/7] x86: NOP out most XPTI entry/exit code when it's not in use

[Jan Beulich]

Introduce a synthetic feature flag to use alternative instruction
patching to NOP out all code on entry/exit paths other than those
involved in NMI/#MC handling (the patching logic can't properly handle
those paths yet). Having NOPs here is generally better than using
conditional branches.

Also change the limit on the number of bytes we can patch in one go to
that resulting from the encoding in struct alt_instr - there's no point
reducing it below that limit, and without a check being in place that
the limit isn't actually exceeded, such an artificial boundary is a
latent risk.

Signed-off-by: Jan Beulich 
---
v2: Introduce and use ALTERNATIVE_NOP. Re-base.

--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -24,7 +24,7 @@
 #include 
 #include 
 
-#define MAX_PATCH_LEN (255-1)
+#define MAX_PATCH_LEN 255
 
 extern struct alt_instr __alt_instructions[], __alt_instructions_end[];
 
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3711,7 +3711,7 @@ long do_mmu_update(
  * to the page lock we hold, its pinned status, and uses on
  * this (v)CPU.
  */
-if ( !rc && this_cpu(root_pgt) &&
+if ( !rc && !cpu_has_no_xpti &&
  ((page->u.inuse.type_info & PGT_count_mask) >
   (1 + !!(page->u.inuse.type_info & PGT_pinned) +
(pagetable_get_pfn(curr->arch.guest_table) == mfn) +
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -169,6 +169,9 @@ static int __init parse_smap_param(const
 }
 custom_param("smap", parse_smap_param);
 
+static int8_t __initdata opt_xpti = -1;
+boolean_param("xpti", opt_xpti);
+
 bool __read_mostly acpi_disabled;
 bool __initdata acpi_force;
 static char __initdata acpi_param[10] = "";
@@ -1541,6 +1544,13 @@ void __init noreturn __start_xen(unsigne
 
 cr4_pv32_mask = mmu_cr4_features & XEN_CR4_PV32_BITS;
 
+if ( opt_xpti < 0 )
+opt_xpti = boot_cpu_data.x86_vendor != X86_VENDOR_AMD;
+if ( opt_xpti )
+setup_clear_cpu_cap(X86_FEATURE_NO_XPTI);
+else
+setup_force_cpu_cap(X86_FEATURE_NO_XPTI);
+
 if ( cpu_has_fsgsbase )
 set_in_cr4(X86_CR4_FSGSBASE);
 
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -741,8 +741,6 @@ static int clone_mapping(const void *ptr
 return 0;
 }
 
-static __read_mostly int8_t opt_xpti = -1;
-boolean_param("xpti", opt_xpti);
 DEFINE_PER_CPU(root_pgentry_t *, root_pgt);
 
 static int setup_cpu_root_pgt(unsigned int cpu)
@@ -751,7 +749,7 @@ static int setup_cpu_root_pgt(unsigned i
 unsigned int off;
 int rc;
 
-if ( !opt_xpti )
+if ( cpu_has_no_xpti )
 return 0;
 
 rpt = alloc_xen_pagetable();
@@ -1003,9 +1001,6 @@ void __init smp_prepare_cpus(unsigned in
 
 stack_base[0] = stack_start;
 
-if ( opt_xpti < 0 )
-opt_xpti = boot_cpu_data.x86_vendor != X86_VENDOR_AMD;
-
 rc = setup_cpu_root_pgt(0);
 if ( rc )
 panic("Error %d setting up PV root page table\n", rc);
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -199,7 +199,7 @@ ENTRY(compat_post_handle_exception)
 
 /* See lstar_enter for entry register state. */
 ENTRY(cstar_enter)
-/* sti could live here when we don't switch page tables below. */
+ALTERNATIVE nop, sti, X86_FEATURE_NO_XPTI
 CR4_PV32_RESTORE
 movq  8(%rsp),%rax /* Restore %rax. */
 movq  $FLAT_KERNEL_SS,8(%rsp)
@@ -214,6 +214,7 @@ ENTRY(cstar_enter)
 /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
 
 GET_STACK_END(bx)
+.Lcstar_cr3_start:
 mov   STACK_CPUINFO_FIELD(xen_cr3)(%rbx), %rcx
 neg   %rcx
 jz.Lcstar_cr3_okay
@@ -223,6 +224,8 @@ ENTRY(cstar_enter)
 movq  $0, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 .Lcstar_cr3_okay:
 sti
+.Lcstar_cr3_end:
+ALTERNATIVE_NOP .Lcstar_cr3_start, .Lcstar_cr3_end, X86_FEATURE_NO_XPTI
 
 movq  STACK_CPUINFO_FIELD(current_vcpu)(%rbx), %rbx
 movq  VCPU_domain(%rbx),%rcx
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -43,6 +43,7 @@ restore_all_guest:
 mov VCPUMSR_spec_ctrl_raw(%rdx), %r15d
 
 /* Copy guest mappings and switch to per-CPU root page table. */
+.Lrag_cr3_start:
 mov   VCPU_cr3(%rbx), %r9
 GET_STACK_END(dx)
 mov   STACK_CPUINFO_FIELD(pv_cr3)(%rdx), %rdi
@@ -50,7 +51,6 @@ restore_all_guest:
 movabs $DIRECTMAP_VIRT_START, %rcx
 mov   %rdi, %rax
 and   %rsi, %rdi
-jz.Lrag_keep_cr3
 and   %r9, %rsi
 add   %rcx, %rdi
 add   %rcx, %rsi
@@ -72,7 +72,8 @@ restore_all_guest:
 mov   %rdi, %cr4
 mov   %rax, %cr3
 mov   %rsi, %cr4
-.Lrag_keep_cr3:
+.Lrag_cr3_end:
+ALTERNATIVE_NOP .Lrag_cr3_start, .Lrag_cr3_end, X86_FEATURE_NO_XPTI
 
 /* Restore stashed 

[Xen-devel] [PATCH v2 2/7] x86: remove CR reads from exit-to-guest path

[Jan Beulich]

CR3 is - during normal operation - only ever loaded from v->arch.cr3,
so there's no need to read the actual control register. For CR4 we can
generally use the cached value on all synchronous entry end exit paths.
Drop the write_cr3 macro, as the two use sites are probably easier to
follow without its use.

Signed-off-by: Jan Beulich 
---
v2: Drop write_cr3 macro. Re-base.

--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -88,6 +88,7 @@ void __dummy__(void)
 OFFSET(VCPU_kernel_ss, struct vcpu, arch.pv_vcpu.kernel_ss);
 OFFSET(VCPU_iopl, struct vcpu, arch.pv_vcpu.iopl);
 OFFSET(VCPU_guest_context_flags, struct vcpu, arch.vgc_flags);
+OFFSET(VCPU_cr3, struct vcpu, arch.cr3);
 OFFSET(VCPU_arch_msr, struct vcpu, arch.msr);
 OFFSET(VCPU_nmi_pending, struct vcpu, nmi_pending);
 OFFSET(VCPU_mce_pending, struct vcpu, mce_pending);
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -43,7 +43,7 @@ restore_all_guest:
 mov VCPUMSR_spec_ctrl_raw(%rdx), %r15d
 
 /* Copy guest mappings and switch to per-CPU root page table. */
-mov   %cr3, %r9
+mov   VCPU_cr3(%rbx), %r9
 GET_STACK_END(dx)
 mov   STACK_CPUINFO_FIELD(pv_cr3)(%rdx), %rdi
 movabs $PADDR_MASK & PAGE_MASK, %rsi
@@ -65,8 +65,13 @@ restore_all_guest:
 sub   $(ROOT_PAGETABLE_FIRST_XEN_SLOT - \
 ROOT_PAGETABLE_LAST_XEN_SLOT - 1) * 8, %rdi
 rep movsq
+mov   STACK_CPUINFO_FIELD(cr4)(%rdx), %rdi
 mov   %r9, STACK_CPUINFO_FIELD(xen_cr3)(%rdx)
-write_cr3 rax, rdi, rsi
+mov   %rdi, %rsi
+and   $~X86_CR4_PGE, %rdi
+mov   %rdi, %cr4
+mov   %rax, %cr3
+mov   %rsi, %cr4
 .Lrag_keep_cr3:
 
 /* Restore stashed SPEC_CTRL value. */
@@ -122,7 +127,12 @@ restore_all_xen:
  * so "g" will have to do.
  */
 UNLIKELY_START(g, exit_cr3)
-write_cr3 rax, rdi, rsi
+mov   %cr4, %rdi
+mov   %rdi, %rsi
+and   $~X86_CR4_PGE, %rdi
+mov   %rdi, %cr4
+mov   %rax, %cr3
+mov   %rsi, %cr4
 UNLIKELY_END(exit_cr3)
 
 /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -205,15 +205,6 @@ void ret_from_intr(void);
 #define ASM_STAC ASM_AC(STAC)
 #define ASM_CLAC ASM_AC(CLAC)
 
-.macro write_cr3 val:req, tmp1:req, tmp2:req
-mov   %cr4, %\tmp1
-mov   %\tmp1, %\tmp2
-and   $~X86_CR4_PGE, %\tmp1
-mov   %\tmp1, %cr4
-mov   %\val, %cr3
-mov   %\tmp2, %cr4
-.endm
-
 #define CR4_PV32_RESTORE   \
 667: ASM_NOP5; \
 .pushsection .altinstr_replacement, "ax";  \




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

[Xen-devel] [PATCH v2 1/7] x86: slightly reduce Meltdown band-aid overhead

[Jan Beulich]

I'm not sure why I didn't do this right away: By avoiding the use of
global PTEs in the cloned directmap, there's no need to fiddle with
CR4.PGE on any of the entry paths. Only the exit paths need to flush
global mappings.

The reduced flushing, however, implies that we now need to have
interrupts off on all entry paths until after the page table switch, so
that flush IPIs can't arrive with the restricted page tables still
active, but only a non-global flush happening with the CR3 loads. Along
those lines the "sync" IPI after L4 entry updates now needs to become a
real (and global) flush IPI, so that inside Xen we'll also pick up such
changes.

Signed-off-by: Jan Beulich 
---
v2: Re-phrase description. Re-base.

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3826,18 +3826,14 @@ long do_mmu_update(
 {
 /*
  * Force other vCPU-s of the affected guest to pick up L4 entry
- * changes (if any). Issue a flush IPI with empty operation mask to
- * facilitate this (including ourselves waiting for the IPI to
- * actually have arrived). Utilize the fact that FLUSH_VA_VALID is
- * meaningless without FLUSH_CACHE, but will allow to pass the no-op
- * check in flush_area_mask().
+ * changes (if any).
  */
 unsigned int cpu = smp_processor_id();
 cpumask_t *mask = per_cpu(scratch_cpumask, cpu);
 
 cpumask_andnot(mask, pt_owner->dirty_cpumask, cpumask_of(cpu));
 if ( !cpumask_empty(mask) )
-flush_area_mask(mask, ZERO_BLOCK_PTR, FLUSH_VA_VALID);
+flush_mask(mask, FLUSH_TLB_GLOBAL);
 }
 
 perfc_add(num_page_updates, i);
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -728,6 +728,7 @@ static int clone_mapping(const void *ptr
 }
 
 pl1e += l1_table_offset(linear);
+flags &= ~_PAGE_GLOBAL;
 
 if ( l1e_get_flags(*pl1e) & _PAGE_PRESENT )
 {
@@ -1009,8 +1010,17 @@ void __init smp_prepare_cpus(unsigned in
 if ( rc )
 panic("Error %d setting up PV root page table\n", rc);
 if ( per_cpu(root_pgt, 0) )
+{
 get_cpu_info()->pv_cr3 = __pa(per_cpu(root_pgt, 0));
 
+/*
+ * All entry points which may need to switch page tables have to start
+ * with interrupts off. Re-write what pv_trap_init() has put there.
+ */
+_set_gate(idt_table + LEGACY_SYSCALL_VECTOR, SYS_DESC_irq_gate, 3,
+  _direct_trap);
+}
+
 set_nr_sockets();
 
 socket_cpumask = xzalloc_array(cpumask_t *, nr_sockets);
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -200,7 +200,7 @@ ENTRY(compat_post_handle_exception)
 
 /* See lstar_enter for entry register state. */
 ENTRY(cstar_enter)
-sti
+/* sti could live here when we don't switch page tables below. */
 CR4_PV32_RESTORE
 movq  8(%rsp),%rax /* Restore %rax. */
 movq  $FLAT_KERNEL_SS,8(%rsp)
@@ -220,9 +220,10 @@ ENTRY(cstar_enter)
 jz.Lcstar_cr3_okay
 mov   %rcx, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 neg   %rcx
-write_cr3 rcx, rdi, rsi
+mov   %rcx, %cr3
 movq  $0, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 .Lcstar_cr3_okay:
+sti
 
 movq  STACK_CPUINFO_FIELD(current_vcpu)(%rbx), %rbx
 movq  VCPU_domain(%rbx),%rcx
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -148,7 +148,7 @@ UNLIKELY_END(exit_cr3)
  * %ss must be saved into the space left by the trampoline.
  */
 ENTRY(lstar_enter)
-sti
+/* sti could live here when we don't switch page tables below. */
 movq  8(%rsp),%rax /* Restore %rax. */
 movq  $FLAT_KERNEL_SS,8(%rsp)
 pushq %r11
@@ -167,9 +167,10 @@ ENTRY(lstar_enter)
 jz.Llstar_cr3_okay
 mov   %rcx, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 neg   %rcx
-write_cr3 rcx, rdi, rsi
+mov   %rcx, %cr3
 movq  $0, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 .Llstar_cr3_okay:
+sti
 
 movq  STACK_CPUINFO_FIELD(current_vcpu)(%rbx), %rbx
 testb $TF_kernel_mode,VCPU_thread_flags(%rbx)
@@ -252,7 +253,7 @@ process_trap:
 jmp  test_all_events
 
 ENTRY(sysenter_entry)
-sti
+/* sti could live here when we don't switch page tables below. */
 pushq $FLAT_USER_SS
 pushq $0
 pushfq
@@ -273,9 +274,10 @@ GLOBAL(sysenter_eflags_saved)
 jz.Lsyse_cr3_okay
 mov   %rcx, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 neg   %rcx
-write_cr3 rcx, rdi, rsi
+mov   %rcx, %cr3
 movq  $0, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 .Lsyse_cr3_okay:
+sti
 
 movq  STACK_CPUINFO_FIELD(current_vcpu)(%rbx), %rbx
 cmpb  $0,VCPU_sysenter_disables_events(%rbx)
@@ -322,9 +324,10 @@ ENTRY(int80_direct_trap)
 jz.Lint80_cr3_okay
 mov   %rcx, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 neg   

[Xen-devel] [PATCH v2 0/7] x86: Meltdown band-aid overhead reduction

[Jan Beulich]

1: slightly reduce Meltdown band-aid overhead
2: remove CR reads from exit-to-guest path
3: introduce altinstruction_nop assembler macro
4: NOP out most XPTI entry/exit code when it's not in use
5: avoid double CR3 reload when switching to guest user mode
6: disable XPTI when RDCL_NO
7: x86: log XPTI enabled status

I won't mind if it was decided for some of them to be pointless, but I
think 1 (because of a measurable improvement of 1-3%), 4 (helping
the "xpti=no" case, even if only a little; taking 3 as prereq), and
6+7 should be considered seriously.

Signed-off-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v4 4/7] kconfig/gcov: rename to coverage

[Jan Beulich]

>>> On 07.02.18 at 11:53,  wrote:
>  docs/misc/coverage.markdown  | 2 +-
>  xen/Kconfig.debug| 6 +++---
>  xen/Rules.mk | 9 +++--
>  xen/arch/x86/efi/Makefile| 2 +-
>  xen/common/Makefile  | 2 +-
>  xen/common/coverage/Makefile | 5 -
>  xen/common/sysctl.c  | 2 --
>  xen/include/xen/coverage.h   | 7 ++-
>  8 files changed, 23 insertions(+), 12 deletions(-)

I've taken the liberty to also adjust the shim's stored config while
committing.

Jan


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

[Xen-devel] Ping: [PATCH v2 0/3] XSA-248...251 follow-up

[Jan Beulich]

>>> On 20.12.17 at 10:37,  wrote:
> The parts of this series aren't really dependent upon one another,
> they belong together solely because of their origin.
> 
> 1: x86/shadow: widen reference count
> 2: x86/mm: clean up SHARED_M2P{,_ENTRY} uses
> 3: x86: use paging_mark_pfn_dirty()

George,

any chance to get an ack or otherwise (or an indication that they
can go in with just Andrew's ack, which was provided via IRC) for
the latter two?

Thanks, Jan


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

Re: [Xen-devel] qemu-xen fails to build in staging

[Anthony PERARD]

On Wed, Feb 07, 2018 at 02:44:05PM +, Anthony PERARD wrote:
> On Wed, Feb 07, 2018 at 01:40:04PM +0100, Olaf Hering wrote:
> > Am Wed, 7 Feb 2018 11:13:22 +0100
> > schrieb Olaf Hering :
> > 
> > > Yes, it looks like qemu has now submodules which are required for build.
> > 
> > How is the required state of the submodules tracked?
> 
> Hi,
> 
> QEMU have now a script to take care of submodules when building qemu,
> it's ./scripts/git-submodule.sh
> 
> The ./configure script will find out which submodules are needed. If the
> script can find a libdtc, then the submodule dtc should not be build.
> But I think the submodule ui/keycodemapdb is likely to be required.

Maybe the option '--disable-git-update' of the QEMU configure script
will be useful to you, there is some explanation in this commit message:
https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=commit;h=f62bbee55d503f639ee9498878ebf42ff4f4299a

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH] x86/emul: Fix the decoding of segment overrides in 64bit mode

[Jan Beulich]

>>> On 07.02.18 at 15:41,  wrote:
> Explicit segment overides other than %fs and %gs are documented as ignored by
> both Intel and AMD.
> 
> In practice, this means that:
> 
>  * Explicit uses of %ss don't actually yield #SS[0] for non-canonical
>memory references.
>  * Explicit uses of %{e,c,d}s don't override %rbp/%rsp-based memory references
>to yield #GP[0] for non-canonical memory references.
> 
> 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

[Xen-devel] [PATCH] stubdom: install firmware files as data

[Olaf Hering]

Remove the executable bits of vtpm files by using _DATA instead of _PROG.

Signed-off-by: Olaf Hering 
---
 stubdom/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/stubdom/Makefile b/stubdom/Makefile
index f45eeabd8b..7cb62e6c36 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -612,11 +612,11 @@ install-xenstore: xenstore-stubdom
 
 install-vtpm: vtpm-stubdom
$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
-   $(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-vtpm/mini-os.gz 
"$(DESTDIR)$(XENFIRMWAREDIR)/vtpm-stubdom.gz"
+   $(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-vtpm/mini-os.gz 
"$(DESTDIR)$(XENFIRMWAREDIR)/vtpm-stubdom.gz"
 
 install-vtpmmgr: vtpmmgr-stubdom
$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
-   $(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-vtpmmgr/mini-os.gz 
"$(DESTDIR)$(XENFIRMWAREDIR)/vtpmmgr-stubdom.gz"
+   $(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-vtpmmgr/mini-os.gz 
"$(DESTDIR)$(XENFIRMWAREDIR)/vtpmmgr-stubdom.gz"
 
 ###
 # uninstall

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

[Xen-devel] [PATCH 4/4] firmware/shim: avoid mkdir error during Xen tree setup

[Jan Beulich]

"mkdir -p" reports a missing operand, as config/ has no subdirs. Oddly
enough this doesn't cause the whole command (and hence the build to
fail), despite the "set -e" now covering the entire set of commands -
perhaps a quirk of the relatively old bash I've seen this with (a few
simple experiments suggest that commands inside () producing a non-
success status would exit the inner shell, but not the outer one).

Add a dummy . argument to the invocation.

Suggested-by: Wei Liu 
Signed-off-by: Jan Beulich 

--- unstable.orig/tools/firmware/xen-dir/Makefile   2018-02-07 
15:35:18.197717910 +0100
+++ unstable/tools/firmware/xen-dir/Makefile2018-02-07 15:35:51.027213823 
+0100
@@ -22,7 +22,7 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES)
 (mkdir -p $(D)/$(d); \
  cd $(D)/$(d); \
  find $(XEN_ROOT)/$(d)/ -type d |\
-   sed 's,^$(XEN_ROOT)/$(d)/,,g' | xargs mkdir -p);) \
+   sed 's,^$(XEN_ROOT)/$(d)/,,g' | xargs mkdir -p .);) \
$(foreach d, $(LINK_DIRS), \
(cd $(XEN_ROOT); \
 find $(d) ! -type l -type f \




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

[Xen-devel] [PATCH 3/4] firmware/shim: better filtering of intermediate files during Xen tree setup

[Jan Beulich]

I have no idea what *.1 is meant to cover. Instead also exclude
preprocessed and non-source assembly files.

Signed-off-by: Jan Beulich 

--- unstable.orig/tools/firmware/xen-dir/Makefile   2018-02-07 
15:30:24.038600788 +0100
+++ unstable/tools/firmware/xen-dir/Makefile2018-02-07 15:35:18.197717910 
+0100
@@ -26,7 +26,7 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES)
$(foreach d, $(LINK_DIRS), \
(cd $(XEN_ROOT); \
 find $(d) ! -type l -type f \
-$(addprefix ! -path , '*.[oa1]' '.*.d' '.*.d2')) \
+$(addprefix ! -path , '*.[isoa]' '.*.d' '.*.d2')) \
 >> linkfarm.stamp.tmp ; ) \
$(foreach f, $(LINK_FILES), \
echo $(f) >> linkfarm.stamp.tmp ;)




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

[Xen-devel] [PATCH 2/4] firmware/shim: better filtering of dependency files during Xen tree setup

[Jan Beulich]

I have no idea what *.d1 is supposed to refer to - we only have .*.d
and .*.d2 files (note also the leading dot).

Signed-off-by: Jan Beulich 

--- a/tools/firmware/xen-dir/Makefile
+++ b/tools/firmware/xen-dir/Makefile
@@ -26,7 +26,7 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES)
$(foreach d, $(LINK_DIRS), \
(cd $(XEN_ROOT); \
 find $(d) ! -type l -type f \
-$(addprefix ! -path , '*.[oda1]' '*.d[12]')) \
+$(addprefix ! -path , '*.[oa1]' '.*.d' '.*.d2')) \
 >> linkfarm.stamp.tmp ; ) \
$(foreach f, $(LINK_FILES), \
echo $(f) >> linkfarm.stamp.tmp ;)




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

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Jan Beulich]

>>> On 07.02.18 at 14:24,  wrote:
> On 07/02/18 13:08, Jan Beulich wrote:
> On 07.02.18 at 14:01,  wrote:
>>> So far the issue confirmed:
>>> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
>>> that it was tested on), Intel S2600XX, etc.
>>>
>>> Also see:
>>> https://bugs.xenserver.org/browse/XSO-774 
>>>
>>> Well, no-watchdog is what we currently recommend in that case but we
>>> hoped there is a general solution here from Xen side. You have your
>>> point that they should fix this on their side because it's their fault
>>> indeed. But the user experience is also important for us I think.
>> Of course, hence the suggestion of possible alternative workarounds.
>> Impacting everyone is, as said, not a desirable approach in a case
>> like this one. I also continue to dislike the seemingly random division
>> by 10.
> 
> Xen's usability is crap, which is in large part due to attitude like
> this.  It is not ok to expect the end user to know diagnose/debug issues
> like this, and it is entirely unreasonable to expect the end user to
> have to manually work around it.

Excuse me? The watchdog is off by default. Anyone turning it on
ought to know what they do. You (iirc) turning it on unilaterally in
XenServer puts the burden of avoidng users to have to diagnose
the issue on you.

> This particular issue does want feeding back to Intel so they can try
> and fix it, but whatever is wrong is present in a large amount of
> Skylake systems in the field.  Xen needs to be able to cope.

But in a reasonable way.

> Finally, as to boot times, your argument is backwards seeing as you care
> about elapsed boot time.  Slowing the frequency will speed everything
> up, as we aren't executing a large chunk of the BSP boot path with 100hz
> NMI constantly interrupting.

How long does handling a single NMI take? Microseconds, I assume.
Contrast this with waiting for two NMIs to arrive in wait_for_nmis(),
which goes up from 20ms to 200ms with this change.

Also you completely ignore my argument against the seemingly
random division by 10, including the resulting question of what you
mean to do once 10Hz also turns out too high a frequency.

I wouldn't, btw, mind an attempt to avoid the high rate NMIs
during early boot (if those occur in the first place, which from
two successive replies by Igor yesterday I wasn't sure anymore
is an actual fact), but that's independent of the issue at hand.

Jan


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

[Xen-devel] [PATCH 1/4] firmware/shim: correctly handle errors during Xen tree setup

[Jan Beulich]

"set -e" on a separate Makefile line is meaningless. Glue together all
the lines that this is supposed to cover.

Signed-off-by: Jan Beulich 

--- a/tools/firmware/xen-dir/Makefile
+++ b/tools/firmware/xen-dir/Makefile
@@ -16,18 +16,18 @@ DEP_FILES=$(foreach i, $(LINK_FILES), $(
 
 linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES) FORCE
mkdir -p $(D)
-   set -e
rm -f linkfarm.stamp.tmp
+   set -e; \
$(foreach d, $(LINK_DIRS), \
 (mkdir -p $(D)/$(d); \
  cd $(D)/$(d); \
  find $(XEN_ROOT)/$(d)/ -type d |\
-   sed 's,^$(XEN_ROOT)/$(d)/,,g' | xargs mkdir -p);)
+   sed 's,^$(XEN_ROOT)/$(d)/,,g' | xargs mkdir -p);) \
$(foreach d, $(LINK_DIRS), \
(cd $(XEN_ROOT); \
 find $(d) ! -type l -type f \
 $(addprefix ! -path , '*.[oda1]' '*.d[12]')) \
->> linkfarm.stamp.tmp ; )
+>> linkfarm.stamp.tmp ; ) \
$(foreach f, $(LINK_FILES), \
echo $(f) >> linkfarm.stamp.tmp ;)
cmp -s linkfarm.stamp.tmp linkfarm.stamp && \




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

[Xen-devel] [PATCH 0/4] firmware/shim: fix Xen tree setup

[Jan Beulich]

This is a split of the RFC with the mkdir fix added, but with the symlink
handling left off for now (I'll need some more time to properly deal with
that without using -xtype, ideally treating absolute and relative ones
differently).

1: correctly handle errors during Xen tree setup
2: better filtering of dependency files during Xen tree setup
3: better filtering of intermediate files during Xen tree setup
4: avoid mkdir error during Xen tree setup

Signed-off-by: Jan Beulich 


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

Re: [Xen-devel] qemu-xen fails to build in staging

[Anthony PERARD]

On Wed, Feb 07, 2018 at 01:40:04PM +0100, Olaf Hering wrote:
> Am Wed, 7 Feb 2018 11:13:22 +0100
> schrieb Olaf Hering :
> 
> > Yes, it looks like qemu has now submodules which are required for build.
> 
> How is the required state of the submodules tracked?

Hi,

QEMU have now a script to take care of submodules when building qemu,
it's ./scripts/git-submodule.sh

The ./configure script will find out which submodules are needed. If the
script can find a libdtc, then the submodule dtc should not be build.
But I think the submodule ui/keycodemapdb is likely to be required.


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


-- 
Anthony PERARD

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

[Xen-devel] [PATCH] x86/emul: Fix the decoding of segment overrides in 64bit mode

[Andrew Cooper]

Explicit segment overides other than %fs and %gs are documented as ignored by
both Intel and AMD.

In practice, this means that:

 * Explicit uses of %ss don't actually yield #SS[0] for non-canonical
   memory references.
 * Explicit uses of %{e,c,d}s don't override %rbp/%rsp-based memory references
   to yield #GP[0] for non-canonical memory references.

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

I've got 3/4's of an XTF test for this, but not enough time to get it finished
in any reasable period.  I noticed the issue originally when getting some
unexpected results from VMX_INSTRUCTION_INFO in some unrelated nested virt
work.
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index d192280..85383ea 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2505,6 +2505,10 @@ x86_decode(
 }
  done_prefixes:
 
+/* %{e,c,s,d}s overrides are ignored in 64bit mode. */
+if ( mode_64bit() && override_seg < x86_seg_fs )
+override_seg = x86_seg_none;
+
 if ( rex_prefix & REX_W )
 op_bytes = 8;
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH RFC 7/8] xen-blkback: frontend feature control

[Joao Martins]

On 02/07/2018 12:08 PM, Roger Pau Monné wrote:
> On Thu, Nov 02, 2017 at 06:06:15PM +, Joao Martins wrote:
>> Toolstack may write values to the "require" subdirectory in the
>> backend main directory (e.g. backend/vbd/X/Y/). Read these values
>> and use them when announcing those to the frontend. When backend
>> scans frontend features the values set in the require directory
>> take precedence, hence making no significant changes in feature
>> parsing.
>>
>> xenbus_read_feature() reads from require subdirectory and prints that
>> value and otherwise writing a default_val in the entry. We then replace
>> all instances of xenbus_printf to use these previously seeded features.
>> A backend_features struct is introduced and all values set there are
>> used in place of the module parameters being used.
>>
>> Note, however that feature-barrier, feature-flush-support and
>> feature-discard aren't probed because first two are physical
>> device dependent and feature-discard already has tunables to
>> adjust.
>>
>> Signed-off-by: Joao Martins 
>> ---
>>  drivers/block/xen-blkback/blkback.c |  2 +-
>>  drivers/block/xen-blkback/common.h  |  1 +
>>  drivers/block/xen-blkback/xenbus.c  | 66 
>> -
>>  3 files changed, 60 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkback/blkback.c 
>> b/drivers/block/xen-blkback/blkback.c
>> index c90e90b6..05b3f124c871 100644
>> --- a/drivers/block/xen-blkback/blkback.c
>> +++ b/drivers/block/xen-blkback/blkback.c
>> @@ -1271,7 +1271,7 @@ static int dispatch_rw_block_io(struct xen_blkif_ring 
>> *ring,
>>  unlikely((req->operation != BLKIF_OP_INDIRECT) &&
>>   (nseg > BLKIF_MAX_SEGMENTS_PER_REQUEST)) ||
>>  unlikely((req->operation == BLKIF_OP_INDIRECT) &&
>> - (nseg > MAX_INDIRECT_SEGMENTS))) {
>> + (nseg > ring->blkif->vbd.max_indirect_segs))) {
>>  pr_debug("Bad number of segments in request (%d)\n", nseg);
>>  /* Haven't submitted any bio's yet. */
>>  goto fail_response;
>> diff --git a/drivers/block/xen-blkback/common.h 
>> b/drivers/block/xen-blkback/common.h
>> index a7832428e0da..ff12f2d883b9 100644
>> --- a/drivers/block/xen-blkback/common.h
>> +++ b/drivers/block/xen-blkback/common.h
>> @@ -229,6 +229,7 @@ struct xen_vbd {
>>  unsigned intdiscard_secure:1;
>>  unsigned intfeature_gnt_persistent:1;
>>  unsigned intoverflow_max_grants:1;
>> +unsigned intmax_indirect_segs;
> 
> Please place this above, in order to get less padding between fields.
> 
/nods

>>  };
>>  
>>  struct backend_info;
>> diff --git a/drivers/block/xen-blkback/xenbus.c 
>> b/drivers/block/xen-blkback/xenbus.c
>> index 48d796ea3626..31683f29d5fb 100644
>> --- a/drivers/block/xen-blkback/xenbus.c
>> +++ b/drivers/block/xen-blkback/xenbus.c
>> @@ -25,11 +25,19 @@
>>  
>>  /* On the XenBus the max length of 'ring-ref%u'. */
>>  #define RINGREF_NAME_LEN (20)
>> +#define REQUIRE_PATH_LEN (256)
>> +
>> +struct backend_features {
>> +unsigned max_queues;
>> +unsigned max_ring_order;
> 
> unsigned int.
> 
>> +unsigned pers_grants;
> 
> bool?
> 
> Since you are already doing this, is it worth adding support to
> disable other features like flush or discard?
>
Hmm, possibly. But I didn't really know if you folks wanted discard because it
already has a tunable? I guess probably yes given libxl is stateless, it could
be good for behaviour consistency. flush/barrier depended on whether the queue
had it enabled or not so I left it out thinking there was some other way to
mangle these features.

>> +};
>>  
>>  struct backend_info {
>>  struct xenbus_device*dev;
>>  struct xen_blkif*blkif;
>>  struct xenbus_watch backend_watch;
>> +struct backend_features features;
>>  unsignedmajor;
>>  unsignedminor;
>>  char*mode;
>> @@ -602,6 +610,40 @@ int xen_blkbk_barrier(struct xenbus_transaction xbt,
>>  return err;
>>  }
>>  
>> +static int xenbus_read_feature(const char *dir, const char *node,
>> +   unsigned int default_val)
>> +{
>> +char reqnode[REQUIRE_PATH_LEN];
>> +unsigned int val;
>> +
>> +snprintf(reqnode, REQUIRE_PATH_LEN, "%s/require", dir);
>> +val = xenbus_read_unsigned(reqnode, node, default_val);
>> +return val;
>> +}
> 
> You could avoid the temporary buffer by doing something like:
> 
>> +
>> +static void xen_blkbk_probe_features(struct xenbus_device *dev,
>> + struct backend_info *be)
>> +{
>> +struct backend_features *ft = >features;
>> +struct xen_vbd *vbd = >blkif->vbd;
>> +
> 
> #define READ_FEAT(path, feat, default) \
>   xenbus_read_unsigned(path, "require/" node, default)
> 
>> +vbd->max_indirect_segs = xenbus_read_feature(dev->nodename,
>> +

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Igor Druzhinin]

On 07/02/18 13:08, Jan Beulich wrote:
 On 07.02.18 at 14:01,  wrote:
>> So far the issue confirmed:
>> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
>> that it was tested on), Intel S2600XX, etc.
>>
>> Also see:
>> https://bugs.xenserver.org/browse/XSO-774 
>>
>> Well, no-watchdog is what we currently recommend in that case but we
>> hoped there is a general solution here from Xen side. You have your
>> point that they should fix this on their side because it's their fault
>> indeed. But the user experience is also important for us I think.
> 
> Of course, hence the suggestion of possible alternative workarounds.
> Impacting everyone is, as said, not a desirable approach in a case
> like this one. I also continue to dislike the seemingly random division
> by 10.
> 
> Jan
> 

There is also a workaround by initializing the watchdog later (after SMP
bootstrap) on CPU0 - as Linux does AFAIK. But I don't think this would
be acceptable either.

Igor

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

[Xen-devel] [seabios test] 118631: regressions - FAIL

[osstest service owner]

flight 118631 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118631/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 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-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 seabios  14d91c353e19b7085fdbb7b2dcc43f3355665670
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   95 days
Failing since115733  2017-11-10 17:19:59 Z   88 days  111 attempts
Testing same since   118140  2018-01-17 05:09:48 Z   21 days   32 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Marcel Apfelbaum 
  Michael S. Tsirkin 
  Paul Menzel 
  Stefan Berger 

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-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



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

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

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

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


Not pushing.


commit 14d91c353e19b7085fdbb7b2dcc43f3355665670
Author: Marcel Apfelbaum 
Date:   Thu Jan 11 22:15:12 2018 +0200

pci: fix 'io hints' capability for RedHat PCI bridges

Commit ec6cb17f (pci: enable RedHat PCI bridges to reserve additional
 resources on PCI init)
added a new vendor specific PCI capability for RedHat PCI bridges
allowing them to reserve additional buses and/or IO/MEM space.

When adding the IO hints PCI capability to the pcie-root-port
without specifying a value for bus reservation, the subordinate bus
computation is wrong and the guest kernel gets messed up.

Fix it by returning to prev code if the value for bus
reservation is not set.

Removed also a wrong debug print "PCI: invalid QEMU resource reserve
cap offset" which appears if the 'IO hints' capability is not present.

Acked-by: Michael S. Tsirkin 

Re: [Xen-devel] [PATCH 5/7] xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support

[Volodymyr Babchuk]

Hi,

On 6 February 2018 at 20:12, Julien Grall  wrote:
> On 02/06/2018 04:23 PM, Volodymyr Babchuk wrote:
>>
>> Hi,
>
>
> Hi,
>
>> On 5 February 2018 at 15:20, Julien Grall  wrote:
>>>
>>> SMCCC 1.1 offers firmware-based CPU workarounds. In particular,
>>> SMCCC_ARCH_WORKAROUND_1 provides BP hardening for variant 2 of XSA-254
>>> (CVE-2017-5715).
>>>
>>> If the hypervisor has some mitigation for this issue, report that we
>>> deal with it using SMCCC_ARCH_WORKAROUND_1, as we apply the hypervisor
>>> workaround on every guest exit.
>>
>> Just to be sure: is there some way to disable this workaround?
>
>
> In which context? If the platform does not have any processor affected by
> variant 2, then the workaround will not be enabled.
Yes, right. I missed CPU caps check below.

> In case of Linux, this workaround will only be called on affected
> processors.
>
>
>>
>>
>>>
>>> Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

>>> ---
>>>   xen/arch/arm/vsmc.c | 22 --
>>>   xen/include/asm-arm/smccc.h |  6 ++
>>>   2 files changed, 26 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
>>> index a708aa5e81..144a1cd761 100644
>>> --- a/xen/arch/arm/vsmc.c
>>> +++ b/xen/arch/arm/vsmc.c
>>> @@ -18,6 +18,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>>   #include 
>>>   #include 
>>>   #include 
>>> @@ -93,8 +94,25 @@ static bool handle_arch(struct cpu_user_regs *regs)
>>>   return true;
>>>
>>>   case ARM_SMCCC_ARCH_FEATURES_FID:
>>> -/* Nothing supported yet */
>>> -set_user_reg(regs, 0, -1);
>>> +{
>>> +uint32_t arch_func_id = get_user_reg(regs, 1);
>>> +int ret = -1;
>>
>> I think that register_t will suit better in this case.
>
>
> Well no. The return in the spec is int32 and will fit in w0. register_t is
> either 32-bit or 64-bit. So int is the right type here.
Ah, yes, you are right.

>
>>
>>> +
>>> +switch ( arch_func_id )
>>> +{
>>> +case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
>>> +if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) )
>>> +ret = 0;
>>> +break;
>>> +}
>>> +
>>> +set_user_reg(regs, 0, ret);
>>> +
>>> +return true;
>>> +}
>>> +
>>> +case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
>>> +/* No return value */
>>>   return true;
>>>   }
>>>
>>> diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
>>> index 431389c118..b790fac17c 100644
>>> --- a/xen/include/asm-arm/smccc.h
>>> +++ b/xen/include/asm-arm/smccc.h
>>> @@ -115,6 +115,12 @@ static inline uint32_t smccc_get_owner(register_t
>>> funcid)
>>>  ARM_SMCCC_OWNER_ARCH,\
>>>  0x1)
>>>
>>> +#define ARM_SMCCC_ARCH_WORKAROUND_1_FID \
>>> +ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
>>> +  ARM_SMCCC_CONV_32,\
>>> +  ARM_SMCCC_OWNER_ARCH, \
>>> +  0x8000)
>>> +
>>>   /* Only one error code defined in SMCCC */
>>>   #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
>>>
>>> --
>>> 2.11.0
>>>
>>>
>>> ___
>>> Xen-devel mailing list
>>> Xen-devel@lists.xenproject.org
>>> https://lists.xenproject.org/mailman/listinfo/xen-devel
>
>
> Cheers,
>
> --
> Julien Grall



-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

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

Re: [Xen-devel] [PATCH 7/7] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_1

[Volodymyr Babchuk]

Hi Julien,


On 6 February 2018 at 20:33, Julien Grall  wrote:
> Hi,
>
> On 02/06/2018 04:36 PM, Volodymyr Babchuk wrote:
>>
>> On 5 February 2018 at 15:20, Julien Grall  wrote:
>>>
>>> The function SMCCC_ARCH_WORKAROUND_1 will be called by the guest for
>>> hardening the branch predictor. So we want the handling to be as fast as
>>> possible.
>>>
>>> As the mitigation is applied on every guest exit, we can check for the
>>> call before saving all the context and return very early.
>>
>> Have you tried any benchmarks? How big is the benefit?
>
>
> I have benchmarked but I can't share the result. I can give you an idea on
> how this could benefits Xen.
>
> Linux will call the workaround on every context switch between process. So
> imagine for each context switch, you have will enter in Xen and in the
> following order:
> 1) enter Xen
> 2) apply the workaround which means calling EL3.
> 3) save part of the guest context
> 4) call enter_hypervisor_head that will sync the vGIC state
> 5) detect you actually call SMCCC_ARCH_WORKAROUND_1 that will do
> nothing
> 6) call leave_hypervisor_tail that will sync back the vGIC state and
> execute softirq (that could reschedule the vCPU)
> 7) restore the guest context
> 8) return to the guest
>
> So effectively, instead of executing hundreds (if not thousands)
> instructions each time, you will end up only executing less than 50
> instructions.
Sounds fine.

>
>>>
>>> For now, only provide a fast path for HVC64 call. Because the code rely
>>> on 2 registers, x0 and x1 are saved in advanced.
>>
>> Is there a typo? Should it be "advance"?
>>
>>>
>>> Signed-off-by: Julien Grall 
Provided that above typo is fixed:

Reviewed-by: Volodymyr Babchuk 
>>>
>>> ---
>>>  guest_sync only handle 64-bit guest, so I have only implemented the
>>>  64-bit side for now. We can discuss whether it is useful to
>>>  implement it for 32-bit guests.
>>>
>>>  We could also consider to implement the fast path for SMC64,
>>>  althought a guest should always use HVC.
>>
>> I can imagine a guest that know nothing about virtualization and use
>> SMC as a conduit. But I can't provide real world example, thou.
I'm okay with this.


-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

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

Re: [Xen-devel] [PATCH 4/7] xen/arm: vsmc: Implement SMCCC 1.1

[Volodymyr Babchuk]

Hi Julien,

On 6 February 2018 at 20:04, Julien Grall  wrote:
> Hi,
>
> On 02/06/2018 04:18 PM, Volodymyr Babchuk wrote:
>>
>> On 5 February 2018 at 15:20, Julien Grall  wrote:
>>>
>>> The new SMC Calling Convention (v1.1) allows for a reduced overhead when
>>> calling into the firmware, and provides a new feature discovery
>>> mechanism. See ARM DEN 00070A.
>>
>> Сould you please use also a human-readable document name? I remember
>> that I read "Firmware interfaces for mitigating CVE-2017-5715", but I
>> can't remember what is ARM DEN 00070A about.
>
>
> The reason I am using ARM DEN 0070A is because the name does not give you
> revision of the specification. So you can't know whether you use rev A or B.
> As new revision may introduce/change behavior, this is very helpful to know
> which specific revision that was used to write the code.

Yes, this is true.
> It is also much easier to find on the web the identifier than the title as
> you directly reach to a given version
>

And this is also true.
> Anyway, I can mention the full name of the specification in the commit.
Yes, this is exactly what I asked. It would be good to have *both*
document ID and human readable name so one can quickly understood
about what document you are speaking, without googling its ID.


-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

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

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Andrew Cooper]

On 07/02/18 13:08, Jan Beulich wrote:
 On 07.02.18 at 14:01,  wrote:
>> So far the issue confirmed:
>> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
>> that it was tested on), Intel S2600XX, etc.
>>
>> Also see:
>> https://bugs.xenserver.org/browse/XSO-774 
>>
>> Well, no-watchdog is what we currently recommend in that case but we
>> hoped there is a general solution here from Xen side. You have your
>> point that they should fix this on their side because it's their fault
>> indeed. But the user experience is also important for us I think.
> Of course, hence the suggestion of possible alternative workarounds.
> Impacting everyone is, as said, not a desirable approach in a case
> like this one. I also continue to dislike the seemingly random division
> by 10.

Xen's usability is crap, which is in large part due to attitude like
this.  It is not ok to expect the end user to know diagnose/debug issues
like this, and it is entirely unreasonable to expect the end user to
have to manually work around it.

This particular issue does want feeding back to Intel so they can try
and fix it, but whatever is wrong is present in a large amount of
Skylake systems in the field.  Xen needs to be able to cope.

Finally, as to boot times, your argument is backwards seeing as you care
about elapsed boot time.  Slowing the frequency will speed everything
up, as we aren't executing a large chunk of the BSP boot path with 100hz
NMI constantly interrupting.

~Andrew

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

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Jan Beulich]

>>> On 07.02.18 at 14:01,  wrote:
> So far the issue confirmed:
> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
> that it was tested on), Intel S2600XX, etc.
> 
> Also see:
> https://bugs.xenserver.org/browse/XSO-774 
> 
> Well, no-watchdog is what we currently recommend in that case but we
> hoped there is a general solution here from Xen side. You have your
> point that they should fix this on their side because it's their fault
> indeed. But the user experience is also important for us I think.

Of course, hence the suggestion of possible alternative workarounds.
Impacting everyone is, as said, not a desirable approach in a case
like this one. I also continue to dislike the seemingly random division
by 10.

Jan


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

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Igor Druzhinin]

On 07/02/18 09:13, Jan Beulich wrote:
 On 06.02.18 at 22:51,  wrote:
>> The problem with a quirk/commandline parameter is that the issue is
>> reported for a wide variety of systems and, as it looks like, depends on
>> the default BIOS setup - means it's hard to identify particular
>> machines. We should obviously sort this out with Intel but until then
>> lowering the initial frequency is our only option.
> 
> "Wide variety" is interesting, considering that we've had no earlier
> reports. As the description of the patch talks about "post-Skylake" -
> are these production machines? If not, a command line option
> would quite certainly be sufficient here. If yes, I'd like "wide variety"
> to be further qualified. After all we're talking about a processing
> overhead on the order of 10ms here, which is absurd. There are
> systems anyway where the watchdog doesn't work - we may need
> to consider to suggest to people to simply not enable the watchdog
> on such systems until the firmware issue has been taken care of.
> 
> As mentioned before - if firmware takes on the order of 10ms to
> process the SMI intercept, I can't see why it wouldn't be possible
> for them to screw up further and take 20, 50, or 100ms, at which
> point your seemingly random HZ / 10 would no longer work either.
> The same goes for the case of someone coming along and
> changing HZ to a higher value (with a good reason provided).
> 
> Jan
> 

So far the issue confirmed:
Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
that it was tested on), Intel S2600XX, etc.

Also see:
https://bugs.xenserver.org/browse/XSO-774

Well, no-watchdog is what we currently recommend in that case but we
hoped there is a general solution here from Xen side. You have your
point that they should fix this on their side because it's their fault
indeed. But the user experience is also important for us I think.

Igor

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118605
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118605
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118605
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-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-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-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-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  7edcbd02aa088ee0fb721f9cc34d28089b779267
baseline version:
 libvirt  cb775a51a0eb953635c8e35689b8b1f3cce0d381

Last test of basis   118605  2018-02-06 04:20:10 Z1 days
Testing same since   118632  2018-02-07 04:20:36 Z0 days1 attempts


People who touched revisions under test:
  Christian Ehrhardt 
  Guido Günther 
  John Ferlan 
  Shivaprasad G Bhat 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-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-armhf-armhf-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

Re: [Xen-devel] qemu-xen fails to build in staging

[Jan Beulich]

>>> On 07.02.18 at 13:40,  wrote:
> Am Wed, 7 Feb 2018 11:13:22 +0100
> schrieb Olaf Hering :
> 
>> Yes, it looks like qemu has now submodules which are required for build.
> 
> How is the required state of the submodules tracked? When I did a local 
> build I got 10739aa from qemu.org, and building xen.git#staging succeeds. 
> After that I updated my packaging, created a new tar from 
> keycodemapdb.git#master and got a non-working build. It turned out that 
> 044f21d was packaged.
> 
> Does the build of xen.git#staging now depend on random state at 
> git.qemu.org?

No - the git tree containing the submodule tracks the intended
commit at which the submodule is to be used. You need to fish
out that hash instead of using plain master from the other repo.
"git submodule status" should tell you, I think.

Jan


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

Re: [Xen-devel] qemu-xen fails to build in staging

[Olaf Hering]

Am Wed, 7 Feb 2018 11:13:22 +0100
schrieb Olaf Hering :

> Yes, it looks like qemu has now submodules which are required for build.

How is the required state of the submodules tracked? When I did a local build I 
got 10739aa from qemu.org, and building xen.git#staging succeeds. After that I 
updated my packaging, created a new tar from keycodemapdb.git#master and got a 
non-working build. It turned out that 044f21d was packaged.

Does the build of xen.git#staging now depend on random state at git.qemu.org?

Olaf


pgpEWI4ki9PiL.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [qemu-mainline test] 118630: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118613
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118613
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118613
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118613
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118613
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118613
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-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-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 qemuu20e0d439a6ded635ec89f6135c08cd5541c68962
baseline version:
 qemuu2b3805f370521deacab974b9c9ca07d2319a8890

Last test of basis   118613  2018-02-06 11:17:51 Z1 days
Testing same since   118630  2018-02-06 23:42:48 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 
  Richard Henderson 

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

Re: [Xen-devel] Problem with IOMEM and domain reboot

[Oleksandr Andrushchenko]

On 02/06/2018 02:52 PM, Wei Liu wrote:

On Tue, Feb 06, 2018 at 02:44:56PM +0200, Oleksandr Andrushchenko wrote:

  From aa1f20af73a5a3c8f2c904b857a79334d18d41ff Mon Sep 17 00:00:00 2001

From: Oleksandr Andrushchenko 
Date: Wed, 20 Dec 2017 17:51:18 +0200
Subject: [PATCH] [HACK] Reset iomem's gfn to LIBXL_INVALID_GFN on reboot

During domain reboot its configuration is partially reused
to re-create a new domain, but iomem's GFN field for the
iomem is only restored for those memory ranges, which are
configured in form of [IOMEM_START,NUM_PAGES[@GFN], but not for
those in form of [IOMEM_START,NUM_PAGES], e.g. without GFN.
For the latter GFN is reset to 0, but while mapping ranges
to a domain during reboot there is a check that GFN treated
as valid if it is not equal to LIBXL_INVALID_GFN, thus making
Xen to map IOMEM_START to address 0 in the guest's address space.

Workaround it by resseting GFN to LIBXL_INVALID_GFN, so xl
can set proper values for mapping on reboot.

Signed-off-by: Oleksandr Andrushchenko 
---
   tools/libxl/libxl_domain.c | 9 +
   1 file changed, 9 insertions(+)

diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index ef1a0927b00d..2678ad2ad54f 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -1647,6 +1647,15 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, 
uint32_t domid,
   }
   }
+/* reset IOMEM's GFN to initial value */
+{
+int i;
+
+for (i = 0; i < d_config->b_info.num_iomem; i++)
+if (d_config->b_info.iomem[i].gfn == 0)
+d_config->b_info.iomem[i].gfn = LIBXL_INVALID_GFN;
+}
+

I don't think this is necessary. Instead we should tell libxl to save
the generated value into the template. Add an update_config hook for the
iomem type should be better.

Agree, this is why I tagged the patch as [HACK]
Unfortunately, I have little knowledge of libxl and not sure
how to properly fix it. Can you tell a bit more on what
a proper fix could be?

See libxl__update_domain_configuration, which is called after domain
construction is completed. It will call the update_config hook for a
device type to save anything that is generated in the process of domain
creation. One example is in libxl_nic. You can do the same to iomem I
think.

The end result is the generated values you care about are saved into the
template. When the domain is migrated / rebooted libxl will use the
saved values instead.

Thank you, will look at it to make a proper fix

Strictly speaking your patch of adding the snippet to
libxl_retrieve_domain_configuration isn't wrong, but I would prefer that
function to only contain code to fetch states that can be changed during
domain runtime. The iomem range isn't one of those states AIUI.

Wei.



Wei.

Thank you,
Oleksandr



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

Re: [Xen-devel] [PATCH RFC 2/8] public/io/netif: add directory for backend parameters

[Joao Martins]

On 02/06/2018 05:12 PM, Wei Liu wrote:
> (Three months after you sent this, sorry...)
> 
> On Mon, Nov 06, 2017 at 12:33:06PM +, Joao Martins wrote:
>> On Mon, Nov 06, 2017 at 10:33:59AM +, Paul Durrant wrote:
 -Original Message-
 From: Joao Martins [mailto:joao.m.mart...@oracle.com]
 Sent: 02 November 2017 18:06
 To: Xen Development List 
 Cc: Joao Martins ; Konrad Rzeszutek Wilk
 ; Paul Durrant ; Wei Liu
 
 Subject: [PATCH RFC 2/8] public/io/netif: add directory for backend
 parameters

 The proposed directory provides a mechanism for tools to control the
 maximum feature set of the device being provisioned by backend.
 The parameters/features include offloading features, number of
 queues etc.

 Signed-off-by: Joao Martins 
 ---
  xen/include/public/io/netif.h | 16 
  1 file changed, 16 insertions(+)

 diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
 index 2454448baa..a412e4771d 100644
 --- a/xen/include/public/io/netif.h
 +++ b/xen/include/public/io/netif.h
 @@ -161,6 +161,22 @@
   */

  /*
 + * The directory "require" maybe be created in backend path by tools
 + * domain to override the maximum feature set that backend provides to
 the
 + * frontend. The children entries within this directory are features names
 + * and the correspondent values that should be used backend as defaults
 e.g.:
 + *
 + * /local/domain/X/backend///require
 + * /local/domain/X/backend///require/multi-queue-
 max-queues = "2"
 + * /local/domain/X/backend///require/feature-no-csum-
 offload = "1"
 + *
 + * In the example above, network backend will negotiate up to a maximum
 of
 + * two queues with frontend plus disabling IPv4 checksum offloading.
 + *
 + * This directory and its children entries shall only be visible to the 
 backend.
 + */
 +
>>>
>>> What should happen if the toolstack sets something in 'require' that
>>> the backend cannot provide? I don't see anything in your RFC patches
>>> to check that the backend has responded appropriately to the keys.
>>
>> Hmm, you're right that this RFC doesn't handle that properly - but for the
>> ones the backend provide I had suggested (albeit not implemented here)
>> back in the other thread that we could compare the values of feature in
>> "require" with the one announced to the frontend. But well this wouldn't
>> cover the non-provided ones, and possibly would fall a bit as a hack.
>>
>> I could change the format of the entries within "require"
>> directory to be e.g. "- = " and the
>> acknowledgement entry would come in the form "-status
>> = ". Consequently the lack of a "-status" entry would
>> have a stronger semantic i.e. unsupported and ignored. The toolstack then 
>> would have
>> means to check whether the feature was really succesfull set as desired
>> or not. But then one question comes to mind: should the backend be
>> prevented to init in the event that the features requested fail to be
>> set? In which case uevent (on Linux) isn't triggered and xenbus state doesn't
>> get changed and toolstack would fail with timeout later on.
>>
> 
> I think the backend should not proceed if it can't meet the
> requirements. But to be clear I also don't think the timeout behaviour
> should be used to determine if the setting is successful because it is
> asking other part of the system to pick up the slack and system
> administrators would be left in the dark (unless there is easily
> accessible message that can be obtained by libxl to return to system
> administrators).

That timeout behaviour is already there *I think* (or maybe I have the wrong
impression)? The alternative is to trigger the uevent and add more logic on the
hotplug script to check if the parameters were set according to config, but OTOH
you add more complexity there. Or perhaps we can check that the backend set to
its state to Unknown (or some other state) and that determines the failure - but
still no uevent should be triggered. Unless you had something else in your mind?

Joao

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

Re: [Xen-devel] [PATCH RFC 0/8] libxl, xl, public/io: PV backends feature control

[Joao Martins]

On 02/07/2018 11:16 AM, Roger Pau Monné wrote:
> On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote:
>> Hey folks,
>>
>> Presented herewith is an attempt to implement PV backends feature control
>> as discussed in the list 
>> (https://lists.xen.org/archives/html/xen-devel/2017-09/msg00766.html)
>>
>> Given that this a simple proposal hence I thought to include all changes
>> involved in the same patchset such that everyone see all the changes and has 
>> a
>> better estimate (but restricted to xen-devel just for the RFC purposes).
>>
>> The motivation here is to allow system administrators more fine grained
>> control of the device features being used by guest.
>>
>> The only change I made compared to the proposed discussed above was to use
>> "require" instead of "request" as the prefix because there is a feature which
> 
> require in the above context, like:
> 
> require-multi-queue-max-queues=2
> 
> Seems to imply that the guest _must_ have support for multiqueue and
> use exactly two queues.
> 
> What about using 'config' prefix?
> 
> config-multi-queue-max-queues=2
> config-feature-persistent=0
>

Hmm, 'config' sounds better indeed. We mainly chose 'require' because the domain
shall only be booted with those configs. I am fine with both.

>> has "request" in it. But if "request" is still preferred as a prefix I can 
>> change
>> it up.
>>
>> The scheme proposed is quite simple:
>>
>> * The directory "require" is created (inside the backend path) and within 
>> that
>> directory the features/capabilities names and values are written.
> 
> I'm quite sure I'm missing something, but what's the point in having
> this require directory in the xenstore backend path?
> 
> AFAICT you should just write this directly to the backend directory,
> and backends should be modified to check if there's a value already
> present before writing the default one.
> It's also an option which I can go with if folks prefer it.

Creating a config/require directory for requested features simply sounded
cleaner to me, and would also allow you to know what config you passed on to the
backend vs the one the backend exposed (better separation). And writing over the
currently reserved entries would be a little confusing when dealing with new
features (e.g. you write multi-queue-max-queues on a non multi queue backend and
the entry being present is a little misleading even though you would restrict
its access with backend-only permissions).

>> * Toolstack constructs a key value store of features, and user specifies 
>> those
>> through special entry names prefixed also as "require". Toolstack is 
>> stateless thus sys
>> admin has full control over what to pass to the backend. In other words it
>> doesn't look at particular feature names/values.
>>
>> * The backend will then use that for seeding its maximum feature set to the
>> frontend.
> 
> Oh, I see. So the backend picks up the suggested config from this
> directory together with it's capabilities and then produces the final
> set of features exposed to the frontend.
> 
/nods

> In order to prevent adding more logic to the backends, would it make
> sense to export the backend capabilities in /sys/ (or sysctl on BSDs)
> and do those calculations from the toolstack itself, so that the
> toolstack directly writes the features to the backend top level
> xenstore directory?

I had suggested in answer to Paul's comment[0] to create this maximum featureset
of the backend in its top level directory. Pasting it here that part (with one
addition):

/local/domain/X/backend//features/-desc = "Short
description
of "
/local/domain/X/backend//features/-defval =
""
/local/domain/X/backend//features/-type =
"uint|int|string|bool" (but could be done with regexp instead of this entry)

e.g.

/local/domain/X/backend/vif/features/multi-queue-max-queues-desc = "Number of
queues of the interface"
/local/domain/X/backend/vif/features/multi-queue-max-queues-defval = "8"
/local/domain/X/backend/vif/features/multi-queue-max-queues-type = "uint"

Just wondering about the handling of these that would complicate the backend
implementation (e.g. types, error checking). But I am not seeing another good
way of doing this.

Joao

[0] https://lists.xen.org/archives/html/xen-devel/2017-11/msg00347.html

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

Re: [Xen-devel] [PATCH RFC 7/8] xen-blkback: frontend feature control

[Roger Pau Monné]

On Thu, Nov 02, 2017 at 06:06:15PM +, Joao Martins wrote:
> Toolstack may write values to the "require" subdirectory in the
> backend main directory (e.g. backend/vbd/X/Y/). Read these values
> and use them when announcing those to the frontend. When backend
> scans frontend features the values set in the require directory
> take precedence, hence making no significant changes in feature
> parsing.
> 
> xenbus_read_feature() reads from require subdirectory and prints that
> value and otherwise writing a default_val in the entry. We then replace
> all instances of xenbus_printf to use these previously seeded features.
> A backend_features struct is introduced and all values set there are
> used in place of the module parameters being used.
> 
> Note, however that feature-barrier, feature-flush-support and
> feature-discard aren't probed because first two are physical
> device dependent and feature-discard already has tunables to
> adjust.
> 
> Signed-off-by: Joao Martins 
> ---
>  drivers/block/xen-blkback/blkback.c |  2 +-
>  drivers/block/xen-blkback/common.h  |  1 +
>  drivers/block/xen-blkback/xenbus.c  | 66 
> -
>  3 files changed, 60 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c 
> b/drivers/block/xen-blkback/blkback.c
> index c90e90b6..05b3f124c871 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -1271,7 +1271,7 @@ static int dispatch_rw_block_io(struct xen_blkif_ring 
> *ring,
>   unlikely((req->operation != BLKIF_OP_INDIRECT) &&
>(nseg > BLKIF_MAX_SEGMENTS_PER_REQUEST)) ||
>   unlikely((req->operation == BLKIF_OP_INDIRECT) &&
> -  (nseg > MAX_INDIRECT_SEGMENTS))) {
> +  (nseg > ring->blkif->vbd.max_indirect_segs))) {
>   pr_debug("Bad number of segments in request (%d)\n", nseg);
>   /* Haven't submitted any bio's yet. */
>   goto fail_response;
> diff --git a/drivers/block/xen-blkback/common.h 
> b/drivers/block/xen-blkback/common.h
> index a7832428e0da..ff12f2d883b9 100644
> --- a/drivers/block/xen-blkback/common.h
> +++ b/drivers/block/xen-blkback/common.h
> @@ -229,6 +229,7 @@ struct xen_vbd {
>   unsigned intdiscard_secure:1;
>   unsigned intfeature_gnt_persistent:1;
>   unsigned intoverflow_max_grants:1;
> + unsigned intmax_indirect_segs;

Please place this above, in order to get less padding between fields.

>  };
>  
>  struct backend_info;
> diff --git a/drivers/block/xen-blkback/xenbus.c 
> b/drivers/block/xen-blkback/xenbus.c
> index 48d796ea3626..31683f29d5fb 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -25,11 +25,19 @@
>  
>  /* On the XenBus the max length of 'ring-ref%u'. */
>  #define RINGREF_NAME_LEN (20)
> +#define REQUIRE_PATH_LEN (256)
> +
> +struct backend_features {
> + unsigned max_queues;
> + unsigned max_ring_order;

unsigned int.

> + unsigned pers_grants;

bool?

Since you are already doing this, is it worth adding support to
disable other features like flush or discard?

> +};
>  
>  struct backend_info {
>   struct xenbus_device*dev;
>   struct xen_blkif*blkif;
>   struct xenbus_watch backend_watch;
> + struct backend_features features;
>   unsignedmajor;
>   unsignedminor;
>   char*mode;
> @@ -602,6 +610,40 @@ int xen_blkbk_barrier(struct xenbus_transaction xbt,
>   return err;
>  }
>  
> +static int xenbus_read_feature(const char *dir, const char *node,
> +unsigned int default_val)
> +{
> + char reqnode[REQUIRE_PATH_LEN];
> + unsigned int val;
> +
> + snprintf(reqnode, REQUIRE_PATH_LEN, "%s/require", dir);
> + val = xenbus_read_unsigned(reqnode, node, default_val);
> + return val;
> +}

You could avoid the temporary buffer by doing something like:

> +
> +static void xen_blkbk_probe_features(struct xenbus_device *dev,
> +  struct backend_info *be)
> +{
> + struct backend_features *ft = >features;
> + struct xen_vbd *vbd = >blkif->vbd;
> +

#define READ_FEAT(path, feat, default) \
xenbus_read_unsigned(path, "require/" node, default)

> + vbd->max_indirect_segs = xenbus_read_feature(dev->nodename,
> + "feature-max-indirect-segments",
> + MAX_INDIRECT_SEGMENTS);
> +
> + ft->max_queues = xenbus_read_feature(dev->nodename,
> +  "multi-queue-max-queues",
> +  xenblk_max_queues);
> +
> + ft->max_ring_order = xenbus_read_feature(dev->nodename,
> +  "max-ring-page-order",
> +

Re: [Xen-devel] [PATCH RFC 0/8] libxl, xl, public/io: PV backends feature control

[Joao Martins]

On 02/07/2018 11:30 AM, Roger Pau Monné wrote:
> On Wed, Feb 07, 2018 at 12:20:42PM +0100, Juergen Gross wrote:
>> On 07/02/18 12:16, Roger Pau Monné wrote:
>>> On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote:
 * Toolstack constructs a key value store of features, and user specifies 
 those
 through special entry names prefixed also as "require". Toolstack is 
 stateless thus sys
 admin has full control over what to pass to the backend. In other words it
 doesn't look at particular feature names/values.

 * The backend will then use that for seeding its maximum feature set to the
 frontend.
>>>
>>> Oh, I see. So the backend picks up the suggested config from this
>>> directory together with it's capabilities and then produces the final
>>> set of features exposed to the frontend.
>>>
>>> In order to prevent adding more logic to the backends, would it make
>>> sense to export the backend capabilities in /sys/ (or sysctl on BSDs)
>>> and do those calculations from the toolstack itself, so that the
>>> toolstack directly writes the features to the backend top level
>>> xenstore directory?
>>
>> So you want the toolstack to read the /sys/ entries? How would that work
>> for driver domains?
> 
> Right, that won't work for driver domains... And feeding that
> information from a driver domain into the control domain is even
> worse, so I'm fine with this.

Right, in the first email thread[0] we had, Konrad also pointed this out about
driver domains. So the choice of xenstore over OS specific constructs was mainly
because of driver domains.

Joao

[0] https://lists.xen.org/archives/html/xen-devel/2017-09/msg02275.html

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

Re: [Xen-devel] [PATCH RFC 1/8] public/io/blkif: add directory for backend parameters

[Roger Pau Monné]

On Thu, Nov 02, 2017 at 06:06:09PM +, Joao Martins wrote:
> The proposed directory provides a mechanism for tools to control the
> maximum feature set of the device being provisioned by backends.
> Examples include max ring page order, persistent grants, number of
> queues etc.
> 
> Signed-off-by: Joao Martins 
> ---
>  xen/include/public/io/blkif.h | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
> index 15a71e3fea..4c0a93a2bf 100644
> --- a/xen/include/public/io/blkif.h
> +++ b/xen/include/public/io/blkif.h
> @@ -133,6 +133,20 @@
>   *  This option doesn't require a backend to use O_DIRECT, so it
>   *  should not be used to try to control the caching behaviour.
>   *
> + * require

I would maybe name this 'config'.

> + *
> + *  The directory "require" maybe be created by tools domain to
> + *  override the maximum feature set that backend provides to the
> + *  frontend. The children entries within this directory are
> + *  features names and its correspondent value e.g.:
  ^ corresponding

Thanks, Roger.

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

[Xen-devel] [linux-linus test] 118629: regressions - FAIL

[osstest service owner]

flight 118629 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118629/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start   fail REGR. vs. 118324
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. 
vs. 118324

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118324
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118324
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118324
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118324
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118324
 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-xsm 13 migrate-support-checkfail   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-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 linuxb46dc8ae17a427c50c00241898832807576fd28a
baseline version:
 linux5b7d27967dabfb17c21b0d98b29153b9e3ee71e5

Last test of basis   118324  2018-01-25 07:31:24 Z   13 days
Failing since118362  2018-01-26 16:56:17 Z   11 days   14 attempts
Testing same since   118629  2018-02-06 22:50:32 Z0 days1 attempts


1968 people touched 

Re: [Xen-devel] [PATCH RFC 0/8] libxl, xl, public/io: PV backends feature control

[Juergen Gross]

On 07/02/18 12:16, Roger Pau Monné wrote:
> On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote:
>> Hey folks,
>>
>> Presented herewith is an attempt to implement PV backends feature control
>> as discussed in the list 
>> (https://lists.xen.org/archives/html/xen-devel/2017-09/msg00766.html)
>>
>> Given that this a simple proposal hence I thought to include all changes
>> involved in the same patchset such that everyone see all the changes and has 
>> a
>> better estimate (but restricted to xen-devel just for the RFC purposes).
>>
>> The motivation here is to allow system administrators more fine grained
>> control of the device features being used by guest.
>>
>> The only change I made compared to the proposed discussed above was to use
>> "require" instead of "request" as the prefix because there is a feature which
> 
> require in the above context, like:
> 
> require-multi-queue-max-queues=2
> 
> Seems to imply that the guest _must_ have support for multiqueue and
> use exactly two queues.
> 
> What about using 'config' prefix?
> 
> config-multi-queue-max-queues=2
> config-feature-persistent=0
> 
>> has "request" in it. But if "request" is still preferred as a prefix I can 
>> change
>> it up.
>>
>> The scheme proposed is quite simple:
>>
>> * The directory "require" is created (inside the backend path) and within 
>> that
>> directory the features/capabilities names and values are written.
> 
> I'm quite sure I'm missing something, but what's the point in having
> this require directory in the xenstore backend path?
> 
> AFAICT you should just write this directly to the backend directory,
> and backends should be modified to check if there's a value already
> present before writing the default one.
> 
>> * Toolstack constructs a key value store of features, and user specifies 
>> those
>> through special entry names prefixed also as "require". Toolstack is 
>> stateless thus sys
>> admin has full control over what to pass to the backend. In other words it
>> doesn't look at particular feature names/values.
>>
>> * The backend will then use that for seeding its maximum feature set to the
>> frontend.
> 
> Oh, I see. So the backend picks up the suggested config from this
> directory together with it's capabilities and then produces the final
> set of features exposed to the frontend.
> 
> In order to prevent adding more logic to the backends, would it make
> sense to export the backend capabilities in /sys/ (or sysctl on BSDs)
> and do those calculations from the toolstack itself, so that the
> toolstack directly writes the features to the backend top level
> xenstore directory?

So you want the toolstack to read the /sys/ entries? How would that work
for driver domains?

Juergen

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

Re: [Xen-devel] [PATCH RFC 0/8] libxl, xl, public/io: PV backends feature control

[Roger Pau Monné]

On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote:
> Hey folks,
> 
> Presented herewith is an attempt to implement PV backends feature control
> as discussed in the list 
> (https://lists.xen.org/archives/html/xen-devel/2017-09/msg00766.html)
> 
> Given that this a simple proposal hence I thought to include all changes
> involved in the same patchset such that everyone see all the changes and has a
> better estimate (but restricted to xen-devel just for the RFC purposes).
> 
> The motivation here is to allow system administrators more fine grained
> control of the device features being used by guest.
> 
> The only change I made compared to the proposed discussed above was to use
> "require" instead of "request" as the prefix because there is a feature which

require in the above context, like:

require-multi-queue-max-queues=2

Seems to imply that the guest _must_ have support for multiqueue and
use exactly two queues.

What about using 'config' prefix?

config-multi-queue-max-queues=2
config-feature-persistent=0

> has "request" in it. But if "request" is still preferred as a prefix I can 
> change
> it up.
> 
> The scheme proposed is quite simple:
> 
> * The directory "require" is created (inside the backend path) and within that
> directory the features/capabilities names and values are written.

I'm quite sure I'm missing something, but what's the point in having
this require directory in the xenstore backend path?

AFAICT you should just write this directly to the backend directory,
and backends should be modified to check if there's a value already
present before writing the default one.

> * Toolstack constructs a key value store of features, and user specifies those
> through special entry names prefixed also as "require". Toolstack is 
> stateless thus sys
> admin has full control over what to pass to the backend. In other words it
> doesn't look at particular feature names/values.
> 
> * The backend will then use that for seeding its maximum feature set to the
> frontend.

Oh, I see. So the backend picks up the suggested config from this
directory together with it's capabilities and then produces the final
set of features exposed to the frontend.

In order to prevent adding more logic to the backends, would it make
sense to export the backend capabilities in /sys/ (or sysctl on BSDs)
and do those calculations from the toolstack itself, so that the
toolstack directly writes the features to the backend top level
xenstore directory?

Thanks, Roger.

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

[Xen-devel] [PATCH v4 4/7] kconfig/gcov: rename to coverage

[Roger Pau Monne]

So it can be used by both gcc and clang. Just add the Kconfig option
and modify the makefiles so the llvm coverage specific code can be
added in a follow up patch.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Changes since v3:
 - s/nogcov/nocov.
 - Remove leading spaces in filter-out.

Changes since v2:
 - select SUPPRESS_DUPLICATE_SYMBOL_WARNINGS when enabling coverage
   support in Kconfig.
 - Introduce COV_FLAGS to store the compiler flags to enable coverage
   support for clang and gcc.
 - Return -EOPNOTSUPP in sysctl_cov_op if not implemented.

Changes since v1:
 - Use a choice in kconfig to select code coverage technology.
 - Compile coverage.c regardless of selected code coverage technology.
 - Introduce an unimplemented sysctl_cov_op function if
   CONFIG_COVERAGE is not set.
---
 docs/misc/coverage.markdown  | 2 +-
 xen/Kconfig.debug| 6 +++---
 xen/Rules.mk | 9 +++--
 xen/arch/x86/efi/Makefile| 2 +-
 xen/common/Makefile  | 2 +-
 xen/common/coverage/Makefile | 5 -
 xen/common/sysctl.c  | 2 --
 xen/include/xen/coverage.h   | 7 ++-
 8 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/docs/misc/coverage.markdown b/docs/misc/coverage.markdown
index b47aba2648..430cd27b2f 100644
--- a/docs/misc/coverage.markdown
+++ b/docs/misc/coverage.markdown
@@ -10,7 +10,7 @@ down your hypervisor.
 
 ## Enable coverage
 
-Test coverage support can be turned on compiling Xen with the `CONFIG_GCOV`
+Test coverage support can be turned on compiling Xen with the `CONFIG_COVERAGE`
 option set to `y`.
 
 Change your `.config` or run `make -C xen menuconfig`.
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 7bb0465b5d..380c4e8d75 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -28,12 +28,12 @@ config FRAME_POINTER
  maybe slower, but it gives very useful debugging information
  in case of any Xen bugs.
 
-config GCOV
-   bool "Gcov Support"
+config COVERAGE
+   bool "Code coverage support"
depends on !LIVEPATCH
select SUPPRESS_DUPLICATE_SYMBOL_WARNINGS
---help---
- Enable gcov (a test coverage program in GCC) support.
+ Enable code coverage support.
 
  If unsure, say N here.
 
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 541ed13aa1..da3c35ba36 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -119,8 +119,13 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += 
-DINIT_SECTIONS_ONLY
 
-ifeq ($(CONFIG_GCOV),y)
-$(filter-out %.init.o $(nogcov-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += 
-fprofile-arcs -ftest-coverage
+ifeq ($(CONFIG_COVERAGE),y)
+ifeq ($(clang),y)
+COV_FLAGS := -fprofile-instr-generate -fcoverage-mapping
+else
+COV_FLAGS := -fprofile-arcs -ftest-coverage
+endif
+$(filter-out %.init.o $(nocov-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += 
$(COV_FLAGS)
 endif
 
 ifeq ($(CONFIG_UBSAN),y)
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 3edff1cf24..3be9661108 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -13,4 +13,4 @@ boot.init.o: buildid.o
 obj-y := stub.o
 obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
 extra-$(efi) += buildid.o
-nogcov-$(efi) += stub.o
+nocov-$(efi) += stub.o
diff --git a/xen/common/Makefile b/xen/common/Makefile
index ad181636f6..3a349f478b 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -74,7 +74,7 @@ tmem-y := tmem.o tmem_xen.o tmem_control.o
 tmem-$(CONFIG_COMPAT) += compat/tmem_xen.o
 obj-$(CONFIG_TMEM) += $(tmem-y)
 
-subdir-$(CONFIG_GCOV) += coverage
+subdir-$(CONFIG_COVERAGE) += coverage
 subdir-$(CONFIG_UBSAN) += ubsan
 
 subdir-y += libelf
diff --git a/xen/common/coverage/Makefile b/xen/common/coverage/Makefile
index 5387bc6429..1039a160c4 100644
--- a/xen/common/coverage/Makefile
+++ b/xen/common/coverage/Makefile
@@ -1,6 +1,9 @@
-obj-y += coverage.o gcov_base.o gcov.o
+obj-y += coverage.o
+ifneq ($(clang),y)
+obj-y += gcov_base.o gcov.o
 obj-y += $(call cc-ifversion,lt,0x040700, \
gcc_3_4.o, $(call cc-ifversion,lt,0x040900, \
gcc_4_7.o, $(call cc-ifversion,lt,0x05, \
gcc_4_9.o, $(call cc-ifversion,lt,0x07, \
gcc_5.o, gcc_7.o
+endif
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index f2ae6295ff..8e83c33a16 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -396,12 +396,10 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
 }
 break;
 
-#ifdef CONFIG_GCOV
 case XEN_SYSCTL_coverage_op:
 ret = 

Re: [Xen-devel] [PATCH v3] x86/boot: Make alternative patching NMI-safe

[Jan Beulich]

>>> On 06.02.18 at 12:09,  wrote:
> During patching, there is a very slim risk that an NMI or MCE interrupt in the
> middle of altering the code in the NMI/MCE paths, in which case bad things
> will happen.
> 
> The NMI risk can be eliminated by running the patching loop in NMI context, at
> which point the CPU will defer further NMIs until patching is complete.
> 
> Signed-off-by: Andrew Cooper 

While I'm not overly happy with this approach, I can live with it,
at least for the time being, so
Acked-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH] docs: clearify symlink usage in xen-pv-channel

[Wei Liu]

On Wed, Feb 07, 2018 at 09:45:53AM +0100, Olaf Hering wrote:
> The previous version simply states that a symlink has to be created
> without telling where the symlink should point to.
> 
> Signed-off-by: Olaf Hering 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] docs: fix kernel config option in xen-pv-channel

[Wei Liu]

On Wed, Feb 07, 2018 at 09:30:57AM +0100, Olaf Hering wrote:
> HVC is shown underlined, the underscores are missing.
> Fix it by using underscores.
> Remove stale I.
> 
> Signed-off-by: Olaf Hering 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 1/2] make xen ocaml safe-strings compliant

[Wei Liu]

On Tue, Feb 06, 2018 at 09:56:14PM +, Michael Young wrote:
> On Tue, 6 Feb 2018, Wei Liu wrote:
> 
> > On Tue, Jan 30, 2018 at 10:55:47PM +, Michael Young wrote:
> > > Xen built with ocaml 4.06 gives errors such as
> > > Error: This expression has type bytes but an expression was
> > >   expected of type string
> > > as Byte and safe-strings which were introduced in 4.02 are the
> > > default in 4.06.
> > > This patch which is partly by Richard W.M. Jones of Red Hat
> > > from https://bugzilla.redhat.com/show_bug.cgi?id=1526703
> > > fixes these issues.
> > > 
> > > Signed-off-by: Michael Young 
> > > Reviewed-by: Christian Lindig 
> > 
> > Strangely this doesn't apply to staging. And after examining the
> > downloaded patch I'm not sure if my mail client is acting up. Do you
> > have a git branch that I can pull from?
> 
> The patch needed to be reduced as one of the sections being patched was
> removed by a recent patch. I am attaching the revised patch as a file in
> case there was also an email formatting issue.
> 

Thanks, I will try this today.

Wei.

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

[Xen-devel] [xen-unstable-coverity test] 118635: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  30cbd0c83ef3d0edac2d5bcc41a9a2b7a843ae58
baseline version:
 xen  99d9d7a33b781bc9a91416f1e04c8e50e40fa4ef

Last test of basis   118564  2018-02-04 09:18:44 Z3 days
Testing same since   118635  2018-02-07 09:20:25 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Brian Woods 
  Jan Beulich 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 
  Zhongze Liu 

jobs:
 coverity-amd64   pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   99d9d7a33b..30cbd0c83e  30cbd0c83ef3d0edac2d5bcc41a9a2b7a843ae58 -> 
coverity-tested/smoke

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

Re: [Xen-devel] qemu-xen fails to build in staging

[Olaf Hering]

Am Wed, 07 Feb 2018 02:56:55 -0700
schrieb "Jan Beulich" :

> I think I had seen this too, and only then I realized that now I need
> to set up the respective submodule in the qemu tree.

Yes, it looks like qemu has now submodules which are required for build. 
Neither configure nor 'git archive' does not take that into account, as a 
result the "checkout" is incomplete. Great...

/xen-staging $ find -name .git
./.git
./tools/firmware/seabios-dir-remote/.git
./tools/qemu-xen-traditional-dir-remote/.git
./tools/qemu-xen-dir-remote/.git
./tools/qemu-xen-dir-remote/capstone/.git
./tools/qemu-xen-dir-remote/dtc/.git
./tools/qemu-xen-dir-remote/ui/keycodemapdb/.git

Olaf


pgp4bCM_ppoiy.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] qemu-xen fails to build in staging

[Jan Beulich]

>>> On 07.02.18 at 09:18,  wrote:
> With current staging, qemu-xen fails to build. It looks like a ordering
> issue, I assume ui/input-keymap-linux-to-qcode.c is a generated file.
> It is (as always) a fresh clean checkout in a clean chroot.

I think I had seen this too, and only then I realized that now I need
to set up the respective submodule in the qemu tree.

Jan


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

Re: [Xen-devel] [PATCH 1/3] Make credit2 the default scheduler

[George Dunlap]

On 02/06/2018 10:39 PM, Dario Faggioli wrote:
> On Tue, 2018-02-06 at 17:02 +, George Dunlap wrote:
>> On 02/06/2018 06:18 AM, Juergen Gross wrote:
>>> On 05/02/18 17:53, Dario Faggioli wrote:

 Considering we're releasing in June, but freezing in March, do we
 think
  it is still early enough?
>>
>>> The 4.11 release is completely dominated by Meltdown/Spectre
>>> mitigation
>>> work. So either 4.11 will be a security focused version or we need
>>> to
>>> extend the development phase.
>>
>> Personally I could go either way on this.  So unless someone wants to
>> argue for switching now (or we significantly extend the development
>> window), let's plan on leaving this for post-4.11.
>>
> Yes, I agree.
> 
> And if we don't switch now, I think we should say that, unless someone
> argues against your reasoning in your other email, and convince us,
> we'll switch as soon as 4.12 is branched (or perhaps as soon as 4.11 is
> released?).

Well I had planned to do that for 4.11, but something came up. :-)
Hopefully nothing similar will come up this time...

 -George

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

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Jan Beulich]

>>> On 06.02.18 at 22:51,  wrote:
> The problem with a quirk/commandline parameter is that the issue is
> reported for a wide variety of systems and, as it looks like, depends on
> the default BIOS setup - means it's hard to identify particular
> machines. We should obviously sort this out with Intel but until then
> lowering the initial frequency is our only option.

"Wide variety" is interesting, considering that we've had no earlier
reports. As the description of the patch talks about "post-Skylake" -
are these production machines? If not, a command line option
would quite certainly be sufficient here. If yes, I'd like "wide variety"
to be further qualified. After all we're talking about a processing
overhead on the order of 10ms here, which is absurd. There are
systems anyway where the watchdog doesn't work - we may need
to consider to suggest to people to simply not enable the watchdog
on such systems until the firmware issue has been taken care of.

As mentioned before - if firmware takes on the order of 10ms to
process the SMI intercept, I can't see why it wouldn't be possible
for them to screw up further and take 20, 50, or 100ms, at which
point your seemingly random HZ / 10 would no longer work either.
The same goes for the case of someone coming along and
changing HZ to a higher value (with a good reason provided).

Jan


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

[Xen-devel] [PATCH] docs: clearify symlink usage in xen-pv-channel

[Olaf Hering]

The previous version simply states that a symlink has to be created
without telling where the symlink should point to.

Signed-off-by: Olaf Hering 
---
 docs/man/xen-pv-channel.pod.7 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/docs/man/xen-pv-channel.pod.7 b/docs/man/xen-pv-channel.pod.7
index 226418ad94..7229b26d06 100644
--- a/docs/man/xen-pv-channel.pod.7
+++ b/docs/man/xen-pv-channel.pod.7
@@ -122,6 +122,8 @@ SUBSYSTEM=="xen", DEVPATH=="/devices/console-[0-9]", 
RUN+="xen-console-setup"
 
 where the "xen-console-setup" script would read the channel name and
 make a symlink in /dev/xen-channel/org.my.cloud.software.agent.version1
+pointing to /dev/hvcN. N is the same number as the number in 
"/devices/console-[0-9]".
+In other words, "/devices/console-2" maps to /dev/hvc2.
 
 
 =item 8.

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

[Xen-devel] [PATCH] docs: fix kernel config option in xen-pv-channel

[Olaf Hering]

HVC is shown underlined, the underscores are missing.
Fix it by using underscores.
Remove stale I.

Signed-off-by: Olaf Hering 
---
 docs/man/xen-pv-channel.pod.7 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/man/xen-pv-channel.pod.7 b/docs/man/xen-pv-channel.pod.7
index 2333083cce..226418ad94 100644
--- a/docs/man/xen-pv-channel.pod.7
+++ b/docs/man/xen-pv-channel.pod.7
@@ -108,7 +108,7 @@ socket, writes a handshake message and waits for a reply
 
 =item 6.
 
-Assuming the guest kernel has CONFIGIXEN_FRONTEND set then the console
+Assuming the guest kernel has CONFIG_HVC_XEN_FRONTEND set then the console
 driver will generate a hotplug event
 
 

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

[Xen-devel] qemu-xen fails to build in staging

[Olaf Hering]

With current staging, qemu-xen fails to build. It looks like a ordering
issue, I assume ui/input-keymap-linux-to-qcode.c is a generated file.
It is (as always) a fresh clean checkout in a clean chroot.

[  505s] 
/home/abuild/rpmbuild/BUILD/xen-4.11.20180206T183258.30cbd0c83e/non-dbg/tools/qemu-xen-dir/ui/input-keymap.c:8:44:
 fatal error: ui/input-keymap-linux-to-qcode.c: No such file or directory
[  505s]  #include "ui/input-keymap-linux-to-qcode.c"
[  505s] ^
[  505s] compilation terminated.
[  505s] 
/home/abuild/rpmbuild/BUILD/xen-4.11.20180206T183258.30cbd0c83e/non-dbg/tools/qemu-xen-dir/rules.mak:66:
 recipe for target 'ui/input-keymap.o' failed
[  505s] make: *** [ui/input-keymap.o] Error 1

The previous snapshot did not have this issue:
xen_commit b6c2c7f48ab8bd5566759cb404afd80fd0df2dfe Wed Jan 10 10:33:26 UTC 2018
seabios_tag 5f4c7b13cdf9c450eb55645f4362ea58fa61b79b Fri Feb 24 14:01:20 UTC 
2017
minios_tag 0b4b7897e08b967a09bed2028a79fabff82342dd Fri Oct 20 10:50:35 UTC 2017
ipxe_tag 356f6c1b64d7a97746d1816cef8ca22bdd8d0b5d Tue May 23 17:48:06 UTC 2017
ovmf_tag 947f3737abf65fda63f3ffd97fddfa6986986868 Wed Sep 20 18:25:19 UTC 2017
qemu_xen_traditional_tag c8ea0457495342c417c3dc033bba25148b279f60 Fri Sep 15 
18:37:27 UTC 2017
qemu_xen_upstream_tag b79708a8ed1b3d18bee67baeaf33b3fa529493e2 Thu Nov  9 
15:46:00 UTC 2017

Olaf


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