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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
113666
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 113666

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail in 113703 pass in 113730
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 113703 pass in 113730
 test-armhf-armhf-libvirt-raw  6 xen-install  fail in 113703 pass in 113730
 test-armhf-armhf-xl-cubietruck  6 xen-install  fail pass in 113703
 test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail 
pass in 113703
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail pass in 113703
 test-armhf-armhf-xl-vhd  10 debian-di-install  fail pass in 113703

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 113703 
like 113666
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 113703 like 
113666
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 113703 never 
pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 113703 
never pass
 test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 113703 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 113703 never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113666
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 113666
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 113666
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113666
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 113666
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux6e80ecdddf4ea6f3cd84e83720f3d852e6624a68
baseline version:
 linuxc52f56a69d104d5294af3d652776d94b1ef6a175

Last test of basis   113666  2017-09-21 12:50:30 Z1 days
Testing same since   113703  2017-09-22 02:22:02 Z1 days2 attempts


People who touched revisions under test:
  Al Viro 
  Arnd Bergmann 
  Boris Brezillon 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ba30d5f0512196b1ee7b3d864f980e551da0ebf5
baseline version:
 ovmf 947f3737abf65fda63f3ffd97fddfa6986986868

Last test of basis   113647  2017-09-20 22:34:05 Z2 days
Failing since113654  2017-09-21 06:22:39 Z1 days9 attempts
Testing same since   113739  2017-09-22 17:57:03 Z0 days1 attempts


People who touched revisions under test:
  Amit Kumar 
  Ard Biesheuvel 
  Dandan Bi 
  Gabriel Somlo 
  Hao Wu 
  Huajing Li 
  Jian J Wang 
  Laszlo Ersek 
  Star Zeng 

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=ba30d5f0512196b1ee7b3d864f980e551da0ebf5
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ 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 
ba30d5f0512196b1ee7b3d864f980e551da0ebf5
+ branch=ovmf
+ revision=ba30d5f0512196b1ee7b3d864f980e551da0ebf5
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.:.
 PERLLIB=.:.:.
+++ 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
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ 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.9-testing
+ '[' xba30d5f0512196b1ee7b3d864f980e551da0ebf5 = 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
++ : 

[Xen-devel] [seabios test] 113733: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 113492

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 113492
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 seabios  d6728f301d7e6e31ba0ee2fa51ed4a24feab8860
baseline version:
 seabios  ec6cb17f89498bcd6123e50a0368a414e6e85d82

Last test of basis   113492  2017-09-15 21:16:16 Z7 days
Testing same since   113733  2017-09-22 15:20:41 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



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

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

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

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


Pushing revision :

+ branch=seabios
+ revision=d6728f301d7e6e31ba0ee2fa51ed4a24feab8860
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ 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 seabios 
d6728f301d7e6e31ba0ee2fa51ed4a24feab8860
+ branch=seabios
+ revision=d6728f301d7e6e31ba0ee2fa51ed4a24feab8860
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.:.
 PERLLIB=.:.:.
+++ 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 

[Xen-devel] [xen-unstable test] 113724: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
113387

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 113387

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds   16 guest-start/debian.repeat fail blocked in 113387
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113387
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113387
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 113387
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 113387
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 113387
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 113387
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  73b9640a3c4a6ea093c7fee231df717f66e3
baseline version:
 xen  16b1414de91b5a82a0996c67f6db3af7d7e32873

Last test of basis   113387  2017-09-12 23:20:09 Z   10 days
Failing since113430  2017-09-14 01:24:48 Z9 days   17 attempts
Testing same since   113691  2017-09-21 21:17:07 Z1 days2 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andrew Cooper 
  Bhupinder Thakur 
  Boris Ostrovsky 
  Daniel De Graaf 
  Dario Faggioli 
  George Dunlap 
  Haozhong Zhang 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Konrad Rzeszutek 

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

[Thomas Garnier]

On Thu, Sep 21, 2017 at 2:21 PM, Thomas Garnier  wrote:
> On Thu, Sep 21, 2017 at 9:10 AM, Ard Biesheuvel
>  wrote:
>>
>> On 21 September 2017 at 08:59, Ingo Molnar  wrote:
>> >
>> > ( Sorry about the delay in answering this. I could blame the delay on the 
>> > merge
>> >   window, but in reality I've been procrastinating this is due to the 
>> > permanent,
>> >   non-trivial impact PIE has on generated C code. )
>> >
>> > * Thomas Garnier  wrote:
>> >
>> >> 1) PIE sometime needs two instructions to represent a single
>> >> instruction on mcmodel=kernel.
>> >
>> > What again is the typical frequency of this occurring in an x86-64 
>> > defconfig
>> > kernel, with the very latest GCC?
>> >
>> > Also, to make sure: which unwinder did you use for your measurements,
>> > frame-pointers or ORC? Please use ORC only for future numbers, as
>> > frame-pointers is obsolete from a performance measurement POV.
>> >
>> >> 2) GCC does not optimize switches in PIE in order to reduce relocations:
>> >
>> > Hopefully this can either be fixed in GCC or at least influenced via a 
>> > compiler
>> > switch in the future.
>> >
>>
>> There are somewhat related concerns in the ARM world, so it would be
>> good if we could work with the GCC developers to get a more high level
>> and arch neutral command line option (-mkernel-pie? sounds yummy!)
>> that stops the compiler from making inferences that only hold for
>> shared libraries and/or other hosted executables (GOT indirections,
>> avoiding text relocations etc). That way, we will also be able to drop
>> the 'hidden' visibility override at some point, which we currently
>> need to prevent the compiler from redirecting all global symbol
>> references via entries in the GOT.
>
> My plan was to add a -mtls-reg= to switch the default segment
> register for stack cookies but I can see great benefits in having a
> more general kernel flag that would allow to get rid of the GOT and
> PLT when you are building position independent code for the kernel. It
> could also include optimizations like folding switch tables etc...
>
> Should we start a separate discussion on that? Anyone that would be
> more experienced than I to push that to gcc & clang upstream?

After separate discussion, opened:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303

>
>>
>> All we really need is the ability to move the image around in virtual
>> memory, and things like reducing the CoW footprint or enabling ELF
>> symbol preemption are completely irrelevant for us.
>
>
>
>
> --
> Thomas



-- 
Thomas

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

[Xen-devel] [ovmf bisection] complete build-i386

[osstest service owner]

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

Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  ovmf https://github.com/tianocore/edk2.git
  Bug introduced:  f5566d1530e23fa09c1bf1616efc003f35135071
  Bug not present: 99c9b9490597d2ecdb9cbccd38fd4fdc9f44109a
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/113752/


  commit f5566d1530e23fa09c1bf1616efc003f35135071
  Author: Paulo Alcantara 
  Date:   Fri Sep 8 09:41:48 2017 -0300
  
  OvmfPkg: Enable UDF file system support
  
  This patch enables UDF file system support by default.
  
  Cc: Jordan Justen 
  Cc: Laszlo Ersek 
  Contributed-under: TianoCore Contribution Agreement 1.1
  Signed-off-by: Paulo Alcantara 
  Reviewed-by: Laszlo Ersek 
  Reviewed-by: Ruiyu Ni 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/ovmf/build-i386.xen-build 
--summary-out=tmp/113752.bisection-summary --basis-template=113647 
--blessings=real,real-bisect ovmf build-i386 xen-build
Searching for failure / basis pass:
 113719 fail [host=pinot1] / 113647 [host=baroque1] 113636 [host=baroque1] 
113621 [host=nobling1] 113608 [host=rimava1] 113599 [host=huxelrebe0] 113590 
[host=huxelrebe0] 113572 [host=huxelrebe0] 113566 [host=baroque0] 113526 
[host=elbling1] 113498 [host=baroque1] 113481 [host=chardonnay1] 113462 
[host=nobling0] 113443 [host=nobling1] 113143 [host=elbling1] 113130 
[host=elbling1] 113115 [host=huxelrebe0] 113078 [host=huxelrebe1] 113061 
[host=nobling0] 113050 [host=huxelrebe1] 113045 [host=baroque1] 113037 
[host=chardonnay0] 113029 [host=huxelrebe0] 113005 [host=huxelrebe0] 113000 
[host=huxelrebe0] 112991 [host=rimava0] 112986 [host=chardonnay0] 112971 
[host=chardonnay0] 112958 [host=rimava0] 112947 [host=baroque1] 112919 
[host=italia1] 112911 [host=huxelrebe1] 112903 [host=huxelrebe0] 112899 
[host=nobling0] 112883 [host=nobling0] 112878 [host=italia1] 112867 
[host=nobling1] 112859 [host=nocera1] 112846 [host=huxelrebe0] 112837 
[host=nobling0] 112782 [host=huxelrebe0] 112757 [host=elbling0] 112722 
[host=baroque1] 112702 [host=elbling0] 112687 [host=huxelrebe0] 112671 
[host=huxelrebe0] 112656 [host=baroque1] 112644 [host=huxelrebe0] 112636 
[host=fiano1] 112628 [host=nobling1] 112623 [host=rimava1] 112615 
[host=nobling0] 112606 [host=fiano1] 112601 [host=rimava1] 112594 
[host=rimava0] 112585 [host=rimava1] 112539 [host=huxelrebe1] 112532 
[host=elbling0] 112525 [host=huxelrebe1] 112522 [host=huxelrebe0] 112518 
[host=merlot1] 112512 [host=huxelrebe0] 112501 [host=baroque1] 112495 
[host=nobling1] 112464 [host=elbling0] 112455 [host=elbling0] 112439 
[host=rimava0] 112433 [host=merlot1] 112424 [host=baroque1] 112415 
[host=huxelrebe0] 112404 [host=nobling0] 112367 [host=italia1] 112356 
[host=chardonnay0] 112342 [host=baroque1] 112337 [host=nobling1] 112333 
[host=chardonnay0] 112322 [host=nobling1] 112315 [host=baroque1] 112309 
[host=merlot0] 112305 [host=baroque1] 112091 [host=nobling1] 112039 
[host=nobling0] 111973 [host=italia1] 111959 [host=italia1] 111948 
[host=baroque1] 111941 [host=baroque1] 111837 [host=baroque1] 111810 
[host=nobling0] 111785 [host=nobling0] 111715 [host=rimava1] 111704 
[host=rimava0] 111665 [host=nobling0] 111656 [host=rimava0] 111621 
[host=chardonnay0] 111544 [host=huxelrebe0] 111526 [host=italia0] 111513 
[host=italia0] 111470 [host=italia1] 111384 [host=rimava0] 111370 
[host=huxelrebe0] 111369 [host=rimava1] 111367 [host=rimava0] 111361 
[host=chardonnay0] 111355 [host=huxelrebe1] 111212 [host=huxelrebe1] 98 
[host=fiano0] 89 [host=chardonnay0] 72 [host=huxelrebe0] 53 
[host=nobling1] 05 [host=nobling1] 111089 [host=italia1] 111080 
[host=rimava1] 111076 [host=fiano0] 111067 [host=chardonnay0] 111037 
[host=fiano1] 111019 [host=huxelrebe0] 110988 [host=rimava1] 110965 
[host=rimava0] 110936 [host=italia0] 110905 [host=italia0] 110467 
[host=nocera0] 110439 [host=elbling0] 110414 [host=nocera0] 110393 
[host=italia1] 110263 [host=fiano0] 110195 [host=italia0] 110078 
[host=nobling0] 110056 [host=elbling0] 110023 [host=chardonnay0] 110011 
[host=nobling1] 110007 [host=italia1] 109950 [host=nocera0] 109932 
[host=baroque0] 109931 [host=nobling0] 109930 [host=italia1] 109923 
[host=rimava1] 109915 [host=baroque0] 109877 [host=baroque1] 109835 
[host=elbling0] 109816 [host=elbling1] 109794 [host=baroque0] 109791 

Re: [Xen-devel] Booting signed xen.efi through shim

[Daniel Kiper]

On Fri, Sep 22, 2017 at 02:25:46AM -0600, Jan Beulich wrote:
> >>> On 22.09.17 at 00:46,  wrote:
> > One piece that I see still missing is the Xen command line parameters
> > not being verified. It would be ideal to have the option to get that
> > set during compile time as well, similar to Linux's CONFIG_CMDLINE
> > option, to avoid for example getting iommu or XSM being turned off by
> > someone with physical access.
>
> We do have CMDLINE and CMDLINE_OVERRIDE. But for someone
> with physical access it would likely also be possible to avoid secure
> boot altogether?

Another solutions is here: 
http://lists.gnu.org/archive/html/grub-devel/2017-07/msg3.html
It is TPM based and WIP. It requires verifiers framework which should
be posted on grub-devel soon. Or you can add your own method based
on verifiers. Patches are welcome...

Have a nice weekend,

Daniel

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

Re: [Xen-devel] [PATCH v4 12/13] xen/pvcalls: implement release command

[Boris Ostrovsky]

>> + */
>> +map->active.ring->in_error = -EBADF;
>> +wake_up_interruptible(>active.inflight_conn_req);
>> +
>> +/*
>> + * Wait until there are no more waiters on the mutexes.
>> + * We know that no new waiters can be added because sk_send_head
>> + * is set to NULL -- we only need to wait for the existing
>> + * waiters to return.
>> + */
>> +while (!mutex_trylock(>active.in_mutex) ||
>> +   !mutex_trylock(>active.out_mutex))
>> +cpu_relax();
>
> What if you manage to grab the locks before waiters get to run? for
> example, in recvmsg:
>
>   while (!(flags & MSG_DONTWAIT) && !pvcalls_front_read_todo(map)) {
>   wait_event_interruptible(map->active.inflight_conn_req,
>pvcalls_front_read_todo(map));
>   }
>   ret = __read_ring(map->active.ring, >active.data,
> >msg_iter, len, flags);
>
> map will be freed (by pvcalls_front_free_map() below) before __read_ring
> is passed the just-freed ring.

Actually, since you don't drop the locks I am not sure recvmsg side will
even get there.

-boris

>
>
>> +
>> +pvcalls_front_free_map(bedata, map);
>> +kfree(map);
>
> -boris
>
>


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

Re: [Xen-devel] [PATCH 01/27 v10] xen/arm: vpl011: Define common ring buffer helper functions in console.h

[Stefano Stabellini]

Adding Jan

On Fri, 22 Sep 2017, Bhupinder Thakur wrote:
> DEFINE_XEN_FLEX_RING(xencons) defines common helper functions such as
> xencons_queued() to tell the current size of the ring buffer,
> xencons_mask() to mask off the index, which are useful helper functions.
> pl011 emulation code will use these helper functions.
> 
> io/console.h includes io/ring.h which defines DEFINE_XEN_FLEX_RING.
> 
> In console/daemon/io.c, string.h had to be included before io/console.h
> because ring.h uses string functions.
> 
> Signed-off-by: Bhupinder Thakur 
> Reviewed-by: Stefano Stabellini 
> Acked-by: Wei Liu 
> Acked-by: Konrad Rzeszutek Wilk 

Unfortunately this patch breaks the build on x86. The reason is that
DEFINE_XEN_FLEX_RING requires C99, and the current header checks in
xen/include/Makefile use ANSI C.

The only two headers to use DEFINE_XEN_FLEX_RING so far are pvcalls and
9pfs that are both explicitly marked as c99 in xen/include/Makefile, see
PUBLIC_C99_HEADERS.

One way to solve this problem would be to mark console.h as one of the
c99 headers, but I am guessing that Jan will want to keep it ANSI C.

In that case, we could make DEFINE_XEN_FLEX_RING ANSI C, which is ugly
but possible. It requires turning the static inline functions in ring.h
into macros.

Otherwise, we could take DEFINE_XEN_FLEX_RING(xencons) out of
io/console.h. We could move it to a new header file, and the new header
file could be C99.

Jan, do you have other suggestions?


> ---
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Konrad Rzeszutek Wilk 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> 
> Changes since v4:
> - Split this change in a separate patch.
> 
>  tools/console/daemon/io.c   | 2 +-
>  xen/include/public/io/console.h | 4 
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
> index 7e474bb..e8033d2 100644
> --- a/tools/console/daemon/io.c
> +++ b/tools/console/daemon/io.c
> @@ -21,6 +21,7 @@
>  
>  #include "utils.h"
>  #include "io.h"
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -29,7 +30,6 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/include/public/io/console.h b/xen/include/public/io/console.h
> index e2cd97f..5e45e1c 100644
> --- a/xen/include/public/io/console.h
> +++ b/xen/include/public/io/console.h
> @@ -27,6 +27,8 @@
>  #ifndef __XEN_PUBLIC_IO_CONSOLE_H__
>  #define __XEN_PUBLIC_IO_CONSOLE_H__
>  
> +#include "ring.h"
> +
>  typedef uint32_t XENCONS_RING_IDX;
>  
>  #define MASK_XENCONS_IDX(idx, ring) ((idx) & (sizeof(ring)-1))
> @@ -38,6 +40,8 @@ struct xencons_interface {
>  XENCONS_RING_IDX out_cons, out_prod;
>  };
>  
> +DEFINE_XEN_FLEX_RING(xencons);
> +
>  #endif /* __XEN_PUBLIC_IO_CONSOLE_H__ */
>  
>  /*
> -- 
> 2.7.4
> 

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

Re: [Xen-devel] [PATCH v4 12/13] xen/pvcalls: implement release command

[Boris Ostrovsky]

>  
> +static void pvcalls_front_free_map(struct pvcalls_bedata *bedata,
> +struct sock_mapping *map)

I just noticed: pvcalls_front_free_map() is referenced by patches 2 and 8.

> +{
> + int i;
> +
> + unbind_from_irqhandler(map->active.irq, map);
> +
> + spin_lock(>socket_lock);
> + if (!list_empty(>list))
> + list_del_init(>list);
> + spin_unlock(>socket_lock);
> +
> + for (i = 0; i < (1 << PVCALLS_RING_ORDER); i++)
> + gnttab_end_foreign_access(map->active.ring->ref[i], 0, 0);
> + gnttab_end_foreign_access(map->active.ref, 0, 0);
> + free_page((unsigned long)map->active.ring);
> +}
> +
>  int pvcalls_front_socket(struct socket *sock)
>  {
>   struct pvcalls_bedata *bedata;
> @@ -960,6 +978,92 @@ unsigned int pvcalls_front_poll(struct file *file, 
> struct socket *sock,
>   return ret;
>  }
>  
> +int pvcalls_front_release(struct socket *sock)
> +{
> + struct pvcalls_bedata *bedata;
> + struct sock_mapping *map;
> + int req_id, notify, ret;
> + struct xen_pvcalls_request *req;
> +
> + pvcalls_enter;
> + if (!pvcalls_front_dev) {
> + pvcalls_exit;
> + return -EIO;
> + }
> + if (sock->sk == NULL) {
> + pvcalls_exit;
> + return 0;
> + }
> +
> + bedata = dev_get_drvdata(_front_dev->dev);
> +
> + map = (struct sock_mapping *) sock->sk->sk_send_head;
> + if (map == NULL) {
> + pvcalls_exit;
> + return 0;
> + }
> +
> + spin_lock(>socket_lock);
> + ret = get_request(bedata, _id);
> + if (ret < 0) {
> + spin_unlock(>socket_lock);
> + pvcalls_exit;
> + return ret;
> + }
> + sock->sk->sk_send_head = NULL;
> +
> + req = RING_GET_REQUEST(>ring, req_id);
> + req->req_id = req_id;
> + req->cmd = PVCALLS_RELEASE;
> + req->u.release.id = (uint64_t)map;
> +
> + bedata->ring.req_prod_pvt++;
> + RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(>ring, notify);
> + spin_unlock(>socket_lock);
> + if (notify)
> + notify_remote_via_irq(bedata->irq);
> +
> + wait_event(bedata->inflight_req,
> +READ_ONCE(bedata->rsp[req_id].req_id) == req_id);
> +
> + if (map->active_socket) {
> + /*
> +  * Set in_error and wake up inflight_conn_req to force
> +  * recvmsg waiters to exit.
> +  */
> + map->active.ring->in_error = -EBADF;
> + wake_up_interruptible(>active.inflight_conn_req);
> +
> + /*
> +  * Wait until there are no more waiters on the mutexes.
> +  * We know that no new waiters can be added because sk_send_head
> +  * is set to NULL -- we only need to wait for the existing
> +  * waiters to return.
> +  */
> + while (!mutex_trylock(>active.in_mutex) ||
> +!mutex_trylock(>active.out_mutex))
> + cpu_relax();


What if you manage to grab the locks before waiters get to run? for
example, in recvmsg:

while (!(flags & MSG_DONTWAIT) && !pvcalls_front_read_todo(map)) {
wait_event_interruptible(map->active.inflight_conn_req,
 pvcalls_front_read_todo(map));
}
ret = __read_ring(map->active.ring, >active.data,
  >msg_iter, len, flags);

map will be freed (by pvcalls_front_free_map() below) before __read_ring
is passed the just-freed ring.


> +
> + pvcalls_front_free_map(bedata, map);
> + kfree(map);


-boris



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

Re: [Xen-devel] [PATCH v4 11/13] xen/pvcalls: implement poll command

[Boris Ostrovsky]

>  
> +static unsigned int pvcalls_front_poll_passive(struct file *file,
> +struct pvcalls_bedata *bedata,
> +struct sock_mapping *map,
> +poll_table *wait)
> +{
> + int notify, req_id, ret;
> + struct xen_pvcalls_request *req;
> +
> + if (test_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
> +  (void *)>passive.flags)) {
> + uint32_t req_id = READ_ONCE(map->passive.inflight_req_id);
> +
> + if (req_id != PVCALLS_INVALID_ID &&
> + READ_ONCE(bedata->rsp[req_id].req_id) == req_id)
> + return POLLIN | POLLRDNORM;


Do we need to clear PVCALLS_FLAG_ACCEPT_INFLIGHT? Or do we expect a
(subsequent?) accept() to do that?

-boris



> +
> + poll_wait(file, >passive.inflight_accept_req, wait);
> + return 0;
> + }
> +


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

Re: [Xen-devel] [PATCH v4 10/13] xen/pvcalls: implement recvmsg

[Boris Ostrovsky]

>  
> +static bool pvcalls_front_read_todo(struct sock_mapping *map)
> +{
> + struct pvcalls_data_intf *intf = map->active.ring;
> + RING_IDX cons, prod;
> + int32_t error;
> +
> + cons = intf->in_cons;
> + prod = intf->in_prod;
> + error = intf->in_error;
> + return (error != 0 ||
> + pvcalls_queued(prod, cons,
> +XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER)) != 0);


Does this routine have to be different from pvcalls_front_write_todo()?
They look pretty similar. Can they be merged?

(and you don't really need 'error' variable)

-boris

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

[Xen-devel] [linux-next test] 113717: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail REGR. vs. 
113666
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 113666
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
113666

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 113666
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop   fail REGR. vs. 113666

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113666
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113666
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 113666
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 113666
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux73527316e3fdde8a210b8ab66c1bf48538cf6b09
baseline version:
 linuxc52f56a69d104d5294af3d652776d94b1ef6a175

Last test of basis  (not found) 
Failing since   (not found) 
Testing same since   113717  2017-09-22 09:28:38 Z0 days1 attempts

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

Re: [Xen-devel] [PATCH v4 09/13] xen/pvcalls: implement sendmsg

[Boris Ostrovsky]

> +static bool pvcalls_front_write_todo(struct sock_mapping *map)
> +{
> + struct pvcalls_data_intf *intf = map->active.ring;
> + RING_IDX cons, prod, size = XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
> + int32_t error;
> +
> + cons = intf->out_cons;
> + prod = intf->out_prod;
> + error = intf->out_error;
> + if (error == -ENOTCONN)
> + return false;
> + if (error != 0)
> + return true;

Just like below, error processing can be moved up.

> + return !!(size - pvcalls_queued(prod, cons, size));
> +}
> +
>  static irqreturn_t pvcalls_front_event_handler(int irq, void *dev_id)
>  {
>   struct xenbus_device *dev = dev_id;
> @@ -363,6 +380,108 @@ int pvcalls_front_connect(struct socket *sock, struct 
> sockaddr *addr,
>   return ret;
>  }
>  
> +static int __write_ring(struct pvcalls_data_intf *intf,
> + struct pvcalls_data *data,
> + struct iov_iter *msg_iter,
> + int len)
> +{
> + RING_IDX cons, prod, size, masked_prod, masked_cons;
> + RING_IDX array_size = XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
> + int32_t error;
> +
> + error = intf->out_error;
> + if (error < 0)
> + return error;
> + cons = intf->out_cons;
> + prod = intf->out_prod;
> + /* read indexes before continuing */
> + virt_mb();
> +
> + size = pvcalls_queued(prod, cons, array_size);
> + if (size >= array_size)
> + return 0;


Is it possible to have size > array_size?


> + if (len > array_size - size)
> + len = array_size - size;
> +
> + masked_prod = pvcalls_mask(prod, array_size);
> + masked_cons = pvcalls_mask(cons, array_size);
> +
> + if (masked_prod < masked_cons) {
> + copy_from_iter(data->out + masked_prod, len, msg_iter);
> + } else {
> + if (len > array_size - masked_prod) {
> + copy_from_iter(data->out + masked_prod,
> +array_size - masked_prod, msg_iter);
> + copy_from_iter(data->out,
> +len - (array_size - masked_prod),
> +msg_iter);
> + } else {
> + copy_from_iter(data->out + masked_prod, len, msg_iter);
> + }
> + }
> + /* write to ring before updating pointer */
> + virt_wmb();
> + intf->out_prod += len;
> +
> + return len;


I know that you said you'd be changing len's type to int but now that I
am looking at it I wonder whether you could pass len as a 'size_t *' and
have this routine return error code (i.e. <=0).

OTOH, we'd be mixing up types again since RING_IDX is an unsigned int.

So I'll leave it to you (or anyone else reviewing this) to decide which
way is better.


> +}
> +
> +int pvcalls_front_sendmsg(struct socket *sock, struct msghdr *msg,
> +   size_t len)

Also, the signature here looks suspicious --- you are trying to send
'size_t len' bytes but returning an int, which is how many bytes you've
actually sent. Right?


-boris


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

Re: [Xen-devel] [PATCH 06/27 v10] xen/arm: vpl011: Add a new domctl API to initialize vpl011

[Stefano Stabellini]

On Fri, 22 Sep 2017, Bhupinder Thakur wrote:
> Add a new domctl API to initialize vpl011. It takes the GFN and console
> backend domid as input and returns an event channel to be used for
> sending and receiving events from Xen.
> 
> Xen will communicate with xenconsole using GFN as the ring buffer and
> the event channel to transmit and receive pl011 data on the guest domain's
> behalf.
> 
> Signed-off-by: Bhupinder Thakur 

Reviewed-by: Stefano Stabellini 

This patch still needs an ack from one of the tools maintainers.


> ---
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Andrew Cooper 
> CC: George Dunlap 
> CC: Jan Beulich 
> CC: Konrad Rzeszutek Wilk 
> CC: Stefano Stabellini 
> CC: Tim Deegan 
> CC: Julien Grall 
> 
> Changes since v9:
> - Initialized local variable in libxl__arch_build_dom_finish
> - Replaced __copy_to_guest with copy_to_guest
> - Added comment for console_domid field in vuart_op structure
> 
> Changes since v8:
> - Added explicit padding in the vuart_op structure
> - Moved vuart_op structure after the PSR structure definition
> - The input fields moved before the output fields in vuart_op structure
> - Checking explicitly that padding fields are initialized to 0
> 
> Changes since v6:
> - Renamed the vuart initialization function to a generic name 
> xc_dom_vuart_init 
> - Used domid_t as a type instead of uint32_t for domid
> - Checking the vuart type explicitly against vpl011 enum value
> 
> Changes since v5:
> - xc_dom_vpl011_init() will be compiled for both x86/arm architectures as 
> there
>   is nothing architecture specific in this function. This function will 
> return 
>   error when called for x86.
> - Fixed coding style issues in libxl.
> 
> Changes since v4:
> - Removed libxl__arch_domain_create_finish().
> - Added a new function libxl__arch_build_dom_finish(), which is called at the 
> last
>   in libxl__build_dom(). This function calls the vpl011 initialization 
> function now.
> 
> Changes since v3:
> - Added a new arch specific function libxl__arch_domain_create_finish(), which
>   calls the vpl011 initialization function. For x86 this function does not do
>   anything.
> - domain_vpl011_init() takes a pointer to a structure which contains all the 
>   required information such as console_domid, gfn instead of passing 
> parameters
>   separately.
> - Dropped a DOMCTL API defined for de-initializing vpl011 as that should be
>   taken care when the domain is destroyed (and not dependent on userspace 
>   libraries/applications).
> 
> Changes since v2:
> - Replaced the DOMCTL APIs defined for get/set of event channel and GFN with 
>   a set of DOMCTL APIs for initializing and de-initializing vpl011 emulation.
> 
>  tools/libxc/include/xenctrl.h | 20 +
>  tools/libxc/xc_domain.c   | 27 ++
>  tools/libxl/libxl_arch.h  |  7 ++
>  tools/libxl/libxl_arm.c   | 27 ++
>  tools/libxl/libxl_dom.c   |  4 
>  tools/libxl/libxl_x86.c   |  8 +++
>  xen/arch/arm/domain.c |  6 +
>  xen/arch/arm/domctl.c | 52 
> +++
>  xen/include/public/domctl.h   | 24 
>  9 files changed, 175 insertions(+)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 073fbc9..2086e71 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -886,6 +886,26 @@ int xc_vcpu_getcontext(xc_interface *xch,
> vcpu_guest_context_any_t *ctxt);
>  
>  /**
> + * This function initializes the vuart emulation and returns
> + * the event to be used by the backend for communicating with
> + * the emulation code.
> + *
> + * @parm xch a handle to an open hypervisor interface
> + * #parm type type of vuart
> + * @parm domid the domain to get information from
> + * @parm console_domid the domid of the backend console
> + * @parm gfn the guest pfn to be used as the ring buffer
> + * @parm evtchn the event channel to be used for events
> + * @return 0 on success, negative error on failure
> + */
> +int xc_dom_vuart_init(xc_interface *xch,
> +  uint32_t type,
> +  domid_t domid,
> +  domid_t console_domid,
> +  xen_pfn_t gfn,
> +  evtchn_port_t *evtchn);
> +
> +/**
>   * This function returns information about the XSAVE state of a particular
>   * vcpu of a domain. If extstate->size and extstate->xfeature_mask are 0,
>   * the call is considered a query to retrieve them and the buffer is not
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index f40dc4f..f2e9f0c 100644
> --- a/tools/libxc/xc_domain.c
> +++ 

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

[H. Peter Anvin]

On 09/22/17 11:57, Kees Cook wrote:
> On Fri, Sep 22, 2017 at 11:38 AM, H. Peter Anvin  wrote:
>> We lose EBX on 32 bits, but we don't lose RBX on 64 bits - since x86-64
>> has RIP-relative addressing there is no need for a dedicated PIC register.
> 
> FWIW, since gcc 5, the PIC register isn't totally lost. It is now
> reusable, and that seems to have improved performance:
> https://gcc.gnu.org/gcc-5/changes.html

It still talks about a PIC register on x86-64, which confuses me.
Perhaps older gcc's would allocate a PIC register under certain
circumstances, and then lose it for the entire function?

For i386, the PIC register is required by the ABI to be %ebx at the
point any PLT entry is called.  Not an issue with -mno-plt which goes
straight to the GOT, although in most cases there needs to be a PIC
register to find the GOT unless load-time relocation is permitted.

-hpa


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

Re: [Xen-devel] pci-passthrough loses msi-x interrupts ability after domain destroy

[Konrad Rzeszutek Wilk]

On Fri, Sep 22, 2017 at 09:35:40AM +0200, Sander Eikelenboom wrote:
> On 22/09/17 04:09, Christopher Clark wrote:
> > On Thu, Sep 21, 2017 at 1:27 PM, Sander Eikelenboom
> >  wrote:
> >>
> >> On Thu, September 21, 2017, 10:39:52 AM, Roger Pau Monné wrote:
> >>
> >>> On Wed, Sep 20, 2017 at 03:50:35PM -0400, Jérôme Oufella wrote:
> 
>  I'm using PCI pass-through to map a PCIe (intel i210) controller into
>  a HVM domain. The system uses xen-pciback to hide the appropriate PCI
>  device from Dom0.
> 
>  When creating the HVM domain after an hypervisor cold boot, the HVM
>  domain can access and use the PCIe controller without problem.
> 
>  However, if the HVM domain is destroyed then restarted, it won't be
>  able to use the pass-through PCI device anymore. The PCI device is
>  seen and can be mapped, however, the interrupts will not be passed to
>  the HVM domain anymore (this is visible under a Linux guest as
>  /proc/interrupts counters remain 0). The behavior on a Windows10 guest
>  is the same.
> 
>  A few interesting hints I noticed:
> 
>  - On Dom0, 'lspci -vv' on that PCIe device between the "working" and
>  the "muted interrupts" states, I noted a difference between the
>  MSI-X caps:
> 
>  - Capabilities: [70] MSI-X: Enable- Count=5 Masked- <-- IRQs will work 
>  if domain started
>  + Capabilities: [70] MSI-X: Enable- Count=5 Masked+ <-- IRQs won't work 
>  if domain started
>  ^^^
> >>
> >>> IMHO it seems that either your device is not able to perform a reset
> >>> successfully, or Linux is not correctly performing such reset. I don't
> >>> think there's a lot that can be done from the Xen side.
> >>
> >> Unfortunately for a lot of pci-devices a simple reset as performed by 
> >> default isn't enough,
> >> but also almost none support a real pci FLR.
> >>
> >> In the distant past Konrad has made a patchset that implemented a bus 
> >> reset and
> >> reseting config space. (It piggy backed on already existing libxl 
> >> mechanism of
> >> trying to call on a syfs "do_flr" attribute which triggers pciback to 
> >> perform
> >> the busreset and rewrite of config space for the device.
> >>
> >> I use that patchset ever since for my pci-passtrough needs and it works 
> >> pretty
> >> well. I can shutdown an restart VM's with pci devices passed trhough (also 
> >> AMD
> >> Radeon graphic cards).
> > 
> > Just to confirm the utility of that piece of work: OpenXT also uses an
> > extended version of that same patch to perform device reset for
> > passthrough.
> > 
> > I've attached a copy of that OpenXT patch to this message and it can
> > also be obtained from our git repository:
> > https://github.com/OpenXT/xenclient-oe/blob/f8d3b282a87231d9ae717b13d506e8e7e28c78c4/recipes-kernel/linux/4.9/patches/thorough-reset-interface-to-pciback-s-sysfs.patch
> > This version creates a sysfs node named "reset_device" and the OpenXT
> > libxl toolstack is patched to use that node instead of "do_flr".
> 
> Nice to hear there are more users of this patch. On #xen on IRC there were 
> from time to time
> also users who tried pci-passtrough and ran into this issue (and probably 
> abandonning the idea
> since having to restart your host before being able to use your pass 
> throughed device again
> defies much of the use case).
>  
> > Konrad's original work encountered pushback on upstream acceptance at
> > the time it was developed. I'm not sure I've found where that
> > discussion ended. Is there any prospect of a more comprehensive reset
> > mechanism being accepted into xen-pciback, or elsewhere in the kernel?
> 
> Yeah it was nacked by David Vrabel and the discussion somewhat bleeded to 
> death. 
> >From what i remember the main issue was with the naming, since it doesn't do 
> >a FLR,
> the sysfs hook shouldn't be called "do_flr".
> 
> Some other perhaps minor issues i can think of are:
> - No way to excempt pci-devices from this new way of resetting them.
>   Perhaps there could be pci devices/topologies were this way of
>   resetting causes more problems than it solves and could cause a
>   regression. Unfortunately auto detecting what works doesn't seem to
>   be possible. On the other hand (though only with my n=10) i haven't 
> encountered
>   such a device yet.
> 
> - The communication path between libxl and the kernel via sysfs.
>   I think the preference was for a:
>   a) having it use a more common used Xen communication channel or
>   b) having it all self-contained in pci-back. (from my memory and the openxt 
> patch description
>  there could be some locking issue when trying to implement it this way,
>  but the vfio guys had that solved for there reset implementation if i
>  from one of the comments in there source code (patches by Alex Williamson
>  if i remember correctly).
> 
> - Not an issue back then when 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  7ff9661b904a3af618dc2a2b8cdec46be6930308
baseline version:
 xen  77f80409e086ee320b092847c915427d2eac9317

Last test of basis   113732  2017-09-22 15:18:28 Z0 days
Testing same since   113737  2017-09-22 17:15:18 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Oleksandr Grytsov 
  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=7ff9661b904a3af618dc2a2b8cdec46be6930308
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ 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 
7ff9661b904a3af618dc2a2b8cdec46be6930308
+ branch=xen-unstable-smoke
+ revision=7ff9661b904a3af618dc2a2b8cdec46be6930308
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.:.
 PERLLIB=.:.:.
+++ 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
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ 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.9-testing
+ '[' x7ff9661b904a3af618dc2a2b8cdec46be6930308 = 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
++ : 

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

[H. Peter Anvin]

On 09/22/17 09:32, Ingo Molnar wrote:
> 
> BTW., I think things improved with ORC because with ORC we have RBP as an 
> extra 
> register and with PIE we lose RBX - so register pressure in code generation 
> is 
> lower.
> 

We lose EBX on 32 bits, but we don't lose RBX on 64 bits - since x86-64
has RIP-relative addressing there is no need for a dedicated PIC register.

I'm somewhat confused how we can have as much as almost 1% overhead.  I
suspect that we end up making a GOT and maybe even a PLT for no good reason.

-hpa

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 113659
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113659
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 113659
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 113659
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113659
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu0a8066f0c068f1e318a1aacd7864fc00e455a37b
baseline version:
 qemuub62b7ed0fc9c58e373b8946c9bd2e193be98dae6

Last test of basis   113659  2017-09-21 09:21:25 Z1 days
Testing same since   113689  2017-09-21 20:51:08 Z0 days2 attempts


People who touched revisions under test:
  Artyom Tarasenko 
  Eduardo Habkost 
  Eric Blake 
  Igor Mammedov 
  James Hogan 
  Mark Cave-Ayland 
  Olaf Hering 
  Peter Maydell 
  Philippe Mathieu-Daudé 
  Roger Pau Monne 
  Roger Pau Monné 
  Stefano Stabellini 
  Subbaraya Sundeep 
  Yongbok Kim 

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

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

[Thomas Garnier]

On Fri, Sep 22, 2017 at 11:38 AM, H. Peter Anvin  wrote:
> On 09/22/17 09:32, Ingo Molnar wrote:
>>
>> BTW., I think things improved with ORC because with ORC we have RBP as an 
>> extra
>> register and with PIE we lose RBX - so register pressure in code generation 
>> is
>> lower.
>>
>
> We lose EBX on 32 bits, but we don't lose RBX on 64 bits - since x86-64
> has RIP-relative addressing there is no need for a dedicated PIC register.
>
> I'm somewhat confused how we can have as much as almost 1% overhead.  I
> suspect that we end up making a GOT and maybe even a PLT for no good reason.

We have a GOT with very few entries, mainly linker script globals that
I think we can work to reduce or remove.

We have a PLT but it is empty. On latest iteration (not sent yet),
modules have PLT32 relocations but no PLT entry. I got rid of
mcmodel=large for modules and instead I move the beginning of the
module section just after the kernel so relative relocations work.

>
> -hpa



-- 
Thomas

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

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

[Kees Cook]

On Fri, Sep 22, 2017 at 11:38 AM, H. Peter Anvin  wrote:
> We lose EBX on 32 bits, but we don't lose RBX on 64 bits - since x86-64
> has RIP-relative addressing there is no need for a dedicated PIC register.

FWIW, since gcc 5, the PIC register isn't totally lost. It is now
reusable, and that seems to have improved performance:
https://gcc.gnu.org/gcc-5/changes.html

-Kees

-- 
Kees Cook
Pixel Security

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

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

[H. Peter Anvin]

On 08/21/17 07:28, Peter Zijlstra wrote:
> 
> Ah, I see, this is large mode and that needs to use MOVABS to load 64bit
> immediates. Still, small RIP relative should be able to live at any
> point as long as everything lives inside the same 2G relative range, so
> would still allow the goal of increasing the KASLR range.
> 
> So I'm not seeing how we need large mode for that. That said, after
> reading up on all this, RIP relative will not be too pretty either,
> while CALL is naturally RIP relative, data still needs an explicit %rip
> offset, still loads better than the large model.
> 

The large model makes no sense whatsoever.  I think what we're actually
looking for is the small-PIC model.

Ingo asked:
> I.e. is there no GCC code generation mode where code can be placed anywhere 
> in the 
> canonical address space, yet call and jump distance is within 31 bits so that 
> the 
> generated code is fast?

That's the small-PIC model.  I think if all symbols are forced to hidden
then it won't even need a GOT/PLT.

We do need to consider how we want modules to fit into whatever model we
choose, though.  They can be adjacent, or we could go with a more
traditional dynamic link model where the modules can be separate, and
chained together with the main kernel via the GOT.

-hpa

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

[Xen-devel] [qemu-upstream-unstable baseline-only test] 72142: tolerable trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 72142 qemu-upstream-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72142/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-armhf-armhf-xl-credit2   7 xen-boot fail   like 72098
 test-armhf-armhf-xl   7 xen-boot fail   like 72098
 test-armhf-armhf-libvirt  7 xen-boot fail   like 72098
 test-armhf-armhf-libvirt-xsm  7 xen-boot fail   like 72098
 test-armhf-armhf-xl-multivcpu  7 xen-boot fail  like 72098
 test-armhf-armhf-xl-xsm   7 xen-boot fail   like 72098
 test-armhf-armhf-libvirt-raw  7 xen-boot fail   like 72098
 test-armhf-armhf-xl-rtds  7 xen-boot fail   like 72098
 test-armhf-armhf-xl-vhd   7 xen-boot fail   like 72098
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10  fail like 72098
 test-armhf-armhf-xl-midway7 xen-boot fail   like 72098
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 72098
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu0b157f8d977a9425e2d8d510aa011c5d4f3ec247
baseline version:
 qemuuf5a4c84a5d6b19c154abed4ee0380a6f8fd98c60

Last test of basis72098  2017-09-12 22:49:46 Z9 days
Testing same since72142  2017-09-22 11:44:49 Z0 days1 attempts


People who touched revisions under test:
  Olaf Hering 
  Stefano Stabellini 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-arm64-arm64-xl  blocked 
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

[Thomas Garnier]

On Fri, Sep 22, 2017 at 9:32 AM, Ingo Molnar  wrote:
>
> * Thomas Garnier  wrote:
>
>> On Thu, Sep 21, 2017 at 8:59 AM, Ingo Molnar  wrote:
>> >
>> > ( Sorry about the delay in answering this. I could blame the delay on the 
>> > merge
>> >   window, but in reality I've been procrastinating this is due to the 
>> > permanent,
>> >   non-trivial impact PIE has on generated C code. )
>> >
>> > * Thomas Garnier  wrote:
>> >
>> >> 1) PIE sometime needs two instructions to represent a single
>> >> instruction on mcmodel=kernel.
>> >
>> > What again is the typical frequency of this occurring in an x86-64 
>> > defconfig
>> > kernel, with the very latest GCC?
>>
>> I am not sure what is the best way to measure that.
>
> If this is the dominant factor then 'sizeof vmlinux' ought to be enough:
>
>> With ORC: PIE .text is 0.814224% than baseline
>
> I.e. the overhead is +0.81% in both size and (roughly) in number of 
> instructions
> executed.
>
> BTW., I think things improved with ORC because with ORC we have RBP as an 
> extra
> register and with PIE we lose RBX - so register pressure in code generation is
> lower.

That make sense.

>
> Ok, I suspect we can try it, but my preconditions for merging it would be:
>
>   1) Linus doesn't NAK it (obviously)

Of course.

>   2) we first implement the additional entropy bits that Linus suggested.
>
> does this work for you?

Sure, I can look at how feasible that is. If it is, can I send
everything as part of the same patch set? The additional entropy would
be enabled for all KASLR but PIE will be off-by-default of course.

>
> Thanks,
>
> Ingo



-- 
Thomas

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

Re: [Xen-devel] [PATCH v3 1/3] python: Add binding for xs_fileno()

[Marek Marczykowski-Górecki]

On Fri, Sep 22, 2017 at 05:21:12PM +0100, Euan Harris wrote:
> xs_fileno() returns a file descriptor which receives events when Xenstore
> watches fire.   Exposing this in the Python bindings is a prerequisite
> for writing event-driven clients in Python.
> 
> Signed-off-by: Euan Harris 
> Reviewed-by: Konrad Rzeszutek Wilk 
> Reviewed-by: Wei Liu 

Acked-by: Marek Marczykowski-Górecki 

> ---
> Changed since v2:
>  * Use PyLong_FromLong instead of PyInt_FromLong
> ---
>  tools/python/xen/lowlevel/xs/xs.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/tools/python/xen/lowlevel/xs/xs.c 
> b/tools/python/xen/lowlevel/xs/xs.c
> index aba5a20..3a827b0 100644
> --- a/tools/python/xen/lowlevel/xs/xs.c
> +++ b/tools/python/xen/lowlevel/xs/xs.c
> @@ -453,6 +453,25 @@ static PyObject *xspy_watch(XsHandle *self, PyObject 
> *args)
>  }
>  
>  
> +#define xspy_fileno_doc "\n"  \
> + "Return the FD to poll for notifications when watches fire.\n"   \
> + "Returns: [int] file descriptor.\n"\
> + "\n"
> +
> +static PyObject *xspy_fileno(XsHandle *self)
> +{
> +struct xs_handle *xh = xshandle(self);
> +int fd;
> +
> +if (!xh)
> +return NULL;
> +
> +fd = xs_fileno(xh);
> +
> +return PyLong_FromLong(fd);
> +}
> +
> +
>  #define xspy_read_watch_doc "\n" \
>   "Read a watch notification.\n"  \
>   "\n"\
> @@ -887,6 +906,7 @@ static PyMethodDef xshandle_methods[] = {
>  XSPY_METH(release_domain,METH_VARARGS),
>  XSPY_METH(close, METH_NOARGS),
>  XSPY_METH(get_domain_path,   METH_VARARGS),
> +XSPY_METH(fileno,METH_NOARGS),
>  { NULL /* Sentinel. */ },
>  };
>  

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


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

Re: [Xen-devel] [PATCH v9 09/10] xen: make grant resource limits per domain

[Juergen Gross]

On 22/09/17 17:15, Jan Beulich wrote:
 On 22.09.17 at 13:41,  wrote:
>> Instead of using the same global resource limits of grant tables (max.
>> number of grant frames, max. number of maptrack frames) for all domains
>> make these limits per domain. Set those per-domain limits in
>> grant_table_set_limits(). The global settings are serving as an upper
>> boundary now which must not be exceeded by a per-domain value. The
>> default of max_grant_frames is set to the maximum default xl will use.
>>
>> While updating the semantics of the boot parameters remove the
>> documentation of the no longer existing gnttab_max_nr_frames.
> 
> "... and correct the default gnttab_max_maptrack_frames uses" (or
> some such).

Okay.

> 
>> @@ -1672,8 +1670,8 @@ gnttab_grow_table(struct domain *d, unsigned int 
>> req_nr_frames)
>>  ASSERT(gt->active);
>>  
>>  if ( req_nr_frames < INITIAL_NR_GRANT_FRAMES )
>> -req_nr_frames = INITIAL_NR_GRANT_FRAMES;
>> -ASSERT(req_nr_frames <= max_grant_frames);
>> +req_nr_frames = min(INITIAL_NR_GRANT_FRAMES, gt->max_grant_frames);
> 
> I'm not convinced of this: You effectively allowing a zero size grant
> table this way. I'd prefer if the "initial" constant stayed the lower
> bound. I'm open to lowering that initial value, though.

Okay. What about the value "1" for it? Should be enough for e.g.
stubdoms, dom0, ...

> 
>> @@ -1824,6 +1818,21 @@ gnttab_setup_table(
>>  gt = d->grant_table;
>>  grant_write_lock(gt);
>>  
>> +if ( unlikely(op.nr_frames > gt->max_grant_frames) )
>> +{
>> +gdprintk(XENLOG_INFO, "d%u is limited to %u grant-table frames.\n",
> 
> You've switched to %u one too many times - domain IDs want
> printing with %d (also below).

Okay.

> 
>> @@ -2970,14 +2983,14 @@ 
>> gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
>>  
>>  static long
>>  gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) 
>> uop,
>> - int count)
>> + unsigned int count, unsigned int limit_max)
>> {
>>   gnttab_get_status_frames_t op;
>>  struct domain *d;
>>  struct grant_table *gt;
>>  uint64_t   gmfn;
>>  int i;
>> -int rc;
>> +int rc, ret = 0;
> 
> This variable doesn't look to be necessary anymore (also in
> gnttab_setup_table(), as I notice only now).

Indeed.

> 
>> @@ -3010,9 +3023,19 @@ 
>> gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) 
>> uop,
>>  
>>  if ( unlikely(op.nr_frames > nr_status_frames(gt)) )
>>  {
>> -gdprintk(XENLOG_INFO, "Guest requested addresses for %d grant 
>> status "
>> - "frames, but only %d are available.\n",
>> - op.nr_frames, nr_status_frames(gt));
>> +gdprintk(XENLOG_INFO, "Guest requested addresses of d%u for %u 
>> grant "
>> + "status frames, but only %u are available.\n",
> 
> Drop "Guest" and make the end ", has only %u\n"?

Okay.

> 
>> @@ -3665,7 +3694,11 @@ int grant_table_set_limits(struct domain *d, unsigned 
>> int grant_frames,
>>  
>>  /* Set limits. */
>>  if ( !gt->active )
>> +{
>> +gt->max_grant_frames = grant_frames;
> 
> As per above I think you want to silently apply a lower bound here.

I already have. It is 1 (note the test for !grant_frames some lines
higher).

> 
>> @@ -3769,6 +3802,12 @@ static void gnttab_usage_print(struct domain *rd)
>>  
>>  grant_read_lock(gt);
>>  
>> +printk("grant-table for remote domain:%5d (v%d)\n"
> 
> "grant table for d%d (v%u)\n"?

Okay.

> 
>> +   "  %d frames (%d max), %d maptrack frames (%d max)\n",
> 
> %u (four times)

Okay.

One final note: I have detected another problem  in the ARM part of
this patch: gnttab_size is set wrong. Will correct this.


Juergen

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

Re: [Xen-devel] [PATCH] VMX: PLATFORM_INFO MSR is r/o

[Andrew Cooper]

On 22/09/17 10:07, Jan Beulich wrote:

Therefore all write attempts should produce #GP, just like on real
hardware.

Signed-off-by: Jan Beulich 


Sergey has already posted a patch series to fix this.

What is the benefit of this version?  As far as I can tell, it isn't as 
complete as his work, because it doesn't fix the problems with this MSR 
on AMD systems.


~Andrew



--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3138,10 +3138,7 @@ static int vmx_msr_write_intercept(unsig
  break;
  
  case MSR_INTEL_PLATFORM_INFO:

-if ( msr_content ||
- rdmsr_safe(MSR_INTEL_PLATFORM_INFO, msr_content) )
-goto gp_fault;
-break;
+goto gp_fault;
  
  case MSR_INTEL_MISC_FEATURES_ENABLES:

  {




___
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] Config.mk: update OVMF changeset

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
---
 Config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index bba81bee7d..57d3e2bc44 100644
--- a/Config.mk
+++ b/Config.mk
@@ -272,7 +272,7 @@ QEMU_TRADITIONAL_URL ?= 
git://xenbits.xen.org/qemu-xen-traditional.git
 SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
 endif
-OVMF_UPSTREAM_REVISION ?= 5920a9d16b1ab887c2858224316a98e961d71b05
+OVMF_UPSTREAM_REVISION ?= 947f3737abf65fda63f3ffd97fddfa6986986868
 QEMU_UPSTREAM_REVISION ?= master
 MINIOS_UPSTREAM_REVISION ?= d991bdbc062248221511ecb795617c36b37e1d2e
 # Wed Aug 9 13:15:48 2017 +0100
-- 
Anthony PERARD


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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf 66918edd34fd2b6edb5f3f7b86bdd40e833d40ff
baseline version:
 ovmf 947f3737abf65fda63f3ffd97fddfa6986986868

Last test of basis   113647  2017-09-20 22:34:05 Z1 days
Failing since113654  2017-09-21 06:22:39 Z1 days8 attempts
Testing same since   113719  2017-09-22 09:47:09 Z0 days1 attempts


People who touched revisions under test:
  Amit Kumar 
  Dandan Bi 
  Gabriel Somlo 
  Hao Wu 
  Huajing Li 
  Jian J Wang 
  Laszlo Ersek 
  Star Zeng 

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



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

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

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

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


Not pushing.


commit 66918edd34fd2b6edb5f3f7b86bdd40e833d40ff
Author: Dandan Bi 
Date:   Fri Sep 22 09:28:28 2017 +0800

MdeModulePkg/SetupBrowser:Add NULL check before using a pointer

Add NULL pointer check before using a pointer to avoid possible
NULL pointer dereference.

Cc: Eric Dong 
Cc: Hao Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
Reviewed-by: Hao Wu 

commit 96207191fd715e268c6ba6d6ac8650ef914e1686
Author: Jian J Wang 
Date:   Fri Sep 22 09:31:19 2017 +0800

UefiCpuPkg/CpuDxe: Fix GCC build warning

There're uninitialized variables warning reported by GCC.
This patch will fix it. The original commit is

  c1cab54ce57c2608b8b3ea051c7041f036f21153

Cc: Hao Wu 
Cc: Anthony PERARD 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
Reviewed-by: Hao Wu 

commit 09e8678380aaaf0a5ef59179ff59e0a045d1b0bf
Author: Huajing Li 
Date:   Fri Sep 15 10:39:33 2017 +0800

ShellPkg/dmpstore: Show name of known variable vendor GUID

Change "dmpstore" to show name of known variable vendor GUID.
The name is got from ShellProtocol.GetGuidName().

Cc: Jaben Carsey 
Reviewed-by: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Huajing Li 
Reviewed-by: Jaben Carsey 

commit 89f7f2cdf0266619976cb53b45b5de1aba2f8fac
Author: Amit Kumar 
Date:   Fri Jun 23 18:09:47 2017 +0800

MdeModulePkg/DxeCore: Fixed Interface returned by CoreOpenProtocol

Change since v4: Revise the patch based on V4 sent by Amit 

Re: [Xen-devel] [PATCH] VMX: PLATFORM_INFO MSR is r/o

[Roger Pau Monné]

On Fri, Sep 22, 2017 at 03:07:44AM -0600, Jan Beulich wrote:
> Therefore all write attempts should produce #GP, just like on real
> hardware.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3138,10 +3138,7 @@ static int vmx_msr_write_intercept(unsig
>  break;
>  
>  case MSR_INTEL_PLATFORM_INFO:
> -if ( msr_content ||
> - rdmsr_safe(MSR_INTEL_PLATFORM_INFO, msr_content) )
> -goto gp_fault;
> -break;
> +goto gp_fault;

Could you place the label together with the MSR_IA32_FEATURE_CONTROL
one above? So that we don't add another case with just a gp_fault.

With that:

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v6 02/11] vpci: introduce basic handlers to trap accesses to the PCI config space

[Roger Pau Monné]

On Thu, Sep 21, 2017 at 02:36:25PM +0100, Wei Liu wrote:
> On Tue, Sep 19, 2017 at 04:29:27PM +0100, Roger Pau Monne wrote:
> > This functionality is going to reside in vpci.c (and the corresponding
> > vpci.h header), and should be arch-agnostic. The handlers introduced
> > in this patch setup the basic functionality required in order to trap
> > accesses to the PCI config space, and allow decoding the address and
> > finding the corresponding handler that should handle the access
> > (although no handlers are implemented).
> > 
> > Note that the traps to the PCI IO ports registers (0xcf8/0xcfc) are
> > setup inside of a x86 HVM file, since that's not shared with other
> > arches.
> > 
> > A new XEN_X86_EMU_VPCI x86 domain flag is added in order to signal Xen
> > whether a domain should use the newly introduced vPCI handlers, this
> > is only enabled for PVH Dom0 at the moment.
> > 
> > A very simple user-space test is also provided, so that the basic
> > functionality of the vPCI traps can be asserted. This has been proven
> > quite helpful during development, since the logic to handle partial
> > accesses or accesses that expand across multiple registers is not
> > trivial.
> > 
> > The handlers for the registers are added to a linked list that's keep
> > sorted at all times. Both the read and write handlers support accesses
> > that expand across multiple emulated registers and contain gaps not
> > emulated.
> > 
> > Signed-off-by: Roger Pau Monné 
> 
> I am afraid I don't know much about PCI so I can't do meaningful review
> of this patch.
> 
> The change to libxl looks good to me so for that bit:
> 
> Acked-by: Wei Liu 

Thanks.

> > ---
> > Cc: Ian Jackson 
> > Cc: Wei Liu 
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > Cc: Paul Durrant 
> > ---
> > Changes since v5:
> >  - Use a spinlock per pci device.
> >  - Use the recently introduced pci_sbdf_t type.
> >  - Fix test harness to use the right handler type and the newly
> >introduced lock.
> >  - Move the position of the vpci sections in the linker scripts.
> >  - Constify domain and pci_dev in vpci_{read/write}.
> >  - Fix typos in comments.
> >  - Use _XEN_VPCI_H_ as header guard.
> > 
> > Changes since v4:
> > * User-space test harness:
> >  - Do not redirect the output of the test.
> >  - Add main.c and emul.h as dependencies of the Makefile target.
> >  - Use the same rule to modify the vpci and list headers.
> >  - Remove underscores from local macro variables.
> >  - Add _check suffix to the test harness multiread function.
> >  - Change the value written by every different size in the multiwrite
> >test.
> >  - Use { } to initialize the r16 and r20 arrays (instead of { 0 }).
> >  - Perform some of the read checks with the local variable directly.
> >  - Expand some comments.
> >  - Implement a dummy rwlock.
> > * Hypervisor code:
> >  - Guard the linker script changes with CONFIG_HAS_PCI.
> >  - Rename vpci_access_check to vpci_access_allowed and make it return
> >bool.
> >  - Make hvm_pci_decode_addr return the register as return value.
> >  - Use ~3 instead of 0xfffc to remove the register offset when
> >checking accesses to IO ports.
> >  - s/head/prev in vpci_add_register.
> >  - Add parentheses around & in vpci_add_register.
> >  - Fix register removal.
> >  - Change the BUGs in vpci_{read/write}_hw helpers to
> >ASSERT_UNREACHABLE.
> >  - Make merge_result static and change the computation of the mask to
> >avoid using a uint64_t.
> >  - Modify vpci_read to only read from hardware the not-emulated gaps.
> >  - Remove the vpci_val union and use a uint32_t instead.
> >  - Change handler read type to return a uint32_t instead of modifying
> >a variable passed by reference.
> >  - Constify the data opaque parameter of read handlers.
> >  - Change the size parameter of the vpci_{read/write} functions to
> >unsigned int.
> >  - Place the array of initialization handlers in init.rodata or
> >.rodata depending on whether late-hwdom is enabled.
> >  - Remove the pci_devs lock, assume the Dom0 is well behaved and won't
> >remove the device while trying to access it.
> >  - Change the recursive spinlock into a rw lock for performance
> >reasons.
> > 
> > Changes since v3:
> > * User-space test harness:
> >  - Fix spaces in container_of macro.
> >  - Implement a dummy locking functions.
> >  - Remove 'current' macro make current a pointer to the statically
> >allocated vpcu.
> >  - Remove unneeded parentheses in the pci_conf_readX macros.
> >  - Fix the name of the write test macro.
> >  - Remove the dummy EXPORT_SYMBOL macro (this was needed by the RB
> >code only).
> >  - Import the max macro.
> >  - Test all possible read/write size combinations with all possible
> >emulated register sizes.
> >  - Introduce a test for register 

Re: [Xen-devel] Xen Porting Inquiry

[Konrad Rzeszutek Wilk]

On Fri, Sep 22, 2017 at 09:31:26AM -0700, t...@hughes.net wrote:
> Hello,
> 
> Who can I contact at Xen to obtain an estimate of the effort required to port
> Xen to IBM's OpenPOWER 9 CPU?

I would recommend you speak to IBM as they would be most qualified to answer 
that question.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  77f80409e086ee320b092847c915427d2eac9317
baseline version:
 xen  829324d18c089636ce492613f7e99c8f78096d9b

Last test of basis   113721  2017-09-22 11:11:38 Z0 days
Testing same since   113732  2017-09-22 15:18:28 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Yi Sun 

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=77f80409e086ee320b092847c915427d2eac9317
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ 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 
77f80409e086ee320b092847c915427d2eac9317
+ branch=xen-unstable-smoke
+ revision=77f80409e086ee320b092847c915427d2eac9317
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.:.
 PERLLIB=.:.:.
+++ 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
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ 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.9-testing
+ '[' x77f80409e086ee320b092847c915427d2eac9317 = 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
++ : 

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

[Ingo Molnar]

* Thomas Garnier  wrote:

> On Thu, Sep 21, 2017 at 8:59 AM, Ingo Molnar  wrote:
> >
> > ( Sorry about the delay in answering this. I could blame the delay on the 
> > merge
> >   window, but in reality I've been procrastinating this is due to the 
> > permanent,
> >   non-trivial impact PIE has on generated C code. )
> >
> > * Thomas Garnier  wrote:
> >
> >> 1) PIE sometime needs two instructions to represent a single
> >> instruction on mcmodel=kernel.
> >
> > What again is the typical frequency of this occurring in an x86-64 defconfig
> > kernel, with the very latest GCC?
> 
> I am not sure what is the best way to measure that.

If this is the dominant factor then 'sizeof vmlinux' ought to be enough:

> With ORC: PIE .text is 0.814224% than baseline

I.e. the overhead is +0.81% in both size and (roughly) in number of 
instructions 
executed.

BTW., I think things improved with ORC because with ORC we have RBP as an extra 
register and with PIE we lose RBX - so register pressure in code generation is 
lower.

Ok, I suspect we can try it, but my preconditions for merging it would be:

  1) Linus doesn't NAK it (obviously)
  2) we first implement the additional entropy bits that Linus suggested.

does this work for you?

Thanks,

Ingo

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

[Xen-devel] [linux-4.9 test] 113706: trouble: broken/fail/pass

[osstest service owner]

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

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  broken

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   4 host-install(4)  broken pass in 113680
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 113680 pass in 
113706
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 113680 pass 
in 113706
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail in 113680 pass in 
113706

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 113680 
like 113458
 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 113680 never pass
 test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 113680 never 
pass
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail like 113425
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 113458
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 113458
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 113479
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 113479
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass

version targeted for testing:
 linux089d7720383d7bc9ca6b8824a05dfa66f80d1f41
baseline version:
 linux4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae

Last test of basis   113479  2017-09-15 15:56:10 Z7 days
Testing same since   113620  2017-09-20 06:49:19 Z2 days5 attempts


People who touched revisions under test:
  Alexei Starovoitov 
  Amir Goldstein 
  Andy Lutomirski 
  Arnd Bergmann 
  Benjamin Poirier 
  Brian Foster 

[Xen-devel] Xen Porting Inquiry

[tcb]

  
  
Hello,
Who can I contact at Xen to obtain an estimate of the effort
  required to port Xen to IBM's OpenPOWER 9 CPU?
Kind regards,
TCB
  


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

Re: [Xen-devel] [PATCH v9 10/10] xen: add new Xen cpuid node for max address width info

[Juergen Gross]

On 22/09/17 16:47, Jan Beulich wrote:
 On 22.09.17 at 13:41,  wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -929,6 +929,13 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, 
>> uint32_t leaf,
>>  res->b = v->vcpu_id;
>>  break;
>>  
>> +case 5: /* PV-specific parameters */
>> +if ( is_hvm_domain(d) || subleaf != 0 )
>> +break;
>> +
>> +res->a = generic_flsl(get_upper_mfn_bound()) + PAGE_SHIFT;
>> +break;
> 
> The subleaf check here should be mirrored ...
> 
>> --- a/xen/include/public/arch-x86/cpuid.h
>> +++ b/xen/include/public/arch-x86/cpuid.h
>> @@ -85,6 +85,15 @@
>>  #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
>>  #define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3) /* vcpu id is present in 
>> EBX 
>> */
>>  
>> -#define XEN_CPUID_MAX_NUM_LEAVES 4
>> +/*
>> + * Leaf 6 (0x4x05)
>> + * PV-specific parameters
>> + * EAX: bits 0-7: max machine address width
>> + */
> 
> ... in the comment here. This is easily doable while committing,

Up to now there is no example for this: the time leaf isn't documented
and the HVM leaf from which I copied the subleaf check doesn't have
anything related to it in the comments.

Do you have any special format recommendations?

And should I add related comments to the HVM leaf section?

> but I'd like to be certain Andrew in particular has no objections
> to this new leaf before putting this in.

Sure.


Juergen


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

[Xen-devel] [PATCH v2 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va

[Joao Martins]

Right now there is only a pvclock_pvti_cpu0_va() which is defined
on kvmclock since:

commit dac16fba6fc5
("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")

The only user of this interface so far is kvm. This commit adds a
setter function for the pvti page and moves pvclock_pvti_cpu0_va
to pvclock, which is a more generic place to have it; and would
allow other PV clocksources to use it, such as Xen.

Signed-off-by: Joao Martins 
Acked-by: Andy Lutomirski 
---
Changes since v1:
 * Rebased: the only conflict was that I had move the export
 pvclock_pvti_cpu0_va() symbol as it is used by kvm PTP driver.
 * Do not initialize pvti_cpu0_va to NULL (checkpatch error)

 ( Comments from Andy Lutomirski )
 * Removed asm/pvclock.h 'pvclock_set_pvti_cpu0_va' definition
 for non !PARAVIRT_CLOCK to better track screwed Kconfig stuff.
 * Add his Acked-by (provided the previous adjustment was made)

Changes since RFC:
 (Comments from Andy Lutomirski)
 * Add __init to pvclock_set_pvti_cpu0_va
 * Add WARN_ON(vclock_was_used(VCLOCK_PVCLOCK)) to
 pvclock_set_pvti_cpu0_va
---
 arch/x86/include/asm/pvclock.h | 19 ++-
 arch/x86/kernel/kvmclock.c |  7 +--
 arch/x86/kernel/pvclock.c  | 14 ++
 3 files changed, 25 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index 448cfe1b48cf..6f228f90cdd7 100644
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@ -4,15 +4,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_KVM_GUEST
-extern struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
-#else
-static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
-{
-   return NULL;
-}
-#endif
-
 /* some helper functions for xen and kvm pv clock sources */
 u64 pvclock_clocksource_read(struct pvclock_vcpu_time_info *src);
 u8 pvclock_read_flags(struct pvclock_vcpu_time_info *src);
@@ -101,4 +92,14 @@ struct pvclock_vsyscall_time_info {
 
 #define PVTI_SIZE sizeof(struct pvclock_vsyscall_time_info)
 
+#ifdef CONFIG_PARAVIRT_CLOCK
+void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti);
+struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
+#else
+static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
+{
+   return NULL;
+}
+#endif
+
 #endif /* _ASM_X86_PVCLOCK_H */
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index d88967659098..538738047ff5 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -47,12 +47,6 @@ early_param("no-kvmclock", parse_no_kvmclock);
 static struct pvclock_vsyscall_time_info *hv_clock;
 static struct pvclock_wall_clock wall_clock;
 
-struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
-{
-   return hv_clock;
-}
-EXPORT_SYMBOL_GPL(pvclock_pvti_cpu0_va);
-
 /*
  * The wallclock is the time of day when we booted. Since then, some time may
  * have elapsed since the hypervisor wrote the data. So we try to account for
@@ -334,6 +328,7 @@ int __init kvm_setup_vsyscall_timeinfo(void)
return 1;
}
 
+   pvclock_set_pvti_cpu0_va(hv_clock);
put_cpu();
 
kvm_clock.archdata.vclock_mode = VCLOCK_PVCLOCK;
diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index 5c3f6d6a5078..cb7d6d9c9c2d 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -25,8 +25,10 @@
 
 #include 
 #include 
+#include 
 
 static u8 valid_flags __read_mostly = 0;
+static struct pvclock_vsyscall_time_info *pvti_cpu0_va __read_mostly;
 
 void pvclock_set_flags(u8 flags)
 {
@@ -144,3 +146,15 @@ void pvclock_read_wallclock(struct pvclock_wall_clock 
*wall_clock,
 
set_normalized_timespec(ts, now.tv_sec, now.tv_nsec);
 }
+
+void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti)
+{
+   WARN_ON(vclock_was_used(VCLOCK_PVCLOCK));
+   pvti_cpu0_va = pvti;
+}
+
+struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
+{
+   return pvti_cpu0_va;
+}
+EXPORT_SYMBOL_GPL(pvclock_pvti_cpu0_va);
-- 
2.11.0


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

[Xen-devel] [PATCH v2 2/3] x86/xen/time: setup vcpu 0 time info page

[Joao Martins]

In order to support pvclock vdso on xen we need to setup the time
info page for vcpu 0 and register the page with Xen using the
VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall
will also forcefully update the pvti which will set some of the
necessary flags for vdso. Afterwards we check if it supports the
PVCLOCK_TSC_STABLE_BIT flag which is mandatory for having
vdso/vsyscall support. And if so, it will set the cpu 0 pvti that
will be later on used when mapping the vdso image.

The xen headers are also updated to include the new hypercall for
registering the secondary vcpu_time_info struct.

Signed-off-by: Joao Martins 
---
Changes since v1:
 * Check flags ahead to see if the  primary clock can use
 PVCLOCK_TSC_STABLE_BIT even if secondary registration fails.

 (Comments from Boris)
 * Remove addr, addr variables;
 * Change first pr_debug to pr_warn;
 * Change last pr_debug to pr_notice;
 * Add routine to solely register secondary time info.
 * Move xen_clock to outside xen_setup_vsyscall_time_info to allow
 restore path to simply re-register secondary time info. Let us
 handle the restore path more gracefully without re-allocating a
 page.
 * Removed cpu argument from xen_setup_vsyscall_time_info()
 * Adjustment failed registration error messages/loglevel to be the same
 * Also teardown secondary time info on suspend

Changes since RFC:
 (Comments from Boris and David)
 * Remove Kconfig option
 * Use get_zeroed_page/free/page
 * Remove the hypercall availability check
 * Unregister pvti with arg.addr.v = NULL if stable bit isn't supported.
 (New)
 * Set secondary copy on restore such that it works on migration.
 * Drop global xen_clock variable and stash it locally on
 xen_setup_vsyscall_time_info.
 * WARN_ON(ret) if we fail to unregister the pvti.
---
 arch/x86/xen/suspend.c   |   4 ++
 arch/x86/xen/time.c  | 100 +++
 arch/x86/xen/xen-ops.h   |   2 +
 include/xen/interface/vcpu.h |  28 
 4 files changed, 134 insertions(+)

diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index d6b1680693a9..800ed36ecfba 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -16,6 +16,8 @@
 
 void xen_arch_pre_suspend(void)
 {
+   xen_save_time_memory_area();
+
if (xen_pv_domain())
xen_pv_pre_suspend();
 }
@@ -26,6 +28,8 @@ void xen_arch_post_suspend(int cancelled)
xen_pv_post_suspend(cancelled);
else
xen_hvm_post_suspend(cancelled);
+
+   xen_restore_time_memory_area();
 }
 
 static void xen_vcpu_notify_restore(void *data)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 1ecb05db3632..2924b97691c6 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -370,6 +370,105 @@ static const struct pv_time_ops xen_time_ops __initconst 
= {
.steal_clock = xen_steal_clock,
 };
 
+static struct pvclock_vsyscall_time_info *xen_clock __read_mostly;
+
+void xen_save_time_memory_area(void)
+{
+   struct vcpu_register_time_memory_area t;
+   int ret;
+
+   if (!xen_clock)
+   return;
+
+   t.addr.v = NULL;
+
+   ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, );
+   if (ret != 0)
+   pr_notice("Cannot save secondary vcpu_time_info (err %d)",
+ ret);
+   else
+   clear_page(xen_clock);
+}
+
+void xen_restore_time_memory_area(void)
+{
+   struct vcpu_register_time_memory_area t;
+   int ret;
+
+   if (!xen_clock)
+   return;
+
+   t.addr.v = _clock->pvti;
+
+   ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, );
+
+   /*
+* We don't disable VCLOCK_PVCLOCK entirely if it fails to register the
+* secondary time info with Xen or if we migrated to a host without the
+* necessary flags. On both of these cases what happens is either
+* process seeing a zeroed out pvti or seeing no PVCLOCK_TSC_STABLE_BIT
+* bit set. Userspace checks the latter and if 0, it discards the data
+* in pvti and fallbacks to a system call for a reliable timestamp.
+*/
+   if (ret != 0)
+   pr_notice("Cannot restore secondary vcpu_time_info (err %d)",
+ ret);
+}
+
+static void xen_setup_vsyscall_time_info(void)
+{
+   struct vcpu_register_time_memory_area t;
+   struct pvclock_vsyscall_time_info *ti;
+   struct pvclock_vcpu_time_info *pvti;
+   int ret;
+
+   pvti = &__this_cpu_read(xen_vcpu)->time;
+
+   /*
+* We check ahead on the primary time info if this
+* bit is supported hence speeding up Xen clocksource.
+*/
+   if (!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))
+   return;
+
+   pvclock_set_flags(PVCLOCK_TSC_STABLE_BIT);
+
+   ti = (struct pvclock_vsyscall_time_info *) get_zeroed_page(GFP_KERNEL);
+   if (!ti)
+ 

[Xen-devel] [PATCH v2 0/3] x86/xen: pvclock vdso support

[Joao Martins]

Hey,

Sorry for the huge delay in following up this series.

This take 2 for vdso for Xen. PVCLOCK_TSC_STABLE_BIT can be set starting Xen
 4.8 which is required for vdso time related calls. In order to have it on, you
need to have the hypervisor clocksource be TSC e.g. with the following boot
params "clocksource=tsc tsc=stable:socket".

Series is structured as following:

Patch 1 streamlines pvti page get/set in pvclock for both of its users
Patch 2 registers the pvti page on Xen and sets it in pvclock accordingly
Patch 3 adds a file to KVM/Xen maintainers for tracking pvclock ABI changes.

Changelog since v1 is included in individual patches.

Any comments/suggestions are welcome.

Thanks,
Joao


Joao Martins (3):
  x86/pvclock: add setter for pvclock_pvti_cpu0_va
  x86/xen/time: setup vcpu 0 time info page
  MAINTAINERS: xen, kvm: track pvclock-abi.h changes

 MAINTAINERS|   2 +
 arch/x86/include/asm/pvclock.h |  19 
 arch/x86/kernel/kvmclock.c |   7 +--
 arch/x86/kernel/pvclock.c  |  14 ++
 arch/x86/xen/suspend.c |   4 ++
 arch/x86/xen/time.c| 100 +
 arch/x86/xen/xen-ops.h |   2 +
 include/xen/interface/vcpu.h   |  28 
 8 files changed, 161 insertions(+), 15 deletions(-)

-- 
2.11.0


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

[Xen-devel] [PATCH v2 3/3] MAINTAINERS: xen, kvm: track pvclock-abi.h changes

[Joao Martins]

This file defines an ABI shared between guest and hypervisor(s)
(KVM, Xen) and as such there should be an correspondent entry in
MAINTAINERS file. Notice that there's already a text notice at the
top of the header file, hence this commit simply enforces it more
explicitly and have both peers noticed when such changes happen.

Signed-off-by: Joao Martins 
Acked-by: Juergen Gross 
---
Out of the two options (and provided I was given a choice) I choose the
originally posted because this is so far the only ABI shared between Xen/KVM.
Whenever we have more things shared it would probably deserve moving into its
own section in MAINTAINERS file. If my thinking is wrong, I can switch to the
alternative i.e. a "PARAVIRT ABIS" section.

Changes since v1:
 * Add Juergen Gross Acked-by.
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2281af4b41b6..5a6c26c298b1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7592,6 +7592,7 @@ S:Supported
 F: arch/x86/kvm/
 F: arch/x86/include/uapi/asm/kvm*
 F: arch/x86/include/asm/kvm*
+F: arch/x86/include/asm/pvclock-abi.h
 F: arch/x86/kernel/kvm.c
 F: arch/x86/kernel/kvmclock.c
 
@@ -14708,6 +14709,7 @@ F:  arch/x86/xen/
 F: drivers/*/xen-*front.c
 F: drivers/xen/
 F: arch/x86/include/asm/xen/
+F: arch/x86/include/asm/pvclock-abi.h
 F: include/xen/
 F: include/uapi/xen/
 F: Documentation/ABI/stable/sysfs-hypervisor-xen
-- 
2.11.0


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

[Xen-devel] [PATCH v3 2/3] python: Extract registered watch search logic from xspy_read_watch()

[Euan Harris]

When a watch fires, xspy_read_watch() checks whether the client has
registered interest in the path which changed and, if so, returns the
path and a client-supplied token.   The binding for xs_check_watch()
needs to do the same, so this patch extracts the search code into a
separate function.

Signed-off-by: Euan Harris 
Reviewed-by: Wei Liu 
Acked-by: Marek Marczykowski-Górecki 
---
Changed since v1:
 * Remove stray newline
 * Fix indentation
---
 tools/python/xen/lowlevel/xs/xs.c | 60 ---
 1 file changed, 37 insertions(+), 23 deletions(-)

diff --git a/tools/python/xen/lowlevel/xs/xs.c 
b/tools/python/xen/lowlevel/xs/xs.c
index 3a827b0..e7c3bd0 100644
--- a/tools/python/xen/lowlevel/xs/xs.c
+++ b/tools/python/xen/lowlevel/xs/xs.c
@@ -77,6 +77,8 @@ static inline struct xs_handle *xshandle(XsHandle *self)
 
 static void remove_watch(XsHandle *xsh, PyObject *token);
 
+static PyObject *match_watch_by_token(XsHandle *self, char **xsval);
+
 static PyObject *none(bool result);
 
 static int parse_transaction_path(XsHandle *self, PyObject *args,
@@ -484,8 +486,6 @@ static PyObject *xspy_read_watch(XsHandle *self, PyObject 
*args)
 struct xs_handle *xh = xshandle(self);
 PyObject *val = NULL;
 char **xsval;
-PyObject *token;
-int i;
 unsigned int num;
 
 if (!xh)
@@ -497,29 +497,16 @@ again:
 Py_END_ALLOW_THREADS
 if (!xsval) {
 PyErr_SetFromErrno(xs_error);
-goto exit;
-}
-if (sscanf(xsval[XS_WATCH_TOKEN], "%li", (unsigned long *)) != 1) {
-   xs_set_error(EINVAL);
-goto exit;
-}
-for (i = 0; i < PyList_Size(self->watches); i++) {
-if (token == PyList_GetItem(self->watches, i))
-break;
-}
-if (i == PyList_Size(self->watches)) {
-  /* We do not have a registered watch for the one that has just fired.
- Ignore this -- a watch that has been recently deregistered can still
- have watches in transit.  This is a blocking method, so go back to
- read again.
-  */
-  free(xsval);
-  goto again;
+return val;
 }
-/* Create tuple (path, token). */
-val = Py_BuildValue("(sO)", xsval[XS_WATCH_PATH], token);
- exit:
+
+val = match_watch_by_token(self, xsval);
 free(xsval);
+
+if (!val && errno == EAGAIN) {
+goto again;
+}
+
 return val;
 }
 
@@ -868,6 +855,33 @@ static int parse_transaction_path(XsHandle *self, PyObject 
*args,
 }
 
 
+static PyObject *match_watch_by_token(XsHandle *self, char **xsval)
+{
+PyObject *token;
+int i;
+
+if (sscanf(xsval[XS_WATCH_TOKEN], "%li", (unsigned long *)) != 1) {
+xs_set_error(EINVAL);
+return NULL;
+}
+for (i = 0; i < PyList_Size(self->watches); i++) {
+if (token == PyList_GetItem(self->watches, i))
+break;
+}
+if (i == PyList_Size(self->watches)) {
+/* We do not have a registered watch for the one that has just fired.
+   Ignore this -- a watch that has been recently deregistered can still
+   have watches in transit.
+*/
+xs_set_error(EAGAIN);
+return NULL;
+}
+
+/* Create tuple (path, token). */
+return Py_BuildValue("(sO)", xsval[XS_WATCH_PATH], token);
+}
+
+
 static PyObject *none(bool result)
 {
 if (result) {
-- 
1.8.3.1


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

[Xen-devel] [PATCH v3 1/3] python: Add binding for xs_fileno()

[Euan Harris]

xs_fileno() returns a file descriptor which receives events when Xenstore
watches fire.   Exposing this in the Python bindings is a prerequisite
for writing event-driven clients in Python.

Signed-off-by: Euan Harris 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Wei Liu 
---
Changed since v2:
 * Use PyLong_FromLong instead of PyInt_FromLong
---
 tools/python/xen/lowlevel/xs/xs.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/tools/python/xen/lowlevel/xs/xs.c 
b/tools/python/xen/lowlevel/xs/xs.c
index aba5a20..3a827b0 100644
--- a/tools/python/xen/lowlevel/xs/xs.c
+++ b/tools/python/xen/lowlevel/xs/xs.c
@@ -453,6 +453,25 @@ static PyObject *xspy_watch(XsHandle *self, PyObject *args)
 }
 
 
+#define xspy_fileno_doc "\n"  \
+   "Return the FD to poll for notifications when watches fire.\n"   \
+   "Returns: [int] file descriptor.\n"\
+   "\n"
+
+static PyObject *xspy_fileno(XsHandle *self)
+{
+struct xs_handle *xh = xshandle(self);
+int fd;
+
+if (!xh)
+return NULL;
+
+fd = xs_fileno(xh);
+
+return PyLong_FromLong(fd);
+}
+
+
 #define xspy_read_watch_doc "\n"   \
"Read a watch notification.\n"  \
"\n"\
@@ -887,6 +906,7 @@ static PyMethodDef xshandle_methods[] = {
 XSPY_METH(release_domain,METH_VARARGS),
 XSPY_METH(close, METH_NOARGS),
 XSPY_METH(get_domain_path,   METH_VARARGS),
+XSPY_METH(fileno,METH_NOARGS),
 { NULL /* Sentinel. */ },
 };
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH v3 3/3] python: Add binding for non-blocking xs_check_watch()

[Euan Harris]

xs_check_watch() checks for watch notifications without blocking.
Together with the binding for xs_fileno(), this makes it possible
to write event-driven clients in Python.

Signed-off-by: Euan Harris 
Reviewed-by: Wei Liu 
Acked-by: Marek Marczykowski-Górecki 
---
 tools/python/xen/lowlevel/xs/xs.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/tools/python/xen/lowlevel/xs/xs.c 
b/tools/python/xen/lowlevel/xs/xs.c
index e7c3bd0..9a0acfc 100644
--- a/tools/python/xen/lowlevel/xs/xs.c
+++ b/tools/python/xen/lowlevel/xs/xs.c
@@ -474,6 +474,33 @@ static PyObject *xspy_fileno(XsHandle *self)
 }
 
 
+#define xspy_check_watch_doc "\n"  \
+   "Check for watch notifications without blocking.\n" \
+   "\n"\
+   "Returns: [tuple] (path, token).\n" \
+   " None if no watches have fired.\n" \
+   "Raises xen.lowlevel.xs.Error on error.\n"  \
+   "\n"
+
+static PyObject *xspy_check_watch(XsHandle *self, PyObject *args)
+{
+struct xs_handle *xh = xshandle(self);
+PyObject *val = NULL;
+char **xsval;
+
+if (!xh)
+return NULL;
+
+xsval = xs_check_watch(xh);
+if (!xsval) {
+return none(errno == EAGAIN);
+}
+
+val = match_watch_by_token(self, xsval);
+free(xsval);
+return val;
+}
+
 #define xspy_read_watch_doc "\n"   \
"Read a watch notification.\n"  \
"\n"\
@@ -911,6 +938,7 @@ static PyMethodDef xshandle_methods[] = {
 XSPY_METH(set_permissions,   METH_VARARGS),
 XSPY_METH(watch, METH_VARARGS),
 XSPY_METH(read_watch,METH_NOARGS),
+XSPY_METH(check_watch,   METH_NOARGS),
 XSPY_METH(unwatch,   METH_VARARGS),
 XSPY_METH(transaction_start, METH_NOARGS),
 XSPY_METH(transaction_end,   METH_VARARGS | METH_KEYWORDS),
-- 
1.8.3.1


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

[Xen-devel] [PATCH v3 0/3] python: Add non-blocking Xenstore watch bindings

[Euan Harris]

Expose xs_fileno() and xs_check_watch() to Python.   These functions
make it posible to write event-driven Xenstore clients in Python:

  #!/usr/bin/env python
  
  import xen.lowlevel.xs
  
  import sys
  import errno
  from select import select
  import time
  
  # Connect to XenStore and set watch
  xsh = xen.lowlevel.xs.xs()
  xsh.watch("/foo", "footoken")
  xsh.watch("/bar", "bartoken")
  
  # Start polling loop
  xsfd = xsh.fileno()
  while True:
 readable, writable, exceptional = select([xsfd], [], [xsfd], 1.0)
 print "%d tick" % time.time()
  
 if readable:
 while True:
 watch = xsh.check_watch()
 if not watch:
 break
 path, token = watch
 print "%d watch fired: path=%s, token=%s" % (time.time(), 
  path, token)
 value = xsh.read("", path)
 print "%d read %s = %s" % (time.time(), path, value)
  
 if exceptional:
 print "select error"
  
The polling loop can be simplified further by wrapping the call to
xsh.check_watch() in a generator, but this is easier to do in Python
than in the C bindings.


Euan Harris (3):
  python: Add binding for xs_fileno()
  python: Extract registered watch search logic from  xspy_read_watch()
  python: Add binding for non-blocking xs_check_watch()

 tools/python/xen/lowlevel/xs/xs.c | 108 ++
 1 file changed, 85 insertions(+), 23 deletions(-)

-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH 01/14] fuzz/x86_emulate: Remove redundant AFL hook

[Andrew Cooper]

On 22/09/17 16:47, George Dunlap wrote:

On Fri, Aug 25, 2017 at 6:37 PM, Andrew Cooper
 wrote:

On 25/08/17 17:43, George Dunlap wrote:

You don't need __AFL_INIT if you have __AFL_LOOP.

Signed-off-by: George Dunlap 

Really?  Is that covered in any documentation?

I got the contrary impression from whichever version of AFL I was using
when I put this in, and a quick look over the afl-fuzz source doesn't
appear to equate them in any way.

Trying to answer the feof() question, I dug into llvm mode a bit more.
They are independent features but they can be used together: that is,
if you compile with afl-clang-fast, you always get a forkserver.  If
you specify the location with __AFL_INIT, that's where the forkserver
get started; otherwise, it's somewhere before main() is called.

When __AFL_LOOP(N) is present, it will execute the loop N times before
calling exit(); at which point, the forkserver will fork another
instance (either before main(), or at __AFL_INIT).

So you don't *need* __AFL_INIT; and the amount of time it will save
isn't much (the initialization every 1000 iterations), but I suppose
we might as well keep it.


The purpose of c/s 63092064eb was very deliberately to cause the 
mprotect() remapping the stack as executable to be not repeated.


~Andrew

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

Re: [Xen-devel] [PATCH v2 02/21] libxl: introduce a way to mark fields as deprecated in the idl

[Ian Jackson]

Roger Pau Monné writes ("Re: [PATCH v2 02/21] libxl: introduce a way to mark 
fields as deprecated in the idl"):
> Thanks for the review. I've fixed all the other comments on the series
> and started an osstest flight, my aim is to post a new version of the
> series using the same deprecation idl mechanism ASAP.

I'll look forward to it.

> The motivation for doing this is that I think we really need stable
> PVHv2 support in Xen, and it must be in the next release.

I agree.


> Regarding your proposal for deprecating fields, I was thinking of
> something along the lines of:
> 
> deprecated_fields=[['u.hvm.timer_mode', 'timer_mode'],
>['u.pv.bootloader', 'booloader'],
>...]

That looks fairly nice, yes.

> Something like a list of tuples (I'm not sure this is the right
> terminology in python?), where the first element is the deprecated
> field, and the second one is the new position.
> 
> This has the extra complication that when parsing the types gentypes
> needs to split the strings based on the '.' or '->' delimiters, and
> then iterate inside of the structure object to find the actual
> element. AFAICT this is doable, but not as simple as my current
> approach.

Indeed.

Ian.

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

Re: [Xen-devel] [PATCH v5 18/23] x86/mm: export some stuff via local mm.h

[Andrew Cooper]

On 22/09/17 17:07, Wei Liu wrote:

On Fri, Sep 22, 2017 at 10:00:20AM -0600, Jan Beulich wrote:

On 22.09.17 at 17:56,  wrote:

On Fri, Sep 22, 2017 at 09:44:53AM -0600, Jan Beulich wrote:

On 14.09.17 at 14:58,  wrote:

They will be used by PV mm code and mm hypercall code, which is going
to be split into two files.

Hmm, no, I think I'd prefer mod_lN_entry() and
{get,put}_page_from_lNe() to stay in the same file (with the
possible exception of {get,put}_page_from_l1e(), as under
discussion elsewhere).


Seeing that mod_lN_entry's are only used by PV hypercall code I opted to
split them to mm-hypercalls.c in later file.

Now you want to put {get,put}_page_from_lNe and mod_lN_entry in the same
file, there are two choices:

1. Merge mm-hypercalls.c into pv/mm.c.
2. Leave mod_*_entry in pv/mm.c and keep mm-hypercalls.c -- this would
require exporting mod_*_entry via local header file.

Which one do you prefer?

I think I'd prefer 1 over 2, but please give Andrew a chance to
voice his opinion too.


Definitely.


I'd err on the side of 1) over 2) in this case.  I think it is more 
important to not have these functions exported, than to minimize the 
size of each translation unit.


~Andrew

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

Re: [Xen-devel] [PATCH v5 18/23] x86/mm: export some stuff via local mm.h

[Wei Liu]

On Fri, Sep 22, 2017 at 10:00:20AM -0600, Jan Beulich wrote:
> >>> On 22.09.17 at 17:56,  wrote:
> > On Fri, Sep 22, 2017 at 09:44:53AM -0600, Jan Beulich wrote:
> >> >>> On 14.09.17 at 14:58,  wrote:
> >> > They will be used by PV mm code and mm hypercall code, which is going
> >> > to be split into two files.
> >> 
> >> Hmm, no, I think I'd prefer mod_lN_entry() and
> >> {get,put}_page_from_lNe() to stay in the same file (with the
> >> possible exception of {get,put}_page_from_l1e(), as under
> >> discussion elsewhere).
> >> 
> > 
> > Seeing that mod_lN_entry's are only used by PV hypercall code I opted to
> > split them to mm-hypercalls.c in later file.
> > 
> > Now you want to put {get,put}_page_from_lNe and mod_lN_entry in the same
> > file, there are two choices:
> > 
> > 1. Merge mm-hypercalls.c into pv/mm.c.
> > 2. Leave mod_*_entry in pv/mm.c and keep mm-hypercalls.c -- this would
> >require exporting mod_*_entry via local header file.
> > 
> > Which one do you prefer?
> 
> I think I'd prefer 1 over 2, but please give Andrew a chance to
> voice his opinion too.
> 

Definitely.

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

Re: [Xen-devel] [PATCH v2 02/21] libxl: introduce a way to mark fields as deprecated in the idl

[Roger Pau Monné]

On Wed, Sep 20, 2017 at 04:46:16PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v2 02/21] libxl: introduce a way to mark 
> fields as deprecated in the idl"):
> > The deprecation involves generating a function that copies the
> > deprecated fields into it's new location if the new location has not
> > been set.
> 
> Hi.  We had an IRL conversation which I will summarise.
> 
> 
> The first issue is about the scoping and context of the deprecated_by
> annotations.  The arrangement you have is that the field name in
> deprecated_by is a (textual) reference to an (implicit) enclosing
> struct which has copy_deprecated_fn specified.
> 
> This is kind of OK but it feels a bit limited and irregular to me.
> The practical consequence is that this can be used to bring fields out
> into the toplevel, but it is difficult to use it in other ways (for
> example, to move a field from one substruct to another, or to
> deprecate fields which are part of named substrutures rather than
> anonymous ones and which might therefore appear in several places).
> 
> We discussed how this might be done better.  To me it seems like the
> only really plausible alternative was to replace the
> `deprecated_by' and `copy_deprecated_fn' annotations with a single
> annotation in the parent structure, something like
>   deprecated_fields=['u.hvm','u',['bootloader_args',
>   'timer_mode', ...]
> or maybe even
>   deprecated_fields=['u.hvm','u',[('timer_mode_new_name','timer_mode')]]
> 
> I really don't want to ask you to implement this general scheme now,
> but if you feel like it you could perhaps experiment and see how it
> seems.

Hello,

Thanks for the review. I've fixed all the other comments on the series
and started an osstest flight, my aim is to post a new version of the
series using the same deprecation idl mechanism ASAP.

The motivation for doing this is that I think we really need stable
PVHv2 support in Xen, and it must be in the next release.

Regarding your proposal for deprecating fields, I was thinking of
something along the lines of:

deprecated_fields=[['u.hvm.timer_mode', 'timer_mode'],
   ['u.pv.bootloader', 'booloader'],
   ...]

Something like a list of tuples (I'm not sure this is the right
terminology in python?), where the first element is the deprecated
field, and the second one is the new position.

This has the extra complication that when parsing the types gentypes
needs to split the strings based on the '.' or '->' delimiters, and
then iterate inside of the structure object to find the actual
element. AFAICT this is doable, but not as simple as my current
approach.

Roger.

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

Re: [Xen-devel] [PATCH v5 18/23] x86/mm: export some stuff via local mm.h

[Jan Beulich]

>>> On 22.09.17 at 17:56,  wrote:
> On Fri, Sep 22, 2017 at 09:44:53AM -0600, Jan Beulich wrote:
>> >>> On 14.09.17 at 14:58,  wrote:
>> > They will be used by PV mm code and mm hypercall code, which is going
>> > to be split into two files.
>> 
>> Hmm, no, I think I'd prefer mod_lN_entry() and
>> {get,put}_page_from_lNe() to stay in the same file (with the
>> possible exception of {get,put}_page_from_l1e(), as under
>> discussion elsewhere).
>> 
> 
> Seeing that mod_lN_entry's are only used by PV hypercall code I opted to
> split them to mm-hypercalls.c in later file.
> 
> Now you want to put {get,put}_page_from_lNe and mod_lN_entry in the same
> file, there are two choices:
> 
> 1. Merge mm-hypercalls.c into pv/mm.c.
> 2. Leave mod_*_entry in pv/mm.c and keep mm-hypercalls.c -- this would
>require exporting mod_*_entry via local header file.
> 
> Which one do you prefer?

I think I'd prefer 1 over 2, but please give Andrew a chance to
voice his opinion too.

Jan


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

Re: [Xen-devel] [PATCH v5 18/23] x86/mm: export some stuff via local mm.h

[Wei Liu]

On Fri, Sep 22, 2017 at 09:44:53AM -0600, Jan Beulich wrote:
> >>> On 14.09.17 at 14:58,  wrote:
> > They will be used by PV mm code and mm hypercall code, which is going
> > to be split into two files.
> 
> Hmm, no, I think I'd prefer mod_lN_entry() and
> {get,put}_page_from_lNe() to stay in the same file (with the
> possible exception of {get,put}_page_from_l1e(), as under
> discussion elsewhere).
> 

Seeing that mod_lN_entry's are only used by PV hypercall code I opted to
split them to mm-hypercalls.c in later file.

Now you want to put {get,put}_page_from_lNe and mod_lN_entry in the same
file, there are two choices:

1. Merge mm-hypercalls.c into pv/mm.c.
2. Leave mod_*_entry in pv/mm.c and keep mm-hypercalls.c -- this would
   require exporting mod_*_entry via local header file.

Which one do you prefer?

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

Re: [Xen-devel] [PATCH v5 17/23] x86/mm: export base_disallow_mask and l1 mask in asm-x86/mm.h

[Wei Liu]

On Fri, Sep 22, 2017 at 07:52:13AM -0600, Jan Beulich wrote:
> >>> On 14.09.17 at 14:58,  wrote:
> > The l1 mask needs to stay in x86/mm.c while l{2,3,4} masks are only
> > needed by PV code. Both x86 common mm code and PV mm code use
> > base_disallow_mask and l1 maks.
> > 
> > Export base_disallow_mask and l1 mask in asm-x86/mm.h.
> 
> So that's because in patch 20 you need to keep
> get_page_from_l1e() in x86/mm.c, due to being used by shadow
> code. But is shadow using the same disallow mask for HVM guests
> actually correct? Perhaps it would be better for callers of
> get_page_from_l1e() to pass in their disallow masks, even if it
> would just so happen that PV and shadow use the same ones?

I think this is a fine idea, fwiw.

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

Re: [Xen-devel] [PATCH v5 20/23] x86/mm: split out PV mm code to pv/mm.c

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> A load of functions are moved:
> 
> 1. {get,put}_page_from_l{2,3,4}e

As just indicated in reply to another patch, I'd really hope for these
to stay together with mod_lN_entry().

Jan


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

Re: [Xen-devel] [PATCH v5 19/23] x86/mm: export get_page_light via asm-x86/mm.h

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> It is going to be needed by common x86 mm code and pv mm code.

The sole callers are alloc_page_type() and __put_final_page_type(),
and their respective code paths should be PV only. I'd also prefer if
the compiler remained to be able to decide whether it wants to inline
the function.

Jan


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

Re: [Xen-devel] [PATCH 01/14] fuzz/x86_emulate: Remove redundant AFL hook

[George Dunlap]

On Fri, Aug 25, 2017 at 6:37 PM, Andrew Cooper
 wrote:
> On 25/08/17 17:43, George Dunlap wrote:
>> You don't need __AFL_INIT if you have __AFL_LOOP.
>>
>> Signed-off-by: George Dunlap 
>
> Really?  Is that covered in any documentation?
>
> I got the contrary impression from whichever version of AFL I was using
> when I put this in, and a quick look over the afl-fuzz source doesn't
> appear to equate them in any way.

Trying to answer the feof() question, I dug into llvm mode a bit more.
They are independent features but they can be used together: that is,
if you compile with afl-clang-fast, you always get a forkserver.  If
you specify the location with __AFL_INIT, that's where the forkserver
get started; otherwise, it's somewhere before main() is called.

When __AFL_LOOP(N) is present, it will execute the loop N times before
calling exit(); at which point, the forkserver will fork another
instance (either before main(), or at __AFL_INIT).

So you don't *need* __AFL_INIT; and the amount of time it will save
isn't much (the initialization every 1000 iterations), but I suppose
we might as well keep it.

 -George

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

Re: [Xen-devel] [PATCH v5 18/23] x86/mm: export some stuff via local mm.h

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> They will be used by PV mm code and mm hypercall code, which is going
> to be split into two files.

Hmm, no, I think I'd prefer mod_lN_entry() and
{get,put}_page_from_lNe() to stay in the same file (with the
possible exception of {get,put}_page_from_l1e(), as under
discussion elsewhere).

Jan


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

Re: [Xen-devel] [PATCH v9 07/10] xen: delay allocation of grant table sub structures

[Juergen Gross]

On 22/09/17 16:43, Jan Beulich wrote:
 On 22.09.17 at 13:41,  wrote:
>> Delay the allocation of the grant table sub structures in order to
>> allow modifying parameters needed for sizing of these structures at a
>> per domain basis. Allocate the structures and the table frames only
>> from grant_table_set_limits() (dom0: from grant_table_create()).
> 
> I think this last part is stale now - it's uniformly grant_table_init()
> where this happens.
> 
>> +if ( d->domain_id == 0 )
>>  {
>> -if ( (t->shared_raw[i] = alloc_xenheap_page()) == NULL )
>> -goto no_mem_4;
>> -clear_page(t->shared_raw[i]);
>> +grant_write_lock(t);
>> +ret = grant_table_init(d, t);
>> +grant_write_unlock(t);
>>  }
> 
> With this and ...
> 
>> @@ -3653,8 +3650,9 @@ int grant_table_set_limits(struct domain *d, unsigned 
>> int grant_frames,
>>  
>>  grant_write_lock(gt);
>>  
>> -ret = 0;
>> -/* Set limits, alloc needed arrays. */
>> +/* Set limits. */
>> +if ( !gt->active )
>> +ret = grant_table_init(d, gt);
>>  
>>  grant_write_unlock(gt);
> 
> ... this, wouldn't it be more natural now to acquire and release the
> lock in grant_table_init()?

Right. The test for !gt->active can be dropped, as grant_table_init()
will return -EBUSY in this case anyway.


Juergen

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

Re: [Xen-devel] [PATCH v9 09/10] xen: make grant resource limits per domain

[Jan Beulich]

>>> On 22.09.17 at 13:41,  wrote:
> Instead of using the same global resource limits of grant tables (max.
> number of grant frames, max. number of maptrack frames) for all domains
> make these limits per domain. Set those per-domain limits in
> grant_table_set_limits(). The global settings are serving as an upper
> boundary now which must not be exceeded by a per-domain value. The
> default of max_grant_frames is set to the maximum default xl will use.
> 
> While updating the semantics of the boot parameters remove the
> documentation of the no longer existing gnttab_max_nr_frames.

"... and correct the default gnttab_max_maptrack_frames uses" (or
some such).

> @@ -1672,8 +1670,8 @@ gnttab_grow_table(struct domain *d, unsigned int 
> req_nr_frames)
>  ASSERT(gt->active);
>  
>  if ( req_nr_frames < INITIAL_NR_GRANT_FRAMES )
> -req_nr_frames = INITIAL_NR_GRANT_FRAMES;
> -ASSERT(req_nr_frames <= max_grant_frames);
> +req_nr_frames = min(INITIAL_NR_GRANT_FRAMES, gt->max_grant_frames);

I'm not convinced of this: You effectively allowing a zero size grant
table this way. I'd prefer if the "initial" constant stayed the lower
bound. I'm open to lowering that initial value, though.

> @@ -1824,6 +1818,21 @@ gnttab_setup_table(
>  gt = d->grant_table;
>  grant_write_lock(gt);
>  
> +if ( unlikely(op.nr_frames > gt->max_grant_frames) )
> +{
> +gdprintk(XENLOG_INFO, "d%u is limited to %u grant-table frames.\n",

You've switched to %u one too many times - domain IDs want
printing with %d (also below).

> @@ -2970,14 +2983,14 @@ 
> gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
>  
>  static long
>  gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) 
> uop,
> - int count)
> + unsigned int count, unsigned int limit_max)
> {
>   gnttab_get_status_frames_t op;
>  struct domain *d;
>  struct grant_table *gt;
>  uint64_t   gmfn;
>  int i;
> -int rc;
> +int rc, ret = 0;

This variable doesn't look to be necessary anymore (also in
gnttab_setup_table(), as I notice only now).

> @@ -3010,9 +3023,19 @@ 
> gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) 
> uop,
>  
>  if ( unlikely(op.nr_frames > nr_status_frames(gt)) )
>  {
> -gdprintk(XENLOG_INFO, "Guest requested addresses for %d grant status 
> "
> - "frames, but only %d are available.\n",
> - op.nr_frames, nr_status_frames(gt));
> +gdprintk(XENLOG_INFO, "Guest requested addresses of d%u for %u grant 
> "
> + "status frames, but only %u are available.\n",

Drop "Guest" and make the end ", has only %u\n"?

> @@ -3665,7 +3694,11 @@ int grant_table_set_limits(struct domain *d, unsigned 
> int grant_frames,
>  
>  /* Set limits. */
>  if ( !gt->active )
> +{
> +gt->max_grant_frames = grant_frames;

As per above I think you want to silently apply a lower bound here.

> @@ -3769,6 +3802,12 @@ static void gnttab_usage_print(struct domain *rd)
>  
>  grant_read_lock(gt);
>  
> +printk("grant-table for remote domain:%5d (v%d)\n"

"grant table for d%d (v%u)\n"?

> +   "  %d frames (%d max), %d maptrack frames (%d max)\n",

%u (four times)

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  ffdce9b1f1a5c59b928222b886488e28d4a03590
baseline version:
 libvirt  eae746b2d75973babf1d8b5095db1c7c53573659

Last test of basis   113652  2017-09-21 04:20:55 Z1 days
Testing same since   113708  2017-09-22 04:23:35 Z0 days1 attempts


People who touched revisions under test:
  Ashish Mittal 
  Boris Fiuczynski 
  Daniel P. Berrange 
  Jiri Denemark 
  John Ferlan 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Pino Toscano 

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



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=ffdce9b1f1a5c59b928222b886488e28d4a03590
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ 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
++ 

Re: [Xen-devel] Booting signed xen.efi through shim

[Tamas K Lengyel]

On Fri, Sep 22, 2017 at 2:25 AM, Jan Beulich  wrote:
 On 22.09.17 at 00:46,  wrote:
>> One piece that I see still missing is the Xen command line parameters
>> not being verified. It would be ideal to have the option to get that
>> set during compile time as well, similar to Linux's CONFIG_CMDLINE
>> option, to avoid for example getting iommu or XSM being turned off by
>> someone with physical access.
>
> We do have CMDLINE and CMDLINE_OVERRIDE. But for someone
> with physical access it would likely also be possible to avoid secure
> boot altogether?
>

Interesting, it never showed up for me in make menuconfig. Searching
for it does show it but seems to be not accessible in menuconfig.
Anyway, good to know! And indeed, someone having physical access could
do a firmware reset by taking the computer apart (firmware would need
to be password protected if Secureboot is enabled). What I meant is
protection against someone during boot changing the config options or
altering the cfg file on disk.

And even with a firmware reset, I guess it's up to the OEM to decide
what the reset state is. So it might be possible in some situations to
have the reset state also include having Secureboot enabled with the
custom keys. Otherwise having the disk encrypted with the key being
sealed in the TPM against PCR[0-4] for example should work. Provided
of course that a malicious firmware can't fake those measurements
somehow.

Tamas

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

[Xen-devel] [GIT PULL] xen: Fixes for rc2

[Juergen Gross]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-4.14b-rc2-tag

xen: Fixes for rc2

It contains a fix for a missing __init annotation and two cleanup patches.

Thanks.

Juergen

 arch/x86/xen/mmu_pv.c  |   2 +-
 drivers/xen/xenbus/xenbus_client.c | 130 +++--
 include/xen/arm/page.h |  10 ---
 3 files changed, 68 insertions(+), 74 deletions(-)

Arnd Bergmann (1):
  xen: x86: mark xen_find_pt_base as __init

Juergen Gross (1):
  xen: don't compile pv-specific parts if XEN_PV isn't configured

Tycho Andersen (1):
  xen, arm64: drop dummy lookup_address()

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

Re: [Xen-devel] [PATCH v9 10/10] xen: add new Xen cpuid node for max address width info

[Jan Beulich]

>>> On 22.09.17 at 13:41,  wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -929,6 +929,13 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, 
> uint32_t leaf,
>  res->b = v->vcpu_id;
>  break;
>  
> +case 5: /* PV-specific parameters */
> +if ( is_hvm_domain(d) || subleaf != 0 )
> +break;
> +
> +res->a = generic_flsl(get_upper_mfn_bound()) + PAGE_SHIFT;
> +break;

The subleaf check here should be mirrored ...

> --- a/xen/include/public/arch-x86/cpuid.h
> +++ b/xen/include/public/arch-x86/cpuid.h
> @@ -85,6 +85,15 @@
>  #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
>  #define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3) /* vcpu id is present in 
> EBX 
> */
>  
> -#define XEN_CPUID_MAX_NUM_LEAVES 4
> +/*
> + * Leaf 6 (0x4x05)
> + * PV-specific parameters
> + * EAX: bits 0-7: max machine address width
> + */

... in the comment here. This is easily doable while committing,
but I'd like to be certain Andrew in particular has no objections
to this new leaf before putting this in.

Jan


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

Re: [Xen-devel] [PATCH v9 07/10] xen: delay allocation of grant table sub structures

[Jan Beulich]

>>> On 22.09.17 at 13:41,  wrote:
> Delay the allocation of the grant table sub structures in order to
> allow modifying parameters needed for sizing of these structures at a
> per domain basis. Allocate the structures and the table frames only
> from grant_table_set_limits() (dom0: from grant_table_create()).

I think this last part is stale now - it's uniformly grant_table_init()
where this happens.

> +if ( d->domain_id == 0 )
>  {
> -if ( (t->shared_raw[i] = alloc_xenheap_page()) == NULL )
> -goto no_mem_4;
> -clear_page(t->shared_raw[i]);
> +grant_write_lock(t);
> +ret = grant_table_init(d, t);
> +grant_write_unlock(t);
>  }

With this and ...

> @@ -3653,8 +3650,9 @@ int grant_table_set_limits(struct domain *d, unsigned 
> int grant_frames,
>  
>  grant_write_lock(gt);
>  
> -ret = 0;
> -/* Set limits, alloc needed arrays. */
> +/* Set limits. */
> +if ( !gt->active )
> +ret = grant_table_init(d, gt);
>  
>  grant_write_unlock(gt);

... this, wouldn't it be more natural now to acquire and release the
lock in grant_table_init()?

Jan


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

Re: [Xen-devel] [PATCH v9 01/10] xen: add function for obtaining highest possible memory address

[Jan Beulich]

>>> On 22.09.17 at 13:41,  wrote:
> @@ -104,6 +104,8 @@ struct xen_sysctl_physinfo {
>  
>  /* XEN_SYSCTL_PHYSCAP_??? */
>  uint32_t capabilities;
> +
> +uint64_t max_mfn; /* Largest possible MFN on this host */
>  };

I'm sorry for not having noticed this earlier - this needs to be
uint64_aligned_t and creates an unnamed padding hole (yes,
there already is another one, but anyway). So I think this also
wants moving up to avoid creating yet another hole. I think
this is doable while committing (and if I end up doing it I'll likely
take the opportunity and move "capabilities" up into the earlier
hole at the same time). With that adjustment
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

[Thomas Garnier]

On Thu, Sep 21, 2017 at 9:24 PM, Markus Trippelsdorf
 wrote:
> On 2017.09.21 at 14:21 -0700, Thomas Garnier wrote:
>> On Thu, Sep 21, 2017 at 9:10 AM, Ard Biesheuvel
>>  wrote:
>> >
>> > On 21 September 2017 at 08:59, Ingo Molnar  wrote:
>> > >
>> > > ( Sorry about the delay in answering this. I could blame the delay on 
>> > > the merge
>> > >   window, but in reality I've been procrastinating this is due to the 
>> > > permanent,
>> > >   non-trivial impact PIE has on generated C code. )
>> > >
>> > > * Thomas Garnier  wrote:
>> > >
>> > >> 1) PIE sometime needs two instructions to represent a single
>> > >> instruction on mcmodel=kernel.
>> > >
>> > > What again is the typical frequency of this occurring in an x86-64 
>> > > defconfig
>> > > kernel, with the very latest GCC?
>> > >
>> > > Also, to make sure: which unwinder did you use for your measurements,
>> > > frame-pointers or ORC? Please use ORC only for future numbers, as
>> > > frame-pointers is obsolete from a performance measurement POV.
>> > >
>> > >> 2) GCC does not optimize switches in PIE in order to reduce relocations:
>> > >
>> > > Hopefully this can either be fixed in GCC or at least influenced via a 
>> > > compiler
>> > > switch in the future.
>> > >
>> >
>> > There are somewhat related concerns in the ARM world, so it would be
>> > good if we could work with the GCC developers to get a more high level
>> > and arch neutral command line option (-mkernel-pie? sounds yummy!)
>> > that stops the compiler from making inferences that only hold for
>> > shared libraries and/or other hosted executables (GOT indirections,
>> > avoiding text relocations etc). That way, we will also be able to drop
>> > the 'hidden' visibility override at some point, which we currently
>> > need to prevent the compiler from redirecting all global symbol
>> > references via entries in the GOT.
>>
>> My plan was to add a -mtls-reg= to switch the default segment
>> register for stack cookies but I can see great benefits in having a
>> more general kernel flag that would allow to get rid of the GOT and
>> PLT when you are building position independent code for the kernel. It
>> could also include optimizations like folding switch tables etc...
>>
>> Should we start a separate discussion on that? Anyone that would be
>> more experienced than I to push that to gcc & clang upstream?
>
> Just open a gcc bug. See
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 as an example.

Make sense, I will look into this. Thanks Andy for the stack cookie bug!

>
> --
> Markus



-- 
Thomas

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

Re: [Xen-devel] [PATCH v5 16/23] x86/mm: add pv prefix to {alloc, free}_page_type

[Wei Liu]

On Fri, Sep 22, 2017 at 08:24:20AM -0600, Jan Beulich wrote:
> >>> On 22.09.17 at 16:07,  wrote:
> > On Fri, Sep 22, 2017 at 07:40:04AM -0600, Jan Beulich wrote:
> >> Additionally could you add (half) a sentence regarding the
> >> PGT_l*_page_table uses outside of PV specific code, which I'm
> >> sure you have verified can't make it into the stubs?
> > 
> > At this stage I can only verify it by reading the code. I can't turn off
> > PV yet.
> 
> Of course, that's what I did mean.
> 
> > To allocate a PGT_l*_page_table type page, the guest must explicitly
> > request such types via PV MMU hypercall; there is no code other than the
> > PV dom0 builder and p2m_alloc_ptp  in the hypervisor would explicitly
> > ask for PGT_l*_page_table type pages.
> > 
> > p2m_alloc_table is a bit tricky. I think it can get away with not using
> > PGT_l*_page_table type pages, but that is work for another day.  Anyway,
> > currently it frees the pages directly with free_page from different
> > paging modes, all of which won't go into PV mm code.
> 
> Right, hence the request to extend the description a little.
> shadow_enable() also has a use that's not so obviously not
> a problem.

The call chain is paging_enable -> shadow_enable. paging_enable is only
called by hvm code.

The teardown in shadow_final_teardown is also done with p2m_teardown
which goes to free_page function in respective paging modes.

All in all, it is not a problem in that code path either.

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

Re: [Xen-devel] [PATCH v5 16/23] x86/mm: add pv prefix to {alloc, free}_page_type

[Jan Beulich]

>>> On 22.09.17 at 16:07,  wrote:
> On Fri, Sep 22, 2017 at 07:40:04AM -0600, Jan Beulich wrote:
>> Additionally could you add (half) a sentence regarding the
>> PGT_l*_page_table uses outside of PV specific code, which I'm
>> sure you have verified can't make it into the stubs?
> 
> At this stage I can only verify it by reading the code. I can't turn off
> PV yet.

Of course, that's what I did mean.

> To allocate a PGT_l*_page_table type page, the guest must explicitly
> request such types via PV MMU hypercall; there is no code other than the
> PV dom0 builder and p2m_alloc_ptp  in the hypervisor would explicitly
> ask for PGT_l*_page_table type pages.
> 
> p2m_alloc_table is a bit tricky. I think it can get away with not using
> PGT_l*_page_table type pages, but that is work for another day.  Anyway,
> currently it frees the pages directly with free_page from different
> paging modes, all of which won't go into PV mm code.

Right, hence the request to extend the description a little.
shadow_enable() also has a use that's not so obviously not
a problem.

Jan


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  6 xen-install  fail REGR. vs. 113666

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail REGR. vs. 113666
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 113666

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113666
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail like 113666
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 113666
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113666
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 113666
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 113666
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux6e80ecdddf4ea6f3cd84e83720f3d852e6624a68
baseline version:
 linuxc52f56a69d104d5294af3d652776d94b1ef6a175

Last test of basis   113666  2017-09-21 12:50:30 Z1 days
Testing same since   113703  2017-09-22 02:22:02 Z0 days1 attempts


People who touched revisions under test:
  Al Viro 
  Arnd Bergmann 
  Boris Brezillon 
  Changbin Du 
  Chris Wilson 
  Christoph Hellwig 
  Christophe JAILLET 
  Corentin Labbe 
  Cyrille Pitchen 
  Cyrille Pitchen 
  Dan Williams 
  Dave Airlie 
  Geert Uytterhoeven 
  Greg Kroah-Hartman 
  Himanshu Jha 
  Inki Dae 
  Jani Nikula 

Re: [Xen-devel] [PATCH v1] libxl: remove list callback from device framework

[Oleksandr Grytsov]

On Fri, Sep 22, 2017 at 5:17 PM, Wei Liu  wrote:
> On Fri, Sep 22, 2017 at 05:00:44PM +0300, Oleksandr Grytsov wrote:
>> On Fri, Sep 22, 2017 at 4:02 PM, Wei Liu  wrote:
>> > On Fri, Sep 22, 2017 at 03:28:55PM +0300, Oleksandr Grytsov wrote:
>> >> From: Oleksandr Grytsov 
>> >>
>> >> As we have generic functions to get device list
>> >> (libxl__device_list) no need to have callback in
>> >> the framework. To resolve issue when XS entry
>> >> doesn't match device name, device type is
>> >> extended with field "entry" which keeps XS entry.
>> >>
>> >> Signed-off-by: Oleksandr Grytsov 
>> >
>> > Acked-by: Wei Liu 
>>
>> Shall I resend the patch with your ack?
>
> If this is the final that I can apply, then no; otherwise please resend.

It is final.

-- 
Best Regards,
Oleksandr Grytsov.

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

Re: [Xen-devel] [PATCH v1] libxl: remove list callback from device framework

[Wei Liu]

On Fri, Sep 22, 2017 at 05:00:44PM +0300, Oleksandr Grytsov wrote:
> On Fri, Sep 22, 2017 at 4:02 PM, Wei Liu  wrote:
> > On Fri, Sep 22, 2017 at 03:28:55PM +0300, Oleksandr Grytsov wrote:
> >> From: Oleksandr Grytsov 
> >>
> >> As we have generic functions to get device list
> >> (libxl__device_list) no need to have callback in
> >> the framework. To resolve issue when XS entry
> >> doesn't match device name, device type is
> >> extended with field "entry" which keeps XS entry.
> >>
> >> Signed-off-by: Oleksandr Grytsov 
> >
> > Acked-by: Wei Liu 
> 
> Shall I resend the patch with your ack?

If this is the final that I can apply, then no; otherwise please resend.

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

Re: [Xen-devel] [PATCH v2 0/2] ARM: ACPI: IORT: Hide SMMU from hardware domain's IORT table

[Andre Przywara]

Hi Manish,

On 11/09/17 22:33, mja...@caviumnetworks.com wrote:
> From: Manish Jaggi 
> 
> The set is divided into two patches. First one calculates the size of IORT
> while second one writes the IORT table itself.

It would be good if you could give a quick introduction *why* this set
is needed here (and introduce IORT to the casual reader).
In general some more high-level documentation on your functions would be
good, as it took me quite some time to understand what each function does.

So my understanding is:
phase 1:
- go over each entry in each RC node
-   if that points to an SMMU node, go over each outgoing ITS entry and
find overlaps with this RC entry
- for each overlap create a new entry in a list with this RC
pointing to the ITS directly

phase 2, creating the new IORT
- go over each RC node
-   if that points to an ITS, copy through IORT entries
-   if that points to an SMMU, replace with the remapped entries
- go over each ITS node
-   copy through IORT entries

So I believe this would do the trick and you end up with an efficient
representation of the IORT without SMMUs - at least for RC nodes.

After some brainstorming with Julien we found two problems:
1) This only covers RC nodes, but not "named components" (platform
devices), which we will need. That should be fixable by removing the
hardcoded IORT node types in the code and treating NC nodes like RC nodes.
2) Eventually we will need *virtual* deviceID support, for DomUs. Now we
could start introducing that already, also doing some virtual mapping
for Dom0. The ITS code would then translate each virtual device ID that
Dom0 requests into a hardware device ID.
I agree that this means a lot more work, but we will need it anyway.

I think 1) can be solved using this series as a base. I have quite some
comments ready for the patches, shall we follow this route.

2) obviously would change the game completely. We need to sit down and
design this properly. Probably this means that Xen parses the IORT and
builds internal representations of the mappings, which are consulted as
needed when passing through devices. The guest's (that would include
Dom0) IORT would then be generated completely from scratch.

I would like to hear your opinion on this. I will try to discuss the
feasibility of 2) with people at Connect. It would be good if we could
decide whether this is the way to go or we should use a solution based
on this series.

Cheers,
Andre.


> patch1: estimates size of hardware domain IORT table by parsing all
> the pcirc nodes and their idmaps, and thereby calculating size by
> removing smmu nodes.
> 
> Hardware domain IORT table will have only ITS and PCIRC nodes, and PCIRC
> nodes' idmap will have output refrences to ITS group nodes.
> 
> patch 2: The steps are:
> a. First ITS group nodes are written and their offsets are saved
> along with the respective offsets from the firmware table.
> This is required when smmu node is hidden and smmu node still points
> to the old output_reference.
> 
> b. PCIRC idmap is parsed and a list of idmaps is created which will
> have PCIRC idmap -> ITS group nodes.
> Each idmap is written by resolving ITS offset from the map saved in
> previous step.
> 
> Changes wrt v1:
> No assumption is made wrt format of IORT / hw support
> 
> Manish Jaggi (2):
>   ARM: ACPI: IORT: Estimate the size of hardware domain IORT table
>   ARM: ACPI: IORT: Write Hardware domain's IORT table
> 
>  xen/arch/arm/acpi/Makefile  |   1 +
>  xen/arch/arm/acpi/iort.c| 414 
> 
>  xen/arch/arm/domain_build.c |  49 +-
>  xen/include/asm-arm/acpi.h  |   1 +
>  xen/include/asm-arm/iort.h  |  17 ++
>  5 files changed, 481 insertions(+), 1 deletion(-)
>  create mode 100644 xen/arch/arm/acpi/iort.c
>  create mode 100644 xen/include/asm-arm/iort.h
> 

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

Re: [Xen-devel] [PATCH] custom parameter handling fixes

[Andrew Cooper]

On 14/09/17 09:57, Jan Beulich wrote:

The recent changes to their handling introduced a few false warnings,
due to checks looking at the wrong string slot. While going through all
those commits and looking for patterns similar to the "dom0_mem=" I've
noticed this with, I also realized that there were other issues with
"dom0_nodes=" and "rmrr=", partly pre-existing, but partly also due to
those recent changes not having gone far enough.

Signed-off-by: Jan Beulich 


Acked-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v5 16/23] x86/mm: add pv prefix to {alloc, free}_page_type

[Wei Liu]

On Fri, Sep 22, 2017 at 07:40:04AM -0600, Jan Beulich wrote:
> >>> On 14.09.17 at 14:58,  wrote:
> > And move the declarations to pv/mm.h. The code will be moved later.
> > 
> > The stubs contain BUG() because they aren't supposed to be called when
> > PV is disabled.
> 
> I'd prefer ASSERT_UNREACHABLE() - they return proper errors

ASSERT_UNREACHABLE() -- no problem.

> after all, and there's no need to bring down a production system.
> Additionally could you add (half) a sentence regarding the
> PGT_l*_page_table uses outside of PV specific code, which I'm
> sure you have verified can't make it into the stubs?

At this stage I can only verify it by reading the code. I can't turn off
PV yet.

To allocate a PGT_l*_page_table type page, the guest must explicitly
request such types via PV MMU hypercall; there is no code other than the
PV dom0 builder and p2m_alloc_ptp  in the hypervisor would explicitly
ask for PGT_l*_page_table type pages.

p2m_alloc_table is a bit tricky. I think it can get away with not using
PGT_l*_page_table type pages, but that is work for another day.  Anyway,
currently it frees the pages directly with free_page from different
paging modes, all of which won't go into PV mm code.

So my conclusion by reading the code is non-PV code can't make it to the
stubs

> 
> > --- a/xen/include/asm-x86/pv/mm.h
> > +++ b/xen/include/asm-x86/pv/mm.h
> > @@ -32,6 +32,11 @@ bool pv_map_ldt_shadow_page(unsigned int off);
> >  
> >  void pv_arch_init_memory(void);
> >  
> > +int pv_alloc_page_type(struct page_info *page, unsigned long type,
> > +   int preemptible);
> > +int pv_free_page_type(struct page_info *page, unsigned long type,
> > +  int preemptible);
> > +
> >  #else
> >  
> >  #include 
> > @@ -51,6 +56,13 @@ static inline bool pv_map_ldt_shadow_page(unsigned int 
> > off) { return false; }
> >  
> >  static inline void pv_arch_init_memory(void) {}
> >  
> > +static inline int pv_alloc_page_type(struct page_info *page, unsigned long 
> > type,
> > + int preemptible)
> > +{ BUG(); return -EINVAL; }
> > +static inline int pv_free_page_type(struct page_info *page, unsigned long 
> > type,
> > +int preemptible)
> > +{ BUG(); return -EINVAL; }
> 
> Take the opportunity and make all the "preemptible" parameters bool?

No problem.

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

Re: [Xen-devel] [PATCH v4 04/11] livepatch/arm[32, 64]: Don't load and crash on livepatches loaded with wrong text alignment.

[Jan Beulich]

>>> On 21.09.17 at 00:31,  wrote:

> @@ -272,6 +271,16 @@ int arch_livepatch_perform(struct livepatch_elf *elf,
>  elf->name, symndx);
>  return -EINVAL;
>  }
> +else if ( (type != R_ARM_ABS32 && type != R_ARM_REL32) /* Only check 
> code. */ &&
> +  ((uint32_t)dest % sizeof(uint32_t)) )
> +{
> +dprintk(XENLOG_ERR, LIVEPATCH "%s: dest=%p (%s) is not aligned 
> properly!\n",
> +elf->name, dest, base->name);
> +return -EINVAL;
> +}

And no similar check being added to ARM64? Looking at that code I
also notice that the general "minimum 32-bit width" there is likely
wrong for at least ABS16 and PREL16.

> --- a/xen/common/livepatch.c
> +++ b/xen/common/livepatch.c
> @@ -473,6 +473,13 @@ static bool section_ok(const struct livepatch_elf *elf,
>  return false;
>  }
>  
> +if ( !arch_livepatch_verify_alignment(sec) )
> +{
> +dprintk(XENLOG_ERR, LIVEPATCH "%s: %s text section is not aligned 
> properly!\n",
> +   elf->name, sec->name);

If you really mean to say "text section" here, then the SHF_EXECINSTR
check should move here too.

Jan


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

Re: [Xen-devel] [PATCH v1] libxl: remove list callback from device framework

[Oleksandr Grytsov]

On Fri, Sep 22, 2017 at 4:02 PM, Wei Liu  wrote:
> On Fri, Sep 22, 2017 at 03:28:55PM +0300, Oleksandr Grytsov wrote:
>> From: Oleksandr Grytsov 
>>
>> As we have generic functions to get device list
>> (libxl__device_list) no need to have callback in
>> the framework. To resolve issue when XS entry
>> doesn't match device name, device type is
>> extended with field "entry" which keeps XS entry.
>>
>> Signed-off-by: Oleksandr Grytsov 
>
> Acked-by: Wei Liu 

Shall I resend the patch with your ack?

-- 
Best Regards,
Oleksandr Grytsov.

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

Re: [Xen-devel] [PATCH v5 17/23] x86/mm: export base_disallow_mask and l1 mask in asm-x86/mm.h

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> The l1 mask needs to stay in x86/mm.c while l{2,3,4} masks are only
> needed by PV code. Both x86 common mm code and PV mm code use
> base_disallow_mask and l1 maks.
> 
> Export base_disallow_mask and l1 mask in asm-x86/mm.h.

So that's because in patch 20 you need to keep
get_page_from_l1e() in x86/mm.c, due to being used by shadow
code. But is shadow using the same disallow mask for HVM guests
actually correct? Perhaps it would be better for callers of
get_page_from_l1e() to pass in their disallow masks, even if it
would just so happen that PV and shadow use the same ones?
Tim, do you have any thoughts or insights here?

Jan


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

Re: [Xen-devel] ARM64:Porting xen to new hardware

[Konrad Rzeszutek Wilk]

On Fri, Sep 22, 2017 at 03:30:57PM +0530, bharat gohil wrote:
> Hello Wilk,
> 
> I had try 'console=hvc0' but no success.
> 
> @Oleksandr: At this moment it is difficult to share any file of guest.
> It would be helpful if anyone provide me general technique to debug dom0
> bringup issue.

You can also hit 'Ctrl-a' three times and then 'd' which would give you
the stack trace and EIP of dom0. That should help in figuirng where your
dom0 is stuck.

> 
> Thanks,
> Bharat
> 
> On Mon, Sep 18, 2017 at 8:16 PM, Konrad Rzeszutek Wilk <
> konrad.w...@oracle.com> wrote:
> 
> > On Fri, Sep 08, 2017 at 10:19:55PM +0300, Oleksandr Tyshchenko wrote:
> > > Hi Bharat
> > >
> > > On Thu, Sep 7, 2017 at 4:30 PM, bharat gohil  wrote:
> > > > Hello Olensandr,
> > > >
> > > > I able to boot xen and trying to boot dom0 but there are no console
> > log for
> > > > dom0.
> > > >
> > > > following log for xen and it stuck booting dom0.
> > > >
> > > > (XEN) I/O virtualisation disabled
> > > > (XEN) build-id: 7c2a3c70fb94754801d18c4cb9e3db3ffa01d8c4
> > > > (XEN) alternatives: Patching with alt table 400d2e08 ->
> > > > 400d32dc
> > > > (XEN) *** LOADING DOMAIN 0 ***
> > > > (XEN) Loading kernel from boot module @ 40148158
> > > > (XEN) Allocating 1:1 mappings totalling 128MB for dom0:
> > > > (XEN) BANK[0] 0x004800-0x005000 (128MB)
> > > > (XEN) Grant table range: 0x00bfe0-0x00bfe65000
> > > > (XEN) Loading zImage from 40148158 to
> > > > 4808-4948
> > > > (XEN) Allocating PPI 16 for event channel interrupt
> > > > (XEN) Loading dom0 DTB to 0x4fe0-0x4fe0f31e
> > > > (XEN) Scrubbing Free RAM on 1 nodes using 3 CPUs
> > > > (XEN) ..done.
> > > > (XEN) Initial low memory virq threshold set at 0x4000 pages.
> > > > (XEN) Std. Loglevel: All
> > > > (XEN) Guest Loglevel: All
> > > > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> > input to
> > > > Xen)
> > > > (XEN) Freed 272kB init memory.
> > > >
> > > > I have done all the xen configuration in linux kernel 4.9. This kernel
> > > > booting fine without xen.
> > > >
> > > > following are the DTB changes,
> > > >
> > > > chosen {
> > > > #address-cells = <1>;
> > > > #size-cells = <1>;
> > > > bootargs = "console=dtuart dtuart=serial0 dom0_mem=128M";
> > > > stdout-path = "serial0";
> > > > module: module@0 {
> > > > compatible = "xen,linux-zimage", "xen,multiboot-module";
> > > > reg = <0x40148158 0x140>;
> > > > bootargs = "console=hvc0,921600n8 earlyprintk=xen debug
> >
> > It should be just 'console=hvc0', not 'console=hvc0,921600n8'
> >
> > > > ignore_loglevel rw root=/dev/mmcblk0p7";
> > > > };
> > > >
> > > > };
> > > >
> > > > Can you tell me how to debug dom0 booting or anything which i can
> > check?
> > >
> > > Don't now much about "debug dom0 booting", I leave it for competent
> > people.
> > >
> > > Looks weird, even with earlyprintk no logs.
> > > Do you have DEBUG_LL and all related options enabled in your dom0 kernel
> > config?
> > >
> > > 1. Check that following options are enabled in your kernel config file:
> > >
> > > CONFIG_HVC_XEN=y
> > > CONFIG_HVC_XEN_FRONTEND=y
> > >
> > > 2. Check that dom0 kernel doesn't disable clock for console.
> > >
> > > BTW, could you post full Xen log, kernel config and device-tree you are
> > using?
> > > If you have some changes on top of Xen, post them too.
> > > These may help people to identify what is wrong.
> > >
> > > >
> > > >
> > > > Thanks,
> > > > Bharat
> > > >
> > > > On Wed, Sep 6, 2017 at 3:49 PM, Oleksandr Tyshchenko <
> > olekst...@gmail.com>
> > > > wrote:
> > > >>
> > > >> Hi Bharat
> > > >>
> > > >> On Wed, Sep 6, 2017 at 10:01 AM, bharat gohil 
> > wrote:
> > > >> > Hello Oleksandr,
> > > >> >
> > > >> > Thank you very much.It resolved my issue.
> > > >> Sounds great!
> > > >>
> > > >> >
> > > >> > Thanks,
> > > >> > Bharat
> > > >> >
> > > >> > On Mon, Sep 4, 2017 at 6:24 PM, Oleksandr Tyshchenko
> > > >> > 
> > > >> > wrote:
> > > >> >>
> > > >> >> Hi Bharat
> > > >> >>
> > > >> >> On Mon, Sep 4, 2017 at 7:13 AM, bharat gohil 
> > > >> >> wrote:
> > > >> >> > Hello Oleksandr,
> > > >> >> >
> > > >> >> > I have corrected  GIC settings but no success.Following line
> > > >> >> > disappear
> > > >> >> > from
> > > >> >> > log.
> > > >> >> >>>XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected
> > > >> >> >>> 0x2000
> > > >> >> >
> > > >> >> > Is anything else which can I try.
> > > >> >> >
> > > >> >> > I don’t know much about xen internal for ARM architecture. As you
> > > >> >> > mentioned,
> > > >> >> >>>Wrong GIC settings might lead to that IPIs won't work as
> > expected.
> > > >> >> >>> And
> > > >> >> >>>boot CPU will get stuck waiting for another CPU.
> > > >> >> >
> > > >> >> > Can you 

Re: [Xen-devel] [PATCH v5 16/23] x86/mm: add pv prefix to {alloc, free}_page_type

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> And move the declarations to pv/mm.h. The code will be moved later.
> 
> The stubs contain BUG() because they aren't supposed to be called when
> PV is disabled.

I'd prefer ASSERT_UNREACHABLE() - they return proper errors
after all, and there's no need to bring down a production system.
Additionally could you add (half) a sentence regarding the
PGT_l*_page_table uses outside of PV specific code, which I'm
sure you have verified can't make it into the stubs?

> --- a/xen/include/asm-x86/pv/mm.h
> +++ b/xen/include/asm-x86/pv/mm.h
> @@ -32,6 +32,11 @@ bool pv_map_ldt_shadow_page(unsigned int off);
>  
>  void pv_arch_init_memory(void);
>  
> +int pv_alloc_page_type(struct page_info *page, unsigned long type,
> +   int preemptible);
> +int pv_free_page_type(struct page_info *page, unsigned long type,
> +  int preemptible);
> +
>  #else
>  
>  #include 
> @@ -51,6 +56,13 @@ static inline bool pv_map_ldt_shadow_page(unsigned int 
> off) { return false; }
>  
>  static inline void pv_arch_init_memory(void) {}
>  
> +static inline int pv_alloc_page_type(struct page_info *page, unsigned long 
> type,
> + int preemptible)
> +{ BUG(); return -EINVAL; }
> +static inline int pv_free_page_type(struct page_info *page, unsigned long 
> type,
> +int preemptible)
> +{ BUG(); return -EINVAL; }

Take the opportunity and make all the "preemptible" parameters bool?

Jan


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

Re: [Xen-devel] [PATCH v5 15/23] x86/mm: move declaration of new_guest_cr3 to local pv/mm.h

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> It is only used by PV. The code can only be moved together with other
> PV mm code.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v5 14/23] x86/mm: move PV l4 table setup code

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> @@ -32,6 +33,14 @@
>  #undef page_to_mfn
>  #define page_to_mfn(pg) _mfn(__page_to_mfn(pg))
>  
> +#ifndef NDEBUG
> +static unsigned int __read_mostly root_pgt_pv_xen_slots
> += ROOT_PAGETABLE_PV_XEN_SLOTS;
> +static l4_pgentry_t __read_mostly split_l4e;
> +#else
> +#define root_pgt_pv_xen_slots ROOT_PAGETABLE_PV_XEN_SLOTS
> +#endif
> +
>  /*
>   * Get a mapping of a PV guest's l1e for this linear address.  The return
>   * pointer should be unmapped using unmap_domain_page().
> @@ -133,6 +142,79 @@ bool pv_map_ldt_shadow_page(unsigned int offset)
>  return true;
>  }
>  
> +/*
> + * This function must write all ROOT_PAGETABLE_PV_XEN_SLOTS, to clobber any
> + * values a guest may have left there from alloc_l4_table().
> + */
> +void init_guest_l4_table(l4_pgentry_t l4tab[], const struct domain *d,
> + bool zap_ro_mpt)
> +{

Please move the static variables down right before this function,
so that what belongs together stays together. With that
Acked-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v9 05/10] xl: add global grant limit config items

[Wei Liu]

On Fri, Sep 22, 2017 at 01:41:29PM +0200, Juergen Gross wrote:
> Add xl.conf config items for default values of grant limits:
> 
> max_grant_frames will set the default for the maximum number of grant
> frames for a domain which will take effect if the domain's config file
> doesn't specify a value. If max_grant_frames isn't set in xl.conf it
> will default to 32 for hosts with all memory below 16TB and to 64 for
> hosts with memory above 16TB.
> 
> max_maptrack_frames will set the default for the maximum number of
> maptrack frames for a domain. If max_maptrack_frames isn't set in
> xl.conf it will default to 0, as normally only backend domains need
> maptrack frames.
> 
> Signed-off-by: Juergen Gross 
> Acked-by: Ian Jackson 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v9 06/10] libxl: add libxl support for setting grant table resource limits

[Wei Liu]

On Fri, Sep 22, 2017 at 01:41:30PM +0200, Juergen Gross wrote:
> Add new domain config items for setting the limits for the maximum
> numbers of grant table frames and maptrack frames of a domain.
> 
> Signed-off-by: Juergen Gross 
> Acked-by: Ian Jackson 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v9 04/10] libxl: add max possible mfn to libxl_physinfo

[Wei Liu]

On Fri, Sep 22, 2017 at 01:41:28PM +0200, Juergen Gross wrote:
> Add the maximum possible mfn of the host to the libxl_physinfo
> data structure.
> 
> Signed-off-by: Juergen Gross 
> Acked-by: Ian Jackson 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v5 13/23] x86/mm: factor out pv_arch_init_memory

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> Move the split l4 setup code into the new function. It can then be
> moved to pv/ in a later patch.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v5 12/23] x86/mm: move and rename map_ldt_shadow_page

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> Add pv prefix to it. Move it to pv/mm.c. Fix call sites.
> 
> Take the chance to change v to curr and d to currd.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 



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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  829324d18c089636ce492613f7e99c8f78096d9b
baseline version:
 xen  73b9640a3c4a6ea093c7fee231df717f66e3

Last test of basis   113669  2017-09-21 14:02:26 Z0 days
Testing same since   113721  2017-09-22 11:11:38 Z0 days1 attempts


People who touched revisions under test:
  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=829324d18c089636ce492613f7e99c8f78096d9b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ 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 
829324d18c089636ce492613f7e99c8f78096d9b
+ branch=xen-unstable-smoke
+ revision=829324d18c089636ce492613f7e99c8f78096d9b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.:.
 PERLLIB=.:.:.
+++ 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
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ 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.9-testing
+ '[' x829324d18c089636ce492613f7e99c8f78096d9b = 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
++ : 

Re: [Xen-devel] [PATCH v5 10/23] x86/mm: split out descriptor table manipulation code

[Wei Liu]

On Fri, Sep 22, 2017 at 07:07:29AM -0600, Jan Beulich wrote:
> >>> On 14.09.17 at 14:58,  wrote:
> > Move the code to pv/descriptor-tables.c. Change u64 to uint64_t while
> > moving. Use currd in do_update_descriptor.
> 
> Hmm, so the "later" in patch 9 isn't in a future series, but here.
> Why couldn't the move and rename then be done in one step?

Because I thought it would be easier to review if I could keep the
patches as self-contained as possible, i.e. only do one or two closely
related things if I could.

Overall I think this is a better strategy to reduce cognitive burden for
the reviewers.

Anyway, thanks for your review.

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

Re: [Xen-devel] [PATCH v5 11/23] x86/mm: move compat descriptor table manipulation code

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> --- a/xen/arch/x86/pv/descriptor-tables.c
> +++ b/xen/arch/x86/pv/descriptor-tables.c
> @@ -181,6 +181,46 @@ long do_update_descriptor(uint64_t pa, uint64_t desc)
>  return ret;
>  }
>  
> +int compat_set_gdt(XEN_GUEST_HANDLE_PARAM(uint) frame_list, unsigned int 
> entries)
> +{
> +unsigned int i, nr_pages = (entries + 511) / 512;
> +unsigned long frames[16];
> +long ret;

Considering the function returns int, how about changing this to int
as you go? Either way

Acked-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v5 10/23] x86/mm: split out descriptor table manipulation code

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> Move the code to pv/descriptor-tables.c. Change u64 to uint64_t while
> moving. Use currd in do_update_descriptor.

Hmm, so the "later" in patch 9 isn't in a future series, but here.
Why couldn't the move and rename then be done in one step?
Anyway ...

> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v5 09/23] x86/mm: add pv prefix to {set, destroy}_gdt

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> --- a/xen/include/asm-x86/pv/mm.h
> +++ b/xen/include/asm-x86/pv/mm.h
> @@ -25,14 +25,24 @@
>  
>  int pv_ro_page_fault(unsigned long addr, struct cpu_user_regs *regs);
>  
> +long pv_set_gdt(struct vcpu *d, unsigned long *frames, unsigned int entries);
> +void pv_destroy_gdt(struct vcpu *d);
> +
>  #else
>  
> +#include 
> +
>  static inline int pv_ro_page_fault(unsigned long addr,
> struct cpu_user_regs *regs)
>  {
>  return 0;
>  }
>  
> +static inline long pv_set_gdt(struct vcpu *d, unsigned long *frames,
> +  unsigned int entries)
> +{ return -EINVAL; }
> +static inline void pv_destroy_gdt(struct vcpu *d) {}

Please everywhere here switch the parameter names from d to v.
With that and again maybe ASSERT_UNREACHABLE() added to the
stubs
Acked-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v1] libxl: remove list callback from device framework

[Wei Liu]

On Fri, Sep 22, 2017 at 03:28:55PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> As we have generic functions to get device list
> (libxl__device_list) no need to have callback in
> the framework. To resolve issue when XS entry
> doesn't match device name, device type is
> extended with field "entry" which keeps XS entry.
> 
> Signed-off-by: Oleksandr Grytsov 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v5 08/23] x86/mm: split out pv grant table code

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> Move the code to pv/grant_table.c. Nothing needs to be done with
> regard to headers.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v5 07/23] x86/mm: move map_guest_l1e to pv/mm.c

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> And export the function via pv/mm.h.
> 
> Signed-off-by: Wei Liu 

I'm not overly happy with the function becoming non-static, but I
can see that it'll be better to move grant table stuff and update-va-
mapping into different files, so
Acked-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v5 06/23] x86/mm: remove the now unused inclusion of pv/emulate.h

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v5 05/23] x86/mm: move ro page fault emulation code

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> --- /dev/null
> +++ b/xen/include/asm-x86/pv/mm.h
> @@ -0,0 +1,38 @@
> +/*
> + * asm-x86/pv/mm.h
> + *
> + * Memory management interfaces for PV guests
> + *
> + * Copyright (C) 2017 Wei Liu 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms and conditions of the GNU General Public
> + * License, version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see 
> .
> + */
> +
> +#ifndef __X86_PV_MM_H__
> +#define __X86_PV_MM_H__
> +
> +#ifdef CONFIG_PV
> +
> +int pv_ro_page_fault(unsigned long addr, struct cpu_user_regs *regs);
> +
> +#else
> +
> +static inline int pv_ro_page_fault(unsigned long addr,
> +   struct cpu_user_regs *regs)
> +{

ASSERT_UNREACHABLE()? In any event
Acked-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v5 04/23] x86/mm: move {un, }adjust_guest_l*e to pv/mm.h

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v5 03/23] x86/mm: move update_intpte to pv/mm.h

[Jan Beulich]

>>> On 14.09.17 at 14:58,  wrote:
> --- a/xen/arch/x86/pv/mm.h
> +++ b/xen/arch/x86/pv/mm.h
> @@ -18,4 +18,69 @@ static inline l1_pgentry_t guest_get_eff_l1e(unsigned long 
> linear)
>  return l1e;
>  }
>  
> +/*
> + * PTE updates can be done with ordinary writes except:
> + *  1. Debug builds get extra checking by using CMPXCHG[8B].
> + */
> +#if !defined(NDEBUG)

#ifdef

> +#define PTE_UPDATE_WITH_CMPXCHG

#else
#undef

now that it sits in a header, to be on the safe side.

With that

Acked-by: Jan Beulich 

Jan


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

[Xen-devel] [PATCH v1] libxl: provide typedefs for device framework functions

[Oleksandr Grytsov]

From: Oleksandr Grytsov 

Resend

Oleksandr Grytsov (1):
  libxl: remove list callback from device framework

 tools/libxl/libxl_checkpoint_device.c |  4 ++--
 tools/libxl/libxl_colo_save.c |  2 +-
 tools/libxl/libxl_device.c|  4 ++--
 tools/libxl/libxl_disk.c  | 24 
 tools/libxl/libxl_domain.c|  4 ++--
 tools/libxl/libxl_internal.h  | 30 --
 tools/libxl/libxl_nic.c   |  6 +++---
 tools/libxl/libxl_pci.c   |  2 +-
 tools/libxl/libxl_vdispl.c| 23 ++-
 tools/libxl/libxl_vtpm.c  | 23 +++
 10 files changed, 44 insertions(+), 78 deletions(-)

-- 
2.7.4


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