[Xen-devel] [xen-4.10-testing test] 122592: regressions - trouble: blocked/broken/fail/pass

2018-05-04 Thread osstest service owner
flight 122592 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122592/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 122490
 build-arm64   5 host-build-prep  fail REGR. vs. 122490

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 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-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 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-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
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-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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail 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-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  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-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  99e50001bea6f3d777b86bbb9bb41ef66ba47974
baseline version:
 xen  c30ab3d97c8ff0d2ed8948dd013737befc7a2223

Last test of basis   122490  2018-04-28 06:03:56 Z6 days
Testing same since   122560  2018-05-02 10:07:00 Z2 days3 attempts


People who touched revisions under test:
  Jan Beulich 

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

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

2018-05-04 Thread osstest service owner
flight 122607 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122607/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 122587

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

version targeted for testing:
 xen  e38e285a51c805cfeee4693962df23e39b3c3bd7
baseline version:
 xen  4611f529c0e39493a3945641cc161967a864d6b5

Last test of basis   122587  2018-05-03 16:00:26 Z1 days
Testing same since   122602  2018-05-04 18:01:13 Z0 days4 attempts


People who touched revisions under test:
  Jan Beulich 
  Juergen Gross 
  Wei Liu 

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



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

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

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

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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.


commit e38e285a51c805cfeee4693962df23e39b3c3bd7
Author: Wei Liu 
Date:   Fri May 4 16:08:04 2018 +0100

docs: fix xpti command line option doc

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

commit 5c81d260c244026ea74632faa3c6d0a00cc76469
Author: Juergen Gross 
Date:   Thu Apr 26 13:33:18 2018 +0200

xen/x86: use PCID feature

Avoid flushing the complete TLB when switching %cr3 for mitigation of
Meltdown by using the PCID feature if available.

We are using 4 PCID values for a 64 bit pv domain subject to XPTI and
2 values for the non-XPTI case:

- guest active and in kernel mode
- guest active and in user mode
- hypervisor active and guest in user mode (XPTI only)
- hypervisor active and guest in kernel mode (XPTI only)

We use PCID only if PCID _and_ INVPCID are supported. With PCID in use
we disable global pages in cr4. A command line parameter controls in
which cases PCID is being used.

As the non-XPTI case has shown not to perform better with PCID at least
on some machines the default is to use PCID only for domains subject to
XPTI.

With PCID enabled we always disable global pages. This avoids having to
either flush the complete TLB or do a cycle through all PCID values
when invalidating a single global page.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 

commit 1a32c9868711b4ee883ebb6f8807e08d70a920be
Author: Juergen Gross 
Date:   Thu Apr 26 13:33:17 2018 +0200

xen/x86: add some cr3 helpers

Add some helper macros to access the address and pcid parts of cr3.

Use those helpers where appropriate.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 

commit a5407c1d8c6c0cac96d3e84e7b2b25b18fa2bf4d
Author: Juergen Gross 
Date:   Thu Apr 26 13:33:16 2018 +0200

xen/x86: convert pv_guest_cr4_to_real_cr4() to a function

pv_guest_cr4_to_real_cr4() is becoming more and more complex. Convert
it from a macro to an ordinary function.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 

commit 065a499f78d5b644fa586e3e66f88949821e4f8c
Author: Juergen Gross 
Date:   Thu Apr 26 

[Xen-devel] [xen-4.7-testing test] 122589: trouble: broken/fail/pass

2018-05-04 Thread osstest service owner
flight 122589 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122589/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64   broken
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm broken in 122569
 test-amd64-amd64-xl-shadow   broken  in 122569
 test-amd64-i386-libvirt-xsm  broken  in 122569
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm broken in 122569
 test-amd64-amd64-xl-qcow2broken  in 122569

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 4 host-install(4) broken in 
122569 pass in 122589
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken in 
122569 pass in 122589
 test-amd64-amd64-xl-shadow   4 host-install(4) broken in 122569 pass in 122589
 test-amd64-i386-libvirt-xsm  4 host-install(4) broken in 122569 pass in 122589
 test-amd64-amd64-xl-qcow24 host-install(4) broken in 122569 pass in 122589
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 4 host-install(4) broken pass in 
122569
 test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 122569 pass 
in 122589
 test-armhf-armhf-xl-multivcpu  6 xen-install fail in 122569 pass in 122589
 test-xtf-amd64-amd64-2   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 122569

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 122569 like 
122131
 test-xtf-amd64-amd64-4  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122131
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 122131
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122131
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 122131
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122131
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122131
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122131
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 122131
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 122131
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122131
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122131
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122131
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 122131
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-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-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-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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
 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-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 

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

2018-05-04 Thread Platform Team regression test user
This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
74668

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 74668
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail like 74668
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail like 74668
 test-armhf-armhf-libvirt 12 guest-start  fail   like 74668
 test-armhf-armhf-libvirt-xsm 12 guest-start  fail   like 74668
 test-armhf-armhf-xl-multivcpu 12 guest-start  fail  like 74668
 test-armhf-armhf-xl-midway   12 guest-start  fail   like 74668
 test-armhf-armhf-xl-xsm  12 guest-start  fail   like 74668
 test-armhf-armhf-xl  12 guest-start  fail   like 74668
 test-armhf-armhf-xl-credit2  12 guest-start  fail   like 74668
 test-armhf-armhf-xl-rtds 12 guest-start  fail   like 74668
 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail like 74668
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 74668
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail like 74668
 test-armhf-armhf-xl-vhd  10 debian-di-installfail   like 74668
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail   like 74668
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 74668
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 74668
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-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-amd64-i386-xl-qemut-win10-i386 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass

version targeted for testing:
 xen  0306a1311d02ea52b4a9a9bc339f8bab9354c5e3
baseline version:
 xen  eff2fbe4dd71b3e4fe2dbb2696882252c1cc7897

Last test of basis74668  2018-05-03 12:22:29 Z1 days
Testing same since74673  2018-05-04 13:19:07 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Brian Woods 
  Ian Jackson 
  Jan Beulich 
  Lars Kurth 
  Stewart Hildebrand 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass
 test-xtf-amd64-amd64-1

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

2018-05-04 Thread osstest service owner
flight 122604 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122604/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 122587

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

version targeted for testing:
 xen  e38e285a51c805cfeee4693962df23e39b3c3bd7
baseline version:
 xen  4611f529c0e39493a3945641cc161967a864d6b5

Last test of basis   122587  2018-05-03 16:00:26 Z1 days
Testing same since   122602  2018-05-04 18:01:13 Z0 days2 attempts


People who touched revisions under test:
  Jan Beulich 
  Juergen Gross 
  Wei Liu 

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



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

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

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

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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.


commit e38e285a51c805cfeee4693962df23e39b3c3bd7
Author: Wei Liu 
Date:   Fri May 4 16:08:04 2018 +0100

docs: fix xpti command line option doc

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

commit 5c81d260c244026ea74632faa3c6d0a00cc76469
Author: Juergen Gross 
Date:   Thu Apr 26 13:33:18 2018 +0200

xen/x86: use PCID feature

Avoid flushing the complete TLB when switching %cr3 for mitigation of
Meltdown by using the PCID feature if available.

We are using 4 PCID values for a 64 bit pv domain subject to XPTI and
2 values for the non-XPTI case:

- guest active and in kernel mode
- guest active and in user mode
- hypervisor active and guest in user mode (XPTI only)
- hypervisor active and guest in kernel mode (XPTI only)

We use PCID only if PCID _and_ INVPCID are supported. With PCID in use
we disable global pages in cr4. A command line parameter controls in
which cases PCID is being used.

As the non-XPTI case has shown not to perform better with PCID at least
on some machines the default is to use PCID only for domains subject to
XPTI.

With PCID enabled we always disable global pages. This avoids having to
either flush the complete TLB or do a cycle through all PCID values
when invalidating a single global page.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 

commit 1a32c9868711b4ee883ebb6f8807e08d70a920be
Author: Juergen Gross 
Date:   Thu Apr 26 13:33:17 2018 +0200

xen/x86: add some cr3 helpers

Add some helper macros to access the address and pcid parts of cr3.

Use those helpers where appropriate.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 

commit a5407c1d8c6c0cac96d3e84e7b2b25b18fa2bf4d
Author: Juergen Gross 
Date:   Thu Apr 26 13:33:16 2018 +0200

xen/x86: convert pv_guest_cr4_to_real_cr4() to a function

pv_guest_cr4_to_real_cr4() is becoming more and more complex. Convert
it from a macro to an ordinary function.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 

commit 065a499f78d5b644fa586e3e66f88949821e4f8c
Author: Juergen Gross 
Date:   Thu Apr 26 

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

2018-05-04 Thread Marek Marczykowski-Górecki
On Fri, May 04, 2018 at 06:13:25PM -0400, Rich Persaud wrote:
> > On May 1, 2018, at 08:53, Jason Cooper  wrote:
> > 
> > add the link to xen-users thread of me talking to myself.  :-))
> > 
> >> On Tue, May 01, 2018 at 12:37:51PM +, Jason Cooper wrote:
> >> When I was first digging into this, I started a thread on xen-users [1],
> >> I've attached my xl-reboot.sh script here so you can see exactly what
> >> I'm attempting to do:
> > 
> > [1] https://marc.info/?l=xen-users=152389443206023=2
> 
> You may want to look at the code (toolstack and/or frontend-backend drivers) 
> for Qubes and OpenXT, both of which use network driver domains and support 
> wired/wireless networks.  
> 
> Operational restart of a measured, non-persistent driver domain (instead of 
> host) is a benefit of Xen disaggregation architectures.

In Qubes, on backend restart, we do equivalent of xl network-detach &&
xl network-attach (as you do in xl-reboot.sh). xl itself doesn't provide
any place to plug such script, but we use libvirt which provide events.
Also, we have full control over domain config (libvirt XML), so don't
need to extract vif list from xenstore...

The problem you describe looks related to
https://lkml.org/lkml/2018/2/28/289, but fix is included in 4.16...
There was also related libxl patch:
https://xen.markmail.org/thread/6qbgmwyjqsshjus7
(but it applies to the case where you first shutdown backend and only
then do xl network-detach)

Do you have xl devd running in your driver domain? Without that xl
network-attach wont work (AFAIR udev isn't used here anymore).

Also note that backend shutdown/restart/crash was a source of many
problems in frontend kernel and toolstack in the past. Even simple
dynamic network-attach/detach sometimes is problematic for the frontend.
Links:
https://github.com/QubesOS/qubes-issues/issues/3657 (frontend kernel
problem)
https://github.com/QubesOS/qubes-issues/issues/1426 (toolstack problem,
+ libvirt)
https://github.com/QubesOS/qubes-issues/issues/975 (frontend kernel
problem)

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

2018-05-04 Thread Rich Persaud
> On May 1, 2018, at 08:53, Jason Cooper  wrote:
> 
> add the link to xen-users thread of me talking to myself.  :-))
> 
>> On Tue, May 01, 2018 at 12:37:51PM +, Jason Cooper wrote:
>> When I was first digging into this, I started a thread on xen-users [1],
>> I've attached my xl-reboot.sh script here so you can see exactly what
>> I'm attempting to do:
> 
> [1] https://marc.info/?l=xen-users=152389443206023=2

You may want to look at the code (toolstack and/or frontend-backend drivers) 
for Qubes and OpenXT, both of which use network driver domains and support 
wired/wireless networks.  

Operational restart of a measured, non-persistent driver domain (instead of 
host) is a benefit of Xen disaggregation architectures.

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

Re: [Xen-devel] [PATCH 0/3] Document intent for supported build platforms and bump min glib to 2.42

2018-05-04 Thread Daniel P . Berrangé
CC'ing xen-devel in case Xen maintainers have a need for something that
will that conflict with this proposal wrt supported build platforms.

On Fri, May 04, 2018 at 05:00:23PM +0100, Daniel P. Berrangé wrote:
> This short series is a followup the discussions around min glib version
> when Olaf found we had accidentally increased the min glib by using a
> newer function:
> 
>   https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg02699.html
> 
> Some key points from that thread
> 
>   - Although we have a docker job that tries to test the min glib
> version is adhered to, that's only run post-build, not by Peter's
> merge tests, nor by patchew.
> 
>   - The docker min glib test failed to detect the problem anyway
> because RHEL had backported the symbol in question.
> 
>   - The docker min glib test only builds with certain configure
> options so isn't foolproof.
> 
>   - The modern distros we implicitly care about have way newer glib
> than 2.22
> 
>   - Peter's OS-X build host previously had 2.22, but after switching
> from fink to homebrew now has 2.56
> 
>   - I suggested following libvirt's lead in writing a policy for how
> we pick supported OS targets to inform maintainers when min versions
> can be increased.
> 
> This series writes such a document largely based on one I wrote for
> libvirt with a few changes, largely around OS-X and *BSD. Note it
> is not meant to be an exhaustive list of distros we'll build on, rather
> a representative selection, so that we can identify the range of 3rd
> party library versions we need to care about. So if your favourite
> distro is missing, dont be alarmed, as it probably ships similar
> vintage software to one of those listed - if not feel free to suggest
> additions.
> 
> Based on that doc and https://repology.org/metapackage/glib/versions,
> I identified that we could feasibly set min glib to 2.42. Note that
> this would be dropping RHEL-6 as a build host (RHEL-6.0 came out in
> 2010 so that's reasonable to drop IMHO). It would still cover 2 major
> Debian versions and 2 most recent Ubuntu LTS (16.04, 18.04, but *not*
> 14.04). This min glib lets us remove almost all our compat code.
> 
> Most interestingly, thanks tothe new min version being greater than
> 2.32, we can now use GLIB_VERSION_MAX_ALLOWED to validate the correct
> API usage according to our min version:
> 
>   
> https://developer.gnome.org/glib/stable/glib-Version-Information.html#GLIB-VERSION-MAX-ALLOWED:CAPS
> 
> This means that *all* our CI jobs & developer builds will be enforcing
> the min version, so means very many more conditionally built features
> will get their build validated against min glib version. This would
> do a much better job of catching mistakes than our min-glib docker
> job, making that obsolete.
> 
> Daniel P. Berrangé (3):
>   qemu-doc: provide details of supported build platforms
>   glib: bump min required glib library version to 2.42
>   glib: enforce the minimum required version and warn about old APIs
> 
>  configure   |   6 +-
>  include/glib-compat.h   | 362 
> ++--
>  qemu-doc.texi   |  68 +
>  tests/test-qmp-event.c  |   2 +-
>  tests/tpm-emu.h |   4 +-
>  tests/vhost-user-test.c |   4 +-
>  trace/simple.c  |   6 +-
>  7 files changed, 123 insertions(+), 329 deletions(-)
> 
> -- 
> 2.14.3
> 

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

[Xen-devel] [xen-unstable-smoke test] 122602: trouble: broken/pass

2018-05-04 Thread osstest service owner
flight 122602 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122602/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-xsm  broken
 test-arm64-arm64-xl-xsm   4 host-install(4)broken REGR. vs. 122587

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

version targeted for testing:
 xen  e38e285a51c805cfeee4693962df23e39b3c3bd7
baseline version:
 xen  4611f529c0e39493a3945641cc161967a864d6b5

Last test of basis   122587  2018-05-03 16:00:26 Z1 days
Testing same since   122602  2018-05-04 18:01:13 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Juergen Gross 
  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  broken  
 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

broken-job test-arm64-arm64-xl-xsm broken
broken-step test-arm64-arm64-xl-xsm host-install(4)

Not pushing.


commit e38e285a51c805cfeee4693962df23e39b3c3bd7
Author: Wei Liu 
Date:   Fri May 4 16:08:04 2018 +0100

docs: fix xpti command line option doc

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

commit 5c81d260c244026ea74632faa3c6d0a00cc76469
Author: Juergen Gross 
Date:   Thu Apr 26 13:33:18 2018 +0200

xen/x86: use PCID feature

Avoid flushing the complete TLB when switching %cr3 for mitigation of
Meltdown by using the PCID feature if available.

We are using 4 PCID values for a 64 bit pv domain subject to XPTI and
2 values for the non-XPTI case:

- guest active and in kernel mode
- guest active and in user mode
- hypervisor active and guest in user mode (XPTI only)
- hypervisor active and guest in kernel mode (XPTI only)

We use PCID only if PCID _and_ INVPCID are supported. With PCID in use
we disable global pages in cr4. A command line parameter controls in
which cases PCID is being used.

As the non-XPTI case has shown not to perform better with PCID at least
on some machines the default is to use PCID only for domains subject to
XPTI.

With PCID enabled we always disable global pages. This avoids having to
either flush the complete TLB or do a cycle through all PCID values
when invalidating a single global page.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 

commit 1a32c9868711b4ee883ebb6f8807e08d70a920be
Author: Juergen Gross 
Date:   Thu Apr 26 13:33:17 2018 +0200

xen/x86: add some cr3 helpers

Add some helper macros to access the address and pcid parts of cr3.

Use those helpers where appropriate.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 

commit a5407c1d8c6c0cac96d3e84e7b2b25b18fa2bf4d
Author: Juergen Gross 
Date:   Thu Apr 26 13:33:16 2018 +0200

xen/x86: convert pv_guest_cr4_to_real_cr4() to a function

pv_guest_cr4_to_real_cr4() is becoming more and more complex. Convert
it from a macro to an ordinary function.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 

commit 065a499f78d5b644fa586e3e66f88949821e4f8c
Author: Juergen Gross 
Date:   Thu Apr 26 13:33:15 2018 +0200

xen/x86: use flag byte for 

[Xen-devel] [PATCH v3 1/8] xen_backend: add grant table helpers

2018-05-04 Thread Paul Durrant
This patch adds grant table helper functions to the xen_backend code to
localize error reporting and use of xen_domid.

The patch also defers the call to xengnttab_open() until just before the
initialise method in XenDevOps is invoked. This method is responsible for
mapping the shared ring. No prior method requires access to the grant table.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 

v2:
 - New in v2
---
 hw/xen/xen_backend.c | 123 ++-
 include/hw/xen/xen_backend.h |  33 
 2 files changed, 144 insertions(+), 12 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 7445b50..50412d6 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -106,6 +106,103 @@ int xen_be_set_state(struct XenDevice *xendev, enum 
xenbus_state state)
 return 0;
 }
 
+void xen_be_set_max_grant_refs(struct XenDevice *xendev,
+   unsigned int nr_refs)
+{
+assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV);
+
+if (xengnttab_set_max_grants(xendev->gnttabdev, nr_refs)) {
+xen_pv_printf(xendev, 0, "xengnttab_set_max_grants failed: %s\n",
+  strerror(errno));
+}
+}
+
+void *xen_be_map_grant_refs(struct XenDevice *xendev, uint32_t *refs,
+unsigned int nr_refs, int prot)
+{
+void *ptr;
+
+assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV);
+
+ptr = xengnttab_map_domain_grant_refs(xendev->gnttabdev, nr_refs,
+  xen_domid, refs, prot);
+if (!ptr) {
+xen_pv_printf(xendev, 0,
+  "xengnttab_map_domain_grant_refs failed: %s\n",
+  strerror(errno));
+}
+
+return ptr;
+}
+
+void xen_be_unmap_grant_refs(struct XenDevice *xendev, void *ptr,
+ unsigned int nr_refs)
+{
+assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV);
+
+if (xengnttab_unmap(xendev->gnttabdev, ptr, nr_refs)) {
+xen_pv_printf(xendev, 0, "xengnttab_unmap failed: %s\n",
+  strerror(errno));
+}
+}
+
+int xen_be_copy_grant_refs(struct XenDevice *xendev,
+   bool to_domain,
+   XenGrantCopySegment segs[],
+   unsigned int nr_segs)
+{
+xengnttab_grant_copy_segment_t *xengnttab_segs;
+unsigned int i;
+int rc;
+
+assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV);
+
+xengnttab_segs = g_new0(xengnttab_grant_copy_segment_t, nr_segs);
+
+for (i = 0; i < nr_segs; i++) {
+XenGrantCopySegment *seg = [i];
+xengnttab_grant_copy_segment_t *xengnttab_seg = _segs[i];
+
+if (to_domain) {
+xengnttab_seg->flags = GNTCOPY_dest_gref;
+xengnttab_seg->dest.foreign.domid = xen_domid;
+xengnttab_seg->dest.foreign.ref = seg->dest.foreign.ref;
+xengnttab_seg->dest.foreign.offset = seg->dest.foreign.offset;
+xengnttab_seg->source.virt = seg->source.virt;
+} else {
+xengnttab_seg->flags = GNTCOPY_source_gref;
+xengnttab_seg->source.foreign.domid = xen_domid;
+xengnttab_seg->source.foreign.ref = seg->source.foreign.ref;
+xengnttab_seg->source.foreign.offset =
+seg->source.foreign.offset;
+xengnttab_seg->dest.virt = seg->dest.virt;
+}
+
+xengnttab_seg->len = seg->len;
+}
+
+rc = xengnttab_grant_copy(xendev->gnttabdev, nr_segs, xengnttab_segs);
+
+if (rc) {
+xen_pv_printf(xendev, 0, "xengnttab_copy failed: %s\n",
+  strerror(errno));
+}
+
+for (i = 0; i < nr_segs; i++) {
+xengnttab_grant_copy_segment_t *xengnttab_seg =
+_segs[i];
+
+if (xengnttab_seg->status != GNTST_okay) {
+xen_pv_printf(xendev, 0, "segment[%u] status: %d\n", i,
+  xengnttab_seg->status);
+rc = -1;
+}
+}
+
+g_free(xengnttab_segs);
+return rc;
+}
+
 /*
  * get xen backend device, allocate a new one if it doesn't exist.
  */
@@ -149,18 +246,6 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 }
 qemu_set_cloexec(xenevtchn_fd(xendev->evtchndev));
 
-if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
-xendev->gnttabdev = xengnttab_open(NULL, 0);
-if (xendev->gnttabdev == NULL) {
-xen_pv_printf(NULL, 0, "can't open gnttab device\n");
-xenevtchn_close(xendev->evtchndev);
-qdev_unplug(DEVICE(xendev), NULL);
-return NULL;
-}
-} else {
-xendev->gnttabdev = NULL;
-}
-
 xen_pv_insert_xendev(xendev);
 
 if (xendev->ops->alloc) {
@@ -322,6 +407,16 @@ static int xen_be_try_initialise(struct XenDevice *xendev)
 }
 }
 
+

[Xen-devel] [PATCH v3 5/8] xen_disk: remove use of grant map/unmap

2018-05-04 Thread Paul Durrant
Now that the (native or emulated) xen_be_copy_grant_refs() helper is
always available, the xen_disk code can be significantly simplified by
removing direct use of grant map and unmap operations.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 

v2:
 - Squashed in separate patche removing persistent grant use
 - Re-based
---
 hw/block/xen_disk.c | 370 
 1 file changed, 25 insertions(+), 345 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 66ed2b7..28be8b6 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -36,27 +36,9 @@
 
 /* - */
 
-static int batch_maps   = 0;
-
-/* - */
-
 #define BLOCK_SIZE  512
 #define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_REQUEST + 2)
 
-struct PersistentGrant {
-void *page;
-struct XenBlkDev *blkdev;
-};
-
-typedef struct PersistentGrant PersistentGrant;
-
-struct PersistentRegion {
-void *addr;
-int num;
-};
-
-typedef struct PersistentRegion PersistentRegion;
-
 struct ioreq {
 blkif_request_t req;
 int16_t status;
@@ -65,14 +47,11 @@ struct ioreq {
 off_t   start;
 QEMUIOVectorv;
 int presync;
-uint8_t mapped;
 
 /* grant mapping */
 uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-int prot;
 void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 void*pages;
-int num_unmap;
 
 /* aio status */
 int aio_inflight;
@@ -103,7 +82,6 @@ struct XenBlkDev {
 int protocol;
 blkif_back_rings_t  rings;
 int more_work;
-int cnt_map;
 
 /* request lists */
 QLIST_HEAD(inflight_head, ioreq) inflight;
@@ -114,13 +92,7 @@ struct XenBlkDev {
 int requests_finished;
 unsigned intmax_requests;
 
-/* Persistent grants extension */
 gbooleanfeature_discard;
-gbooleanfeature_persistent;
-GTree   *persistent_gnts;
-GSList  *persistent_regions;
-unsigned intpersistent_gnt_count;
-unsigned intmax_grants;
 
 /* qemu block driver */
 DriveInfo   *dinfo;
@@ -139,10 +111,8 @@ static void ioreq_reset(struct ioreq *ioreq)
 ioreq->status = 0;
 ioreq->start = 0;
 ioreq->presync = 0;
-ioreq->mapped = 0;
 
 memset(ioreq->refs, 0, sizeof(ioreq->refs));
-ioreq->prot = 0;
 memset(ioreq->page, 0, sizeof(ioreq->page));
 ioreq->pages = NULL;
 
@@ -156,37 +126,6 @@ static void ioreq_reset(struct ioreq *ioreq)
 qemu_iovec_reset(>v);
 }
 
-static gint int_cmp(gconstpointer a, gconstpointer b, gpointer user_data)
-{
-uint ua = GPOINTER_TO_UINT(a);
-uint ub = GPOINTER_TO_UINT(b);
-return (ua > ub) - (ua < ub);
-}
-
-static void destroy_grant(gpointer pgnt)
-{
-PersistentGrant *grant = pgnt;
-struct XenBlkDev *blkdev = grant->blkdev;
-struct XenDevice *xendev = >xendev;
-
-xen_be_unmap_grant_ref(xendev, grant->page);
-grant->blkdev->persistent_gnt_count--;
-xen_pv_printf(xendev, 3, "unmapped grant %p\n", grant->page);
-g_free(grant);
-}
-
-static void remove_persistent_region(gpointer data, gpointer dev)
-{
-PersistentRegion *region = data;
-struct XenBlkDev *blkdev = dev;
-struct XenDevice *xendev = >xendev;
-
-xen_be_unmap_grant_refs(xendev, region->addr, region->num);
-xen_pv_printf(xendev, 3, "unmapped grant region %p with %d pages\n",
-  region->addr, region->num);
-g_free(region);
-}
-
 static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
 {
 struct ioreq *ioreq = NULL;
@@ -254,7 +193,6 @@ static int ioreq_parse(struct ioreq *ioreq)
   ioreq->req.handle, ioreq->req.id, ioreq->req.sector_number);
 switch (ioreq->req.operation) {
 case BLKIF_OP_READ:
-ioreq->prot = PROT_WRITE; /* to memory */
 break;
 case BLKIF_OP_FLUSH_DISKCACHE:
 ioreq->presync = 1;
@@ -263,7 +201,6 @@ static int ioreq_parse(struct ioreq *ioreq)
 }
 /* fall through */
 case BLKIF_OP_WRITE:
-ioreq->prot = PROT_READ; /* from memory */
 break;
 case BLKIF_OP_DISCARD:
 return 0;
@@ -310,173 +247,6 @@ err:
 return -1;
 }
 
-static void ioreq_unmap(struct ioreq *ioreq)
-{
-struct XenBlkDev *blkdev = ioreq->blkdev;
-struct XenDevice *xendev = >xendev;
-int i;
-
-if (ioreq->num_unmap == 0 || ioreq->mapped == 0) {
-return;
-}
-if (batch_maps) {
-if (!ioreq->pages) {
-return;
-}
- 

[Xen-devel] [PATCH v3 6/8] xen_backend: make the xen_feature_grant_copy flag private

2018-05-04 Thread Paul Durrant
There is no longer any use of this flag outside of the xen_backend code.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 

v2:
 - New in v2
---
 hw/xen/xen_backend.c | 2 +-
 include/hw/xen/xen_backend.h | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 3c3fc2c..9a8e877 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -44,9 +44,9 @@ BusState *xen_sysbus;
 /* public */
 struct xs_handle *xenstore = NULL;
 const char *xen_protocol;
-bool xen_feature_grant_copy;
 
 /* private */
+static bool xen_feature_grant_copy;
 static int debug;
 
 int xenstore_write_be_str(struct XenDevice *xendev, const char *node, const 
char *val)
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 29bf1c3..9c17fdd 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -16,7 +16,6 @@
 /* variables */
 extern struct xs_handle *xenstore;
 extern const char *xen_protocol;
-extern bool xen_feature_grant_copy;
 extern DeviceState *xen_sysdev;
 extern BusState *xen_sysbus;
 
-- 
2.1.4


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

[Xen-devel] [PATCH v3 0/8] xen_disk: legacy code removal and cleanup

2018-05-04 Thread Paul Durrant
The grant copy operation was added to libxengnttab in Xen 4.8.0 (released
nearly 18 months ago) but the xen_disk PV backend QEMU is still carrying
a significant amount of code purely to remain compatible with older
versions of Xen.

As can be inferred from the diff stats below, removing this support for
older versions of Xen from QEMU reduces the size of the xen_disk source by
around 320 lines (~25%).
 
This versionseries maintains compatibility with older Xen, and OS
not supporting the grant copy operation, by adding an emulation of it
into the xen_backend code. Thus xen_disk can be simplified without
regressing support for any environment. This series also performs
general cleanup of the code by introducing and consistently using
helper functions for calling into libxenttab.

Paul Durrant (8):
  xen_backend: add grant table helpers
  xen_disk: remove open-coded use of libxengnttab
  xen: remove other open-coded use of libxengnttab
  xen_backend: add an emulation of grant copy
  xen_disk: remove use of grant map/unmap
  xen_backend: make the xen_feature_grant_copy flag private
  xen_disk: use a single entry iovec
  xen_disk: be consistent with use of xendev and blkdev->xendev

 hw/9pfs/xen-9p-backend.c |  32 ++-
 hw/block/xen_disk.c  | 614 +++
 hw/char/xen_console.c|   9 +-
 hw/net/xen_nic.c |  34 ++-
 hw/usb/xen-usb.c |  37 ++-
 hw/xen/xen_backend.c | 178 -
 include/hw/xen/xen_backend.h |  34 ++-
 7 files changed, 351 insertions(+), 587 deletions(-)
---
Cc: Anthony Perard 
Cc: Gerd Hoffmann 
Cc: Greg Kurz 
Cc: Jason Wang 
Cc: Kevin Wolf 
Cc: Max Reitz 
Cc: Paolo Bonzini 
Cc: Stefano Stabellini 

-- 
2.1.4


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

[Xen-devel] [PATCH v3 2/8] xen_disk: remove open-coded use of libxengnttab

2018-05-04 Thread Paul Durrant
Now that helpers are present in xen_backend, this patch removes open-coded
calls to libxengnttab from the xen_disk code.

This patch also fixes one whitspace error in the assignment of the
XenDevOps initialise method.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 

v2:
 - New in v2
---
 hw/block/xen_disk.c | 122 ++--
 1 file changed, 32 insertions(+), 90 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index f74fcd4..66ed2b7 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -68,7 +68,6 @@ struct ioreq {
 uint8_t mapped;
 
 /* grant mapping */
-uint32_tdomids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 int prot;
 void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
@@ -142,7 +141,6 @@ static void ioreq_reset(struct ioreq *ioreq)
 ioreq->presync = 0;
 ioreq->mapped = 0;
 
-memset(ioreq->domids, 0, sizeof(ioreq->domids));
 memset(ioreq->refs, 0, sizeof(ioreq->refs));
 ioreq->prot = 0;
 memset(ioreq->page, 0, sizeof(ioreq->page));
@@ -168,16 +166,12 @@ static gint int_cmp(gconstpointer a, gconstpointer b, 
gpointer user_data)
 static void destroy_grant(gpointer pgnt)
 {
 PersistentGrant *grant = pgnt;
-xengnttab_handle *gnt = grant->blkdev->xendev.gnttabdev;
+struct XenBlkDev *blkdev = grant->blkdev;
+struct XenDevice *xendev = >xendev;
 
-if (xengnttab_unmap(gnt, grant->page, 1) != 0) {
-xen_pv_printf(>blkdev->xendev, 0,
-  "xengnttab_unmap failed: %s\n",
-  strerror(errno));
-}
+xen_be_unmap_grant_ref(xendev, grant->page);
 grant->blkdev->persistent_gnt_count--;
-xen_pv_printf(>blkdev->xendev, 3,
-  "unmapped grant %p\n", grant->page);
+xen_pv_printf(xendev, 3, "unmapped grant %p\n", grant->page);
 g_free(grant);
 }
 
@@ -185,15 +179,10 @@ static void remove_persistent_region(gpointer data, 
gpointer dev)
 {
 PersistentRegion *region = data;
 struct XenBlkDev *blkdev = dev;
-xengnttab_handle *gnt = blkdev->xendev.gnttabdev;
+struct XenDevice *xendev = >xendev;
 
-if (xengnttab_unmap(gnt, region->addr, region->num) != 0) {
-xen_pv_printf(>xendev, 0,
-  "xengnttab_unmap region %p failed: %s\n",
-  region->addr, strerror(errno));
-}
-xen_pv_printf(>xendev, 3,
-  "unmapped grant region %p with %d pages\n",
+xen_be_unmap_grant_refs(xendev, region->addr, region->num);
+xen_pv_printf(xendev, 3, "unmapped grant region %p with %d pages\n",
   region->addr, region->num);
 g_free(region);
 }
@@ -304,7 +293,6 @@ static int ioreq_parse(struct ioreq *ioreq)
 goto err;
 }
 
-ioreq->domids[i] = blkdev->xendev.dom;
 ioreq->refs[i]   = ioreq->req.seg[i].gref;
 
 mem = ioreq->req.seg[i].first_sect * blkdev->file_blk;
@@ -324,7 +312,8 @@ err:
 
 static void ioreq_unmap(struct ioreq *ioreq)
 {
-xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
+struct XenBlkDev *blkdev = ioreq->blkdev;
+struct XenDevice *xendev = >xendev;
 int i;
 
 if (ioreq->num_unmap == 0 || ioreq->mapped == 0) {
@@ -334,11 +323,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
 if (!ioreq->pages) {
 return;
 }
-if (xengnttab_unmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
-xen_pv_printf(>blkdev->xendev, 0,
-  "xengnttab_unmap failed: %s\n",
-  strerror(errno));
-}
+xen_be_unmap_grant_refs(xendev, ioreq->pages, ioreq->num_unmap);
 ioreq->blkdev->cnt_map -= ioreq->num_unmap;
 ioreq->pages = NULL;
 } else {
@@ -346,11 +331,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
 if (!ioreq->page[i]) {
 continue;
 }
-if (xengnttab_unmap(gnt, ioreq->page[i], 1) != 0) {
-xen_pv_printf(>blkdev->xendev, 0,
-  "xengnttab_unmap failed: %s\n",
-  strerror(errno));
-}
+xen_be_unmap_grant_ref(xendev, ioreq->page[i]);
 ioreq->blkdev->cnt_map--;
 ioreq->page[i] = NULL;
 }
@@ -360,14 +341,14 @@ static void ioreq_unmap(struct ioreq *ioreq)
 
 static int ioreq_map(struct ioreq *ioreq)
 {
-xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
-uint32_t domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+struct XenBlkDev *blkdev = ioreq->blkdev;
+struct XenDevice *xendev = >xendev;
 uint32_t refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
  

[Xen-devel] [PATCH v3 3/8] xen: remove other open-coded use of libxengnttab

2018-05-04 Thread Paul Durrant
Now that helpers are available in xen_backend, use them throughout all
Xen PV backends.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Greg Kurz 
Cc: Paolo Bonzini 
Cc: Jason Wang 
Cc: Gerd Hoffmann 

v2:
 - New in v2
---
 hw/9pfs/xen-9p-backend.c | 32 +++-
 hw/char/xen_console.c|  9 -
 hw/net/xen_nic.c | 34 +++---
 hw/usb/xen-usb.c | 37 +
 4 files changed, 51 insertions(+), 61 deletions(-)

diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index 95e50c4..6026780 100644
--- a/hw/9pfs/xen-9p-backend.c
+++ b/hw/9pfs/xen-9p-backend.c
@@ -331,14 +331,14 @@ static int xen_9pfs_free(struct XenDevice *xendev)
 
 for (i = 0; i < xen_9pdev->num_rings; i++) {
 if (xen_9pdev->rings[i].data != NULL) {
-xengnttab_unmap(xen_9pdev->xendev.gnttabdev,
-xen_9pdev->rings[i].data,
-(1 << xen_9pdev->rings[i].ring_order));
+xen_be_unmap_grant_refs(_9pdev->xendev,
+xen_9pdev->rings[i].data,
+(1 << xen_9pdev->rings[i].ring_order));
 }
 if (xen_9pdev->rings[i].intf != NULL) {
-xengnttab_unmap(xen_9pdev->xendev.gnttabdev,
-xen_9pdev->rings[i].intf,
-1);
+xen_be_unmap_grant_refs(_9pdev->xendev,
+xen_9pdev->rings[i].intf,
+1);
 }
 if (xen_9pdev->rings[i].bh != NULL) {
 qemu_bh_delete(xen_9pdev->rings[i].bh);
@@ -390,11 +390,10 @@ static int xen_9pfs_connect(struct XenDevice *xendev)
 }
 g_free(str);
 
-xen_9pdev->rings[i].intf =  xengnttab_map_grant_ref(
-xen_9pdev->xendev.gnttabdev,
-xen_9pdev->xendev.dom,
-xen_9pdev->rings[i].ref,
-PROT_READ | PROT_WRITE);
+xen_9pdev->rings[i].intf =
+xen_be_map_grant_ref(_9pdev->xendev,
+ xen_9pdev->rings[i].ref,
+ PROT_READ | PROT_WRITE);
 if (!xen_9pdev->rings[i].intf) {
 goto out;
 }
@@ -403,12 +402,11 @@ static int xen_9pfs_connect(struct XenDevice *xendev)
 goto out;
 }
 xen_9pdev->rings[i].ring_order = ring_order;
-xen_9pdev->rings[i].data = xengnttab_map_domain_grant_refs(
-xen_9pdev->xendev.gnttabdev,
-(1 << ring_order),
-xen_9pdev->xendev.dom,
-xen_9pdev->rings[i].intf->ref,
-PROT_READ | PROT_WRITE);
+xen_9pdev->rings[i].data =
+xen_be_map_grant_refs(_9pdev->xendev,
+  xen_9pdev->rings[i].intf->ref,
+  (1 << ring_order),
+  PROT_READ | PROT_WRITE);
 if (!xen_9pdev->rings[i].data) {
 goto out;
 }
diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index bdfaa40..8b4b4bf 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -233,12 +233,11 @@ static int con_initialise(struct XenDevice *xendev)
 if (!xendev->dev) {
 xen_pfn_t mfn = con->ring_ref;
 con->sring = xenforeignmemory_map(xen_fmem, con->xendev.dom,
-  PROT_READ|PROT_WRITE,
+  PROT_READ | PROT_WRITE,
   1, , NULL);
 } else {
-con->sring = xengnttab_map_grant_ref(xendev->gnttabdev, 
con->xendev.dom,
- con->ring_ref,
- PROT_READ|PROT_WRITE);
+con->sring = xen_be_map_grant_ref(xendev, con->ring_ref,
+  PROT_READ | PROT_WRITE);
 }
 if (!con->sring)
return -1;
@@ -267,7 +266,7 @@ static void con_disconnect(struct XenDevice *xendev)
 if (!xendev->dev) {
 xenforeignmemory_unmap(xen_fmem, con->sring, 1);
 } else {
-xengnttab_unmap(xendev->gnttabdev, con->sring, 1);
+xen_be_unmap_grant_ref(xendev, con->sring);
 }
 con->sring = NULL;
 }
diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c
index 20c43a6..73d6f1b 100644
--- a/hw/net/xen_nic.c
+++ b/hw/net/xen_nic.c
@@ -160,9 +160,8 @@ static void net_tx_packets(struct XenNetDev *netdev)
   (txreq.flags & NETTXF_more_data)  ? " more_data" 
 : "",
   (txreq.flags & NETTXF_extra_info) ? " 
extra_info" : "");
 
-page = 

[Xen-devel] [PATCH v3 4/8] xen_backend: add an emulation of grant copy

2018-05-04 Thread Paul Durrant
Not all Xen environments support the xengnttab_grant_copy() operation.
E.g. where the OS is FreeBSD or Xen is older than 4.8.0.

This patch introduces an emulation of that operation using
xengnttab_map_domain_grant_refs() and memcpy() for those environments.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 

v2:
 - New in v2
---
 hw/xen/xen_backend.c | 53 
 1 file changed, 53 insertions(+)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 50412d6..3c3fc2c 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -146,6 +146,55 @@ void xen_be_unmap_grant_refs(struct XenDevice *xendev, 
void *ptr,
 }
 }
 
+static int compat_copy_grant_refs(struct XenDevice *xendev,
+  bool to_domain,
+  XenGrantCopySegment segs[],
+  unsigned int nr_segs)
+{
+uint32_t *refs = g_new(uint32_t, nr_segs);
+int prot = to_domain ? PROT_WRITE : PROT_READ;
+void *pages;
+unsigned int i;
+
+for (i = 0; i < nr_segs; i++) {
+XenGrantCopySegment *seg = [i];
+
+refs[i] = to_domain ?
+seg->dest.foreign.ref : seg->source.foreign.ref;
+}
+
+pages = xengnttab_map_domain_grant_refs(xendev->gnttabdev, nr_segs,
+xen_domid, refs, prot);
+if (!pages) {
+xen_pv_printf(xendev, 0,
+  "xengnttab_map_domain_grant_refs failed: %s\n",
+  strerror(errno));
+g_free(refs);
+return -1;
+}
+
+for (i = 0; i < nr_segs; i++) {
+XenGrantCopySegment *seg = [i];
+void *page = pages + (i * XC_PAGE_SIZE);
+
+if (to_domain) {
+memcpy(page + seg->dest.foreign.offset, seg->source.virt,
+   seg->len);
+} else {
+memcpy(seg->dest.virt, page + seg->source.foreign.offset,
+   seg->len);
+}
+}
+
+if (xengnttab_unmap(xendev->gnttabdev, pages, nr_segs)) {
+xen_pv_printf(xendev, 0, "xengnttab_unmap failed: %s\n",
+  strerror(errno));
+}
+
+g_free(refs);
+return 0;
+}
+
 int xen_be_copy_grant_refs(struct XenDevice *xendev,
bool to_domain,
XenGrantCopySegment segs[],
@@ -157,6 +206,10 @@ int xen_be_copy_grant_refs(struct XenDevice *xendev,
 
 assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV);
 
+if (!xen_feature_grant_copy) {
+return compat_copy_grant_refs(xendev, to_domain, segs, nr_segs);
+}
+
 xengnttab_segs = g_new0(xengnttab_grant_copy_segment_t, nr_segs);
 
 for (i = 0; i < nr_segs; i++) {
-- 
2.1.4


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

[Xen-devel] [PATCH v3 8/8] xen_disk: be consistent with use of xendev and blkdev->xendev

2018-05-04 Thread Paul Durrant
Certain functions in xen_disk are called with a pointer to xendev
(struct XenDevice *). They then use continer_of() to acces the surrounding
blkdev (struct XenBlkDev) but then in various places use >xendev
when use of the original xendev pointer is shorter to express and clearly
equivalent.

This patch is a purely cosmetic patch which makes sure there is a xendev
pointer on stack for any function where the pointer is need on multiple
occasions modified those functions to use it consistently.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 

v2:
 - Re-based
---
 hw/block/xen_disk.c | 90 +++--
 1 file changed, 46 insertions(+), 44 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 28651c5..9fbc0cd 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -178,10 +178,11 @@ static void ioreq_release(struct ioreq *ioreq, bool 
finish)
 static int ioreq_parse(struct ioreq *ioreq)
 {
 struct XenBlkDev *blkdev = ioreq->blkdev;
+struct XenDevice *xendev = >xendev;
 size_t len;
 int i;
 
-xen_pv_printf(>xendev, 3,
+xen_pv_printf(xendev, 3,
   "op %d, nr %d, handle %d, id %" PRId64 ", sector %" PRId64 
"\n",
   ioreq->req.operation, ioreq->req.nr_segments,
   ioreq->req.handle, ioreq->req.id, ioreq->req.sector_number);
@@ -199,28 +200,28 @@ static int ioreq_parse(struct ioreq *ioreq)
 case BLKIF_OP_DISCARD:
 return 0;
 default:
-xen_pv_printf(>xendev, 0, "error: unknown operation (%d)\n",
+xen_pv_printf(xendev, 0, "error: unknown operation (%d)\n",
   ioreq->req.operation);
 goto err;
 };
 
 if (ioreq->req.operation != BLKIF_OP_READ && blkdev->mode[0] != 'w') {
-xen_pv_printf(>xendev, 0, "error: write req for ro device\n");
+xen_pv_printf(xendev, 0, "error: write req for ro device\n");
 goto err;
 }
 
 ioreq->start = ioreq->req.sector_number * blkdev->file_blk;
 for (i = 0; i < ioreq->req.nr_segments; i++) {
 if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
-xen_pv_printf(>xendev, 0, "error: nr_segments too big\n");
+xen_pv_printf(xendev, 0, "error: nr_segments too big\n");
 goto err;
 }
 if (ioreq->req.seg[i].first_sect > ioreq->req.seg[i].last_sect) {
-xen_pv_printf(>xendev, 0, "error: first > last sector\n");
+xen_pv_printf(xendev, 0, "error: first > last sector\n");
 goto err;
 }
 if (ioreq->req.seg[i].last_sect * BLOCK_SIZE >= XC_PAGE_SIZE) {
-xen_pv_printf(>xendev, 0, "error: page crossing\n");
+xen_pv_printf(xendev, 0, "error: page crossing\n");
 goto err;
 }
 
@@ -228,7 +229,7 @@ static int ioreq_parse(struct ioreq *ioreq)
 ioreq->size += len;
 }
 if (ioreq->start + ioreq->size > blkdev->file_size) {
-xen_pv_printf(>xendev, 0, "error: access beyond end of 
file\n");
+xen_pv_printf(xendev, 0, "error: access beyond end of file\n");
 goto err;
 }
 return 0;
@@ -244,7 +245,7 @@ static int ioreq_grant_copy(struct ioreq *ioreq)
 struct XenDevice *xendev = >xendev;
 XenGrantCopySegment segs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 int i, count, rc;
-int64_t file_blk = ioreq->blkdev->file_blk;
+int64_t file_blk = blkdev->file_blk;
 bool to_domain = (ioreq->req.operation == BLKIF_OP_READ);
 void *virt = ioreq->buf;
 
@@ -272,7 +273,7 @@ static int ioreq_grant_copy(struct ioreq *ioreq)
 rc = xen_be_copy_grant_refs(xendev, to_domain, segs, count);
 
 if (rc) {
-xen_pv_printf(>blkdev->xendev, 0,
+xen_pv_printf(xendev, 0,
   "failed to copy data %d\n", rc);
 ioreq->aio_errors++;
 return -1;
@@ -287,11 +288,12 @@ static void qemu_aio_complete(void *opaque, int ret)
 {
 struct ioreq *ioreq = opaque;
 struct XenBlkDev *blkdev = ioreq->blkdev;
+struct XenDevice *xendev = >xendev;
 
 aio_context_acquire(blkdev->ctx);
 
 if (ret != 0) {
-xen_pv_printf(>xendev, 0, "%s I/O error\n",
+xen_pv_printf(xendev, 0, "%s I/O error\n",
   ioreq->req.operation == BLKIF_OP_READ ? "read" : 
"write");
 ioreq->aio_errors++;
 }
@@ -625,16 +627,17 @@ static void blk_alloc(struct XenDevice *xendev)
 
 static void blk_parse_discard(struct XenBlkDev *blkdev)
 {
+struct XenDevice *xendev = >xendev;
 int enable;
 
 blkdev->feature_discard = true;
 
-if (xenstore_read_be_int(>xendev, "discard-enable", ) == 0) 
{
+if (xenstore_read_be_int(xendev, "discard-enable", ) == 0) {
 blkdev->feature_discard = !!enable;
 }
 
 if (blkdev->feature_discard) {
-

[Xen-devel] [PATCH v3 7/8] xen_disk: use a single entry iovec

2018-05-04 Thread Paul Durrant
Since xen_disk now always copies data to and from a guest there is no need
to maintain a vector entry corresponding to every page of a request.
This means there is less per-request state to maintain so the ioreq
structure can shrink significantly.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 

v3:
 - Un-break by fixing mis-placed qemu_iovec_add()

v2:
 - Re-based
---
 hw/block/xen_disk.c | 76 +++--
 1 file changed, 21 insertions(+), 55 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 28be8b6..28651c5 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -46,13 +46,10 @@ struct ioreq {
 /* parsed request */
 off_t   start;
 QEMUIOVectorv;
+void*buf;
+size_t  size;
 int presync;
 
-/* grant mapping */
-uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-void*pages;
-
 /* aio status */
 int aio_inflight;
 int aio_errors;
@@ -110,12 +107,10 @@ static void ioreq_reset(struct ioreq *ioreq)
 memset(>req, 0, sizeof(ioreq->req));
 ioreq->status = 0;
 ioreq->start = 0;
+ioreq->buf = NULL;
+ioreq->size = 0;
 ioreq->presync = 0;
 
-memset(ioreq->refs, 0, sizeof(ioreq->refs));
-memset(ioreq->page, 0, sizeof(ioreq->page));
-ioreq->pages = NULL;
-
 ioreq->aio_inflight = 0;
 ioreq->aio_errors = 0;
 
@@ -138,7 +133,7 @@ static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
 ioreq = g_malloc0(sizeof(*ioreq));
 ioreq->blkdev = blkdev;
 blkdev->requests_total++;
-qemu_iovec_init(>v, BLKIF_MAX_SEGMENTS_PER_REQUEST);
+qemu_iovec_init(>v, 1);
 } else {
 /* get one from freelist */
 ioreq = QLIST_FIRST(>freelist);
@@ -183,7 +178,6 @@ static void ioreq_release(struct ioreq *ioreq, bool finish)
 static int ioreq_parse(struct ioreq *ioreq)
 {
 struct XenBlkDev *blkdev = ioreq->blkdev;
-uintptr_t mem;
 size_t len;
 int i;
 
@@ -230,13 +224,10 @@ static int ioreq_parse(struct ioreq *ioreq)
 goto err;
 }
 
-ioreq->refs[i]   = ioreq->req.seg[i].gref;
-
-mem = ioreq->req.seg[i].first_sect * blkdev->file_blk;
 len = (ioreq->req.seg[i].last_sect - ioreq->req.seg[i].first_sect + 1) 
* blkdev->file_blk;
-qemu_iovec_add(>v, (void*)mem, len);
+ioreq->size += len;
 }
-if (ioreq->start + ioreq->v.size > blkdev->file_size) {
+if (ioreq->start + ioreq->size > blkdev->file_size) {
 xen_pv_printf(>xendev, 0, "error: access beyond end of 
file\n");
 goto err;
 }
@@ -247,35 +238,6 @@ err:
 return -1;
 }
 
-static void ioreq_free_copy_buffers(struct ioreq *ioreq)
-{
-int i;
-
-for (i = 0; i < ioreq->v.niov; i++) {
-ioreq->page[i] = NULL;
-}
-
-qemu_vfree(ioreq->pages);
-}
-
-static int ioreq_init_copy_buffers(struct ioreq *ioreq)
-{
-int i;
-
-if (ioreq->v.niov == 0) {
-return 0;
-}
-
-ioreq->pages = qemu_memalign(XC_PAGE_SIZE, ioreq->v.niov * XC_PAGE_SIZE);
-
-for (i = 0; i < ioreq->v.niov; i++) {
-ioreq->page[i] = ioreq->pages + i * XC_PAGE_SIZE;
-ioreq->v.iov[i].iov_base = ioreq->page[i];
-}
-
-return 0;
-}
-
 static int ioreq_grant_copy(struct ioreq *ioreq)
 {
 struct XenBlkDev *blkdev = ioreq->blkdev;
@@ -284,25 +246,27 @@ static int ioreq_grant_copy(struct ioreq *ioreq)
 int i, count, rc;
 int64_t file_blk = ioreq->blkdev->file_blk;
 bool to_domain = (ioreq->req.operation == BLKIF_OP_READ);
+void *virt = ioreq->buf;
 
-if (ioreq->v.niov == 0) {
+if (ioreq->req.nr_segments == 0) {
 return 0;
 }
 
-count = ioreq->v.niov;
+count = ioreq->req.nr_segments;
 
 for (i = 0; i < count; i++) {
 if (to_domain) {
-segs[i].dest.foreign.ref = ioreq->refs[i];
+segs[i].dest.foreign.ref = ioreq->req.seg[i].gref;
 segs[i].dest.foreign.offset = ioreq->req.seg[i].first_sect * 
file_blk;
-segs[i].source.virt = ioreq->v.iov[i].iov_base;
+segs[i].source.virt = virt;
 } else {
-segs[i].source.foreign.ref = ioreq->refs[i];
+segs[i].source.foreign.ref = ioreq->req.seg[i].gref;
 segs[i].source.foreign.offset = ioreq->req.seg[i].first_sect * 
file_blk;
-segs[i].dest.virt = ioreq->v.iov[i].iov_base;
+segs[i].dest.virt = virt;
 }
 segs[i].len = (ioreq->req.seg[i].last_sect
- ioreq->req.seg[i].first_sect + 1) * file_blk;
+virt += segs[i].len;
 }
 
 rc = 

Re: [Xen-devel] [PATCH for-4.11] x86/pv: Unconditionally hide EFER.SVME from PV guests

2018-05-04 Thread Andrew Cooper
On 04/05/18 19:45, Boris Ostrovsky wrote:
> On 05/04/2018 01:28 PM, Andrew Cooper wrote:
>> --- a/xen/include/asm-x86/msr-index.h
>> +++ b/xen/include/asm-x86/msr-index.h
>> @@ -31,6 +31,9 @@
>>  #define EFER_LMSLE  (1<<_EFER_LMSLE)
>>  #define EFER_FFXSE  (1<<_EFER_FFXSE)
>>  
>> +#define EFER_KNOWN_MASK (EFER_SCE | EFER_LME | EFER_LMA | 
>> EFER_NX | \
>
> I think there is an extra tab here (but this may be my email client not
> showing it properly)

Its correct in the file, but renders incorrectly everywhere else.  (I
did a doubletake the first time I saw the email.)

> Reviewed-by: Boris Ostrovsky 

Thanks,

~Andrew

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

Re: [Xen-devel] [PATCH for-4.11] x86/pv: Unconditionally hide EFER.SVME from PV guests

2018-05-04 Thread Boris Ostrovsky
On 05/04/2018 01:28 PM, Andrew Cooper wrote:
> --- a/xen/include/asm-x86/msr-index.h
> +++ b/xen/include/asm-x86/msr-index.h
> @@ -31,6 +31,9 @@
>  #define EFER_LMSLE   (1<<_EFER_LMSLE)
>  #define EFER_FFXSE   (1<<_EFER_FFXSE)
>  
> +#define EFER_KNOWN_MASK  (EFER_SCE | EFER_LME | EFER_LMA | 
> EFER_NX | \


I think there is an extra tab here (but this may be my email client not
showing it properly)

Reviewed-by: Boris Ostrovsky 



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

Re: [Xen-devel] [PATCH v3 0/2] SVM: guest state handling adjustments

2018-05-04 Thread Boris Ostrovsky
On 05/04/2018 11:07 AM, Jan Beulich wrote:
> Only patch 1 is clearly meant for 4.11. The second patch, however, eliminates
> a (theoretical) window the first patch still leaves, so should at least be 
> considered.
> Furthermore previous discussion suggests that it might even be desirable to 
> fold
> both patches into one (or swap their order).
>
> 1: re-work VMCB sync-ing
> 2: introduce a VM entry helper
>
> Signed-off-by: Jan Beulich 
>
>


Reviewed-by: Boris Ostrovsky 

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

Re: [Xen-devel] [PATCH v3 0/2] SVM: guest state handling adjustments

2018-05-04 Thread Andrew Cooper
On 04/05/18 16:07, Jan Beulich wrote:
> Only patch 1 is clearly meant for 4.11. The second patch, however, eliminates
> a (theoretical) window the first patch still leaves, so should at least be 
> considered.
> Furthermore previous discussion suggests that it might even be desirable to 
> fold
> both patches into one (or swap their order).
>
> 1: re-work VMCB sync-ing
> 2: introduce a VM entry helper
>
> Signed-off-by: Jan Beulich 

As this is fixing a real bug and we're getting quite late in 4.11 at
this point, Acked-by: Andrew Cooper 

I'm still not happy with the API, and especially that
"svm_sync_vmcb(curr, vmcb_needs_vmsave);" in patch two does not do the
intuitive thing.  That said, I'm going to need to rewrite this anyway in
4.12 to get the MSR infrastructure working, so this code isn't going to
stay long.

~Andrew

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

Re: [Xen-devel] [PATCH for-4.11 v3 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

2018-05-04 Thread Ian Jackson
Thanks.  This is much better :-).  I have reviewed this for style,
obvious bugs, and the semantics in the doc comment.  I haven't tried
to follow the algorithm in detail, but I reckon it's probably OK.

I have reordered the patch (and hence the file) to make the grouping
of my comments make more sense.

Lars Kurth writes ("[PATCH for-4.11 v3 1/1] Add new add_maintainers.pl script 
to optimise the workflow when using git format-patch with get_maintainer.pl"):
> +  --inspatch (top|ccbody|cc---|none) | -p (top|ccbody|cc---|none)
> +Insert email addresses into *.patch files according to the POLICY
> +See section POLICY:
> +  --inscover (top|ccend|none) | -c (top|ccend|none)
> +Insert email addresses into cover letteraccording to the POLICY
> +See section PROCESSING POLICY:

I'm afraid that I don't understand which addresses are added where,
from the documentation.  In particular, what happens without --tags or
--tagscc ?  Also you should define `tag'; it has a lot of different
meanings, some subtly different, and it is not completely clear which
one you mean.

I think you should formally state the default behaviour.  Something
like:

  By default:
  * get_maintainer is called on each patch to find email addresses
of maintainers/reviewers for that patch; these are added
to the patch body near the CC section.
  * further email addresses are found in each patch's commit
message tags (CC, signed-off-by, reviewed-by, etc.)
  * All of the above addresses are added to the CC mail headers
of each patch
  * All of the above addresses are added to the CC mail headers
of the cover letter

I suspect that what I have above is not the real behaviour.  You
should write what is true in that kind of style :-).

> +my $patch_prefix = "0"; # Use a 0, such that v* does not get picked up
> +# Obviously this will only work for series with
> +# < 999 patches, which should be fine

I don't understand the purpose of this:

> +if ($rerollcount > 0) {
> +$patch_prefix = "v".$rerollcount;
> +}
...
> +my $pattern = $patch_dir.'/'.$patch_prefix.'*'.$patch_ext;
> +print "Then perform:\n".
> +  "git send-email -to xen-devel\@lists.xenproject.org ".
> +  $patch_dir.'/'.$patch_prefix."*.patch"."\n";

What files matching *.patch exist here that should not be processed ?
If the answer is none then $patch_prefix is redundant, I think ?


> +foreach my $file (@patches) {
> +if ($file =~ /\Q$cover_letter\E/) {

I know you had me look at this over your shoulder and I said it was
right, but I think in fact this would match hypothetical files
 $patch_dir/0020-do-something-about--cover-letter.patch

I think you need to expect a /.  So one of

  +if ($file =~ /\/\Q$cover_letter\E/) {
  +if ($file =~ m{/\Q$cover_letter\E}) {

> +print "Then perform:\n".
> +  "git send-email -to xen-devel\@lists.xenproject.org ".
> +  $patch_dir.'/'.$patch_prefix."*.patch"."\n";
> +
> +exit 0;
> +
> +my $readmailinglists = 0;
> +my @mailinglists = ();

This is a very curious structure.  These assignments are never
executed (but I guess the program works anyway).  I would recommend
moving the main program to the bottom of the file.

> +sub getmailinglists () {
> +   # Read mailing list from MAINTAINERS file and copy
> +   # a list of e-mail addresses to @mailinglists
> +if (!$readmailinglists) {

I suggest you rename this variable $getmailinglists_done or
something.  As it is it is confusing because `read' might be the
present tense, but then the sense is wrong.

Also, you might find it better to use a structure like one of
  if ($getmailingslists_done) { return; }
  return if $getmailingslists_done;

> +if (-e $maintainers) {
...
> +print "Warning: Mailing lists will be treated as CC's\n";
> +}
> +# Don't try again, even if the MAINTAINERS file does not exist
> +$readmailinglists = 1;
> +# Remove any duplicates
> +@mailinglists = uniq @mailinglists;
> +}

Indentation here is misleading.  (But this will go away if you adopt
my suggestion above).

> +sub ismailinglist ($) {
> +my ($check) = @_;
> +# Get the mailing list information
> +getmailinglists();
> +# Do the check
> +if ( grep { $_ eq $check} @mailinglists) {

Rather than uniq above, and then grep here, you could use a hash
%mailinglists.  That would be more idiomatic and also less code and
faster.  But as it is is tolerable.

> +sub getmaintainers ($$$) {
> +my ($file, $rto, $rcc) = @_;
> +my $get_maintainer_args = join " ", @get_maintainer_args;
> +my $cmd = "$get_maintainer $get_maintainer_args <$file";
...
> +open($fh, "-|", $cmd)
> +or die "Failed to open '$cmd'\n";

You should use the array form of piped open, rather than this string
joining.  That way arguments containing spaces make their way through
correct.

> +if (! -e $get_maintainer) {
> +die "$tool: The tool requires 

[Xen-devel] [PATCH for-4.11] x86/pv: Unconditionally hide EFER.SVME from PV guests

2018-05-04 Thread Andrew Cooper
We don't advertise SVM in CPUID so a PV guest shouldn't be under the
impression that it can use SVM functionality, but despite this, it really
shouldn't see SVME set when reading EFER.

Introduce EFER_KNOWN_MASK to whitelist the features Xen knows about, and use
this to clamp the guests view.

Take the opportunity to reuse the mask to simplify svm_vmcb_isvalid(), and
change "undefined" to "unknown" in the print message, as there is at least
EFER.TCE (Translation Cache Extension) defined but unknown to Xen.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
CC: Brian Woods 
CC: Juergen Gross 

Arguably, this wants backporting to the stable trees, so should be considered
for 4.11 at this point.
---
 xen/arch/x86/hvm/svm/svmdebug.c | 5 ++---
 xen/arch/x86/pv/emul-priv-op.c  | 4 +++-
 xen/include/asm-x86/msr-index.h | 3 +++
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c
index 6c215d1..d35e405 100644
--- a/xen/arch/x86/hvm/svm/svmdebug.c
+++ b/xen/arch/x86/hvm/svm/svmdebug.c
@@ -133,9 +133,8 @@ bool svm_vmcb_isvalid(const char *from, const struct 
vmcb_struct *vmcb,
 PRINTF("DR7: bits [63:32] are not zero (%#"PRIx64")\n",
vmcb_get_dr7(vmcb));
 
-if ( efer & ~(EFER_SCE | EFER_LME | EFER_LMA | EFER_NX | EFER_SVME |
-  EFER_LMSLE | EFER_FFXSE) )
-PRINTF("EFER: undefined bits are not zero (%#"PRIx64")\n", efer);
+if ( efer & ~EFER_KNOWN_MASK )
+PRINTF("EFER: unknown bits are not zero (%#"PRIx64")\n", efer);
 
 if ( hvm_efer_valid(v, efer, -1) )
 PRINTF("EFER: %s (%"PRIx64")\n", hvm_efer_valid(v, efer, -1), efer);
diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 15f42b3..8293f31 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -867,7 +867,9 @@ static int read_msr(unsigned int reg, uint64_t *val,
 return X86EMUL_OKAY;
 
 case MSR_EFER:
-*val = read_efer();
+/* Hide unknown bits, and unconditionally hide SVME from guests. */
+*val = read_efer() & EFER_KNOWN_MASK & ~EFER_SVME;
+/* Hide the 64-bit features from 32-bit guests. */
 if ( is_pv_32bit_domain(currd) )
 *val &= ~(EFER_LME | EFER_LMA | EFER_LMSLE);
 return X86EMUL_OKAY;
diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
index c9f44eb..6d94d65 100644
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -31,6 +31,9 @@
 #define EFER_LMSLE (1<<_EFER_LMSLE)
 #define EFER_FFXSE (1<<_EFER_FFXSE)
 
+#define EFER_KNOWN_MASK(EFER_SCE | EFER_LME | EFER_LMA | 
EFER_NX | \
+EFER_SVME | EFER_LMSLE | EFER_FFXSE)
+
 /* Speculation Controls. */
 #define MSR_SPEC_CTRL  0x0048
 #define SPEC_CTRL_IBRS (_AC(1, ULL) << 0)
-- 
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 6/7] xen/x86/efi: Verify dom0 kernel with SHIM_LOCK protocol in efi_multiboot2()

2018-05-04 Thread Jan Beulich
>>> On 08.07.17 at 23:53,  wrote:
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -383,9 +383,13 @@ __efi64_mb2_start:
>  jmp x86_32_switch
>  
>  .Lefi_multiboot2_proto:
> -/* Zero EFI SystemTable and EFI ImageHandle addresses. */
> +/*
> + * Zero EFI SystemTable, EFI ImageHandle and
> + * dom0 kernel module struct addresses.
> + */
>  xor %esi,%esi
>  xor %edi,%edi
> +xor %r14d,%r14d
>  
>  /* Skip Multiboot2 information fixed part. */
>  lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx
> @@ -423,6 +427,15 @@ __efi64_mb2_start:
>  cmove   MB2_efi64_ih(%rcx),%rdi
>  je  .Lefi_mb2_next_tag
>  
> +/* Get dom0 kernel module struct address from Multiboot2 
> information. */
> +cmpl$MULTIBOOT2_TAG_TYPE_MODULE,MB2_tag_type(%rcx)
> +jne .Lefi_mb2_end
> +
> +test%r14d,%r14d
> +cmovz   %ecx,%r14d
> +jmp .Lefi_mb2_next_tag
> +
> +.Lefi_mb2_end:
>  /* Is it the end of Multiboot2 information? */
>  cmpl$MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%rcx)
>  je  .Lrun_bs
> @@ -484,9 +497,12 @@ __efi64_mb2_start:
>  /* Keep the stack aligned. Do not pop a single item off it. */
>  mov (%rsp),%rdi
>  
> +mov %r14d,%edx
> +
>  /*
>   * efi_multiboot2() is called according to System V AMD64 ABI:
> - *   - IN:  %rdi - EFI ImageHandle, %rsi - EFI SystemTable.
> + *   - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
> + * %rdx - dom0 kernel module struct address.

How come everything further up treats this as a 32-bit quantity only?

> @@ -47,6 +49,7 @@ extern const struct pe_base_relocs {
>  
>  static void __init efi_arch_relocate_image(unsigned long delta)
>  {
> +#if 0
>  const struct pe_base_relocs *base_relocs;
>  
>  for ( base_relocs = __base_relocs_start; base_relocs < 
> __base_relocs_end; )
> @@ -95,6 +98,7 @@ static void __init efi_arch_relocate_image(unsigned long 
> delta)
>  }
>  base_relocs = (const void *)(base_relocs->entries + i + (i & 1));
>  }
> +#endif
>  }

???

> @@ -669,7 +673,9 @@ static bool __init 
> efi_arch_use_config_file(EFI_SYSTEM_TABLE *SystemTable)
>  
>  static void efi_arch_flush_dcache_area(const void *vaddr, UINTN size) { }
>  
> -void __init efi_multiboot2(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
> *SystemTable)
> +void __init efi_multiboot2(EFI_HANDLE ImageHandle,
> +   EFI_SYSTEM_TABLE *SystemTable,
> +   multiboot2_tag_module_t *dom0_kernel)

const?

Jan



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

Re: [Xen-devel] [PATCH RFC 3/7] xen/x86: Add some addresses to the Multiboot header

2018-05-04 Thread Jan Beulich
>>> On 08.07.17 at 23:53,  wrote:
> In comparison to ELF the PE format is not supported by the Multiboot
> protocol. So, if we wish to load xen.efi using this protocol we have
> to put header_addr, load_addr, load_end_addr, bss_end_addr and
> entry_addr data into Multiboot header.

Looks fine, but you will want to assure us that this non-ELF method of
loading is compatible with each and every loader able of loading Xen so
far.

Jan



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

Re: [Xen-devel] [PATCH RFC 2/7] xen/x86: Manually build PE header

2018-05-04 Thread Jan Beulich
>>> On 08.07.17 at 23:53,  wrote:
> This is the first step to get:
>   - one binary which can be loaded by the EFI loader,
> Multiboot and Multiboot2 protocols,
>   - if we wish, in the future we can drop xen/xen.gz
> and build xen.efi only,

If anything, generate xen.gz from xen.efi - I see value in the compression,
but the EFI loader requires an uncompressed binary. And of course we'd have
to raise the minimal gcc version requirement.

> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -7,6 +7,8 @@ CFLAGS += -I$(BASEDIR)/include
>  CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
>  CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
>  CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
> +CFLAGS += -DXEN_LOAD_ALIGN=XEN_IMG_OFFSET
> +CFLAGS += -DXEN_FILE_ALIGN=PAGE_SIZE

??? (Sadly your description talks about benefits only, not about what the
patch actually does.)

> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -1,3 +1,4 @@
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -44,6 +45,150 @@
>  .Lmb2ht_init_end\@:
>  .endm
>  
> +.section .efi.pe.header, "a", @progbits
> +
> +ENTRY(efi_pe_head)

Since you put this in a separate section anyway, why don't you place it in
a C file (perhaps even of its own) with suitably declared structures?

> +/*
> + * Legacy EXE header.
> + *
> + * Most of it is copied from binutils package, version 2.28,
> + * include/coff/pe.h:struct external_PEI_filehdr and
> + * bfd/peXXigen.c:_bfd_XXi_only_swap_filehdr_out().
> + *
> + * Page is equal 512 bytes here.
> + * Paragraph is equal 16 bytes here.
> + */
> +.short  0x5a4d /* EXE magic number. */
> +.short  0x90   /* Bytes on last page of 
> file. */
> +.short  0x3/* Pages in file. */
> +.short  0  /* Relocations. */
> +.short  0x4/* Size of header in 
> paragraphs. */
> +.short  0  /* Minimum extra 
> paragraphs needed. */
> +.short  0x /* Maximum extra 
> paragraphs needed. */
> +.short  0  /* Initial (relative) SS 
> value. */
> +.short  0xb8   /* Initial SP value. */
> +.short  0  /* Checksum. */
> +.short  0  /* Initial IP value. */
> +.short  0  /* Initial (relative) CS 
> value. */
> +.short  0x40   /* File address of 
> relocation table. */
> +.short  0  /* Overlay number. */
> +.fill   4, 2, 0/* Reserved words. */
> +.short  0  /* OEM identifier. */
> +.short  0  /* OEM information. */
> +.fill   10, 2, 0   /* Reserved words. */
> +.long   pe_header - efi_pe_head/* File address of the PE 
> header. */
> +
> +/*
> + * DOS message.
> + *
> + * It is copied from binutils package, version 2.28,
> + * include/coff/pe.h:struct external_PEI_filehdr and
> + * bfd/peXXigen.c:_bfd_XXi_only_swap_filehdr_out().
> + */
> +.long   0x0eba1f0e
> +.long   0xcd09b400
> +.long   0x4c01b821
> +.long   0x685421cd
> +.long   0x70207369
> +.long   0x72676f72
> +.long   0x63206d61
> +.long   0x6f6e6e61
> +.long   0x65622074
> +.long   0x6e757220
> +.long   0x206e6920
> +.long   0x20534f44
> +.long   0x65646f6d
> +.long   0x0a0d0d2e
> +.long   0x24
> +.long   0

Other than what the comment says, this isn't just a message (or else you
could have used .asciz for the whole thing). I'm not convinced we need
any of this.

> @@ -259,6 +266,8 @@ SECTIONS
>  #endif
>__2M_rwdata_end = .;
>  
> +  __pe_SizeOfImage = ALIGN(. - __image_base__, XEN_LOAD_ALIGN);

I don't think this is in line with what xen.efi currently has. Any difference
needs explaining (I think there are further fields in this category).

Jan


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

Re: [Xen-devel] [Votel] Graduation Review: Windows PV Driver

2018-05-04 Thread Jan Beulich
>>> On 04.05.18 at 16:51,  wrote:
> A bit more than a week ago, I put out for initial review the proposal for 
> “Graduation Review: Windows PV Driver” at  
> https://xen.markmail.org/thread/vcbvln7aa3ocikx4 

+1

Jan


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

Re: [Xen-devel] [PATCH v2 7/8] xen_disk: use a single entry iovec

2018-05-04 Thread Paul Durrant
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 04 May 2018 14:56
> To: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-
> de...@nongnu.org
> Cc: Paul Durrant ; Stefano Stabellini
> ; Anthony Perard ;
> Kevin Wolf ; Max Reitz 
> Subject: [PATCH v2 7/8] xen_disk: use a single entry iovec
> 
> Since xen_disk now always copies data to and from a guest there is no need
> to maintain a vector entry corresponding to every page of a request.
> This means there is less per-request state to maintain so the ioreq
> structure can shrink significantly.
> 
> Signed-off-by: Paul Durrant 
> ---
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: Kevin Wolf 
> Cc: Max Reitz 
> 
> v2:
>  - Re-based

Unfortunately I managed to drop a hunk during rebase and so this patch is 
actually broken. I'll send a rectified v3 shortly.

  Paul

> ---
>  hw/block/xen_disk.c | 71 
> ++---
>  1 file changed, 18 insertions(+), 53 deletions(-)
> 
> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> index 28be8b6..230961f 100644
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -46,13 +46,10 @@ struct ioreq {
>  /* parsed request */
>  off_t   start;
>  QEMUIOVectorv;
> +void*buf;
> +size_t  size;
>  int presync;
> 
> -/* grant mapping */
> -uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> -void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> -void*pages;
> -
>  /* aio status */
>  int aio_inflight;
>  int aio_errors;
> @@ -110,12 +107,10 @@ static void ioreq_reset(struct ioreq *ioreq)
>  memset(>req, 0, sizeof(ioreq->req));
>  ioreq->status = 0;
>  ioreq->start = 0;
> +ioreq->buf = NULL;
> +ioreq->size = 0;
>  ioreq->presync = 0;
> 
> -memset(ioreq->refs, 0, sizeof(ioreq->refs));
> -memset(ioreq->page, 0, sizeof(ioreq->page));
> -ioreq->pages = NULL;
> -
>  ioreq->aio_inflight = 0;
>  ioreq->aio_errors = 0;
> 
> @@ -138,7 +133,7 @@ static struct ioreq *ioreq_start(struct XenBlkDev
> *blkdev)
>  ioreq = g_malloc0(sizeof(*ioreq));
>  ioreq->blkdev = blkdev;
>  blkdev->requests_total++;
> -qemu_iovec_init(>v, BLKIF_MAX_SEGMENTS_PER_REQUEST);
> +qemu_iovec_init(>v, 1);
>  } else {
>  /* get one from freelist */
>  ioreq = QLIST_FIRST(>freelist);
> @@ -183,7 +178,6 @@ static void ioreq_release(struct ioreq *ioreq, bool
> finish)
>  static int ioreq_parse(struct ioreq *ioreq)
>  {
>  struct XenBlkDev *blkdev = ioreq->blkdev;
> -uintptr_t mem;
>  size_t len;
>  int i;
> 
> @@ -230,13 +224,10 @@ static int ioreq_parse(struct ioreq *ioreq)
>  goto err;
>  }
> 
> -ioreq->refs[i]   = ioreq->req.seg[i].gref;
> -
> -mem = ioreq->req.seg[i].first_sect * blkdev->file_blk;
>  len = (ioreq->req.seg[i].last_sect - ioreq->req.seg[i].first_sect + 
> 1) *
> blkdev->file_blk;
> -qemu_iovec_add(>v, (void*)mem, len);
> +ioreq->size += len;
>  }
> -if (ioreq->start + ioreq->v.size > blkdev->file_size) {
> +if (ioreq->start + ioreq->size > blkdev->file_size) {
>  xen_pv_printf(>xendev, 0, "error: access beyond end of
> file\n");
>  goto err;
>  }
> @@ -247,35 +238,6 @@ err:
>  return -1;
>  }
> 
> -static void ioreq_free_copy_buffers(struct ioreq *ioreq)
> -{
> -int i;
> -
> -for (i = 0; i < ioreq->v.niov; i++) {
> -ioreq->page[i] = NULL;
> -}
> -
> -qemu_vfree(ioreq->pages);
> -}
> -
> -static int ioreq_init_copy_buffers(struct ioreq *ioreq)
> -{
> -int i;
> -
> -if (ioreq->v.niov == 0) {
> -return 0;
> -}
> -
> -ioreq->pages = qemu_memalign(XC_PAGE_SIZE, ioreq->v.niov *
> XC_PAGE_SIZE);
> -
> -for (i = 0; i < ioreq->v.niov; i++) {
> -ioreq->page[i] = ioreq->pages + i * XC_PAGE_SIZE;
> -ioreq->v.iov[i].iov_base = ioreq->page[i];
> -}
> -
> -return 0;
> -}
> -
>  static int ioreq_grant_copy(struct ioreq *ioreq)
>  {
>  struct XenBlkDev *blkdev = ioreq->blkdev;
> @@ -284,6 +246,7 @@ static int ioreq_grant_copy(struct ioreq *ioreq)
>  int i, count, rc;
>  int64_t file_blk = ioreq->blkdev->file_blk;
>  bool to_domain = (ioreq->req.operation == BLKIF_OP_READ);
> +void *virt = ioreq->buf;
> 
>  if (ioreq->v.niov == 0) {
>  return 0;
> @@ -293,16 +256,17 @@ static int ioreq_grant_copy(struct ioreq *ioreq)
> 
>  for (i = 0; i < count; i++) {
>  if (to_domain) {
> -segs[i].dest.foreign.ref = ioreq->refs[i];
> + 

Re: [Xen-devel] [PATCH] docs: fix xpti command line option doc

2018-05-04 Thread Jan Beulich
>>> On 04.05.18 at 17:09,  wrote:
> Signed-off-by: Wei Liu 

I don't think a change like this really needs an ack, but here you go:
Acked-by: Jan Beulich 

Jan



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

[Xen-devel] [PATCH v3 2/2] SVM: introduce a VM entry helper

2018-05-04 Thread Jan Beulich
Neither the register values copying nor the trace entry generation need
doing in assembly. The VMLOAD invocation can also be further deferred
(and centralized). Therefore replace the svm_asid_handle_vmrun()
invocation with one of the new helper.

Similarly move the VM exit side register value copying into
svm_vmexit_handler().

Now that we always make it out to guest context after VMLOAD,
svm_sync_vmcb() no longer overrides vmcb_needs_vmsave, making
svm_vmexit_handler() setting the field early unnecessary.

Signed-off-by: Jan Beulich 
---
v3: svm_vmexit_handler() no longer explicitly sets vmcb_sync_state, and
svm_sync_vmcb() no longer converts a needs-vmsave request into
in-sync state. Also move the svm_trace_vmentry() invocation to C.
v2: New.

--- a/xen/arch/x86/hvm/svm/entry.S
+++ b/xen/arch/x86/hvm/svm/entry.S
@@ -61,23 +61,8 @@ UNLIKELY_START(ne, nsvm_hap)
 jmp  .Lsvm_do_resume
 __UNLIKELY_END(nsvm_hap)
 
-call svm_asid_handle_vmrun
-
-cmpb $0,tb_init_done(%rip)
-UNLIKELY_START(nz, svm_trace)
-call svm_trace_vmentry
-UNLIKELY_END(svm_trace)
-
-mov  VCPU_svm_vmcb(%rbx),%rcx
-mov  UREGS_rax(%rsp),%rax
-mov  %rax,VMCB_rax(%rcx)
-mov  UREGS_rip(%rsp),%rax
-mov  %rax,VMCB_rip(%rcx)
-mov  UREGS_rsp(%rsp),%rax
-mov  %rax,VMCB_rsp(%rcx)
-mov  UREGS_eflags(%rsp),%rax
-or   $X86_EFLAGS_MBS,%rax
-mov  %rax,VMCB_rflags(%rcx)
+mov  %rsp, %rdi
+call svm_vmenter_helper
 
 mov VCPU_arch_msr(%rbx), %rax
 mov VCPUMSR_spec_ctrl_raw(%rax), %eax
@@ -111,16 +96,6 @@ UNLIKELY_END(svm_trace)
 SPEC_CTRL_ENTRY_FROM_VMEXIT /* Req: b=curr %rsp=regs/cpuinfo, Clob: 
acd */
 /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
 
-mov  VCPU_svm_vmcb(%rbx),%rcx
-mov  VMCB_rax(%rcx),%rax
-mov  %rax,UREGS_rax(%rsp)
-mov  VMCB_rip(%rcx),%rax
-mov  %rax,UREGS_rip(%rsp)
-mov  VMCB_rsp(%rcx),%rax
-mov  %rax,UREGS_rsp(%rsp)
-mov  VMCB_rflags(%rcx),%rax
-mov  %rax,UREGS_eflags(%rsp)
-
 STGI
 GLOBAL(svm_stgi_label)
 mov  %rsp,%rdi
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -687,10 +687,9 @@ static void svm_sync_vmcb(struct vcpu *v
 if ( new_state == vmcb_needs_vmsave )
 {
 if ( arch_svm->vmcb_sync_state == vmcb_needs_vmload )
-{
 svm_vmload(arch_svm->vmcb);
-arch_svm->vmcb_sync_state = vmcb_in_sync;
-}
+
+arch_svm->vmcb_sync_state = new_state;
 }
 else
 {
@@ -1171,11 +1170,29 @@ static void noreturn svm_do_resume(struc
 
 hvm_do_resume(v);
 
-svm_sync_vmcb(v, vmcb_needs_vmsave);
-
 reset_stack_and_jump(svm_asm_do_resume);
 }
 
+void svm_vmenter_helper(const struct cpu_user_regs *regs)
+{
+struct vcpu *curr = current;
+struct vmcb_struct *vmcb = curr->arch.hvm_svm.vmcb;
+
+svm_asid_handle_vmrun();
+
+if ( unlikely(tb_init_done) )
+HVMTRACE_ND(VMENTRY,
+nestedhvm_vcpu_in_guestmode(curr) ? TRC_HVM_NESTEDFLAG : 0,
+1/*cycles*/, 0, 0, 0, 0, 0, 0, 0);
+
+svm_sync_vmcb(curr, vmcb_needs_vmsave);
+
+vmcb->rax = regs->rax;
+vmcb->rip = regs->rip;
+vmcb->rsp = regs->rsp;
+vmcb->rflags = regs->rflags | X86_EFLAGS_MBS;
+}
+
 static void svm_guest_osvw_init(struct vcpu *vcpu)
 {
 if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
@@ -2621,7 +2638,11 @@ void svm_vmexit_handler(struct cpu_user_
 bool_t vcpu_guestmode = 0;
 struct vlapic *vlapic = vcpu_vlapic(v);
 
-v->arch.hvm_svm.vmcb_sync_state = vmcb_needs_vmsave;
+regs->rax = vmcb->rax;
+regs->rip = vmcb->rip;
+regs->rsp = vmcb->rsp;
+regs->rflags = vmcb->rflags;
+
 hvm_invalidate_regs_fields(regs);
 
 if ( paging_mode_hap(v->domain) )
@@ -3108,8 +3129,6 @@ void svm_vmexit_handler(struct cpu_user_
 }
 
   out:
-svm_sync_vmcb(v, vmcb_needs_vmsave);
-
 if ( vcpu_guestmode || vlapic_hw_disabled(vlapic) )
 return;
 
@@ -3118,17 +3137,8 @@ void svm_vmexit_handler(struct cpu_user_
 intr.fields.tpr =
 (vlapic_get_reg(vlapic, APIC_TASKPRI) & 0xFF) >> 4;
 vmcb_set_vintr(vmcb, intr);
-ASSERT(v->arch.hvm_svm.vmcb_sync_state != vmcb_needs_vmload);
 }
 
-void svm_trace_vmentry(void)
-{
-struct vcpu *curr = current;
-HVMTRACE_ND(VMENTRY,
-nestedhvm_vcpu_in_guestmode(curr) ? TRC_HVM_NESTEDFLAG : 0,
-1/*cycles*/, 0, 0, 0, 0, 0, 0, 0);
-}
-  
 /*
  * Local variables:
  * mode: C
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -119,12 +119,6 @@ void __dummy__(void)
 OFFSET(DOMAIN_is_32bit_pv, struct domain, arch.is_32bit_pv);
 BLANK();
 
-OFFSET(VMCB_rax, struct vmcb_struct, rax);
-OFFSET(VMCB_rip, struct vmcb_struct, rip);
-OFFSET(VMCB_rsp, struct vmcb_struct, rsp);
-

[Xen-devel] [PATCH v3 1/2] SVM: re-work VMCB sync-ing

2018-05-04 Thread Jan Beulich
While the main problem to be addressed here is the issue of what so far
was named "vmcb_in_sync" starting out with the wrong value (should have
been true instead of false, to prevent performing a VMSAVE without ever
having VMLOADed the vCPU's state), go a step further and make the
sync-ed state a tristate: CPU and memory may be in sync or an update
may be required in either direction. Rename the field and introduce an
enum. Callers of svm_sync_vmcb() now indicate the intended new state
(with a slight "anomaly" when requesting VMLOAD: we could store
vmcb_needs_vmsave in those cases as the callers request, but the VMCB
really is in sync at that point, and hence there's no need to VMSAVE in
case we don't make it out to guest context), and all syncing goes
through that function.

With that, there's no need to VMLOAD the state perhaps multiple times;
all that's needed is loading it once before VM entry.

Signed-off-by: Jan Beulich 
---
v3: Move conditionals around the svm_sync_vmcb() invocations from
svm_do_resume() and svm_vmexit_handler() into the function.
v2: Also handle VMLOAD in svm_sync_vmcb(). Add comment to enum
vmcb_sync_state.
---
I've been considering to put the VMLOAD invocation in
svm_asid_handle_vmrun() (instead of the two copies in svm_do_resume()
and svm_vmexit_handler()), but that seemed a little too abusive of the
function. See patch 2.
I'm also not really certain about svm_vmexit_do_vmload(): All I'm doing
here is a 1:1 change from previous behavior, but I'm unconvinced this
was/is really correct.

--- a/xen/arch/x86/hvm/svm/entry.S
+++ b/xen/arch/x86/hvm/svm/entry.S
@@ -112,7 +112,6 @@ UNLIKELY_END(svm_trace)
 /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
 
 mov  VCPU_svm_vmcb(%rbx),%rcx
-movb $0,VCPU_svm_vmcb_in_sync(%rbx)
 mov  VMCB_rax(%rcx),%rax
 mov  %rax,UREGS_rax(%rsp)
 mov  VMCB_rip(%rcx),%rax
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -680,16 +680,26 @@ static void svm_cpuid_policy_changed(str
   cp->extd.ibpb ? MSR_INTERCEPT_NONE : MSR_INTERCEPT_RW);
 }
 
-static void svm_sync_vmcb(struct vcpu *v)
+static void svm_sync_vmcb(struct vcpu *v, enum vmcb_sync_state new_state)
 {
 struct arch_svm_struct *arch_svm = >arch.hvm_svm;
 
-if ( arch_svm->vmcb_in_sync )
-return;
-
-arch_svm->vmcb_in_sync = 1;
+if ( new_state == vmcb_needs_vmsave )
+{
+if ( arch_svm->vmcb_sync_state == vmcb_needs_vmload )
+{
+svm_vmload(arch_svm->vmcb);
+arch_svm->vmcb_sync_state = vmcb_in_sync;
+}
+}
+else
+{
+if ( arch_svm->vmcb_sync_state == vmcb_needs_vmsave )
+svm_vmsave(arch_svm->vmcb);
 
-svm_vmsave(arch_svm->vmcb);
+if ( arch_svm->vmcb_sync_state != vmcb_needs_vmload )
+arch_svm->vmcb_sync_state = new_state;
+}
 }
 
 static unsigned int svm_get_cpl(struct vcpu *v)
@@ -707,7 +717,7 @@ static void svm_get_segment_register(str
 switch ( seg )
 {
 case x86_seg_fs ... x86_seg_gs:
-svm_sync_vmcb(v);
+svm_sync_vmcb(v, vmcb_in_sync);
 
 /* Fallthrough. */
 case x86_seg_es ... x86_seg_ds:
@@ -718,7 +728,7 @@ static void svm_get_segment_register(str
 break;
 
 case x86_seg_tr:
-svm_sync_vmcb(v);
+svm_sync_vmcb(v, vmcb_in_sync);
 *reg = vmcb->tr;
 break;
 
@@ -731,7 +741,7 @@ static void svm_get_segment_register(str
 break;
 
 case x86_seg_ldtr:
-svm_sync_vmcb(v);
+svm_sync_vmcb(v, vmcb_in_sync);
 *reg = vmcb->ldtr;
 break;
 
@@ -746,7 +756,6 @@ static void svm_set_segment_register(str
  struct segment_register *reg)
 {
 struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
-bool sync = false;
 
 ASSERT((v == current) || !vcpu_runnable(v));
 
@@ -768,7 +777,8 @@ static void svm_set_segment_register(str
 case x86_seg_gs:
 case x86_seg_tr:
 case x86_seg_ldtr:
-sync = (v == current);
+if ( v == current )
+svm_sync_vmcb(v, vmcb_needs_vmload);
 break;
 
 default:
@@ -777,9 +787,6 @@ static void svm_set_segment_register(str
 return;
 }
 
-if ( sync )
-svm_sync_vmcb(v);
-
 switch ( seg )
 {
 case x86_seg_ss:
@@ -813,9 +820,6 @@ static void svm_set_segment_register(str
 ASSERT_UNREACHABLE();
 break;
 }
-
-if ( sync )
-svm_vmload(vmcb);
 }
 
 static unsigned long svm_get_shadow_gs_base(struct vcpu *v)
@@ -1086,7 +1090,7 @@ static void svm_ctxt_switch_from(struct
 svm_lwp_save(v);
 svm_tsc_ratio_save(v);
 
-svm_sync_vmcb(v);
+svm_sync_vmcb(v, vmcb_needs_vmload);
 svm_vmload_pa(per_cpu(host_vmcb, cpu));
 
 /* Resume use of ISTs now that the host TR is reinstated. */
@@ -1114,7 +1118,6 @@ static void svm_ctxt_switch_to(struct vc
 

[Xen-devel] [PATCH] docs: fix xpti command line option doc

2018-05-04 Thread Wei Liu
Signed-off-by: Wei Liu 
---
 docs/misc/xen-command-line.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index e7a8bd66e7..616dc9d34c 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1980,7 +1980,7 @@ region of memory being available.
 ### xpti
 > `= List of [ default |  | dom0= | domu= ]`
 
-> Default: `false` on hardware not to be vulnerable to Meltdown (e.g. AMD)
+> Default: `false` on hardware known not to be vulnerable to Meltdown (e.g. 
AMD)
 > Default: `true` everywhere else
 
 Override default selection of whether to isolate 64-bit PV guest page
-- 
2.11.0


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

[Xen-devel] [PATCH v3 0/2] SVM: guest state handling adjustments

2018-05-04 Thread Jan Beulich
Only patch 1 is clearly meant for 4.11. The second patch, however, eliminates
a (theoretical) window the first patch still leaves, so should at least be 
considered.
Furthermore previous discussion suggests that it might even be desirable to fold
both patches into one (or swap their order).

1: re-work VMCB sync-ing
2: introduce a VM entry helper

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 v9 3/9] xen/x86: support per-domain flag for xpti

2018-05-04 Thread Wei Liu
On Fri, Apr 27, 2018 at 02:15:25AM -0600, Jan Beulich wrote:
> >>> On 27.04.18 at 09:59,  wrote:
> > On 27/04/18 09:55, Sergey Dyasli wrote:
> >> On Thu, 2018-04-26 at 13:33 +0200, Juergen Gross wrote:
> >>> index b353352adf..220d1ba020 100644
> >>> --- a/docs/misc/xen-command-line.markdown
> >>> +++ b/docs/misc/xen-command-line.markdown
> >>> @@ -1955,14 +1955,24 @@ clustered mode.  The default, given no hint from 
> >>> the **FADT**, is cluster
> >>>  mode.
> >>>  
> >>>  ### xpti
> >>> -> `= `
> >>> +> `= List of [ default |  | dom0= | domu= ]`
> >>>  
> >>> -> Default: `false` on AMD hardware
> >>> +> Default: `false` on hardware not to be vulnerable to Meltdown (e.g. 
> >>> AMD)
> >>  ^
> >>  known
> > 
> > Yes, indeed.
> 
> Recorded for eventual application of the series; no need to resend just for 
> this.

Oops, I missed this while fixing up the conflicts. 

I will submit a patch to fix this.

Wei.

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

Re: [Xen-devel] [Votel] Graduation Review: Windows PV Driver

2018-05-04 Thread Wei Liu
+1 from me.

Wei.

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

Re: [Xen-devel] [PATCH v9 0/9] xen/x86: various XPTI speedups

2018-05-04 Thread Wei Liu
On Thu, Apr 26, 2018 at 01:33:09PM +0200, Juergen Gross wrote:
> Juergen Gross (9):
>   x86/xpti: avoid copying L4 page table contents when possible
>   xen/x86: add a function for modifying cr3
>   xen/x86: support per-domain flag for xpti
>   xen/x86: use invpcid for flushing the TLB
>   xen/x86: disable global pages for domains with XPTI active
>   xen/x86: use flag byte for decision whether xen_cr3 is valid
>   xen/x86: convert pv_guest_cr4_to_real_cr4() to a function
>   xen/x86: add some cr3 helpers
>   xen/x86: use PCID feature

There are conflicts in xen-command-line. I fixed them up and pushed this
series to staging. Please check if the result is correct.

Wei.

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

Re: [Xen-devel] [Votel] Graduation Review: Windows PV Driver

2018-05-04 Thread Andrew Cooper
On 04/05/18 15:51, Lars Kurth wrote:
> Hi all,
>
> A bit more than a week ago, I put out for initial review the proposal for 
> “Graduation Review: Windows PV Driver” at  
> https://xen.markmail.org/thread/vcbvln7aa3ocikx4
> There has not been feedback, except for two recorded votes from the Xen 
> Project Hypervisor Team by Ian Jackson and George Dunlap (both in favour).
>
> in accordance with https://www.xenproject.org/governance.html, I need the 
> leadership teams of the two mature projects – the Hypervisor and the XAPI 
> project – to vote on this proposal.
>
> The specific voting rules in this case are outlined in section
> https://www.xenproject.org/governance.html#project-decisions
>
> People allowed to vote on behalf of the Hypervisor project are:
> Julien Grall, Andy Cooper, George Dunlap, Ian Jackson, Jan Beulich, Konrad R 
> Wilk, Stefano Stabellini, Tim Deegan, Wei Liu
> and Juergen Gross (as Release Manager).
>
> People allowed to vote on behalf of the XAPI project are:
> Jon Ludlam, Chandrika Srinivasan, David Scott, Euan Harris, Germano Percossi, 
> Siddharth Vinoth Kumar, John Else, Mate Lakat, Konstantina Chremmou, Rob 
> Hoes, Si Beaumont, Thanos Makatos, Thomas Sanders, Vineeth Thampi Raveendran, 
> Zheng Li
>
> I propose to tally the votes by Friday the 6th of October. You can reply via
> +1: for proposal
> -1: against proposal
> in public or private.
>
> Votes will be tallied by subproject – aka the Hypervisor and XAPI project by 
> % for the proposal - and then averaged across sub-projects that achieved the 
> quorum. 
>
> Sub-project needs to achieve the following quorum of votes in favour for the 
> sub-project’s vote to count
> Hypervisor: 4 + votes
> XAPI: 5 + votes
>
> At least one subproject needs to achieve a quorum. So to pass, we need two 
> more votes from the Hypervisor team.

+1.

~Andrew

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

[Xen-devel] [Votel] Graduation Review: Windows PV Driver

2018-05-04 Thread Lars Kurth
Hi all,

A bit more than a week ago, I put out for initial review the proposal for 
“Graduation Review: Windows PV Driver” at  
https://xen.markmail.org/thread/vcbvln7aa3ocikx4
There has not been feedback, except for two recorded votes from the Xen Project 
Hypervisor Team by Ian Jackson and George Dunlap (both in favour).

in accordance with https://www.xenproject.org/governance.html, I need the 
leadership teams of the two mature projects – the Hypervisor and the XAPI 
project – to vote on this proposal.

The specific voting rules in this case are outlined in section
https://www.xenproject.org/governance.html#project-decisions

People allowed to vote on behalf of the Hypervisor project are:
Julien Grall, Andy Cooper, George Dunlap, Ian Jackson, Jan Beulich, Konrad R 
Wilk, Stefano Stabellini, Tim Deegan, Wei Liu
and Juergen Gross (as Release Manager).

People allowed to vote on behalf of the XAPI project are:
Jon Ludlam, Chandrika Srinivasan, David Scott, Euan Harris, Germano Percossi, 
Siddharth Vinoth Kumar, John Else, Mate Lakat, Konstantina Chremmou, Rob Hoes, 
Si Beaumont, Thanos Makatos, Thomas Sanders, Vineeth Thampi Raveendran, Zheng Li

I propose to tally the votes by Friday the 6th of October. You can reply via
+1: for proposal
-1: against proposal
in public or private.

Votes will be tallied by subproject – aka the Hypervisor and XAPI project by % 
for the proposal - and then averaged across sub-projects that achieved the 
quorum. 

Sub-project needs to achieve the following quorum of votes in favour for the 
sub-project’s vote to count
Hypervisor: 4 + votes
XAPI: 5 + votes

At least one subproject needs to achieve a quorum. So to pass, we need two more 
votes from the Hypervisor team.

The proposals are attached

Regards
Lars


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

[Xen-devel] Xen 4.11 RC3

2018-05-04 Thread Juergen Gross
Hi all,

Xen 4.11 rc3 is tagged. You can check that out from xen.git:

git://xenbits.xen.org/xen.git 4.11.0-rc3

For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.11.0-rc3/xen-4.11.0-rc3.tar.gz

And the signature is at:
https://downloads.xenproject.org/release/xen/4.11.0-rc3/xen-4.11.0-rc3.tar.gz.sig

Please send bug reports and test reports to xen-devel@lists.xenproject.org.
When sending bug reports, please CC relevant maintainers and me
(jgr...@suse.com).

As a reminder, there will be another Xen Test Day on May 8th.

See instructions on:

https://wiki.xenproject.org/wiki/Xen_4.11_RC_test_instructions


Juergen

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

[Xen-devel] [PATCH v2 0/8] xen_disk: legacy code removal and cleanup

2018-05-04 Thread Paul Durrant
The grant copy operation was added to libxengnttab in Xen 4.8.0 (released
nearly 18 months ago) but the xen_disk PV backend QEMU is still carrying
a significant amount of code purely to remain compatible with older
versions of Xen.

As can be inferred from the diff stats below, removing this support for
older versions of Xen from QEMU reduces the size of the xen_disk source by
around 320 lines (~25%).

Version 2 of this series maintains compatibility with older Xen, and OS
not supporting the grant copy operation, by adding an emulation of it
into the xen_backend code. Thus xen_disk can be simplified without
regressing support for any environment. This version also performs
general cleanup of the code by introducing and consistently using
helper functions for calling into libxenttab.

Paul Durrant (8):
  xen_backend: add grant table helpers
  xen_disk: remove open-coded use of libxengnttab
  xen: remove other open-coded use of libxengnttab
  xen_backend: add an emulation of grant copy
  xen_disk: remove use of grant map/unmap
  xen_backend: make the xen_feature_grant_copy flag private
  xen_disk: use a single entry iovec
  xen_disk: be consistent with use of xendev and blkdev->xendev

 hw/9pfs/xen-9p-backend.c |  32 ++-
 hw/block/xen_disk.c  | 609 +++
 hw/char/xen_console.c|   9 +-
 hw/net/xen_nic.c |  34 ++-
 hw/usb/xen-usb.c |  37 ++-
 hw/xen/xen_backend.c | 178 -
 include/hw/xen/xen_backend.h |  34 ++-
 7 files changed, 348 insertions(+), 585 deletions(-)
---
Cc: Anthony Perard 
Cc: Gerd Hoffmann 
Cc: Greg Kurz 
Cc: Jason Wang 
Cc: Kevin Wolf 
Cc: Max Reitz 
Cc: Paolo Bonzini 
Cc: Stefano Stabellini 

-- 
2.1.4


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

[Xen-devel] [PATCH v2 7/8] xen_disk: use a single entry iovec

2018-05-04 Thread Paul Durrant
Since xen_disk now always copies data to and from a guest there is no need
to maintain a vector entry corresponding to every page of a request.
This means there is less per-request state to maintain so the ioreq
structure can shrink significantly.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 

v2:
 - Re-based
---
 hw/block/xen_disk.c | 71 ++---
 1 file changed, 18 insertions(+), 53 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 28be8b6..230961f 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -46,13 +46,10 @@ struct ioreq {
 /* parsed request */
 off_t   start;
 QEMUIOVectorv;
+void*buf;
+size_t  size;
 int presync;
 
-/* grant mapping */
-uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-void*pages;
-
 /* aio status */
 int aio_inflight;
 int aio_errors;
@@ -110,12 +107,10 @@ static void ioreq_reset(struct ioreq *ioreq)
 memset(>req, 0, sizeof(ioreq->req));
 ioreq->status = 0;
 ioreq->start = 0;
+ioreq->buf = NULL;
+ioreq->size = 0;
 ioreq->presync = 0;
 
-memset(ioreq->refs, 0, sizeof(ioreq->refs));
-memset(ioreq->page, 0, sizeof(ioreq->page));
-ioreq->pages = NULL;
-
 ioreq->aio_inflight = 0;
 ioreq->aio_errors = 0;
 
@@ -138,7 +133,7 @@ static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
 ioreq = g_malloc0(sizeof(*ioreq));
 ioreq->blkdev = blkdev;
 blkdev->requests_total++;
-qemu_iovec_init(>v, BLKIF_MAX_SEGMENTS_PER_REQUEST);
+qemu_iovec_init(>v, 1);
 } else {
 /* get one from freelist */
 ioreq = QLIST_FIRST(>freelist);
@@ -183,7 +178,6 @@ static void ioreq_release(struct ioreq *ioreq, bool finish)
 static int ioreq_parse(struct ioreq *ioreq)
 {
 struct XenBlkDev *blkdev = ioreq->blkdev;
-uintptr_t mem;
 size_t len;
 int i;
 
@@ -230,13 +224,10 @@ static int ioreq_parse(struct ioreq *ioreq)
 goto err;
 }
 
-ioreq->refs[i]   = ioreq->req.seg[i].gref;
-
-mem = ioreq->req.seg[i].first_sect * blkdev->file_blk;
 len = (ioreq->req.seg[i].last_sect - ioreq->req.seg[i].first_sect + 1) 
* blkdev->file_blk;
-qemu_iovec_add(>v, (void*)mem, len);
+ioreq->size += len;
 }
-if (ioreq->start + ioreq->v.size > blkdev->file_size) {
+if (ioreq->start + ioreq->size > blkdev->file_size) {
 xen_pv_printf(>xendev, 0, "error: access beyond end of 
file\n");
 goto err;
 }
@@ -247,35 +238,6 @@ err:
 return -1;
 }
 
-static void ioreq_free_copy_buffers(struct ioreq *ioreq)
-{
-int i;
-
-for (i = 0; i < ioreq->v.niov; i++) {
-ioreq->page[i] = NULL;
-}
-
-qemu_vfree(ioreq->pages);
-}
-
-static int ioreq_init_copy_buffers(struct ioreq *ioreq)
-{
-int i;
-
-if (ioreq->v.niov == 0) {
-return 0;
-}
-
-ioreq->pages = qemu_memalign(XC_PAGE_SIZE, ioreq->v.niov * XC_PAGE_SIZE);
-
-for (i = 0; i < ioreq->v.niov; i++) {
-ioreq->page[i] = ioreq->pages + i * XC_PAGE_SIZE;
-ioreq->v.iov[i].iov_base = ioreq->page[i];
-}
-
-return 0;
-}
-
 static int ioreq_grant_copy(struct ioreq *ioreq)
 {
 struct XenBlkDev *blkdev = ioreq->blkdev;
@@ -284,6 +246,7 @@ static int ioreq_grant_copy(struct ioreq *ioreq)
 int i, count, rc;
 int64_t file_blk = ioreq->blkdev->file_blk;
 bool to_domain = (ioreq->req.operation == BLKIF_OP_READ);
+void *virt = ioreq->buf;
 
 if (ioreq->v.niov == 0) {
 return 0;
@@ -293,16 +256,17 @@ static int ioreq_grant_copy(struct ioreq *ioreq)
 
 for (i = 0; i < count; i++) {
 if (to_domain) {
-segs[i].dest.foreign.ref = ioreq->refs[i];
+segs[i].dest.foreign.ref = ioreq->req.seg[i].gref;
 segs[i].dest.foreign.offset = ioreq->req.seg[i].first_sect * 
file_blk;
-segs[i].source.virt = ioreq->v.iov[i].iov_base;
+segs[i].source.virt = virt;
 } else {
-segs[i].source.foreign.ref = ioreq->refs[i];
+segs[i].source.foreign.ref = ioreq->req.seg[i].gref;
 segs[i].source.foreign.offset = ioreq->req.seg[i].first_sect * 
file_blk;
-segs[i].dest.virt = ioreq->v.iov[i].iov_base;
+segs[i].dest.virt = virt;
 }
 segs[i].len = (ioreq->req.seg[i].last_sect
- ioreq->req.seg[i].first_sect + 1) * file_blk;
+virt += segs[i].len;
 }
 
 rc = xen_be_copy_grant_refs(xendev, to_domain, segs, count);
@@ -314,6 +278,7 @@ static int ioreq_grant_copy(struct 

[Xen-devel] [PATCH v2 5/8] xen_disk: remove use of grant map/unmap

2018-05-04 Thread Paul Durrant
Now that the (native or emulated) xen_be_copy_grant_refs() helper is
always available, the xen_disk code can be significantly simplified by
removing direct use of grant map and unmap operations.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 

v2:
 - Squashed in separate patche removing persistent grant use
 - Re-based
---
 hw/block/xen_disk.c | 370 
 1 file changed, 25 insertions(+), 345 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 66ed2b7..28be8b6 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -36,27 +36,9 @@
 
 /* - */
 
-static int batch_maps   = 0;
-
-/* - */
-
 #define BLOCK_SIZE  512
 #define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_REQUEST + 2)
 
-struct PersistentGrant {
-void *page;
-struct XenBlkDev *blkdev;
-};
-
-typedef struct PersistentGrant PersistentGrant;
-
-struct PersistentRegion {
-void *addr;
-int num;
-};
-
-typedef struct PersistentRegion PersistentRegion;
-
 struct ioreq {
 blkif_request_t req;
 int16_t status;
@@ -65,14 +47,11 @@ struct ioreq {
 off_t   start;
 QEMUIOVectorv;
 int presync;
-uint8_t mapped;
 
 /* grant mapping */
 uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-int prot;
 void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 void*pages;
-int num_unmap;
 
 /* aio status */
 int aio_inflight;
@@ -103,7 +82,6 @@ struct XenBlkDev {
 int protocol;
 blkif_back_rings_t  rings;
 int more_work;
-int cnt_map;
 
 /* request lists */
 QLIST_HEAD(inflight_head, ioreq) inflight;
@@ -114,13 +92,7 @@ struct XenBlkDev {
 int requests_finished;
 unsigned intmax_requests;
 
-/* Persistent grants extension */
 gbooleanfeature_discard;
-gbooleanfeature_persistent;
-GTree   *persistent_gnts;
-GSList  *persistent_regions;
-unsigned intpersistent_gnt_count;
-unsigned intmax_grants;
 
 /* qemu block driver */
 DriveInfo   *dinfo;
@@ -139,10 +111,8 @@ static void ioreq_reset(struct ioreq *ioreq)
 ioreq->status = 0;
 ioreq->start = 0;
 ioreq->presync = 0;
-ioreq->mapped = 0;
 
 memset(ioreq->refs, 0, sizeof(ioreq->refs));
-ioreq->prot = 0;
 memset(ioreq->page, 0, sizeof(ioreq->page));
 ioreq->pages = NULL;
 
@@ -156,37 +126,6 @@ static void ioreq_reset(struct ioreq *ioreq)
 qemu_iovec_reset(>v);
 }
 
-static gint int_cmp(gconstpointer a, gconstpointer b, gpointer user_data)
-{
-uint ua = GPOINTER_TO_UINT(a);
-uint ub = GPOINTER_TO_UINT(b);
-return (ua > ub) - (ua < ub);
-}
-
-static void destroy_grant(gpointer pgnt)
-{
-PersistentGrant *grant = pgnt;
-struct XenBlkDev *blkdev = grant->blkdev;
-struct XenDevice *xendev = >xendev;
-
-xen_be_unmap_grant_ref(xendev, grant->page);
-grant->blkdev->persistent_gnt_count--;
-xen_pv_printf(xendev, 3, "unmapped grant %p\n", grant->page);
-g_free(grant);
-}
-
-static void remove_persistent_region(gpointer data, gpointer dev)
-{
-PersistentRegion *region = data;
-struct XenBlkDev *blkdev = dev;
-struct XenDevice *xendev = >xendev;
-
-xen_be_unmap_grant_refs(xendev, region->addr, region->num);
-xen_pv_printf(xendev, 3, "unmapped grant region %p with %d pages\n",
-  region->addr, region->num);
-g_free(region);
-}
-
 static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
 {
 struct ioreq *ioreq = NULL;
@@ -254,7 +193,6 @@ static int ioreq_parse(struct ioreq *ioreq)
   ioreq->req.handle, ioreq->req.id, ioreq->req.sector_number);
 switch (ioreq->req.operation) {
 case BLKIF_OP_READ:
-ioreq->prot = PROT_WRITE; /* to memory */
 break;
 case BLKIF_OP_FLUSH_DISKCACHE:
 ioreq->presync = 1;
@@ -263,7 +201,6 @@ static int ioreq_parse(struct ioreq *ioreq)
 }
 /* fall through */
 case BLKIF_OP_WRITE:
-ioreq->prot = PROT_READ; /* from memory */
 break;
 case BLKIF_OP_DISCARD:
 return 0;
@@ -310,173 +247,6 @@ err:
 return -1;
 }
 
-static void ioreq_unmap(struct ioreq *ioreq)
-{
-struct XenBlkDev *blkdev = ioreq->blkdev;
-struct XenDevice *xendev = >xendev;
-int i;
-
-if (ioreq->num_unmap == 0 || ioreq->mapped == 0) {
-return;
-}
-if (batch_maps) {
-if (!ioreq->pages) {
-return;
-}
- 

[Xen-devel] [PATCH v2 8/8] xen_disk: be consistent with use of xendev and blkdev->xendev

2018-05-04 Thread Paul Durrant
Certain functions in xen_disk are called with a pointer to xendev
(struct XenDevice *). They then use continer_of() to acces the surrounding
blkdev (struct XenBlkDev) but then in various places use >xendev
when use of the original xendev pointer is shorter to express and clearly
equivalent.

This patch is a purely cosmetic patch which makes sure there is a xendev
pointer on stack for any function where the pointer is need on multiple
occasions modified those functions to use it consistently.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 

v2:
 - Re-based
---
 hw/block/xen_disk.c | 90 +++--
 1 file changed, 46 insertions(+), 44 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 230961f..d8b430d 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -178,10 +178,11 @@ static void ioreq_release(struct ioreq *ioreq, bool 
finish)
 static int ioreq_parse(struct ioreq *ioreq)
 {
 struct XenBlkDev *blkdev = ioreq->blkdev;
+struct XenDevice *xendev = >xendev;
 size_t len;
 int i;
 
-xen_pv_printf(>xendev, 3,
+xen_pv_printf(xendev, 3,
   "op %d, nr %d, handle %d, id %" PRId64 ", sector %" PRId64 
"\n",
   ioreq->req.operation, ioreq->req.nr_segments,
   ioreq->req.handle, ioreq->req.id, ioreq->req.sector_number);
@@ -199,28 +200,28 @@ static int ioreq_parse(struct ioreq *ioreq)
 case BLKIF_OP_DISCARD:
 return 0;
 default:
-xen_pv_printf(>xendev, 0, "error: unknown operation (%d)\n",
+xen_pv_printf(xendev, 0, "error: unknown operation (%d)\n",
   ioreq->req.operation);
 goto err;
 };
 
 if (ioreq->req.operation != BLKIF_OP_READ && blkdev->mode[0] != 'w') {
-xen_pv_printf(>xendev, 0, "error: write req for ro device\n");
+xen_pv_printf(xendev, 0, "error: write req for ro device\n");
 goto err;
 }
 
 ioreq->start = ioreq->req.sector_number * blkdev->file_blk;
 for (i = 0; i < ioreq->req.nr_segments; i++) {
 if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
-xen_pv_printf(>xendev, 0, "error: nr_segments too big\n");
+xen_pv_printf(xendev, 0, "error: nr_segments too big\n");
 goto err;
 }
 if (ioreq->req.seg[i].first_sect > ioreq->req.seg[i].last_sect) {
-xen_pv_printf(>xendev, 0, "error: first > last sector\n");
+xen_pv_printf(xendev, 0, "error: first > last sector\n");
 goto err;
 }
 if (ioreq->req.seg[i].last_sect * BLOCK_SIZE >= XC_PAGE_SIZE) {
-xen_pv_printf(>xendev, 0, "error: page crossing\n");
+xen_pv_printf(xendev, 0, "error: page crossing\n");
 goto err;
 }
 
@@ -228,7 +229,7 @@ static int ioreq_parse(struct ioreq *ioreq)
 ioreq->size += len;
 }
 if (ioreq->start + ioreq->size > blkdev->file_size) {
-xen_pv_printf(>xendev, 0, "error: access beyond end of 
file\n");
+xen_pv_printf(xendev, 0, "error: access beyond end of file\n");
 goto err;
 }
 return 0;
@@ -244,7 +245,7 @@ static int ioreq_grant_copy(struct ioreq *ioreq)
 struct XenDevice *xendev = >xendev;
 XenGrantCopySegment segs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 int i, count, rc;
-int64_t file_blk = ioreq->blkdev->file_blk;
+int64_t file_blk = blkdev->file_blk;
 bool to_domain = (ioreq->req.operation == BLKIF_OP_READ);
 void *virt = ioreq->buf;
 
@@ -272,7 +273,7 @@ static int ioreq_grant_copy(struct ioreq *ioreq)
 rc = xen_be_copy_grant_refs(xendev, to_domain, segs, count);
 
 if (rc) {
-xen_pv_printf(>blkdev->xendev, 0,
+xen_pv_printf(xendev, 0,
   "failed to copy data %d\n", rc);
 ioreq->aio_errors++;
 return -1;
@@ -288,11 +289,12 @@ static void qemu_aio_complete(void *opaque, int ret)
 {
 struct ioreq *ioreq = opaque;
 struct XenBlkDev *blkdev = ioreq->blkdev;
+struct XenDevice *xendev = >xendev;
 
 aio_context_acquire(blkdev->ctx);
 
 if (ret != 0) {
-xen_pv_printf(>xendev, 0, "%s I/O error\n",
+xen_pv_printf(xendev, 0, "%s I/O error\n",
   ioreq->req.operation == BLKIF_OP_READ ? "read" : 
"write");
 ioreq->aio_errors++;
 }
@@ -624,16 +626,17 @@ static void blk_alloc(struct XenDevice *xendev)
 
 static void blk_parse_discard(struct XenBlkDev *blkdev)
 {
+struct XenDevice *xendev = >xendev;
 int enable;
 
 blkdev->feature_discard = true;
 
-if (xenstore_read_be_int(>xendev, "discard-enable", ) == 0) 
{
+if (xenstore_read_be_int(xendev, "discard-enable", ) == 0) {
 blkdev->feature_discard = !!enable;
 }
 
 if (blkdev->feature_discard) {
-

[Xen-devel] [PATCH v2 1/8] xen_backend: add grant table helpers

2018-05-04 Thread Paul Durrant
This patch adds grant table helper functions to the xen_backend code to
localize error reporting and use of xen_domid.

The patch also defers the call to xengnttab_open() until just before the
initialise method in XenDevOps is invoked. This method is responsible for
mapping the shared ring. No prior method requires access to the grant table.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 

v2:
 - New in v2
---
 hw/xen/xen_backend.c | 123 ++-
 include/hw/xen/xen_backend.h |  33 
 2 files changed, 144 insertions(+), 12 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 7445b50..50412d6 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -106,6 +106,103 @@ int xen_be_set_state(struct XenDevice *xendev, enum 
xenbus_state state)
 return 0;
 }
 
+void xen_be_set_max_grant_refs(struct XenDevice *xendev,
+   unsigned int nr_refs)
+{
+assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV);
+
+if (xengnttab_set_max_grants(xendev->gnttabdev, nr_refs)) {
+xen_pv_printf(xendev, 0, "xengnttab_set_max_grants failed: %s\n",
+  strerror(errno));
+}
+}
+
+void *xen_be_map_grant_refs(struct XenDevice *xendev, uint32_t *refs,
+unsigned int nr_refs, int prot)
+{
+void *ptr;
+
+assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV);
+
+ptr = xengnttab_map_domain_grant_refs(xendev->gnttabdev, nr_refs,
+  xen_domid, refs, prot);
+if (!ptr) {
+xen_pv_printf(xendev, 0,
+  "xengnttab_map_domain_grant_refs failed: %s\n",
+  strerror(errno));
+}
+
+return ptr;
+}
+
+void xen_be_unmap_grant_refs(struct XenDevice *xendev, void *ptr,
+ unsigned int nr_refs)
+{
+assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV);
+
+if (xengnttab_unmap(xendev->gnttabdev, ptr, nr_refs)) {
+xen_pv_printf(xendev, 0, "xengnttab_unmap failed: %s\n",
+  strerror(errno));
+}
+}
+
+int xen_be_copy_grant_refs(struct XenDevice *xendev,
+   bool to_domain,
+   XenGrantCopySegment segs[],
+   unsigned int nr_segs)
+{
+xengnttab_grant_copy_segment_t *xengnttab_segs;
+unsigned int i;
+int rc;
+
+assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV);
+
+xengnttab_segs = g_new0(xengnttab_grant_copy_segment_t, nr_segs);
+
+for (i = 0; i < nr_segs; i++) {
+XenGrantCopySegment *seg = [i];
+xengnttab_grant_copy_segment_t *xengnttab_seg = _segs[i];
+
+if (to_domain) {
+xengnttab_seg->flags = GNTCOPY_dest_gref;
+xengnttab_seg->dest.foreign.domid = xen_domid;
+xengnttab_seg->dest.foreign.ref = seg->dest.foreign.ref;
+xengnttab_seg->dest.foreign.offset = seg->dest.foreign.offset;
+xengnttab_seg->source.virt = seg->source.virt;
+} else {
+xengnttab_seg->flags = GNTCOPY_source_gref;
+xengnttab_seg->source.foreign.domid = xen_domid;
+xengnttab_seg->source.foreign.ref = seg->source.foreign.ref;
+xengnttab_seg->source.foreign.offset =
+seg->source.foreign.offset;
+xengnttab_seg->dest.virt = seg->dest.virt;
+}
+
+xengnttab_seg->len = seg->len;
+}
+
+rc = xengnttab_grant_copy(xendev->gnttabdev, nr_segs, xengnttab_segs);
+
+if (rc) {
+xen_pv_printf(xendev, 0, "xengnttab_copy failed: %s\n",
+  strerror(errno));
+}
+
+for (i = 0; i < nr_segs; i++) {
+xengnttab_grant_copy_segment_t *xengnttab_seg =
+_segs[i];
+
+if (xengnttab_seg->status != GNTST_okay) {
+xen_pv_printf(xendev, 0, "segment[%u] status: %d\n", i,
+  xengnttab_seg->status);
+rc = -1;
+}
+}
+
+g_free(xengnttab_segs);
+return rc;
+}
+
 /*
  * get xen backend device, allocate a new one if it doesn't exist.
  */
@@ -149,18 +246,6 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 }
 qemu_set_cloexec(xenevtchn_fd(xendev->evtchndev));
 
-if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
-xendev->gnttabdev = xengnttab_open(NULL, 0);
-if (xendev->gnttabdev == NULL) {
-xen_pv_printf(NULL, 0, "can't open gnttab device\n");
-xenevtchn_close(xendev->evtchndev);
-qdev_unplug(DEVICE(xendev), NULL);
-return NULL;
-}
-} else {
-xendev->gnttabdev = NULL;
-}
-
 xen_pv_insert_xendev(xendev);
 
 if (xendev->ops->alloc) {
@@ -322,6 +407,16 @@ static int xen_be_try_initialise(struct XenDevice *xendev)
 }
 }
 
+

[Xen-devel] [PATCH v2 2/8] xen_disk: remove open-coded use of libxengnttab

2018-05-04 Thread Paul Durrant
Now that helpers are present in xen_backend, this patch removes open-coded
calls to libxengnttab from the xen_disk code.

This patch also fixes one whitspace error in the assignment of the
XenDevOps initialise method.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 

v2:
 - New in v2
---
 hw/block/xen_disk.c | 122 ++--
 1 file changed, 32 insertions(+), 90 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index f74fcd4..66ed2b7 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -68,7 +68,6 @@ struct ioreq {
 uint8_t mapped;
 
 /* grant mapping */
-uint32_tdomids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 int prot;
 void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
@@ -142,7 +141,6 @@ static void ioreq_reset(struct ioreq *ioreq)
 ioreq->presync = 0;
 ioreq->mapped = 0;
 
-memset(ioreq->domids, 0, sizeof(ioreq->domids));
 memset(ioreq->refs, 0, sizeof(ioreq->refs));
 ioreq->prot = 0;
 memset(ioreq->page, 0, sizeof(ioreq->page));
@@ -168,16 +166,12 @@ static gint int_cmp(gconstpointer a, gconstpointer b, 
gpointer user_data)
 static void destroy_grant(gpointer pgnt)
 {
 PersistentGrant *grant = pgnt;
-xengnttab_handle *gnt = grant->blkdev->xendev.gnttabdev;
+struct XenBlkDev *blkdev = grant->blkdev;
+struct XenDevice *xendev = >xendev;
 
-if (xengnttab_unmap(gnt, grant->page, 1) != 0) {
-xen_pv_printf(>blkdev->xendev, 0,
-  "xengnttab_unmap failed: %s\n",
-  strerror(errno));
-}
+xen_be_unmap_grant_ref(xendev, grant->page);
 grant->blkdev->persistent_gnt_count--;
-xen_pv_printf(>blkdev->xendev, 3,
-  "unmapped grant %p\n", grant->page);
+xen_pv_printf(xendev, 3, "unmapped grant %p\n", grant->page);
 g_free(grant);
 }
 
@@ -185,15 +179,10 @@ static void remove_persistent_region(gpointer data, 
gpointer dev)
 {
 PersistentRegion *region = data;
 struct XenBlkDev *blkdev = dev;
-xengnttab_handle *gnt = blkdev->xendev.gnttabdev;
+struct XenDevice *xendev = >xendev;
 
-if (xengnttab_unmap(gnt, region->addr, region->num) != 0) {
-xen_pv_printf(>xendev, 0,
-  "xengnttab_unmap region %p failed: %s\n",
-  region->addr, strerror(errno));
-}
-xen_pv_printf(>xendev, 3,
-  "unmapped grant region %p with %d pages\n",
+xen_be_unmap_grant_refs(xendev, region->addr, region->num);
+xen_pv_printf(xendev, 3, "unmapped grant region %p with %d pages\n",
   region->addr, region->num);
 g_free(region);
 }
@@ -304,7 +293,6 @@ static int ioreq_parse(struct ioreq *ioreq)
 goto err;
 }
 
-ioreq->domids[i] = blkdev->xendev.dom;
 ioreq->refs[i]   = ioreq->req.seg[i].gref;
 
 mem = ioreq->req.seg[i].first_sect * blkdev->file_blk;
@@ -324,7 +312,8 @@ err:
 
 static void ioreq_unmap(struct ioreq *ioreq)
 {
-xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
+struct XenBlkDev *blkdev = ioreq->blkdev;
+struct XenDevice *xendev = >xendev;
 int i;
 
 if (ioreq->num_unmap == 0 || ioreq->mapped == 0) {
@@ -334,11 +323,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
 if (!ioreq->pages) {
 return;
 }
-if (xengnttab_unmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
-xen_pv_printf(>blkdev->xendev, 0,
-  "xengnttab_unmap failed: %s\n",
-  strerror(errno));
-}
+xen_be_unmap_grant_refs(xendev, ioreq->pages, ioreq->num_unmap);
 ioreq->blkdev->cnt_map -= ioreq->num_unmap;
 ioreq->pages = NULL;
 } else {
@@ -346,11 +331,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
 if (!ioreq->page[i]) {
 continue;
 }
-if (xengnttab_unmap(gnt, ioreq->page[i], 1) != 0) {
-xen_pv_printf(>blkdev->xendev, 0,
-  "xengnttab_unmap failed: %s\n",
-  strerror(errno));
-}
+xen_be_unmap_grant_ref(xendev, ioreq->page[i]);
 ioreq->blkdev->cnt_map--;
 ioreq->page[i] = NULL;
 }
@@ -360,14 +341,14 @@ static void ioreq_unmap(struct ioreq *ioreq)
 
 static int ioreq_map(struct ioreq *ioreq)
 {
-xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
-uint32_t domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+struct XenBlkDev *blkdev = ioreq->blkdev;
+struct XenDevice *xendev = >xendev;
 uint32_t refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
  

[Xen-devel] [PATCH v2 4/8] xen_backend: add an emulation of grant copy

2018-05-04 Thread Paul Durrant
Not all Xen environments support the xengnttab_grant_copy() operation.
E.g. where the OS is FreeBSD or Xen is older than 4.8.0.

This patch introduces an emulation of that operation using
xengnttab_map_domain_grant_refs() and memcpy() for those environments.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 

v2:
 - New in v2
---
 hw/xen/xen_backend.c | 53 
 1 file changed, 53 insertions(+)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 50412d6..3c3fc2c 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -146,6 +146,55 @@ void xen_be_unmap_grant_refs(struct XenDevice *xendev, 
void *ptr,
 }
 }
 
+static int compat_copy_grant_refs(struct XenDevice *xendev,
+  bool to_domain,
+  XenGrantCopySegment segs[],
+  unsigned int nr_segs)
+{
+uint32_t *refs = g_new(uint32_t, nr_segs);
+int prot = to_domain ? PROT_WRITE : PROT_READ;
+void *pages;
+unsigned int i;
+
+for (i = 0; i < nr_segs; i++) {
+XenGrantCopySegment *seg = [i];
+
+refs[i] = to_domain ?
+seg->dest.foreign.ref : seg->source.foreign.ref;
+}
+
+pages = xengnttab_map_domain_grant_refs(xendev->gnttabdev, nr_segs,
+xen_domid, refs, prot);
+if (!pages) {
+xen_pv_printf(xendev, 0,
+  "xengnttab_map_domain_grant_refs failed: %s\n",
+  strerror(errno));
+g_free(refs);
+return -1;
+}
+
+for (i = 0; i < nr_segs; i++) {
+XenGrantCopySegment *seg = [i];
+void *page = pages + (i * XC_PAGE_SIZE);
+
+if (to_domain) {
+memcpy(page + seg->dest.foreign.offset, seg->source.virt,
+   seg->len);
+} else {
+memcpy(seg->dest.virt, page + seg->source.foreign.offset,
+   seg->len);
+}
+}
+
+if (xengnttab_unmap(xendev->gnttabdev, pages, nr_segs)) {
+xen_pv_printf(xendev, 0, "xengnttab_unmap failed: %s\n",
+  strerror(errno));
+}
+
+g_free(refs);
+return 0;
+}
+
 int xen_be_copy_grant_refs(struct XenDevice *xendev,
bool to_domain,
XenGrantCopySegment segs[],
@@ -157,6 +206,10 @@ int xen_be_copy_grant_refs(struct XenDevice *xendev,
 
 assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV);
 
+if (!xen_feature_grant_copy) {
+return compat_copy_grant_refs(xendev, to_domain, segs, nr_segs);
+}
+
 xengnttab_segs = g_new0(xengnttab_grant_copy_segment_t, nr_segs);
 
 for (i = 0; i < nr_segs; i++) {
-- 
2.1.4


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

[Xen-devel] [PATCH v2 3/8] xen: remove other open-coded use of libxengnttab

2018-05-04 Thread Paul Durrant
Now that helpers are available in xen_backend, use them throughout all
Xen PV backends.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Greg Kurz 
Cc: Paolo Bonzini 
Cc: Jason Wang 
Cc: Gerd Hoffmann 

v2:
 - New in v2
---
 hw/9pfs/xen-9p-backend.c | 32 +++-
 hw/char/xen_console.c|  9 -
 hw/net/xen_nic.c | 34 +++---
 hw/usb/xen-usb.c | 37 +
 4 files changed, 51 insertions(+), 61 deletions(-)

diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index 95e50c4..6026780 100644
--- a/hw/9pfs/xen-9p-backend.c
+++ b/hw/9pfs/xen-9p-backend.c
@@ -331,14 +331,14 @@ static int xen_9pfs_free(struct XenDevice *xendev)
 
 for (i = 0; i < xen_9pdev->num_rings; i++) {
 if (xen_9pdev->rings[i].data != NULL) {
-xengnttab_unmap(xen_9pdev->xendev.gnttabdev,
-xen_9pdev->rings[i].data,
-(1 << xen_9pdev->rings[i].ring_order));
+xen_be_unmap_grant_refs(_9pdev->xendev,
+xen_9pdev->rings[i].data,
+(1 << xen_9pdev->rings[i].ring_order));
 }
 if (xen_9pdev->rings[i].intf != NULL) {
-xengnttab_unmap(xen_9pdev->xendev.gnttabdev,
-xen_9pdev->rings[i].intf,
-1);
+xen_be_unmap_grant_refs(_9pdev->xendev,
+xen_9pdev->rings[i].intf,
+1);
 }
 if (xen_9pdev->rings[i].bh != NULL) {
 qemu_bh_delete(xen_9pdev->rings[i].bh);
@@ -390,11 +390,10 @@ static int xen_9pfs_connect(struct XenDevice *xendev)
 }
 g_free(str);
 
-xen_9pdev->rings[i].intf =  xengnttab_map_grant_ref(
-xen_9pdev->xendev.gnttabdev,
-xen_9pdev->xendev.dom,
-xen_9pdev->rings[i].ref,
-PROT_READ | PROT_WRITE);
+xen_9pdev->rings[i].intf =
+xen_be_map_grant_ref(_9pdev->xendev,
+ xen_9pdev->rings[i].ref,
+ PROT_READ | PROT_WRITE);
 if (!xen_9pdev->rings[i].intf) {
 goto out;
 }
@@ -403,12 +402,11 @@ static int xen_9pfs_connect(struct XenDevice *xendev)
 goto out;
 }
 xen_9pdev->rings[i].ring_order = ring_order;
-xen_9pdev->rings[i].data = xengnttab_map_domain_grant_refs(
-xen_9pdev->xendev.gnttabdev,
-(1 << ring_order),
-xen_9pdev->xendev.dom,
-xen_9pdev->rings[i].intf->ref,
-PROT_READ | PROT_WRITE);
+xen_9pdev->rings[i].data =
+xen_be_map_grant_refs(_9pdev->xendev,
+  xen_9pdev->rings[i].intf->ref,
+  (1 << ring_order),
+  PROT_READ | PROT_WRITE);
 if (!xen_9pdev->rings[i].data) {
 goto out;
 }
diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index bdfaa40..8b4b4bf 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -233,12 +233,11 @@ static int con_initialise(struct XenDevice *xendev)
 if (!xendev->dev) {
 xen_pfn_t mfn = con->ring_ref;
 con->sring = xenforeignmemory_map(xen_fmem, con->xendev.dom,
-  PROT_READ|PROT_WRITE,
+  PROT_READ | PROT_WRITE,
   1, , NULL);
 } else {
-con->sring = xengnttab_map_grant_ref(xendev->gnttabdev, 
con->xendev.dom,
- con->ring_ref,
- PROT_READ|PROT_WRITE);
+con->sring = xen_be_map_grant_ref(xendev, con->ring_ref,
+  PROT_READ | PROT_WRITE);
 }
 if (!con->sring)
return -1;
@@ -267,7 +266,7 @@ static void con_disconnect(struct XenDevice *xendev)
 if (!xendev->dev) {
 xenforeignmemory_unmap(xen_fmem, con->sring, 1);
 } else {
-xengnttab_unmap(xendev->gnttabdev, con->sring, 1);
+xen_be_unmap_grant_ref(xendev, con->sring);
 }
 con->sring = NULL;
 }
diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c
index 20c43a6..73d6f1b 100644
--- a/hw/net/xen_nic.c
+++ b/hw/net/xen_nic.c
@@ -160,9 +160,8 @@ static void net_tx_packets(struct XenNetDev *netdev)
   (txreq.flags & NETTXF_more_data)  ? " more_data" 
 : "",
   (txreq.flags & NETTXF_extra_info) ? " 
extra_info" : "");
 
-page = 

[Xen-devel] [PATCH v2 6/8] xen_backend: make the xen_feature_grant_copy flag private

2018-05-04 Thread Paul Durrant
There is no longer any use of this flag outside of the xen_backend code.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 

v2:
 - New in v2
---
 hw/xen/xen_backend.c | 2 +-
 include/hw/xen/xen_backend.h | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 3c3fc2c..9a8e877 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -44,9 +44,9 @@ BusState *xen_sysbus;
 /* public */
 struct xs_handle *xenstore = NULL;
 const char *xen_protocol;
-bool xen_feature_grant_copy;
 
 /* private */
+static bool xen_feature_grant_copy;
 static int debug;
 
 int xenstore_write_be_str(struct XenDevice *xendev, const char *node, const 
char *val)
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 29bf1c3..9c17fdd 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -16,7 +16,6 @@
 /* variables */
 extern struct xs_handle *xenstore;
 extern const char *xen_protocol;
-extern bool xen_feature_grant_copy;
 extern DeviceState *xen_sysdev;
 extern BusState *xen_sysbus;
 
-- 
2.1.4


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

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

2018-05-04 Thread osstest service owner
flight 122580 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122580/

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  0306a1311d02ea52b4a9a9bc339f8bab9354c5e3
baseline version:
 xen  eff2fbe4dd71b3e4fe2dbb2696882252c1cc7897

Last test of basis   122529  2018-04-30 05:28:55 Z4 days
Testing same since   122580  2018-05-03 12:11:46 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Brian Woods 
  Ian Jackson 
  Jan 

Re: [Xen-devel] [PATCH RESEND v1 6/7] x86: Implement Intel Processor Trace MSRs read/write

2018-05-04 Thread Jan Beulich
>>> On 04.05.18 at 05:53,  wrote:
>> >  Thanks for your clarification. Please correct me if I have
>> > something wrong. Guest may execute an instruction and this instruction
>> > may produce an PT packet save in PT output buffer. An EPT violation
>> > will be generated if the address of this PT buffer don't have EPT page
>> > table mapping, but this EPT violations shouldn't be handled by
>> > x86_emulate() because it no relate with the execute of this instruction.
>> 
>> Plus - and that's very important - the EPT violation may be reported on some 
> later insn.
> 
> You mean the "later instruction" is some new instruction in future hardware? 

No, I mean an instruction following later in the instruction stream.

>> >  In that case, can we build the EPT map when set the output buffer
>> > address (IA32_RTIT_OUTPUT_BASE) and crash the guest if still happened
>> > EPT violation with Intel PT output buffer read/write exit
>> > qualification. Or add an exit qualification check before instruction 
>> > emulation?
>> 
>> Imo you should add an exit qualification check in any case. Depending what 
> else you do, finding the new bit set may imply crashing
>> the domain or doing something more sophisticated.
> 
> Do you mean add this check at the beginning of any specific "exit_reason" 
> handler in vmx_vmexit_handler() function?

That depends. Surely not for every exit reason, but only those for which this
new bit is valid (iirc exit qualifications differ per exit reason anyway, so you
can't unilaterally check the same bit everywhere). And even for those where
the bit is valid, I'm not sure you can decide in the exit handler alone what to
do if the bit is set. It may be necessary to propagate the flag down the call
tree.

> Another question is where to build this EPT mapping? Setting 
> IA32_RTIT_OUTPUT_BASE or handled by EPT violation?

I have no idea - that's more a question for you to answer yourself.

Jan



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

Re: [Xen-devel] 答复: [PATCH v3] x86/cpu: Add supports for zhaoxin x86 platform

2018-05-04 Thread Jan Beulich
>>> On 04.05.18 at 04:54,  wrote:
> 发件人: Jan Beulich 
> 发送时间: 2018年5月3日 23:09
>> +if ( cpu_has(c, X86_FEATURE_ITSC) )
>> +{
>> +__set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
>> +__set_bit(X86_FEATURE_NONSTOP_TSC, c->x86_capability);
>> +__set_bit(X86_FEATURE_TSC_RELIABLE, c->x86_capability);
>> +}
>> +
>> +l2 = init_intel_cacheinfo(c);
>> +}
> 
> ... this is its only use?
> Yes, it Only be used to save the return value. I think it is unnecessary but 
> calls of  init_intel_cacheinfo() (in init_intel()) make me confused. Can i 
> delete it in patch v4?

If you don't need the value, you should (not just "can") remove the variable.

Also, I think I had mentioned this before: Please adjust your quoting style
when replying to mails.

Jan


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

[Xen-devel] [GIT PULL] xen: one cleanup for 4.17-rc4

2018-05-04 Thread Juergen Gross
Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-4.17-rc4-tag

xen: one cleanup for 4.17-rc4

It contains one cleanup to remove VLAs from the kernel.


Thanks.

Juergen

 arch/x86/xen/enlighten_pv.c | 86 -
 1 file changed, 31 insertions(+), 55 deletions(-)

Laura Abbott (1):
  x86/xen: Remove use of VLAs

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

[Xen-devel] [distros-debian-jessie test] 74672: tolerable FAIL

2018-05-04 Thread Platform Team regression test user
flight 74672 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74672/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like 
74644

baseline version:
 flight   74644

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub fail
 test-amd64-amd64-i386-jessie-netboot-pygrub  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


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

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

2018-05-04 Thread osstest service owner
flight 122578 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122578/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 118324
 test-armhf-armhf-libvirt-xsm 10 debian-install   fail REGR. vs. 118324
 test-armhf-armhf-xl-credit2  10 debian-install   fail REGR. vs. 118324
 test-armhf-armhf-xl-multivcpu 10 debian-install  fail REGR. vs. 118324
 test-armhf-armhf-xl-xsm  10 debian-install   fail REGR. vs. 118324
 test-armhf-armhf-xl  10 debian-install   fail REGR. vs. 118324

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

version targeted for testing:
 linuxf4ef6a438cee86ca0c6d1b889aa53bec9c1f9de6
baseline version:
 linux5b7d27967dabfb17c21b0d98b29153b9e3ee71e5

Last test of basis   118324  2018-01-25 07:31:24 Z   99 days
Failing since118362  2018-01-26 16:56:17 Z   97 days   78 attempts
Testing same since   122578  2018-05-03 11:56:24 Z0 days1 attempts


3407 people touched revisions under test,
not listing them all

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  

[Xen-devel] [PATCH for-4.11 v3 0/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

2018-05-04 Thread Lars Kurth
This version of this series addresses all comments on the mailing list, as well
as some feedback I got in various personal conversations and/or on IRC. For
the people who asked for specific features/workflows:

Ian Jackson: use ./scripts/add_maintainers.pl -p none [-c top]
Reads CCs from unmodified *.patch files and inserts them into the cover letter

George Dunlap: use ./scripts/add_maintainers.pl -p cc---
Tends to add CC blocks after the --- line in *.patches. This option achieves
this behavior/

Julien Grall: use ./scripts/add_maintainers.pl -c ccend
As far as I recall, Julien adds CC blocks into the body of the cover letter.
This option achieves this, but there is no place that always exists other
than before "-- " where the CC block can be insterted.

I made the processing code easily extendable via policies. So if there is any
missed behavior, the tool can easily be extended.

Also note that git send-email does not automatically add people in *=by:
tags to CC lists (with the exception of Singed-off-by). For this I added
the options -t|--tags and --tagscc.

v2 of this patch contained some cleanup to MAINTAINERS which has been broken
out into a separate series: see
https://lists.xenproject.org/archives/html/xen-devel/2018-05/threads.html#00028

Lars Kurth (1):
  Add new add_maintainers.pl script to optimise the workflow when using
git format-patch with get_maintainer.pl

 scripts/add_maintainers.pl | 512 +
 1 file changed, 512 insertions(+)
 create mode 100755 scripts/add_maintainers.pl

-- 
2.13.0


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

[Xen-devel] [PATCH for-4.11 v3 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

2018-05-04 Thread Lars Kurth
The tool covers step 2 of the following workflow

  Step 1: git format-patch ... -o  ...
  Step 2: ./scripts/add_maintainers.pl -d 
  This overwrites  *.patch files in 
  Step 3: git send-email -to xen-devel@lists.xenproject.org /*.patchxm

I manually tested all options and the most common combinations
on Mac.

Changes since v1:
- Added RAB (indicated by Juergen on IRC that this is OK)
- Remove trailing whitespaces
- Renamed --prefix to --reroll-count
- Cleaned up short options -v, ... to be in line with git
- Added --tags|-t option to add AB, RAB and RB emails to CC list
- Added --insert|-i mode to allow for people adding CCs to commit message
  instead of the e-mail header (the header is the default)
- Moved common code into functions
- Added logic, such that the tool only insert's To: and Cc: statements
  which were not there before, allowing for running the tool multiple times
  on the same 

Changes since v2:
- Deleted --version and related infrastructure
- Added subroutine prototypes
- Removed AT and @lists declaration and used \@ in literals
- Changed usage message and options based on feedback
- Improved error handling
- Removed occurances of index() and replaced with regex
- Removed non-perl idioms
- Moved uniq statements to normalize and added info on what normalize does
- Read L: tags from MAINTAINERS file instead of using heuristic
- Fixed issues related to metacharacters in getmaintainers()
- Allow multiple -a | --arg values (because of this renamed --args)
- Identify tags via regex
- CC's from tags are only inserted in the mail header, never the body
- That is unless the new option --tagscc is used
- Added policy processing which includes reworking insert()
- Replaced -i|--insert with -p|--inspatch and -c|--inscover now using policies
- Added new policies to cover for all user requests
- Rewrote help message to center around usage of policies
- Reordered some code (e.g. help string first to make code more easily readable)

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Signed-off-by: Lars Kurth 
Release-acked-by: Juergen Gross 
---
 scripts/add_maintainers.pl | 512 +
 1 file changed, 512 insertions(+)
 create mode 100755 scripts/add_maintainers.pl

diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
new file mode 100755
index 00..11ae60d888
--- /dev/null
+++ b/scripts/add_maintainers.pl
@@ -0,0 +1,512 @@
+#!/usr/bin/perl -w
+# (c) 2018, Lars Kurth 
+#
+# Add maintainers to patches generated with git format-patch
+#
+# Usage: perl scripts/add_maintainers.pl [OPTIONS] -patchdir 
+#
+# Prerequisites: Execute
+#git format-patch ... -o  ...
+#
+#./scripts/get_maintainer.pl is present in the tree
+#
+# Licensed under the terms of the GNU GPL License version 2
+
+use strict;
+
+use Getopt::Long qw(:config no_auto_abbrev);
+use File::Basename;
+use List::MoreUtils qw(uniq);
+
+sub getmaintainers ($$$);
+sub gettagsfrompatch ($$$;$);
+sub normalize ($$);
+sub insert ();
+sub hastag ($$);
+
+# Tool Variables
+my $tool = $0;
+my $usage = <1: v*.patch
+  --inspatch (top|ccbody|cc---|none) | -p (top|ccbody|cc---|none)
+Insert email addresses into *.patch files according to the POLICY
+See section POLICY:
+  --inscover (top|ccend|none) | -c (top|ccend|none)
+Insert email addresses into cover letteraccording to the POLICY
+See section PROCESSING POLICY:
+  --tags | -t
+Read email addresses from tags and add to CC list.
+Note that git send-email does not do this. It will add the senders
+email adress to the CC list though
+  --tagscc
+Same as tags, only that in this case CCs extracted from tags
+are treated like CCs that have come from the *.patch file
+  --arg  | -a  ...
+Arguments passed on to get_maintainer.pl
+This option can be used multiple times, e.g. -a  -a  ...
+  --verbose
+Show more output
+  --help | -h
+Show this help information
+
+PROCESSING POLICY:
+--
+  *.patch files consist of several sections relevant to processing:
+  :   This is the email header containing email related information
+   It ends with the Subject: line
+  :  This is the body that ends up in the commit message
+   It ends with ---
+  <--->:   This section contains the actual patches. CCs added here are
+   processed 

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

2018-05-04 Thread Platform Team regression test user
This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-i386 22 leak-check/checkfail REGR. vs. 74651
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 74651

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 74651
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail like 74651
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail like 74651
 test-armhf-armhf-libvirt 12 guest-start  fail   like 74651
 test-armhf-armhf-libvirt-xsm 12 guest-start  fail   like 74651
 test-armhf-armhf-xl-rtds 12 guest-start  fail   like 74651
 test-armhf-armhf-xl  12 guest-start  fail   like 74651
 test-armhf-armhf-xl-xsm  12 guest-start  fail   like 74651
 test-armhf-armhf-xl-multivcpu 12 guest-start  fail  like 74651
 test-armhf-armhf-xl-credit2  12 guest-start  fail   like 74651
 test-armhf-armhf-xl-midway   12 guest-start  fail   like 74651
 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail like 74651
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 74651
 test-armhf-armhf-xl-vhd  10 debian-di-installfail   like 74651
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail   like 74651
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 74651
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 74651
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail 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-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install 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-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-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win10-i386 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass

version targeted for testing:
 xen  eff2fbe4dd71b3e4fe2dbb2696882252c1cc7897
baseline version:
 xen  0d16ece0c5adb960ee4e45f12183bcac8fe6d50a

Last test of basis74651  2018-04-30 10:50:18 Z3 days
Testing same since74668  2018-05-03 12:22:29 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass