Re: [Xen-devel] [PATCH net-next 0/7] xen-netback: guest rx side refactor

[David Miller]

From: Paul Durrant 
Date: Mon, 3 Oct 2016 08:31:05 +0100

> This series refactors the guest rx side of xen-netback:
> 
> - The code is moved into its own source module.
> 
> - The prefix variant of GSO handling is retired (since it is no longer
>   in common use, and alternatives exist).
> 
> - The code is then simplified and modifications made to improve
>   performance.

This doesn't apply cleanly to net-next, please respin.

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

[Xen-devel] [ovmf test] 101249: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf c0b7e2b2bfc2748112607bfe83fc99cf48c97b48
baseline version:
 ovmf 8550b5f0810f306850f9a07ee551099155d89ae0

Last test of basis   101248  2016-10-03 21:45:40 Z0 days
Testing same since   101249  2016-10-04 01:14:18 Z0 days1 attempts


People who touched revisions under test:
  Michael Kinney 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=c0b7e2b2bfc2748112607bfe83fc99cf48c97b48
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
c0b7e2b2bfc2748112607bfe83fc99cf48c97b48
+ branch=ovmf
+ revision=c0b7e2b2bfc2748112607bfe83fc99cf48c97b48
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xc0b7e2b2bfc2748112607bfe83fc99cf48c97b48 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

[Xen-devel] [ovmf baseline-only test] 67791: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67791 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67791/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
67786

version targeted for testing:
 ovmf 8550b5f0810f306850f9a07ee551099155d89ae0
baseline version:
 ovmf ed72804638c9b240477c5235d72c3823483813b2

Last test of basis67786  2016-09-30 15:18:53 Z3 days
Testing same since67791  2016-10-04 01:20:23 Z0 days1 attempts


People who touched revisions under test:
  Cinnamon Shia 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  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.


commit 8550b5f0810f306850f9a07ee551099155d89ae0
Author: Cinnamon Shia 
Date:   Mon Oct 3 09:37:17 2016 -0700

ShellPkg/Shell: Update CRC32 in the EFI System Table header

Update CRC32 in the EFI System Table header after shell changes the
value of gST->ConsoleOutHandle and gST->ConOut

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia 
Reviewed-By: Tapan Shah 
Reviewed-By: Jaben Carsey 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale  3 host-install(3) broken in 101246 pass in 101247
 test-armhf-armhf-xl-credit2  16 guest-start.2  fail pass in 101246

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101246 like 
101244
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101244
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101244
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101244
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101244
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101244

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass

version targeted for testing:
 xen  40277cded320efa32b86c0c9f01e33145eab5ee4
baseline version:
 xen  b3d54cead6459567d9786ad415149868ee7f2f5b

Last test of basis   101244  2016-10-03 01:56:58 Z1 days
Testing same since   101246  2016-10-03 14:14:12 Z0 days2 attempts


People who touched revisions under test:
  Ian Jackson 
  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
 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install   fail REGR. vs. 67784
 test-amd64-i386-freebsd10-amd64 21 leak-check/check   fail REGR. vs. 67784

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67784
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67784
 test-amd64-amd64-i386-pvgrub 10 guest-start  fail   like 67784

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 xen  b3d54cead6459567d9786ad415149868ee7f2f5b
baseline version:
 xen  eabe1c39d1cd4fcef18ec50571db3c70c055c1fb

Last test of basis67784  2016-09-30 15:17:19 Z3 days
Testing same since67790  2016-10-03 16:44:46 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Lars Kurth 
  Mihai Donțu 
  Shannon Zhao 
  Wei Liu 
  Zhi Wang 

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

[Xen-devel] [ovmf test] 101248: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 8550b5f0810f306850f9a07ee551099155d89ae0
baseline version:
 ovmf ed72804638c9b240477c5235d72c3823483813b2

Last test of basis   101220  2016-09-30 06:45:26 Z3 days
Testing same since   101248  2016-10-03 21:45:40 Z0 days1 attempts


People who touched revisions under test:
  Cinnamon Shia 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=8550b5f0810f306850f9a07ee551099155d89ae0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
8550b5f0810f306850f9a07ee551099155d89ae0
+ branch=ovmf
+ revision=8550b5f0810f306850f9a07ee551099155d89ae0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x8550b5f0810f306850f9a07ee551099155d89ae0 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

[Xen-devel] [PATCH RFC] x86/Intel: virtualize support for cpuid faulting

[Kyle Huey]

rr (http://rr-project.org/), a Linux userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by providing constant results. Patches for support in the Linux kernel are in
flight, and we'd like to be able to use this feature on virtualized Linux
instances as well.

On HVM guests, the cpuid triggers a vm exit, so we can check the emulated
faulting state in vmx_do_cpuid and inject a GP(0) if CPL > 0. Notably no
hardware support for faulting on cpuid is necessary to emulate support with an
HVM guest.

On PV guests, hardware support is required so that userspace cpuid will trap
to xen. Xen already enables cpuid faulting on supported CPUs for pv guests (that
aren't the control domain, see the comment in intel_ctxt_switch_levelling).
Every userspace cpuid will trap via a GP(0) to emulate_privileged_op
(via do_general_protection). Once there we can simply decline to emulate the
cpuid and instead pass the GP(0) along to the guest kernel, thus emulating
the cpuid faulting behavior. PV guest kernels enter pv_cpuid via a different
path, so we do not need to check the CPL here.

Signed-off-by: Kyle Huey 
---
 xen/arch/x86/domain.c|  2 ++
 xen/arch/x86/hvm/vmx/vmx.c   | 24 +++-
 xen/arch/x86/traps.c | 31 ++-
 xen/include/asm-x86/domain.h |  3 +++
 4 files changed, 54 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 3c4b094..f2bac10 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1095,6 +1095,8 @@ int arch_set_info_guest(
 for ( i = 0; i < 8; i++ )
 (void)set_debugreg(v, i, c(debugreg[i]));
 
+v->arch.cpuid_fault = 0;
+
 if ( v->is_initialised )
 goto out;
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 50cbfed..f1e04c1 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2430,11 +2430,16 @@ static void vmx_cpuid_intercept(
 HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
 }
 
-static int vmx_do_cpuid(struct cpu_user_regs *regs)
+static int vmx_do_cpuid(struct vcpu *v, struct cpu_user_regs *regs)
 {
 unsigned int eax, ebx, ecx, edx;
 unsigned int leaf, subleaf;
 
+if ( v->arch.cpuid_fault && !ring_0(regs) ) {
+hvm_inject_hw_exception(TRAP_gp_fault, 0);
+return 0;
+}
+
 eax = regs->eax;
 ebx = regs->ebx;
 ecx = regs->ecx;
@@ -2701,9 +2706,13 @@ static int vmx_msr_read_intercept(unsigned int msr, 
uint64_t *msr_content)
 break;
 
 case MSR_INTEL_PLATFORM_INFO:
-if ( rdmsr_safe(MSR_INTEL_PLATFORM_INFO, *msr_content) )
-goto gp_fault;
-*msr_content = 0;
+if ( is_pvh_vcpu(current) && !cpu_has_cpuid_faulting )
+*msr_content = 0;
+else
+*msr_content = 0x8000ULL;
+break;
+case MSR_INTEL_MISC_FEATURES_ENABLES:
+*msr_content = current->arch.cpuid_fault ? 1ULL : 0;
 break;
 
 default:
@@ -2931,6 +2940,11 @@ static int vmx_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
  rdmsr_safe(MSR_INTEL_PLATFORM_INFO, msr_content) )
 goto gp_fault;
 break;
+case MSR_INTEL_MISC_FEATURES_ENABLES:
+if ( msr_content > 1 )
+goto gp_fault;
+v->arch.cpuid_fault = msr_content;
+break;
 
 default:
 if ( passive_domain_do_wrmsr(msr, msr_content) )
@@ -3605,7 +3619,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 rc = 0;
 }
 else
-rc = vmx_do_cpuid(regs);
+rc = vmx_do_cpuid(v, regs);
 
 /*
  * rc < 0 error in monitor/vm_event, crash
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 24d173f..d5a348e 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2945,6 +2945,16 @@ static int emulate_privileged_op(struct cpu_user_regs 
*regs)
  rdmsr_safe(MSR_INTEL_PLATFORM_INFO, msr_content) )
 goto fail;
 break;
+case MSR_INTEL_MISC_FEATURES_ENABLES:
+if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
+ rdmsr_safe(MSR_INTEL_MISC_FEATURES_ENABLES, val) ||
+ msr_content > 1 )
+goto fail;
+if ( msr_content == 1 &&
+ (!cpu_has_cpuid_faulting || is_control_domain(v->domain)) )
+goto fail;
+v->arch.cpuid_fault = msr_content;
+break;
 
 case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
 case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(3):
@@ -3079,7 +3089,22 @@ static int emulate_privileged_op(struct cpu_user_regs 
*regs)
 if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
  

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

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   3 host-install(3)broken REGR. vs. 101244

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 101244
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101244
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101244
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101244
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101244
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101244

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass

version targeted for testing:
 xen  40277cded320efa32b86c0c9f01e33145eab5ee4
baseline version:
 xen  b3d54cead6459567d9786ad415149868ee7f2f5b

Last test of basis   101244  2016-10-03 01:56:58 Z0 days
Testing same since   101246  2016-10-03 14:14:12 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 67780
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 67780
 test-amd64-amd64-i386-pvgrub 10 guest-start   fail REGR. vs. 67780

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67780
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail like 67780
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail like 67780
 test-amd64-i386-xl-qemut-debianhvm-amd64  9 debian-hvm-install fail like 67780
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 67780
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67780
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67780
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-install fail like 67780
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install   fail like 67780
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 67780
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67780
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 67780

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 xen  eabe1c39d1cd4fcef18ec50571db3c70c055c1fb
baseline version:
 xen  1e75ed8b64bc1a9b47e540e6f100f17ec6d97f1b

Last test of basis67780  2016-09-28 18:47:02 Z4 days
Testing same since

Re: [Xen-devel] [PATCH v3 4/4] Addressed comments on quorum and security team members

[Ian Jackson]

Lars Kurth writes ("[PATCH v3 4/4] Addressed comments on quorum and security 
team members"):
> Main changes
> Leadership team decisions: express quorum in terms of +1 votes
> Security Team Members: election
> Project Wide Decision Making: minor text changes

The resulting series is a little odd because your v3 4/4 patch only
changes things that are introduced in v3 3/4 and agreed to be probably
wrong there.  I would have been more usual to fold these changes in,
at least if the series related to code.

> --- a/governance.pandoc
> +++ b/governance.pandoc
> @@ -410,18 +410,26 @@ resolution. There is no differentiation between **+1**/ 
> **+2** and
>  **-1**/**-2**: in other words a **+2** is counted as a vote for, a **-2** as 
> a 
>  vote against the resolution. The number of votes for and against a 
> resolution 
>  is called **active vote**. **0** votes **are not counted** as an active vote.
> --   A **quorum of more than 50% of active votes** is required for a 
> resolution 
> -to pass. In other words, if the leadership team has 7 members, at least 4 
> -active votes are required for a resolution to pass.
> +-   A **quorum of at least 1/3 of +1 votes for a proposal** is required for 
> a 
> +resolution to pass. In other words, if the leadership team has 7 members, at 
> +least 3 members need to vote for the resolution. 

This paragraph should say `positive' rather than `+1', since as
written it appears to exclude +2.  (Same in the table.)

>   Project Lead Elections
>  
> @@ -553,10 +568,10 @@ as outlined below.
>  -   Project leadership team members vote for or against a proposal (there is 
> no 
>  differentiation between **-1**/**-2** and **+1**/**+2**). A **0** vote is 
> not 
>  counted as a valid vote.
> --   A **quorum of more than 50%** of each project's leadership team members 
> is 
> -required. In other words: if more than half of a project's leadership team 
> +-   A **quorum of at least 50%** of each project's leadership team members 
> is 
> +required. In other words: if fewer than half of a project's leadership team 
>  members do not vote or abstain, the entire sub-project's vote is not 
> counted. 
> -This avoids situations where only a minority of leadership team members 
> votes, 
> +This avoids situations where only a minority of leadership team members 
> vote, 

This still has the non-monotonicity problem.

I would suggest to deal with this issue by, when calculating the
percentage, dividing all the votes by the larger of (a) the number of
people voting (including `0' votes); (b) one third of the size of the
project leadership team.

So if only two out of a 10-person leadership team vote, and they both
votes in favour, that subproject's overall vote is
  2 / max(10/3, 2)
which = 2 / max(10/3, 6/3) = 2 / (max(10,6) / 3) = 2 / (10/3)
  = 2 * (3/10) = 6 / 10 = 0.6 = 60%

I would add a further backstop that a successful resolution must have
positive votes from at least three (or maybe, two) separate people.

Ian.

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

Re: [Xen-devel] [PATCH v2 12/30] xen/x86: make print_e820_memory_map global

[Roger Pau Monne]

On Fri, Sep 30, 2016 at 09:04:24AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:57,  wrote:
> > So that it can be called from the Dom0 builder.
> 
> Why would the Dom0 builder need to call it, when it doesn't so far?

IMHO, I find it useful to print the domain 0 memory map during creation. It 
wasn't useful for a PV Dom0, because the PV Dom0 memory map is just the 
native memory map, which is already printed earlier during the boot process. 
If it doesn't seem useful to you or others I can leave it out.

Roger.

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

Re: [Xen-devel] Livepatch for Xen 4.9

[Andrew Cooper]

On 03/10/16 15:16, Konrad Rzeszutek Wilk wrote:
> Hey!
>
> [CC-ing xen-devel]
>
> Xen 4.8-rc1 is out and means taking a break from some of the Livepatch 
> hypervisor
> parts for me.
>
> My plan for 4.8 is to concentrate on any livepatch fallout and doing OSSTest 
> along
> with Marcos (CC-ed) and see if we can wrestle it to expand on what
> we want to have done.
>
> However going forward (Xen 4.9) I believe the top issues we need
> to get addressed are:
>
>  a) "A better mechanism to "mask" NMIs during patching. The existing 
> mechanism looses
>NMI if they have been sent and we don't have a mechanism to replay them. 
> Note that
>this is also fixes alternative section patching. Could (like Linux) 
> annotate handlers don't get patched."
>(https://wiki.xenproject.org/wiki/LivePatch).

You cant mask NMIs, and as we have alternatives at the head of the
entrypoints, we need to work towards making patching safe on these
paths.  The traditional way is with 0xcc and magic in the debug trap
handler to take over the responsibility of patching.

>  b) Restart the shrinking of code using__LINE__

+1 (shame these patches missed 4.8)

>  c) When figuring out the new_addr, take into account name being 
> +.
>  d) Make asm code be in its own section. That eases the livepatch tools work 
> in figuring out a change.
> See https://lkml.org/lkml/2009/2/24/364

d.1) Reducing the quantity of ASM code outright.

As a start, {,compat_}create_bounce_frame() should definitely be written
in C, and would half the quantity of runtime ASM we have.  (Worse, we
already have C versions of create_bounce_frame() with
ever-so-slighty-different semantics).  I also have my eye on the general
exception handling path, which I think can safely move up into C.

~Andrew

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

Re: [Xen-devel] [PATCH RFC] xen: make it possible to disable XEN_TMEM

[Vitaly Kuznetsov]

Konrad Rzeszutek Wilk  writes:

> On Mon, Oct 03, 2016 at 04:02:48PM +0200, Vitaly Kuznetsov wrote:
>> XEN_TMEM config option has no prompt and it is enabled as module by
>> default if CLEANCACHE or FRONTSWAP options are set with no way to disable
>> it. The only in-tree user of the tmem interface is xen-selfballoon which
>
> And if CONFIG_XEN=y .
>

Yes, of course)

>> can itself be disabled so it makes sense to make it possible to disable
>
> During boot-time with arguments.

I see, I rather meant we need a way to disable building the module, not
just loading it.

>> XEN_TMEM too. In theory, both these options could be unified under the
>> XEN_SELFBALLOONING but other (out-of-tree) users of the tmem interface
>> may exist and someone may want to keep them supported without enabling
>> XEN_SELFBALLOONING.
>
> I think going the route of XEN_SELFBALLOONING may be better.

Ok, if you say so)

>> 
>> Signed-off-by: Vitaly Kuznetsov 
>> ---
>> - I don't know much about tmem and its users thus RFC.
>> ---
>>  drivers/xen/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
>> index f15bb3b7..0ea1df8 100644
>> --- a/drivers/xen/Kconfig
>> +++ b/drivers/xen/Kconfig
>> @@ -166,7 +166,7 @@ config SWIOTLB_XEN
>>  select SWIOTLB
>>  
>>  config XEN_TMEM
>> -tristate
>> +tristate "Transcendent Memory support for Xen"
>>  depends on !ARM && !ARM64
>>  default m if (CLEANCACHE || FRONTSWAP)
>>  help
>> -- 
>> 2.7.4
>> 
>> 
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel

-- 
  Vitaly

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

[Xen-devel] [PATCH] libxl: fix issues in 38cd0664

[Wei Liu]

A few issues were introduced in 38cd0664 ("libxl/arm: Add the size of
ACPI tables to maxmem"):

1. d_config was not properly initialised and disposed of.
2. using libxl_retrieve_domain_configuration caused thread to
   deadlock itself.

Fix those issues by:

1. properly initialise and dispose of d_config.
2. switch to use libxl__get_domain_configuration.

Note that in theory we can refactor libxl_retrieve_domain_configuration
a bit to get a function without locking, but up until the calculation of
extra memory only relies on static configuration, hence we use the
stored configuration only.

Reported-by: Anthony PERARD 
Signed-off-by: Wei Liu 
Tested-by: Anthony PERARD 
---
Cc: Ian Jackson 
CC: Shannon Zhao 
Cc: Anthony PERARD 
---
 tools/libxl/libxl.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 432e5d9..33c5e4c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4029,6 +4029,8 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t 
domid, uint64_t max_memkb)
 libxl__domain_userdata_lock *lock = NULL;
 libxl_domain_config d_config;
 
+libxl_domain_config_init(_config);
+
 CTX_LOCK;
 
 lock = libxl__lock_domain_userdata(gc, domid);
@@ -4054,7 +4056,7 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t 
domid, uint64_t max_memkb)
 goto out;
 }
 
-rc = libxl_retrieve_domain_configuration(ctx, domid, _config);
+rc = libxl__get_domain_configuration(gc, domid, _config);
 if (rc < 0) {
 LOGE(ERROR, "unable to retrieve domain configuration");
 goto out;
@@ -4076,6 +4078,7 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t 
domid, uint64_t max_memkb)
 
 rc = 0;
 out:
+libxl_domain_config_dispose(_config);
 if (lock) libxl__unlock_domain_userdata(lock);
 CTX_UNLOCK;
 GC_FREE;
@@ -4177,6 +4180,8 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t 
domid,
 libxl__domain_userdata_lock *lock;
 libxl_domain_config d_config;
 
+libxl_domain_config_init(_config);
+
 CTX_LOCK;
 
 lock = libxl__lock_domain_userdata(gc, domid);
@@ -4185,7 +4190,7 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t 
domid,
 goto out_no_transaction;
 }
 
-rc = libxl_retrieve_domain_configuration(ctx, domid, _config);
+rc = libxl__get_domain_configuration(gc, domid, _config);
 if (rc < 0) {
 LOGE(ERROR, "unable to retrieve domain configuration");
 goto out_no_transaction;
@@ -4318,6 +4323,7 @@ out:
 goto retry_transaction;
 
 out_no_transaction:
+libxl_domain_config_dispose(_config);
 if (lock) libxl__unlock_domain_userdata(lock);
 CTX_UNLOCK;
 GC_FREE;
-- 
2.1.4


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

Re: [Xen-devel] Livepatch for Xen 4.9

[Jan Beulich]

>>> Konrad Rzeszutek Wilk  10/03/16 4:18 PM >>>
>2) We could also do some form of restartable patching. That is seed the code 
>(where we are going to
>put a trampoline) with 'CC'. Then do memcpy over the the 'CC' the new 
>instructions (jump). If the
>NMI/MCE handler hits that code it would call the int3 - which we expand now to 
>take over and check
>whether the EIP is in the location which we just seeded with 'CC' - and if so 
>it can memcpy the
>trampoline code in (with a slight twist - we first memcpy the displacement, so 
>the start of a function
>would be say: CC 00 23 00 10 - and then we do a single write to replace 'CC' 
>with 'E9').
   
Careful here: How do you mean to return from the int3 handler? You mustn't use 
IRET
there, or else you unmask further NMIs.

Jan


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

Re: [Xen-devel] [PATCH RFC] xen: make it possible to disable XEN_TMEM

[Konrad Rzeszutek Wilk]

On Mon, Oct 03, 2016 at 04:02:48PM +0200, Vitaly Kuznetsov wrote:
> XEN_TMEM config option has no prompt and it is enabled as module by
> default if CLEANCACHE or FRONTSWAP options are set with no way to disable
> it. The only in-tree user of the tmem interface is xen-selfballoon which

And if CONFIG_XEN=y .

> can itself be disabled so it makes sense to make it possible to disable

During boot-time with arguments.
> XEN_TMEM too. In theory, both these options could be unified under the
> XEN_SELFBALLOONING but other (out-of-tree) users of the tmem interface
> may exist and someone may want to keep them supported without enabling
> XEN_SELFBALLOONING.

I think going the route of XEN_SELFBALLOONING may be better.
> 
> Signed-off-by: Vitaly Kuznetsov 
> ---
> - I don't know much about tmem and its users thus RFC.
> ---
>  drivers/xen/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index f15bb3b7..0ea1df8 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -166,7 +166,7 @@ config SWIOTLB_XEN
>   select SWIOTLB
>  
>  config XEN_TMEM
> - tristate
> + tristate "Transcendent Memory support for Xen"
>   depends on !ARM && !ARM64
>   default m if (CLEANCACHE || FRONTSWAP)
>   help
> -- 
> 2.7.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

[Xen-devel] Livepatch for Xen 4.9

[Konrad Rzeszutek Wilk]

Hey!

[CC-ing xen-devel]

Xen 4.8-rc1 is out and means taking a break from some of the Livepatch 
hypervisor
parts for me.

My plan for 4.8 is to concentrate on any livepatch fallout and doing OSSTest 
along
with Marcos (CC-ed) and see if we can wrestle it to expand on what
we want to have done.

However going forward (Xen 4.9) I believe the top issues we need
to get addressed are:

 a) "A better mechanism to "mask" NMIs during patching. The existing mechanism 
looses
   NMI if they have been sent and we don't have a mechanism to replay them. 
Note that
   this is also fixes alternative section patching. Could (like Linux) annotate 
handlers don't get patched."
   (https://wiki.xenproject.org/wiki/LivePatch).
 b) Restart the shrinking of code using__LINE__
 c) When figuring out the new_addr, take into account name being 
+.
 d) Make asm code be in its own section. That eases the livepatch tools work in 
figuring out a change.
See https://lkml.org/lkml/2009/2/24/364
 e) ? 

 g) Make XENPF_get_symbol also include Live Patch symbols.


I was wondering if folks could put in their preference and what they are 
thinking
to work on during 4.9?


During 4.8 I took a stab at a) and c).

The 'a)' is a thorny one as:
 1) If we get an NMI during patching we better not be patching MCE/NMI code! 
This could be avoided
by annotating all the MCE/NMI code and have a 'blacklist' of functions that 
MUST NEVER BE PATCHED.
But that may be difficult as that code can reach in many parts (especially 
MCE which wants to
send an event channel, hence touches normal event channel code).

 2) We could also do some form of restartable patching. That is seed the code 
(where we are going to
put a trampoline) with 'CC'. Then do memcpy over the the 'CC' the new 
instructions (jump). If the
NMI/MCE handler hits that code it would call the int3 - which we expand now 
to take over and check
whether the EIP is in the location which we just seeded with 'CC' - and if 
so it can memcpy the
trampoline code in (with a slight twist - we first memcpy the displacement, 
so the start of a function
would be say: CC 00 23 00 10 - and then we do a single write to replace 
'CC' with 'E9').
   
We could also (to combat bitrotting) change this a bit more - the debugger 
handler is in charge of
actually memcpying and the arch_livepatch_apply just calls 'int 3' (after 
it has seeded the area with 'CC').

Either of this would would require some global livepatch->debugger handler 
handover structure with
the EIP to patch over and the insns.


The 'c)' needs a bit more work.


Also I was thinking we can drop the IRC meeting we have setup. It has been 
quite useful during the
starting stage to re-sync patches but at this point I think emails are more 
suited?


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

[Xen-devel] [PATCH RFC] xen: make it possible to disable XEN_TMEM

[Vitaly Kuznetsov]

XEN_TMEM config option has no prompt and it is enabled as module by
default if CLEANCACHE or FRONTSWAP options are set with no way to disable
it. The only in-tree user of the tmem interface is xen-selfballoon which
can itself be disabled so it makes sense to make it possible to disable
XEN_TMEM too. In theory, both these options could be unified under the
XEN_SELFBALLOONING but other (out-of-tree) users of the tmem interface
may exist and someone may want to keep them supported without enabling
XEN_SELFBALLOONING.

Signed-off-by: Vitaly Kuznetsov 
---
- I don't know much about tmem and its users thus RFC.
---
 drivers/xen/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index f15bb3b7..0ea1df8 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -166,7 +166,7 @@ config SWIOTLB_XEN
select SWIOTLB
 
 config XEN_TMEM
-   tristate
+   tristate "Transcendent Memory support for Xen"
depends on !ARM && !ARM64
default m if (CLEANCACHE || FRONTSWAP)
help
-- 
2.7.4


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  40277cded320efa32b86c0c9f01e33145eab5ee4
baseline version:
 xen  b3d54cead6459567d9786ad415149868ee7f2f5b

Last test of basis   101229  2016-09-30 21:02:32 Z2 days
Testing same since   101245  2016-10-03 12:01:53 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=40277cded320efa32b86c0c9f01e33145eab5ee4
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
40277cded320efa32b86c0c9f01e33145eab5ee4
+ branch=xen-unstable-smoke
+ revision=40277cded320efa32b86c0c9f01e33145eab5ee4
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x40277cded320efa32b86c0c9f01e33145eab5ee4 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git

[Xen-devel] [ANNOUNCEMENT] Xen 4.8 RC1

[Wei Liu]

Hi all

Xen 4.8 RC1 is tagged. You can check that out from xen.git:

  git://xenbits.xen.org/xen.git 4.8.0-rc1

For you convenience there is also tarball at:
http://bits.xensource.com/oss-xen/release/4.8.0-rc1/xen-4.8.0-rc1.tar.gz

And the signature is at:
http://bits.xensource.com/oss-xen/release/4.8.0-rc1/xen-4.8.0-rc1.tar.gz.sig

Please send bug reports and test reports to
xen-de...@lists.xenproject.org. When sending bug reports, please CC
relevant maintainers and me (wei.l...@citrix.com).

Thanks
Wei.

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

Re: [Xen-devel] [PATCH] Xen 4.8.0-rc1 preparation

[Wei Liu]

On Mon, Oct 03, 2016 at 11:59:49AM +0100, Ian Jackson wrote:
> * Change QEMU_UPSTREAM_REVISION MINIOS_UPSTREAM_REVISION and
>   QEMU_TRADITIONAL_REVISION to refer to the Xen 4.8.0-rc1 tags.
> 
> * Change README and xen/Makefile to refer to Xen 4.8.0-rc (note, the
>   RC number is not included, so we do not have to update these again).
> 
> I reran autogen.sh as per the release checklist and this produced no
> changes, as expected.  (Debian jessie i386.)
> 
> Signed-off-by: Ian Jackson 
> CC: Wei Liu 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2 30/30] xen: allow setting the store pfn HVM parameter

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Roger Pau Monne
> Sent: 27 September 2016 16:57
> To: xen-de...@lists.xenproject.org
> Cc: Andrew Cooper ;
> boris.ostrov...@oracle.com; Roger Pau Monne ; Jan
> Beulich 
> Subject: [Xen-devel] [PATCH v2 30/30] xen: allow setting the store pfn HVM
> parameter
> 
> Xen already allows setting the store event channel, and this parameter is not
> used by Xen at all.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  xen/arch/x86/hvm/hvm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index
> bc4f7bc..5c3aa2a 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4982,6 +4982,7 @@ static int hvm_allow_set_param(struct domain *d,
>  case HVM_PARAM_STORE_EVTCHN:
>  case HVM_PARAM_CONSOLE_EVTCHN:
>  case HVM_PARAM_X87_FIP_WIDTH:
> +case HVM_PARAM_STORE_PFN:

Why does a guest need to be able set this? It needs to to be able to reset the 
store evtchn because of the need to be able to handle an evtchn reset, which 
blows way the guests local port, but what is going move the store ring such 
that the guest needs to play with it?

  Paul

>  break;
>  /*
>   * The following parameters must not be set by the guest
> --
> 2.7.4 (Apple Git-66)
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] Xen 4.8.0-rc1 preparation

[Ian Jackson]

* Change QEMU_UPSTREAM_REVISION MINIOS_UPSTREAM_REVISION and
  QEMU_TRADITIONAL_REVISION to refer to the Xen 4.8.0-rc1 tags.

* Change README and xen/Makefile to refer to Xen 4.8.0-rc (note, the
  RC number is not included, so we do not have to update these again).

I reran autogen.sh as per the release checklist and this produced no
changes, as expected.  (Debian jessie i386.)

Signed-off-by: Ian Jackson 
CC: Wei Liu 
---
 Config.mk|  6 +++---
 README   | 12 ++--
 xen/Makefile |  2 +-
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/Config.mk b/Config.mk
index acb7f95..3c3ff68 100644
--- a/Config.mk
+++ b/Config.mk
@@ -276,8 +276,8 @@ SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
 endif
 OVMF_UPSTREAM_REVISION ?= bc54e50e0fe03c570014f363b547426913e92449
-QEMU_UPSTREAM_REVISION ?= master
-MINIOS_UPSTREAM_REVISION ?= e20998fbec0af4d783abb1a0695ab4614064c520
+QEMU_UPSTREAM_REVISION ?= qemu-xen-4.8.0-rc1
+MINIOS_UPSTREAM_REVISION ?= xen-4.8.0-rc1
 # Wed Sep 28 11:50:04 2016 +0200
 # minios: fix build issue with xen_*mb defines
 
@@ -288,7 +288,7 @@ SEABIOS_UPSTREAM_REVISION ?= rel-1.9.3
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
 
-QEMU_TRADITIONAL_REVISION ?= c4e0d84d3c92923fdbc7fa922638d54e5e834753
+QEMU_TRADITIONAL_REVISION ?= xen-4.8.0-rc1
 # Tue Jul 26 15:31:59 2016 +0100
 # virtio: error out if guest exceeds virtqueue size
 
diff --git a/README b/README
index e1ac04a..91f4a8b 100644
--- a/README
+++ b/README
@@ -1,10 +1,10 @@
 #
-__  ___  ______ _  
-\ \/ /___ _ __   | || |  ( _ )   _   _ _ __  ___| |_ __ _| |__ | | ___ 
- \  // _ \ '_ \  | || |_ / _ \ _| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
- /  \  __/ | | | |__   _| (_) |_| |_| | | | \__ \ || (_| | |_) | |  __/
-/_/\_\___|_| |_||_|(_)___/   \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
-   
+__  ___  ____   ___
+\ \/ /___ _ __   | || |  ( _ ) / _ \   _ __ ___
+ \  // _ \ '_ \  | || |_ / _ \| | | |_| '__/ __|
+ /  \  __/ | | | |__   _| (_) | |_| |_| | | (__
+/_/\_\___|_| |_||_|(_)___(_)___/  |_|  \___|
+
 #
 
 http://www.xen.org/
diff --git a/xen/Makefile b/xen/Makefile
index e989a20..c511330 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -2,7 +2,7 @@
 # All other places this is stored (eg. compile.h) should be autogenerated.
 export XEN_VERSION   = 4
 export XEN_SUBVERSION= 8
-export XEN_EXTRAVERSION ?= -unstable$(XEN_VENDORVERSION)
+export XEN_EXTRAVERSION ?= .0-rc$(XEN_VENDORVERSION)
 export XEN_FULLVERSION   = $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION)
 -include xen-version
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 28/30] xen/x86: add MSI-X emulation to PVHv2 Dom0

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Roger Pau Monne
> Sent: 27 September 2016 16:57
> To: xen-de...@lists.xenproject.org
> Cc: boris.ostrov...@oracle.com; Roger Pau Monne 
> Subject: [Xen-devel] [PATCH v2 28/30] xen/x86: add MSI-X emulation to
> PVHv2 Dom0
> 
> This requires adding handlers to the PCI configuration space, plus a MMIO
> handler for the MSI-X table, the PBA is left mapped directly into the guest.
> The implementation is based on the one already found in the passthrough
> code from QEMU.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Paul Durrant 
> Jan Beulich 
> Andrew Cooper 
> ---
>  xen/arch/x86/hvm/io.c |   2 +
>  xen/arch/x86/hvm/vmsi.c   | 498
> ++
>  xen/drivers/passthrough/pci.c |   6 +-
>  xen/include/asm-x86/hvm/io.h  |  26 +++
>  xen/include/asm-x86/msi.h |   4 +-
>  5 files changed, 534 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
> index 088e3ec..11b7313 100644
> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -867,6 +867,7 @@ static struct hvm_pt_handler_init
> *hwdom_pt_handlers[] = {
>  _pt_bar_init,
>  _pt_vf_bar_init,
>  _pt_msi_init,
> +_pt_msix_init,
>  };
> 
>  int hwdom_add_device(struct pci_dev *pdev)
> @@ -1176,6 +1177,7 @@ void register_dpci_portio_handler(struct domain
> *d)
>  {
>  handler->ops = _dpci_portio_ops;
>  register_mmio_handler(d, _mmio_ops);
> +register_mmio_handler(d, _mmio_ops);

Again, this is a somewhat counterintuitive place to make this call.

  Paul

>  }
>  else
>  handler->ops = _portio_ops;
> diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
> index 75ba429..92c3b50 100644
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -40,6 +40,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  static void vmsi_inj_irq(
>  struct vlapic *target,
> @@ -1162,3 +1163,500 @@ struct hvm_pt_handler_init hvm_pt_msi_init = {
>  .handlers = vmsi_handler,
>  .init = vmsi_group_init,
>  };
> +
> +/* MSI-X */
> +#define latch(fld) latch[PCI_MSIX_ENTRY_##fld / sizeof(uint32_t)]
> +
> +static int vmsix_update_one(struct hvm_pt_device *s, int entry_nr,
> +uint32_t vec_ctrl)
> +{
> +struct hvm_pt_msix_entry *entry = NULL;
> +xen_domctl_bind_pt_irq_t bind;
> +bool bound = true;
> +struct irq_desc *desc;
> +unsigned long flags;
> +int irq;
> +int pirq;
> +int rc;
> +
> +if ( entry_nr < 0 || entry_nr >= s->msix->total_entries )
> +return -EINVAL;
> +
> +entry = >msix->msix_entry[entry_nr];
> +
> +if ( !entry->updated )
> +goto mask;
> +
> +pirq = entry->pirq;
> +
> +/*
> + * Update the entry addr and data to the latest values only when the
> + * entry is masked or they are all masked, as required by the spec.
> + * Addr and data changes while the MSI-X entry is unmasked get deferred
> + * until the next masked -> unmasked transition.
> + */
> +if ( s->msix->maskall ||
> + (entry->latch(VECTOR_CTRL_OFFSET) & PCI_MSIX_VECTOR_BITMASK)
> )
> +{
> +entry->addr = entry->latch(LOWER_ADDR_OFFSET) |
> +  ((uint64_t)entry->latch(UPPER_ADDR_OFFSET) << 32);
> +entry->data = entry->latch(DATA_OFFSET);
> +}
> +
> +if ( pirq == -1 )
> +{
> +struct msi_info msi_info;
> +//struct irq_desc *desc;
> +int index = -1;
> +
> +/* Init physical one */
> +printk_pdev(s->pdev, XENLOG_DEBUG, "setup MSI-X (entry: %d).\n",
> +entry_nr);
> +
> +memset(_info, 0, sizeof(msi_info));
> +msi_info.seg = s->pdev->seg;
> +msi_info.bus = s->pdev->bus;
> +msi_info.devfn = s->pdev->devfn;
> +msi_info.table_base = s->msix->table_base;
> +msi_info.entry_nr = entry_nr;
> +
> +rc = physdev_map_pirq(DOMID_SELF, MAP_PIRQ_TYPE_MSI, ,
> +  , _info);
> +if ( rc )
> +{
> +/*
> + * Do not broadcast this error, since there's nothing else
> + * that can be done (MSI-X setup should have been successful).
> + * Guest MSI would be actually not working.
> + */
> +
> +printk_pdev(s->pdev, XENLOG_ERR,
> +  "can not map MSI-X (entry: %d)!\n", entry_nr);
> +return rc;
> +}
> +entry->pirq = pirq;
> +bound = false;
> +}
> +
> +ASSERT(entry->pirq != -1);
> +
> +if ( bound )
> +{
> +printk_pdev(s->pdev, XENLOG_DEBUG, "destroy bind MSI-X entry
> %d\n",
> +entry_nr);
> +bind.hvm_domid = DOMID_SELF;
> +

Re: [Xen-devel] [PATCH v2 26/30] xen/x86: add PCIe emulation

[Paul Durrant]

> -Original Message-
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: 27 September 2016 16:57
> To: xen-de...@lists.xenproject.org
> Cc: konrad.w...@oracle.com; boris.ostrov...@oracle.com; Roger Pau Monne
> ; Paul Durrant ; Jan
> Beulich ; Andrew Cooper
> 
> Subject: [PATCH v2 26/30] xen/x86: add PCIe emulation
> 
> Add a new MMIO handler that traps accesses to PCIe regions, as discovered
> by
> Xen from the MCFG ACPI table. The handler used is the same as the one
> used
> for accesses to the IO PCI configuration space.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Paul Durrant 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  xen/arch/x86/hvm/io.c | 177
> --
>  1 file changed, 171 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
> index 779babb..088e3ec 100644
> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -46,6 +46,8 @@
>  #include 
>  #include 
> 
> +#include "../x86_64/mmconfig.h"
> +
>  /* Set permissive mode for HVM Dom0 PCI pass-through by default */
>  static bool_t opt_dom0permissive = 1;
>  boolean_param("dom0permissive", opt_dom0permissive);
> @@ -363,7 +365,7 @@ static int hvm_pt_pci_config_access_check(struct
> hvm_pt_device *d,
>  }
> 
>  static int hvm_pt_pci_read_config(struct hvm_pt_device *d, uint32_t addr,
> -  uint32_t *data, int len)
> +  uint32_t *data, int len, bool pcie)
>  {
>  uint32_t val = 0;
>  struct hvm_pt_reg_group *reg_grp_entry = NULL;
> @@ -377,7 +379,7 @@ static int hvm_pt_pci_read_config(struct
> hvm_pt_device *d, uint32_t addr,
>  unsigned int func = PCI_FUNC(d->pdev->devfn);
> 
>  /* Sanity checks. */
> -if ( hvm_pt_pci_config_access_check(d, addr, len) )
> +if ( !pcie && hvm_pt_pci_config_access_check(d, addr, len) )
>  return X86EMUL_UNHANDLEABLE;
> 
>  /* Find register group entry. */
> @@ -468,7 +470,7 @@ static int hvm_pt_pci_read_config(struct
> hvm_pt_device *d, uint32_t addr,
>  }
> 
>  static int hvm_pt_pci_write_config(struct hvm_pt_device *d, uint32_t addr,
> -uint32_t val, int len)
> +uint32_t val, int len, bool pcie)
>  {
>  int index = 0;
>  struct hvm_pt_reg_group *reg_grp_entry = NULL;
> @@ -485,7 +487,7 @@ static int hvm_pt_pci_write_config(struct
> hvm_pt_device *d, uint32_t addr,
>  unsigned int func = PCI_FUNC(d->pdev->devfn);
> 
>  /* Sanity checks. */
> -if ( hvm_pt_pci_config_access_check(d, addr, len) )
> +if ( !pcie && hvm_pt_pci_config_access_check(d, addr, len) )
>  return X86EMUL_UNHANDLEABLE;
> 
>  /* Find register group entry. */
> @@ -677,7 +679,7 @@ static int hw_dpci_portio_read(const struct
> hvm_io_handler *handler,
>  if ( dev != NULL )
>  {
>  reg = (currd->arch.pci_cf8 & 0xfc) | (addr & 0x3);
> -rc = hvm_pt_pci_read_config(dev, reg, , size);
> +rc = hvm_pt_pci_read_config(dev, reg, , size, false);
>  if ( rc == X86EMUL_OKAY )
>  {
>  read_unlock(>arch.hvm_domain.pt_lock);
> @@ -722,7 +724,7 @@ static int hw_dpci_portio_write(const struct
> hvm_io_handler *handler,
>  if ( dev != NULL )
>  {
>  reg = (currd->arch.pci_cf8 & 0xfc) | (addr & 0x3);
> -rc = hvm_pt_pci_write_config(dev, reg, data32, size);
> +rc = hvm_pt_pci_write_config(dev, reg, data32, size, false);
>  if ( rc == X86EMUL_OKAY )
>  {
>  read_unlock(>arch.hvm_domain.pt_lock);
> @@ -1002,6 +1004,166 @@ static const struct hvm_io_ops
> hw_dpci_portio_ops = {
>  .write = hw_dpci_portio_write
>  };
> 
> +static struct acpi_mcfg_allocation *pcie_find_mmcfg(unsigned long addr)
> +{
> +int i;
> +
> +for ( i = 0; i < pci_mmcfg_config_num; i++ )
> +{
> +unsigned long start, end;
> +
> +start = pci_mmcfg_config[i].address;
> +end = pci_mmcfg_config[i].address +
> +  ((pci_mmcfg_config[i].end_bus_number + 1) << 20);
> +if ( addr >= start && addr < end )
> +return _mmcfg_config[i];
> +}
> +
> +return NULL;
> +}
> +
> +static struct hvm_pt_device *hw_pcie_get_device(unsigned int seg,
> +unsigned int bus,
> +unsigned int slot,
> +unsigned int func)
> +{
> +struct hvm_pt_device *dev;
> +struct domain *d = current->domain;
> +
> +list_for_each_entry( dev, >arch.hvm_domain.pt_devices, entries )
> +{
> +if ( dev->pdev->seg != seg || dev->pdev->bus != bus ||
> + dev->pdev->devfn != 

Re: [Xen-devel] [PATCH v2 22/30] xen/x86: support PVHv2 Dom0 BAR remapping

[Paul Durrant]

> -Original Message-
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: 27 September 2016 16:57
> To: xen-de...@lists.xenproject.org
> Cc: konrad.w...@oracle.com; boris.ostrov...@oracle.com; Roger Pau Monne
> ; Paul Durrant ; Jan
> Beulich ; Andrew Cooper
> 
> Subject: [PATCH v2 22/30] xen/x86: support PVHv2 Dom0 BAR remapping
> 
> Add handlers to detect attemps from a PVHv2 Dom0 to change the position
> of the PCI BARs and properly remap them.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Paul Durrant 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  xen/arch/x86/hvm/io.c |   2 +
>  xen/drivers/passthrough/pci.c | 307
> ++
>  xen/include/asm-x86/hvm/io.h  |  19 +++
>  xen/include/xen/pci.h |   3 +
>  4 files changed, 331 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c index
> 7de1de3..4db0266 100644
> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -862,6 +862,8 @@ static int hvm_pt_add_register(struct hvm_pt_device
> *dev,  }
> 
>  static struct hvm_pt_handler_init *hwdom_pt_handlers[] = {
> +_pt_bar_init,
> +_pt_vf_bar_init,
>  };
> 
>  int hwdom_add_device(struct pci_dev *pdev) diff --git
> a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c index
> 6d831dd..60c9e74 100644
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -633,6 +633,313 @@ static int pci_size_bar(unsigned int seg, unsigned
> int bus, unsigned int slot,
>  return 0;
>  }
> 
> +static bool bar_reg_is_vf(uint32_t real_offset, uint32_t
> +handler_offset) {
> +if ( real_offset - handler_offset == PCI_SRIOV_BAR )
> +return true;
> +else
> +return false;
> +}
> +

Return the bool expression rather than the if-then-else?

> +static int bar_reg_init(struct hvm_pt_device *s,
> +struct hvm_pt_reg_handler *handler,
> +uint32_t real_offset, uint32_t *data) {
> +uint8_t seg, bus, slot, func;
> +uint64_t addr, size;
> +uint32_t val;
> +unsigned int index = handler->offset / 4;
> +bool vf = bar_reg_is_vf(real_offset, handler->offset);
> +struct hvm_pt_bar *bars = (vf ? s->vf_bars : s->bars);
> +int num_bars = (vf ? PCI_SRIOV_NUM_BARS : s->num_bars);
> +int rc;
> +
> +if ( index >= num_bars )
> +{
> +*data = HVM_PT_INVALID_REG;
> +return 0;
> +}
> +
> +seg = s->pdev->seg;
> +bus = s->pdev->bus;
> +slot = PCI_SLOT(s->pdev->devfn);
> +func = PCI_FUNC(s->pdev->devfn);
> +val = pci_conf_read32(seg, bus, slot, func, real_offset);
> +
> +if ( index > 0 && bars[index - 1].type == HVM_PT_BAR_MEM64_LO )
> +bars[index].type = HVM_PT_BAR_MEM64_HI;
> +else if ( (val & PCI_BASE_ADDRESS_SPACE) ==
> PCI_BASE_ADDRESS_SPACE_IO )
> +{
> +bars[index].type = HVM_PT_BAR_UNUSED;
> +}
> +else if ( (val & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
> +  PCI_BASE_ADDRESS_MEM_TYPE_64 )
> +bars[index].type = HVM_PT_BAR_MEM64_LO;
> +else
> +bars[index].type = HVM_PT_BAR_MEM32;
> +
> +if ( bars[index].type == HVM_PT_BAR_MEM32 ||
> + bars[index].type == HVM_PT_BAR_MEM64_LO )
> +{
> +/* Size the BAR and map it. */
> +rc = pci_size_bar(seg, bus, slot, func, real_offset - 
> handler->offset,
> +  num_bars, , , );
> +if ( rc )
> +{
> +printk_pdev(s->pdev, XENLOG_ERR, "unable to size BAR#%d\n",
> +index);
> +return rc;
> +}
> +
> +if ( size == 0 )
> +bars[index].type = HVM_PT_BAR_UNUSED;
> +else
> +{
> +printk_pdev(s->pdev, XENLOG_DEBUG,
> +"Mapping BAR#%u: %#lx size: %u\n", index, addr, 
> size);
> +rc = modify_mmio_11(s->pdev->domain, PFN_DOWN(addr),
> +DIV_ROUND_UP(size, PAGE_SIZE), true);
> +if ( rc )
> +{
> +printk_pdev(s->pdev, XENLOG_ERR,
> +"failed to map BAR#%d into memory map: %d\n",
> +index, rc);
> +return rc;
> +}
> +}
> +}
> +
> +*data = bars[index].type == HVM_PT_BAR_UNUSED ?
> HVM_PT_INVALID_REG : val;
> +return 0;
> +}
> +
> +/* Only allow writes to check the size of the BARs */ static int
> +allow_bar_write(struct hvm_pt_bar *bar, struct hvm_pt_reg *reg,
> +   struct pci_dev *pdev, uint32_t val) {
> +uint32_t mask;
> +
> +if ( bar->type == HVM_PT_BAR_MEM64_HI )
> +mask = ~0;
> +else
> +mask = (uint32_t) PCI_BASE_ADDRESS_MEM_MASK;
> +
> +if ( val != ~0 && (val & mask) 

Re: [Xen-devel] [PATCH v2 11/30] xen/x86: split Dom0 build into PV and PVHv2

[Roger Pau Monne]

On Fri, Sep 30, 2016 at 09:03:34AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:57,  wrote:
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -663,6 +663,13 @@ Pin dom0 vcpus to their respective pcpus
> >  
> >  Flag that makes a 64bit dom0 boot in PVH mode. No 32bit support at present.
> >  
> > +### dom0hvm
> > +> `= `
> > +
> > +> Default: `false`
> > +
> > +Flag that makes a dom0 boot in PVHv2 mode.
> 
> Considering sorting aspects this clearly wants to go at least ahead of
> dom0pvh.
>
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -75,6 +75,10 @@ unsigned long __read_mostly cr4_pv32_mask;
> >  static bool_t __initdata opt_dom0pvh;
> >  boolean_param("dom0pvh", opt_dom0pvh);
> >  
> > +/* Boot dom0 in HVM mode */
> > +static bool_t __initdata opt_dom0hvm;
> 
> Plain bool please.
> 
> > @@ -1495,6 +1499,11 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >  if ( opt_dom0pvh )
> >  domcr_flags |= DOMCRF_pvh | DOMCRF_hap;
> >  
> > +if ( opt_dom0hvm ) {
> 
> Coding style.

Fixed all the above.
 
> > +domcr_flags |= DOMCRF_hvm | (hvm_funcs.hap_supported ? DOMCRF_hap 
> > : 0);
> 
> So you mean to support PVHv2 on shadow (including for Dom0)
> right away. Are you also testing that?

I've added the following patch to my queue, in order to allow the user to 
select whether they want to use HAP or shadow, I've tested it locally and 
there seems to be no issues in building a PVHv2 Dom0 using shadow.

---
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 80e20fa..17956e2 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -203,13 +203,6 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
 return setup_dom0_vcpu(dom0, 0, cpumask_first(_cpus));
 }
 
-#ifdef CONFIG_SHADOW_PAGING
-static bool_t __initdata opt_dom0_shadow;
-boolean_param("dom0_shadow", opt_dom0_shadow);
-#else
-#define opt_dom0_shadow 0
-#endif
-
 static char __initdata opt_dom0_ioports_disable[200] = "";
 string_param("dom0_ioports_disable", opt_dom0_ioports_disable);
 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 9272318..252125d 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -79,6 +79,11 @@ boolean_param("dom0pvh", opt_dom0pvh);
 static bool_t __initdata opt_dom0hvm;
 boolean_param("dom0hvm", opt_dom0hvm);
 
+#ifdef CONFIG_SHADOW_PAGING
+bool __initdata opt_dom0_shadow;
+boolean_param("dom0_shadow", opt_dom0_shadow);
+#endif
+
 /*  Linux config option: propagated to domain0. */
 /* "acpi=off":Sisables both ACPI table parsing and interpreter. */
 /* "acpi=force":  Override the disable blacklist.   */
@@ -1500,7 +1505,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 domcr_flags |= DOMCRF_pvh | DOMCRF_hap;
 
 if ( opt_dom0hvm ) {
-domcr_flags |= DOMCRF_hvm | (hvm_funcs.hap_supported ? DOMCRF_hap : 0);
+domcr_flags |= DOMCRF_hvm |
+   (hvm_funcs.hap_supported && !opt_dom0_shadow ?
+   DOMCRF_hap : 0);
 config.emulation_flags = XEN_X86_EMU_LAPIC|XEN_X86_EMU_IOAPIC;
 }
 
diff --git a/xen/include/asm-x86/setup.h b/xen/include/asm-x86/setup.h
index c65b79c..888d952 100644
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -51,6 +51,12 @@ void microcode_grab_module(
 
 extern uint8_t kbd_shift_flags;
 
+#ifdef CONFIG_SHADOW_PAGING
+extern bool opt_dom0_shadow;
+#else
+#define opt_dom0_shadow 0
+#endif
+
 #ifdef NDEBUG
 # define highmem_start 0
 #else


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

[Xen-devel] [distros-debian-sid test] 67789: regressions - FAIL

[Platform Team regression test user]

flight 67789 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67789/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 5 kernel-build  fail REGR. vs. 67762

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-amd64-sid-netboot-pygrub  9 debian-di-install  fail like 67762
 test-amd64-i386-i386-sid-netboot-pvgrub  9 debian-di-install   fail like 67762
 test-amd64-amd64-amd64-sid-netboot-pvgrub  9 debian-di-install fail like 67762
 test-amd64-amd64-i386-sid-netboot-pygrub  9 debian-di-install  fail like 67762

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-sid-netboot-pygrub  1 build-check(1)blocked n/a

baseline version:
 flight   67762

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopsfail
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub fail
 test-armhf-armhf-armhf-sid-netboot-pygrubblocked 
 test-amd64-amd64-i386-sid-netboot-pygrub fail



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.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 20/30] xen/x86: add the basic infrastructure to import QEMU passthrough code

[Paul Durrant]

> -Original Message-
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: 27 September 2016 16:57
> To: xen-de...@lists.xenproject.org
> Cc: konrad.w...@oracle.com; boris.ostrov...@oracle.com; Roger Pau Monne
> ; Jan Beulich ; Andrew Cooper
> ; Paul Durrant 
> Subject: [PATCH v2 20/30] xen/x86: add the basic infrastructure to import
> QEMU passthrough code
> 
> Most of this code has been picked up from QEMU and modified so it can be
> plugged into the internal Xen IO handlers. The structure of the handlers has
> been keep quite similar to QEMU, so existing handlers can be imported
> without a lot of effort.
> 

If you lifted code from QEMU then one assumes there is no problem with license, 
but do you need to amend copyrights for any of the files where you put the code?

> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Paul Durrant 
> ---
>  docs/misc/xen-command-line.markdown |   8 +
>  xen/arch/x86/hvm/hvm.c  |   2 +
>  xen/arch/x86/hvm/io.c   | 621
> 
>  xen/include/asm-x86/hvm/domain.h|   4 +
>  xen/include/asm-x86/hvm/io.h| 176 ++
>  xen/include/xen/pci.h   |   5 +
>  6 files changed, 816 insertions(+)
> 
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-
> command-line.markdown
> index 59d7210..78130c8 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -670,6 +670,14 @@ Flag that makes a 64bit dom0 boot in PVH mode. No
> 32bit support at present.
> 
>  Flag that makes a dom0 boot in PVHv2 mode.
> 
> +### dom0permissive
> +> `= `
> +
> +> Default: `true`
> +
> +Select mode of PCI pass-through when using a PVHv2 Dom0, either
> permissive or
> +not.
> +
>  ### dtuart (ARM)
>  > `= path [:options]`
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index a291f82..bc4f7bc 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -632,6 +632,8 @@ int hvm_domain_initialise(struct domain *d)
>  goto fail1;
>  }
>  memset(d->arch.hvm_domain.io_bitmap, ~0, HVM_IOBITMAP_SIZE);
> +INIT_LIST_HEAD(>arch.hvm_domain.pt_devices);
> +rwlock_init(>arch.hvm_domain.pt_lock);
>  }
>  else
>  d->arch.hvm_domain.io_bitmap = hvm_io_bitmap;
> diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
> index 31d54dc..7de1de3 100644
> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -46,6 +46,10 @@
>  #include 
>  #include 
> 
> +/* Set permissive mode for HVM Dom0 PCI pass-through by default */
> +static bool_t opt_dom0permissive = 1;
> +boolean_param("dom0permissive", opt_dom0permissive);
> +
>  void send_timeoffset_req(unsigned long timeoff)
>  {
>  ioreq_t p = {
> @@ -258,12 +262,403 @@ static bool_t hw_dpci_portio_accept(const struct
> hvm_io_handler *handler,
>  return 0;
>  }
> 
> +static struct hvm_pt_device *hw_dpci_get_device(struct domain *d)
> +{
> +uint8_t bus, slot, func;
> +uint32_t addr;
> +struct hvm_pt_device *dev;
> +
> +/* Decode bus, slot and func. */
> +addr = CF8_BDF(d->arch.pci_cf8);
> +bus = PCI_BUS(addr);
> +slot = PCI_SLOT(addr);
> +func = PCI_FUNC(addr);
> +
> +list_for_each_entry( dev, >arch.hvm_domain.pt_devices, entries )
> +{
> +if ( dev->pdev->seg != 0 || dev->pdev->bus != bus ||
> + dev->pdev->devfn != PCI_DEVFN(slot,func) )
> +continue;
> +
> +return dev;
> +}
> +
> +return NULL;
> +}
> +
> +/* Dispatchers */
> +
> +/* Find emulate register group entry */
> +struct hvm_pt_reg_group *hvm_pt_find_reg_grp(struct hvm_pt_device
> *d,
> + uint32_t address)
> +{
> +struct hvm_pt_reg_group *entry = NULL;
> +
> +/* Find register group entry */
> +list_for_each_entry( entry, >register_groups, entries )
> +{
> +/* check address */
> +if ( (entry->base_offset <= address)
> + && ((entry->base_offset + entry->size) > address) )
> +return entry;
> +}
> +
> +/* Group entry not found */
> +return NULL;
> +}
> +
> +/* Find emulate register entry */
> +struct hvm_pt_reg *hvm_pt_find_reg(struct hvm_pt_reg_group *reg_grp,
> +   uint32_t address)
> +{
> +struct hvm_pt_reg *reg_entry = NULL;
> +struct hvm_pt_reg_handler *handler = NULL;
> +uint32_t real_offset = 0;
> +
> +/* Find register entry */
> +list_for_each_entry( reg_entry, _grp->registers, entries )
> +{
> +handler = reg_entry->handler;
> +real_offset = reg_grp->base_offset + handler->offset;
> +/* Check address */
> +if ( (real_offset <= address)
> + && 

Re: [Xen-devel] [PATCH v2 19/30] xen/dcpi: add a dpci passthrough handler for hardware domain

[Paul Durrant]

> -Original Message-
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: 27 September 2016 16:57
> To: xen-de...@lists.xenproject.org
> Cc: konrad.w...@oracle.com; boris.ostrov...@oracle.com; Roger Pau Monne
> ; Paul Durrant ; Jan
> Beulich ; Andrew Cooper
> 
> Subject: [PATCH v2 19/30] xen/dcpi: add a dpci passthrough handler for
> hardware domain
> 
> This is very similar to the PCI trap used for the traditional PV(H) Dom0.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Paul Durrant 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  xen/arch/x86/hvm/io.c | 72
> ++-
>  xen/arch/x86/traps.c  | 39 ---
>  xen/drivers/passthrough/pci.c | 39 +++
>  xen/include/xen/pci.h |  2 ++
>  4 files changed, 112 insertions(+), 40 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c index
> 1e7a5f9..31d54dc 100644
> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -247,12 +247,79 @@ static int dpci_portio_write(const struct
> hvm_io_handler *handler,
>  return X86EMUL_OKAY;
>  }
> 
> +static bool_t hw_dpci_portio_accept(const struct hvm_io_handler
> *handler,
> +const ioreq_t *p) {
> +if ( (p->addr == 0xcf8 && p->size == 4) || (p->addr & 0xfffc) == 0xcfc)
> +{
> +return 1;
> +}
> +
> +return 0;

Why not just return the value of the boolean expression?

> +}
> +
> +static int hw_dpci_portio_read(const struct hvm_io_handler *handler,
> +uint64_t addr,
> +uint32_t size,
> +uint64_t *data) {
> +struct domain *currd = current->domain;
> +
> +if ( addr == 0xcf8 )
> +{
> +ASSERT(size == 4);
> +*data = currd->arch.pci_cf8;
> +return X86EMUL_OKAY;
> +}
> +
> +ASSERT((addr & 0xfffc) == 0xcfc);

You could do 'addr &= 3' and simplify the expressions below.

> +size = min(size, 4 - ((uint32_t)addr & 3));
> +if ( size == 3 )
> +size = 2;
> +if ( pci_cfg_ok(currd, addr & 3, size, NULL) )

Is this the right place to do the check. Can this not be done in the accept op?

> +*data = pci_conf_read(currd->arch.pci_cf8, addr & 3, size);
> +
> +return X86EMUL_OKAY;
> +}
> +
> +static int hw_dpci_portio_write(const struct hvm_io_handler *handler,
> +uint64_t addr,
> +uint32_t size,
> +uint64_t data) {
> +struct domain *currd = current->domain;
> +uint32_t data32;
> +
> +if ( addr == 0xcf8 )
> +{
> +ASSERT(size == 4);
> +currd->arch.pci_cf8 = data;
> +return X86EMUL_OKAY;
> +}
> +
> +ASSERT((addr & 0xfffc) == 0xcfc);

'addr &= 3' again here.

  Paul

> +size = min(size, 4 - ((uint32_t)addr & 3));
> +if ( size == 3 )
> +size = 2;
> +data32 = data;
> +if ( pci_cfg_ok(currd, addr & 3, size, ) )
> +pci_conf_write(currd->arch.pci_cf8, addr & 3, size, data);
> +
> +return X86EMUL_OKAY;
> +}
> +
>  static const struct hvm_io_ops dpci_portio_ops = {
>  .accept = dpci_portio_accept,
>  .read = dpci_portio_read,
>  .write = dpci_portio_write
>  };
> 
> +static const struct hvm_io_ops hw_dpci_portio_ops = {
> +.accept = hw_dpci_portio_accept,
> +.read = hw_dpci_portio_read,
> +.write = hw_dpci_portio_write
> +};
> +
>  void register_dpci_portio_handler(struct domain *d)  {
>  struct hvm_io_handler *handler = hvm_next_io_handler(d); @@ -261,7
> +328,10 @@ void register_dpci_portio_handler(struct domain *d)
>  return;
> 
>  handler->type = IOREQ_TYPE_PIO;
> -handler->ops = _portio_ops;
> +if ( is_hardware_domain(d) )
> +handler->ops = _dpci_portio_ops;
> +else
> +handler->ops = _portio_ops;
>  }
> 
>  /*
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index
> 24d173f..f3c5c9e 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2076,45 +2076,6 @@ static bool_t admin_io_okay(unsigned int port,
> unsigned int bytes,
>  return ioports_access_permitted(d, port, port + bytes - 1);  }
> 
> -static bool_t pci_cfg_ok(struct domain *currd, unsigned int start,
> - unsigned int size, uint32_t *write)
> -{
> -uint32_t machine_bdf;
> -
> -if ( !is_hardware_domain(currd) )
> -return 0;
> -
> -if ( !CF8_ENABLED(currd->arch.pci_cf8) )
> -return 1;
> -
> -machine_bdf = CF8_BDF(currd->arch.pci_cf8);
> -if ( write )
> -{
> -const unsigned long *ro_map = pci_get_ro_map(0);
> -
> -if ( ro_map && test_bit(machine_bdf, ro_map) )
> -return 0;
> 

[Xen-devel] [xen-unstable test] 101244: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail in 101242 
pass in 101244
 test-armhf-armhf-libvirt-raw  9 debian-di-install  fail pass in 101242

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 101242
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101242
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101242
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101242
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101242
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101242

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw 11 migrate-support-check fail in 101242 never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail in 101242 never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass

version targeted for testing:
 xen  b3d54cead6459567d9786ad415149868ee7f2f5b
baseline version:
 xen  b3d54cead6459567d9786ad415149868ee7f2f5b

Last test of basis   101244  2016-10-03 01:56:58 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17077 days0 attempts

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   

Re: [Xen-devel] [PATCH] xen/x86: Initialize per_cpu(xen_vcpu, 0) a little earlier

[Sander Eikelenboom]

On 2016-10-03 00:45, Boris Ostrovsky wrote:

xen_cpuhp_setup() calls mutex_lock() which, when CONFIG_DEBUG_MUTEXES
is defined, ends up calling xen_save_fl(). That routine expects
per_cpu(xen_vcpu, 0) to be already initialized.

Signed-off-by: Boris Ostrovsky 
Reported-by: Sander Eikelenboom 
---
Sander, please see if this fixes the problem. Thanks.


Hi Boris,

I have tested it and it fixes the dom0 crash in early boot for me.
Thanks again for investigating and the swift fix !

--
Sander



 arch/x86/xen/enlighten.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 366b6ae..96c2dea 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1644,7 +1644,6 @@ asmlinkage __visible void __init 
xen_start_kernel(void)

xen_initial_gdt = _cpu(gdt_page, 0);

xen_smp_init();
-   WARN_ON(xen_cpuhp_setup());

 #ifdef CONFIG_ACPI_NUMA
/*
@@ -1658,6 +1657,8 @@ asmlinkage __visible void __init 
xen_start_kernel(void)

   possible map and a non-dummy shared_info. */
per_cpu(xen_vcpu, 0) = _shared_info->vcpu_info[0];

+   WARN_ON(xen_cpuhp_setup());
+
local_irq_disable();
early_boot_irqs_disabled = true;


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

Re: [Xen-devel] [PATCH v2 13/30] xen: introduce a new format specifier to print sizes in human-readable form

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Roger Pau Monne
> Sent: 27 September 2016 16:57
> To: xen-de...@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
> ; Tim (Xen.org) ; Jan Beulich
> ; boris.ostrov...@oracle.com; Roger Pau Monne
> 
> Subject: [Xen-devel] [PATCH v2 13/30] xen: introduce a new format specifier
> to print sizes in human-readable form
> 
> Introduce a new %pB format specifier to print sizes (in bytes) in a human-
> readable form.
> 

This comment does not seem to match the code. You use 'Z' below...

  Paul

> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> ---
>  docs/misc/printk-formats.txt |  5 +
>  xen/common/vsprintf.c| 15 +++
>  2 files changed, 20 insertions(+)
> 
> diff --git a/docs/misc/printk-formats.txt b/docs/misc/printk-formats.txt
> index 525108f..0ee3504 100644
> --- a/docs/misc/printk-formats.txt
> +++ b/docs/misc/printk-formats.txt
> @@ -30,3 +30,8 @@ Domain and vCPU information:
> 
> %pv Domain and vCPU ID from a 'struct vcpu *' (printed as
> "dv")
> +
> +Size in human readable form:
> +
> +   %pZ Size in human-readable form (input size must be in bytes).
> + e.g.  24MB
> diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c index
> f92fb67..2dadaec 100644
> --- a/xen/common/vsprintf.c
> +++ b/xen/common/vsprintf.c
> @@ -386,6 +386,21 @@ static char *pointer(char *str, char *end, const char
> **fmt_ptr,
>  *str = 'v';
>  return number(str + 1, end, v->vcpu_id, 10, -1, -1, 0);
>  }
> +case 'Z':
> +{
> +static const char units[][3] = {"B", "KB", "MB", "GB", "TB"};
> +size_t size = (size_t)arg;
> +int i = 0;
> +
> +/* Advance parents fmt string, as we have consumed 'B' */
> +++*fmt_ptr;
> +
> +while ( ++i < sizeof(units) && size >= 1024 )
> +size >>= 10; /* size /= 1024 */
> +
> +str = number(str, end, size, 10, -1, -1, 0);
> +return string(str, end, units[i-1], -1, -1, 0);
> +}
>  }
> 
>  if ( field_width == -1 )
> --
> 2.7.4 (Apple Git-66)
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 03/30] xen/x86: fix parameters and return value of *_set_allocation functions

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Roger Pau Monne
> Sent: 27 September 2016 16:57
> To: xen-de...@lists.xenproject.org
> Cc: George Dunlap ; Andrew Cooper
> ; Tim (Xen.org) ; Jan Beulich
> ; boris.ostrov...@oracle.com; Roger Pau Monne
> 
> Subject: [Xen-devel] [PATCH v2 03/30] xen/x86: fix parameters and return
> value of *_set_allocation functions
> 
> Return should be an int, and the number of pages should be an unsigned
> long.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: George Dunlap 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Tim Deegan 
> ---
>  xen/arch/x86/mm/hap/hap.c   |  6 +++---
>  xen/arch/x86/mm/shadow/common.c |  7 +++
>  xen/include/asm-x86/domain.h| 12 ++--
>  3 files changed, 12 insertions(+), 13 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
> index 3218fa2..b6d2c61 100644
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -325,7 +325,7 @@ static void hap_free_p2m_page(struct domain *d,
> struct page_info *pg)
>  static unsigned int
>  hap_get_allocation(struct domain *d)
>  {
> -unsigned int pg = d->arch.paging.hap.total_pages
> +unsigned long pg = d->arch.paging.hap.total_pages
>  + d->arch.paging.hap.p2m_pages;

You are modifying this calculation (by including hap.p2m_pages as well as 
hap.total_pages) so the comment should probably mention this.

> 
>  return ((pg >> (20 - PAGE_SHIFT))
> @@ -334,8 +334,8 @@ hap_get_allocation(struct domain *d)
> 
>  /* Set the pool of pages to the required number of pages.
>   * Returns 0 for success, non-zero for failure. */
> -static unsigned int
> -hap_set_allocation(struct domain *d, unsigned int pages, int *preempted)
> +static int
> +hap_set_allocation(struct domain *d, unsigned long pages, int
> *preempted)
>  {
>  struct page_info *pg;
> 
> diff --git a/xen/arch/x86/mm/shadow/common.c
> b/xen/arch/x86/mm/shadow/common.c
> index 21607bf..d3cc2cc 100644
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -1613,9 +1613,8 @@ shadow_free_p2m_page(struct domain *d, struct
> page_info *pg)
>   * Input will be rounded up to at least shadow_min_acceptable_pages(),
>   * plus space for the p2m table.
>   * Returns 0 for success, non-zero for failure. */
> -static unsigned int sh_set_allocation(struct domain *d,
> -  unsigned int pages,
> -  int *preempted)
> +static int sh_set_allocation(struct domain *d, unsigned long pages,
> + int *preempted)
>  {
>  struct page_info *sp;
>  unsigned int lower_bound;
> @@ -1692,7 +1691,7 @@ static unsigned int sh_set_allocation(struct domain
> *d,
>  /* Return the size of the shadow pool, rounded up to the nearest MB */
>  static unsigned int shadow_get_allocation(struct domain *d)
>  {
> -unsigned int pg = d->arch.paging.shadow.total_pages
> +unsigned long pg = d->arch.paging.shadow.total_pages
>  + d->arch.paging.shadow.p2m_pages;

Same here.

>  return ((pg >> (20 - PAGE_SHIFT))
>  + ((pg & ((1 << (20 - PAGE_SHIFT)) - 1)) ? 1 : 0));

OMG. Is there no rounding macro you can use for this?

  Paul

> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index 5807a1f..11ac2a5 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -93,9 +93,9 @@ struct shadow_domain {
> 
>  /* Memory allocation */
>  struct page_list_head freelist;
> -unsigned int  total_pages;  /* number of pages allocated */
> -unsigned int  free_pages;   /* number of pages on freelists */
> -unsigned int  p2m_pages;/* number of pages allocates to p2m */
> +unsigned long  total_pages;  /* number of pages allocated */
> +unsigned long  free_pages;   /* number of pages on freelists */
> +unsigned long  p2m_pages;/* number of pages allocates to p2m */
> 
>  /* 1-to-1 map for use when HVM vcpus have paging disabled */
>  pagetable_t unpaged_pagetable;
> @@ -155,9 +155,9 @@ struct shadow_vcpu {
>  //
>  struct hap_domain {
>  struct page_list_head freelist;
> -unsigned int  total_pages;  /* number of pages allocated */
> -unsigned int  free_pages;   /* number of pages on freelists */
> -unsigned int  p2m_pages;/* number of pages allocates to p2m */
> +unsigned long  total_pages;  /* number of pages allocated */
> +unsigned long  free_pages;   /* number of pages on freelists */
> +unsigned long  p2m_pages;/* number of pages allocates to p2m */
>  };
> 
>  

[Xen-devel] [PATCH net-next 6/7] xen-netback: batch copies for multiple to-guest rx packets

[Paul Durrant]

From: David Vrabel 

Instead of flushing the copy ops when an packet is complete, complete
packets when their copy ops are done.  This improves performance by
reducing the number of grant copy hypercalls.

Latency is still limited by the relatively small size of the copy
batch.

Signed-off-by: David Vrabel 
[re-based]
Signed-off-by: Paul Durrant 
---
Cc: Wei Liu 
---
 drivers/net/xen-netback/common.h |  1 +
 drivers/net/xen-netback/rx.c | 27 +--
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index adef482..5d40603 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -132,6 +132,7 @@ struct xenvif_copy_state {
struct gnttab_copy op[COPY_BATCH_SIZE];
RING_IDX idx[COPY_BATCH_SIZE];
unsigned int num;
+   struct sk_buff_head *completed;
 };
 
 struct xenvif_queue { /* Per-queue data for xenvif */
diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index ae822b8..8c8c5b5 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -133,6 +133,7 @@ static void xenvif_rx_queue_drop_expired(struct 
xenvif_queue *queue)
 static void xenvif_rx_copy_flush(struct xenvif_queue *queue)
 {
unsigned int i;
+   int notify;
 
gnttab_batch_copy(queue->rx_copy.op, queue->rx_copy.num);
 
@@ -154,6 +155,13 @@ static void xenvif_rx_copy_flush(struct xenvif_queue 
*queue)
}
 
queue->rx_copy.num = 0;
+
+   /* Push responses for all completed packets. */
+   RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(>rx, notify);
+   if (notify)
+   notify_remote_via_irq(queue->rx_irq);
+
+   __skb_queue_purge(queue->rx_copy.completed);
 }
 
 static void xenvif_rx_copy_add(struct xenvif_queue *queue,
@@ -279,18 +287,10 @@ static void xenvif_rx_next_skb(struct xenvif_queue *queue,
 static void xenvif_rx_complete(struct xenvif_queue *queue,
   struct xenvif_pkt_state *pkt)
 {
-   int notify;
-
-   /* Complete any outstanding copy ops for this skb. */
-   xenvif_rx_copy_flush(queue);
-
-   /* Push responses and notify. */
+   /* All responses are ready to be pushed. */
queue->rx.rsp_prod_pvt = queue->rx.req_cons;
-   RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(>rx, notify);
-   if (notify)
-   notify_remote_via_irq(queue->rx_irq);
 
-   dev_kfree_skb(pkt->skb);
+   __skb_queue_tail(queue->rx_copy.completed, pkt->skb);
 }
 
 static void xenvif_rx_next_chunk(struct xenvif_queue *queue,
@@ -429,13 +429,20 @@ void xenvif_rx_skb(struct xenvif_queue *queue)
 
 void xenvif_rx_action(struct xenvif_queue *queue)
 {
+   struct sk_buff_head completed_skbs;
unsigned int work_done = 0;
 
+   __skb_queue_head_init(_skbs);
+   queue->rx_copy.completed = _skbs;
+
while (xenvif_rx_ring_slots_available(queue) &&
   work_done < RX_BATCH_SIZE) {
xenvif_rx_skb(queue);
work_done++;
}
+
+   /* Flush any pending copies and complete all skbs. */
+   xenvif_rx_copy_flush(queue);
 }
 
 static bool xenvif_rx_queue_stalled(struct xenvif_queue *queue)
-- 
2.1.4


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

[Xen-devel] [PATCH net-next 7/7] xen/netback: add fraglist support for to-guest rx

[Paul Durrant]

From: Ross Lagerwall 

This allows full 64K skbuffs (with 1500 mtu ethernet, composed of 45
fragments) to be handled by netback for to-guest rx.

Signed-off-by: Ross Lagerwall 
[re-based]
Signed-off-by: Paul Durrant 
---
Cc: Wei Liu 
---
 drivers/net/xen-netback/interface.c |  2 +-
 drivers/net/xen-netback/rx.c| 38 -
 2 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index 1a009e7..8fef4fe 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -476,7 +476,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t 
domid,
dev->netdev_ops = _netdev_ops;
dev->hw_features = NETIF_F_SG |
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
-   NETIF_F_TSO | NETIF_F_TSO6;
+   NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_FRAGLIST;
dev->features = dev->hw_features | NETIF_F_RXCSUM;
dev->ethtool_ops = _ethtool_ops;
 
diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index 8c8c5b5..8e9ade6 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -215,7 +215,8 @@ static unsigned int xenvif_gso_type(struct sk_buff *skb)
 struct xenvif_pkt_state {
struct sk_buff *skb;
size_t remaining_len;
-   int frag; /* frag == -1 => skb->head */
+   struct sk_buff *frag_iter;
+   int frag; /* frag == -1 => frag_iter->head */
unsigned int frag_offset;
struct xen_netif_extra_info extras[XEN_NETIF_EXTRA_TYPE_MAX - 1];
unsigned int extra_count;
@@ -237,6 +238,7 @@ static void xenvif_rx_next_skb(struct xenvif_queue *queue,
memset(pkt, 0, sizeof(struct xenvif_pkt_state));
 
pkt->skb = skb;
+   pkt->frag_iter = skb;
pkt->remaining_len = skb->len;
pkt->frag = -1;
 
@@ -293,20 +295,40 @@ static void xenvif_rx_complete(struct xenvif_queue *queue,
__skb_queue_tail(queue->rx_copy.completed, pkt->skb);
 }
 
+static void xenvif_rx_next_frag(struct xenvif_pkt_state *pkt)
+{
+   struct sk_buff *frag_iter = pkt->frag_iter;
+   unsigned int nr_frags = skb_shinfo(frag_iter)->nr_frags;
+
+   pkt->frag++;
+   pkt->frag_offset = 0;
+
+   if (pkt->frag >= nr_frags) {
+   if (frag_iter == pkt->skb)
+   pkt->frag_iter = skb_shinfo(frag_iter)->frag_list;
+   else
+   pkt->frag_iter = frag_iter->next;
+
+   pkt->frag = -1;
+   }
+}
+
 static void xenvif_rx_next_chunk(struct xenvif_queue *queue,
 struct xenvif_pkt_state *pkt,
 unsigned int offset, void **data,
 size_t *len)
 {
-   struct sk_buff *skb = pkt->skb;
+   struct sk_buff *frag_iter = pkt->frag_iter;
void *frag_data;
size_t frag_len, chunk_len;
 
+   BUG_ON(!frag_iter);
+
if (pkt->frag == -1) {
-   frag_data = skb->data;
-   frag_len = skb_headlen(skb);
+   frag_data = frag_iter->data;
+   frag_len = skb_headlen(frag_iter);
} else {
-   skb_frag_t *frag = _shinfo(skb)->frags[pkt->frag];
+   skb_frag_t *frag = _shinfo(frag_iter)->frags[pkt->frag];
 
frag_data = skb_frag_address(frag);
frag_len = skb_frag_size(frag);
@@ -322,10 +344,8 @@ static void xenvif_rx_next_chunk(struct xenvif_queue 
*queue,
pkt->frag_offset += chunk_len;
 
/* Advance to next frag? */
-   if (frag_len == chunk_len) {
-   pkt->frag++;
-   pkt->frag_offset = 0;
-   }
+   if (frag_len == chunk_len)
+   xenvif_rx_next_frag(pkt);
 
*data = frag_data;
*len = chunk_len;
-- 
2.1.4


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

[Xen-devel] [PATCH net-next 2/7] xen-netback: retire guest rx side prefix GSO feature

[Paul Durrant]

As far as I am aware only very old Windows network frontends make use of
this style of passing GSO packets from backend to frontend. These
frontends can easily be replaced by the freely available Xen Project
Windows PV network frontend, which uses the 'default' mechanism for
passing GSO packets, which is also used by all Linux frontends.

NOTE: Removal of this feature will not cause breakage in old Windows
  frontends. They simply will no longer receive GSO packets - the
  packets instead being fragmented in the backend.

Signed-off-by: Paul Durrant 
---
Cc: Wei Liu 
---
 drivers/net/xen-netback/common.h|  1 -
 drivers/net/xen-netback/interface.c |  4 ++--
 drivers/net/xen-netback/rx.c| 26 --
 drivers/net/xen-netback/xenbus.c| 21 -
 4 files changed, 2 insertions(+), 50 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 3a56268..e16004a 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -260,7 +260,6 @@ struct xenvif {
 
/* Frontend feature information. */
int gso_mask;
-   int gso_prefix_mask;
 
u8 can_sg:1;
u8 ip_csum:1;
diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index 83deeeb..1a009e7 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -328,9 +328,9 @@ static netdev_features_t xenvif_fix_features(struct 
net_device *dev,
 
if (!vif->can_sg)
features &= ~NETIF_F_SG;
-   if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV4))
+   if (~(vif->gso_mask) & GSO_BIT(TCPV4))
features &= ~NETIF_F_TSO;
-   if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV6))
+   if (~(vif->gso_mask) & GSO_BIT(TCPV6))
features &= ~NETIF_F_TSO6;
if (!vif->ip_csum)
features &= ~NETIF_F_IP_CSUM;
diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index 03836aa..6bd7d6e 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -347,16 +347,6 @@ static int xenvif_gop_skb(struct sk_buff *skb,
gso_type = XEN_NETIF_GSO_TYPE_TCPV6;
}
 
-   /* Set up a GSO prefix descriptor, if necessary */
-   if ((1 << gso_type) & vif->gso_prefix_mask) {
-   RING_COPY_REQUEST(>rx, queue->rx.req_cons++, );
-   meta = npo->meta + npo->meta_prod++;
-   meta->gso_type = gso_type;
-   meta->gso_size = skb_shinfo(skb)->gso_size;
-   meta->size = 0;
-   meta->id = req.id;
-   }
-
RING_COPY_REQUEST(>rx, queue->rx.req_cons++, );
meta = npo->meta + npo->meta_prod++;
 
@@ -511,22 +501,6 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
while ((skb = __skb_dequeue()) != NULL) {
struct xen_netif_extra_info *extra = NULL;
 
-   if ((1 << queue->meta[npo.meta_cons].gso_type) &
-   vif->gso_prefix_mask) {
-   resp = RING_GET_RESPONSE(>rx,
-queue->rx.rsp_prod_pvt++);
-
-   resp->flags = XEN_NETRXF_gso_prefix |
- XEN_NETRXF_more_data;
-
-   resp->offset = queue->meta[npo.meta_cons].gso_size;
-   resp->id = queue->meta[npo.meta_cons].id;
-   resp->status = XENVIF_RX_CB(skb)->meta_slots_used;
-
-   npo.meta_cons++;
-   XENVIF_RX_CB(skb)->meta_slots_used--;
-   }
-
queue->stats.tx_bytes += skb->len;
queue->stats.tx_packets++;
 
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index bacf6e0..6c57b02 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -1154,7 +1154,6 @@ static int read_xenbus_vif_flags(struct backend_info *be)
vif->can_sg = !!val;
 
vif->gso_mask = 0;
-   vif->gso_prefix_mask = 0;
 
if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv4",
 "%d", ) < 0)
@@ -1162,32 +1161,12 @@ static int read_xenbus_vif_flags(struct backend_info 
*be)
if (val)
vif->gso_mask |= GSO_BIT(TCPV4);
 
-   if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv4-prefix",
-"%d", ) < 0)
-   val = 0;
-   if (val)
-   vif->gso_prefix_mask |= GSO_BIT(TCPV4);
-
if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv6",
 "%d", ) < 0)
val = 0;
if (val)
vif->gso_mask |= GSO_BIT(TCPV6);
 
-   if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv6-prefix",
-"%d", ) < 

[Xen-devel] [PATCH net-next 5/7] xen-netback: process guest rx packets in batches

[Paul Durrant]

From: David Vrabel 

Instead of only placing one skb on the guest rx ring at a time, process
a batch of up-to 64.  This improves performance by ~10% in some tests.

Signed-off-by: David Vrabel 
[re-based]
Signed-off-by: Paul Durrant 
---
Cc: Wei Liu 
---
 drivers/net/xen-netback/rx.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index 9548709..ae822b8 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -399,7 +399,7 @@ static void xenvif_rx_extra_slot(struct xenvif_queue *queue,
BUG();
 }
 
-void xenvif_rx_action(struct xenvif_queue *queue)
+void xenvif_rx_skb(struct xenvif_queue *queue)
 {
struct xenvif_pkt_state pkt;
 
@@ -425,6 +425,19 @@ void xenvif_rx_action(struct xenvif_queue *queue)
xenvif_rx_complete(queue, );
 }
 
+#define RX_BATCH_SIZE 64
+
+void xenvif_rx_action(struct xenvif_queue *queue)
+{
+   unsigned int work_done = 0;
+
+   while (xenvif_rx_ring_slots_available(queue) &&
+  work_done < RX_BATCH_SIZE) {
+   xenvif_rx_skb(queue);
+   work_done++;
+   }
+}
+
 static bool xenvif_rx_queue_stalled(struct xenvif_queue *queue)
 {
RING_IDX prod, cons;
-- 
2.1.4


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

[Xen-devel] [PATCH net-next 4/7] xen-netback: immediately wake tx queue when guest rx queue has space

[Paul Durrant]

From: David Vrabel 

When an skb is removed from the guest rx queue, immediately wake the
tx queue, instead of after processing them.

Signed-off-by: David Vrabel 
[re-based]
Signed-off-by: Paul Durrant 
---
Cc: Wei Liu 
---
 drivers/net/xen-netback/rx.c | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index b0ce4c6..9548709 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -92,27 +92,21 @@ static struct sk_buff *xenvif_rx_dequeue(struct 
xenvif_queue *queue)
spin_lock_irq(>rx_queue.lock);
 
skb = __skb_dequeue(>rx_queue);
-   if (skb)
+   if (skb) {
queue->rx_queue_len -= skb->len;
+   if (queue->rx_queue_len < queue->rx_queue_max) {
+   struct netdev_queue *txq;
+
+   txq = netdev_get_tx_queue(queue->vif->dev, queue->id);
+   netif_tx_wake_queue(txq);
+   }
+   }
 
spin_unlock_irq(>rx_queue.lock);
 
return skb;
 }
 
-static void xenvif_rx_queue_maybe_wake(struct xenvif_queue *queue)
-{
-   spin_lock_irq(>rx_queue.lock);
-
-   if (queue->rx_queue_len < queue->rx_queue_max) {
-   struct net_device *dev = queue->vif->dev;
-
-   netif_tx_wake_queue(netdev_get_tx_queue(dev, queue->id));
-   }
-
-   spin_unlock_irq(>rx_queue.lock);
-}
-
 static void xenvif_rx_queue_purge(struct xenvif_queue *queue)
 {
struct sk_buff *skb;
@@ -585,8 +579,6 @@ int xenvif_kthread_guest_rx(void *data)
 */
xenvif_rx_queue_drop_expired(queue);
 
-   xenvif_rx_queue_maybe_wake(queue);
-
cond_resched();
}
 
-- 
2.1.4


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

[Xen-devel] [PATCH net-next 0/7] xen-netback: guest rx side refactor

[Paul Durrant]

This series refactors the guest rx side of xen-netback:

- The code is moved into its own source module.

- The prefix variant of GSO handling is retired (since it is no longer
  in common use, and alternatives exist).

- The code is then simplified and modifications made to improve
  performance.

David Vrabel (4):
  xen-netback: refactor guest rx
  xen-netback: immediately wake tx queue when guest rx queue has space
  xen-netback: process guest rx packets in batches
  xen-netback: batch copies for multiple to-guest rx packets

Paul Durrant (2):
  xen-netback: separate guest side rx code into separate module
  xen-netback: retire guest rx side prefix GSO feature

Ross Lagerwall (1):
  xen/netback: add fraglist support for to-guest rx

 drivers/net/xen-netback/Makefile|   2 +-
 drivers/net/xen-netback/common.h|  25 +-
 drivers/net/xen-netback/interface.c |   6 +-
 drivers/net/xen-netback/netback.c   | 754 
 drivers/net/xen-netback/rx.c| 628 ++
 drivers/net/xen-netback/xenbus.c|  21 -
 6 files changed, 643 insertions(+), 793 deletions(-)
 create mode 100644 drivers/net/xen-netback/rx.c

-- 
2.1.4


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

[Xen-devel] [PATCH net-next 1/7] xen-netback: separate guest side rx code into separate module

[Paul Durrant]

The netback source module has become very large and somewhat confusing.
This patch simply moves all code related to the backend to frontend (i.e
guest side rx) data-path into a separate rx source module.

This patch contains no functional change, it is code movement and
minimal changes to avoid patch style-check issues.

Signed-off-by: Paul Durrant 
---
Cc: Wei Liu 
---
 drivers/net/xen-netback/Makefile  |   2 +-
 drivers/net/xen-netback/netback.c | 754 
 drivers/net/xen-netback/rx.c  | 789 ++
 3 files changed, 790 insertions(+), 755 deletions(-)
 create mode 100644 drivers/net/xen-netback/rx.c

diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
index 11e02be..d49798a 100644
--- a/drivers/net/xen-netback/Makefile
+++ b/drivers/net/xen-netback/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
 
-xen-netback-y := netback.o xenbus.o interface.o hash.o
+xen-netback-y := netback.o xenbus.o interface.o hash.o rx.o
diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index edbae0b..1f9d92e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -106,13 +106,6 @@ static void push_tx_responses(struct xenvif_queue *queue);
 
 static inline int tx_work_todo(struct xenvif_queue *queue);
 
-static struct xen_netif_rx_response *make_rx_response(struct xenvif_queue 
*queue,
-u16  id,
-s8   st,
-u16  offset,
-u16  size,
-u16  flags);
-
 static inline unsigned long idx_to_pfn(struct xenvif_queue *queue,
   u16 idx)
 {
@@ -155,571 +148,11 @@ static inline pending_ring_idx_t pending_index(unsigned 
i)
return i & (MAX_PENDING_REQS-1);
 }
 
-static bool xenvif_rx_ring_slots_available(struct xenvif_queue *queue)
-{
-   RING_IDX prod, cons;
-   struct sk_buff *skb;
-   int needed;
-
-   skb = skb_peek(>rx_queue);
-   if (!skb)
-   return false;
-
-   needed = DIV_ROUND_UP(skb->len, XEN_PAGE_SIZE);
-   if (skb_is_gso(skb))
-   needed++;
-   if (skb->sw_hash)
-   needed++;
-
-   do {
-   prod = queue->rx.sring->req_prod;
-   cons = queue->rx.req_cons;
-
-   if (prod - cons >= needed)
-   return true;
-
-   queue->rx.sring->req_event = prod + 1;
-
-   /* Make sure event is visible before we check prod
-* again.
-*/
-   mb();
-   } while (queue->rx.sring->req_prod != prod);
-
-   return false;
-}
-
-void xenvif_rx_queue_tail(struct xenvif_queue *queue, struct sk_buff *skb)
-{
-   unsigned long flags;
-
-   spin_lock_irqsave(>rx_queue.lock, flags);
-
-   __skb_queue_tail(>rx_queue, skb);
-
-   queue->rx_queue_len += skb->len;
-   if (queue->rx_queue_len > queue->rx_queue_max)
-   netif_tx_stop_queue(netdev_get_tx_queue(queue->vif->dev, 
queue->id));
-
-   spin_unlock_irqrestore(>rx_queue.lock, flags);
-}
-
-static struct sk_buff *xenvif_rx_dequeue(struct xenvif_queue *queue)
-{
-   struct sk_buff *skb;
-
-   spin_lock_irq(>rx_queue.lock);
-
-   skb = __skb_dequeue(>rx_queue);
-   if (skb)
-   queue->rx_queue_len -= skb->len;
-
-   spin_unlock_irq(>rx_queue.lock);
-
-   return skb;
-}
-
-static void xenvif_rx_queue_maybe_wake(struct xenvif_queue *queue)
-{
-   spin_lock_irq(>rx_queue.lock);
-
-   if (queue->rx_queue_len < queue->rx_queue_max)
-   netif_tx_wake_queue(netdev_get_tx_queue(queue->vif->dev, 
queue->id));
-
-   spin_unlock_irq(>rx_queue.lock);
-}
-
-
-static void xenvif_rx_queue_purge(struct xenvif_queue *queue)
-{
-   struct sk_buff *skb;
-   while ((skb = xenvif_rx_dequeue(queue)) != NULL)
-   kfree_skb(skb);
-}
-
-static void xenvif_rx_queue_drop_expired(struct xenvif_queue *queue)
-{
-   struct sk_buff *skb;
-
-   for(;;) {
-   skb = skb_peek(>rx_queue);
-   if (!skb)
-   break;
-   if (time_before(jiffies, XENVIF_RX_CB(skb)->expires))
-   break;
-   xenvif_rx_dequeue(queue);
-   kfree_skb(skb);
-   }
-}
-
-struct netrx_pending_operations {
-   unsigned copy_prod, copy_cons;
-   unsigned meta_prod, meta_cons;
-   struct gnttab_copy *copy;
-   struct xenvif_rx_meta *meta;
-   int copy_off;
-   grant_ref_t copy_gref;
-};
-
-static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif_queue *queue,
-struct 

[Xen-devel] [PATCH net-next 3/7] xen-netback: refactor guest rx

[Paul Durrant]

From: David Vrabel 

Refactor the to-guest (rx) path to:

1. Push responses for completed skbs earlier, reducing latency.

2. Reduce the per-queue memory overhead by greatly reducing the
   maximum number of grant copy ops in each hypercall (from 4352 to
   64).  Each struct xenvif_queue is now only 44 kB instead of 220 kB.

3. Make the code more maintainable.

Signed-off-by: David Vrabel 
[re-based]
Signed-off-by: Paul Durrant 
---
Cc: Wei Liu 
---
 drivers/net/xen-netback/common.h |  23 +-
 drivers/net/xen-netback/rx.c | 654 +++
 2 files changed, 254 insertions(+), 423 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index e16004a..adef482 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -91,13 +91,6 @@ struct xenvif_rx_meta {
  */
 #define MAX_XEN_SKB_FRAGS (65536 / XEN_PAGE_SIZE + 1)
 
-/* It's possible for an skb to have a maximal number of frags
- * but still be less than MAX_BUFFER_OFFSET in size. Thus the
- * worst-case number of copy operations is MAX_XEN_SKB_FRAGS per
- * ring slot.
- */
-#define MAX_GRANT_COPY_OPS (MAX_XEN_SKB_FRAGS * XEN_NETIF_RX_RING_SIZE)
-
 #define NETBACK_INVALID_HANDLE -1
 
 /* To avoid confusion, we define XEN_NETBK_LEGACY_SLOTS_MAX indicating
@@ -133,6 +126,14 @@ struct xenvif_stats {
unsigned long tx_frag_overflow;
 };
 
+#define COPY_BATCH_SIZE 64
+
+struct xenvif_copy_state {
+   struct gnttab_copy op[COPY_BATCH_SIZE];
+   RING_IDX idx[COPY_BATCH_SIZE];
+   unsigned int num;
+};
+
 struct xenvif_queue { /* Per-queue data for xenvif */
unsigned int id; /* Queue ID, 0-based */
char name[QUEUE_NAME_SIZE]; /* DEVNAME-qN */
@@ -189,12 +190,7 @@ struct xenvif_queue { /* Per-queue data for xenvif */
unsigned long last_rx_time;
bool stalled;
 
-   struct gnttab_copy grant_copy_op[MAX_GRANT_COPY_OPS];
-
-   /* We create one meta structure per ring request we consume, so
-* the maximum number is the same as the ring size.
-*/
-   struct xenvif_rx_meta meta[XEN_NETIF_RX_RING_SIZE];
+   struct xenvif_copy_state rx_copy;
 
/* Transmit shaping: allow 'credit_bytes' every 'credit_usec'. */
unsigned long   credit_bytes;
@@ -360,6 +356,7 @@ int xenvif_dealloc_kthread(void *data);
 
 int xenvif_ctrl_kthread(void *data);
 
+void xenvif_rx_action(struct xenvif_queue *queue);
 void xenvif_rx_queue_tail(struct xenvif_queue *queue, struct sk_buff *skb);
 
 void xenvif_carrier_on(struct xenvif *vif);
diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index 6bd7d6e..b0ce4c6 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -26,7 +26,6 @@
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
  * IN THE SOFTWARE.
  */
-
 #include "common.h"
 
 #include 
@@ -137,464 +136,299 @@ static void xenvif_rx_queue_drop_expired(struct 
xenvif_queue *queue)
}
 }
 
-struct netrx_pending_operations {
-   unsigned int copy_prod, copy_cons;
-   unsigned int meta_prod, meta_cons;
-   struct gnttab_copy *copy;
-   struct xenvif_rx_meta *meta;
-   int copy_off;
-   grant_ref_t copy_gref;
-};
-
-static struct xenvif_rx_meta *get_next_rx_buffer(
-   struct xenvif_queue *queue,
-   struct netrx_pending_operations *npo)
+static void xenvif_rx_copy_flush(struct xenvif_queue *queue)
 {
-   struct xenvif_rx_meta *meta;
-   struct xen_netif_rx_request req;
+   unsigned int i;
 
-   RING_COPY_REQUEST(>rx, queue->rx.req_cons++, );
+   gnttab_batch_copy(queue->rx_copy.op, queue->rx_copy.num);
 
-   meta = npo->meta + npo->meta_prod++;
-   meta->gso_type = XEN_NETIF_GSO_TYPE_NONE;
-   meta->gso_size = 0;
-   meta->size = 0;
-   meta->id = req.id;
+   for (i = 0; i < queue->rx_copy.num; i++) {
+   struct gnttab_copy *op;
 
-   npo->copy_off = 0;
-   npo->copy_gref = req.gref;
+   op = >rx_copy.op[i];
 
-   return meta;
+   /* If the copy failed, overwrite the status field in
+* the corresponding response.
+*/
+   if (unlikely(op->status != GNTST_okay)) {
+   struct xen_netif_rx_response *rsp;
+
+   rsp = RING_GET_RESPONSE(>rx,
+   queue->rx_copy.idx[i]);
+   rsp->status = op->status;
+   }
+   }
+
+   queue->rx_copy.num = 0;
 }
 
-struct gop_frag_copy {
-   struct xenvif_queue *queue;
-   struct netrx_pending_operations *npo;
-   struct xenvif_rx_meta *meta;
-   int head;
-   int gso_type;
-   int protocol;
-   int hash_present;
-
-   struct page *page;
-};
-
-static void xenvif_setup_copy_gop(unsigned long