[Xen-devel] [linux-3.18 test] 101447: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
101000
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 101000
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101000
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-freebsd10-i386  6 xen-boot   fail REGR. vs. 101000

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl   3 host-install(3)  broken pass in 101434
 test-amd64-amd64-xl-multivcpu 14 guest-saverestore fail in 101389 pass in 
101447
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 101398 pass in 
101447
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
101413 pass in 101447
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
101413 pass in 101447
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101389
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101398
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101398
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-bootfail pass in 101398
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 101413
 test-amd64-i386-libvirt   6 xen-boot   fail pass in 101413
 test-amd64-i386-libvirt-xsm   6 xen-boot   fail pass in 101434
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat  fail pass in 101434

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101000
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101000
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101000

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-xsm   9 debian-install   fail in 101430 pass in 101443
 test-armhf-armhf-xl-credit2   6 xen-boot   fail pass in 101430
 test-armhf-armhf-xl-rtds 14 guest-stop fail pass in 101430

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101365
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101365
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101365

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

version targeted for testing:
 qemuu6aa5a3679449cdf0b6fe5a6829b22e642ded57fd
baseline version:
 qemuu627eae7d729277c84f8e0ac07a8caab39c92c38d

Last test of basis   101365  2016-10-11 02:21:11 Z3 days
Failing since101395  2016-10-12 10:15:00 Z2 days5 attempts
Testing same since   101430  2016-10-14 00:16:31 Z0 days2 attempts


People who touched revisions under test:
  Cornelia Huck 
  Daniel P. Berrange 
  David Gibson 
  Eric Blake 
  Gerd Hoffmann 
  Hans de Goede 
  Lluís Vilanova 
  Marc-André Lureau 
  P J P 
  Peter Maydell 
  Stefan Hajnoczi 
  Thomas Huth 
  Vijay Kumar B 
  Vijay Kumar B. 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 101429 pass 
in 101440
 test-armhf-armhf-libvirt-raw 9 debian-di-install fail in 101429 pass in 101440
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail pass in 
101429

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

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

version targeted for testing:
 xen  b5283627de6b7ba2b8d75ecf1edf0a46bcd83edb
baseline version:
 xen  71b8b46111219a2f83f4f9ae06ac5409744ea86e

Last test of basis   101396  2016-10-12 11:16:02 Z2 days
Failing since101415  2016-10-13 06:04:49 Z1 days3 attempts
Testing same since   101429  2016-10-13 23:16:18 Z0 days2 attempts


People who touched revisions under test:
  Alistair Francis 
  Edgar E. Iglesias 
  Ian Jackson 
  Jan Beulich 
  Lan Tianyu 
  Wei Liu 

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

Re: [Xen-devel] Debugging your environment...

[Jesus M. Gonzalez-Barahona]

Thanks, Tevin.

My experience with Windows is very limited, but it seems what happens
is that the system founds the perceval script, but is not able of
running it because it does not identify the shebang line (the first
line in the script). I'm not completely sure about this, but it seems
that's the problem.

Yoou can check that by cd to the Scripts directory where perceval
lives, and executing:

python perceval --help

If that works, it is very likely that the problem is that one.

Please, try, and if that's the case, we can try to find some fix...

Jesus.

On Fri, 2016-10-14 at 14:15 -0400, tevin.k.mall...@gmail.com wrote:
> Hi Jesus,
>     Since our last chat here is what I have done. I have
> created a new virtualenv with "--no-site-packages" to insure a fresh
> clean environment. After I followed your instructions and pulled up
> my "dir" data. I notice I didn't have a "bin" directory and
> researched why. It turns out a "bin" directory is created on POSIZ
> systems only. Also some paths within the virtualenv are different on
> Windows: scripts and executables on Windows go in "ENV\Scripts\"
> instead of "ENV/bin". I don't know if this will have a problem with
> perceval command scripts.
>     I install perceval into my virtualenv and tried to
> run Perceval again. It still isn’t working for me, so I am going to
> try changing my OS to Unbuntu and try again there. I inserted my
> command prompt below.  
>  
>  
> Microsoft Windows [Version 10.0.14393]
> (c) 2016 Microsoft Corporation. All rights reserved.
>  
> C:\Users\Tevin>cd Desktop
>  
> C:\Users\Tevin\Desktop>md perceval
>  
> C:\Users\Tevin\Desktop>md project
>  
> C:\Users\Tevin\Desktop>cd project
>  
> C:\Users\Tevin\Desktop\project>virtualenv --no-site-packages perceval
> Using base prefix
> 'c:\\users\\tevin\\appdata\\local\\programs\\python\\python35-32'
> New python executable in
> C:\Users\Tevin\Desktop\project\perceval\Scripts\python.exe
> Installing setuptools, pip, wheel...done.
>  
> C:\Users\Tevin\Desktop\project>cd perceval
>  
> C:\Users\Tevin\Desktop\project\perceval>dir
> Volume in drive C is OS
> Volume Serial Number is 2606-BFCB
>  
> Directory of C:\Users\Tevin\Desktop\project\perceval
>  
> 10/14/2016  01:25 PM      .
> 10/14/2016  01:25 PM      ..
> 10/07/2016  12:24 AM      Include
> 10/14/2016  01:24 PM      Lib
> 10/14/2016  01:25 PM    60 pip-selfcheck.json
> 10/14/2016  01:25 PM      Scripts
> 10/14/2016  01:24 PM      tcl
>    1 File(s) 60 bytes
>    6 Dir(s)  416,644,304,896 bytes free
>  
> C:\Users\Tevin\Desktop\project\perceval>scripts\activate
>  
> (perceval) C:\Users\Tevin\Desktop\project\perceval>pip install
> perceval
> Collecting perceval
>   Using cached perceval-0.3.0-py3-none-any.whl
> Collecting python-dateutil>=2.0.0 (from perceval)
>   Using cached python_dateutil-2.5.3-py2.py3-none-any.whl
> Collecting requests>=2.7.0 (from perceval)
>   Using cached requests-2.11.1-py2.py3-none-any.whl
> Collecting beautifulsoup4>=4.3.2 (from perceval)
>   Using cached beautifulsoup4-4.5.1-py3-none-any.whl
> Collecting six>=1.5 (from python-dateutil>=2.0.0->perceval)
>   Using cached six-1.10.0-py2.py3-none-any.whl
> Installing collected packages: six, python-dateutil, requests,
> beautifulsoup4, perceval
> Successfully installed beautifulsoup4-4.5.1 perceval-0.3.0 python-
> dateutil-2.5.3 requests-2.11.1 six-1.10.0
>  
> (perceval) C:\Users\Tevin\Desktop\project\perceval>dir
> Volume in drive C is OS
> Volume Serial Number is 2606-BFCB
>  
> Directory of C:\Users\Tevin\Desktop\project\perceval
>  
> 10/14/2016  01:25 PM      .
> 10/14/2016  01:25 PM      ..
> 10/07/2016  12:24 AM      Include
> 10/14/2016  01:24 PM      Lib
> 10/14/2016  01:25 PM    60 pip-selfcheck.json
> 10/14/2016  01:31 PM      Scripts
> 10/14/2016  01:24 PM      tcl
>    1 File(s) 60 bytes
>    6 Dir(s)  416,637,894,656 bytes free
>  
> (perceval) C:\Users\Tevin\Desktop\project\perceval>echo %PATH%
> C:\Users\Tevin\Desktop\project\perceval\Scripts;C:\ProgramData\Oracle
> \Java\javapath;C:\Program Files (x86)\Intel\TXE
> Components\TCS\;C:\Program Files\Intel\TXE
> Components\TCS\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wb
> em;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files
> (x86)\Common Files\Adobe\AGL;C:\Program Files
> (x86)\DevDesktop\drush;C:\Program Files\Java\jdk\bin;C:\Program
> Files\Java\jre\bin;C:\Users\Tevin\AppData\Local\Programs\Python\Pytho
> n35-
> 32\Scripts\;C:\Users\Tevin\AppData\Local\Programs\Python\Python35-
> 32\;C:\Users\Tevin\AppData\Local\Microsoft\WindowsApps;C:\Windows\Sys
> tem32;C:\Users\Tevin\Documents\project\mtask\Lib\site-packages
>  
> (perceval) C:\Users\Tevin\Desktop\project\perceval>echo %PYTHONPATH
> %PYTHONPATH
>  
> (perceval) 

[Xen-devel] [xtf test] 101455: all pass - PUSHED

[osstest service owner]

flight 101455 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101455/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  c184f0dddc9d8136b9bf0f81909cac3682b3c16f
baseline version:
 xtf  67a53d29ac26348ae56cbee924b411127ad7cc7b

Last test of basis   101374  2016-10-11 12:45:53 Z3 days
Testing same since   101455  2016-10-14 14:43:06 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   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=xtf
+ revision=c184f0dddc9d8136b9bf0f81909cac3682b3c16f
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xtf 
c184f0dddc9d8136b9bf0f81909cac3682b3c16f
+ branch=xtf
+ revision=c184f0dddc9d8136b9bf0f81909cac3682b3c16f
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xc184f0dddc9d8136b9bf0f81909cac3682b3c16f = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' 

Re: [Xen-devel] [PATCH v3 3/4] Significant changes to decision making; some new roles and minor changes

[Konrad Rzeszutek Wilk]

>  Project Team Roles {#roles-local}
>  --
>  
> +Sub-projects or teams are driven by the people who volunteer for the job. 
> This 
> +functions well for most cases. This section lists the main roles which 
> projects 
> +use. This section lists the default roles, which are based on how the 
> +Hypervisor project operates. Sub-projects can deviate from the default, but 
> are 

You have twice 'This section lists' which I don't think is what you meant?

> +required to document deviations from the default and link to it from this 
> +[document](#specialisations). The only exception is that each project is 
> +required to have a project leadership team, as without it, the project will 
> not 
> +be able to function.
> +
> +The following table lists how each project uses these roles. Note that 
> +**incubation projects** have more flexibility in experimenting with roles 
> that 
> +work for them, but need to define specializations before they can **mature**.
> +
> +  -  -  
> --- 
> +  **Project**   **Mature**   **Maintainers**   **Committers**   
> **Security Team**   **Leadership Team**
> +  **Hypervisor**YES  YES   YES  YES  
>Committers and Release Manager, without a Project Lead
> +  **Windows Drivers**   NO   YES   YES  NO   
>Committers, with a Project Lead
> +  **XAPI**  YES  YES   YES  NO   
>Committers, with a Project Lead
> +  -  -  
> --- 
> +

The rest looks OK to me.

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

Re: [Xen-devel] [PATCH v3 2/4] Added document containing governance related todo list

[Konrad Rzeszutek Wilk]

On Fri, Sep 23, 2016 at 07:55:27PM +0100, Lars Kurth wrote:
> Contains items that at some point need to be addressed.
> The items do not directly affect governance.pandoc
> 
> Signed-off-by: Lars Kurth 

Reviewed-by: Konrad Rzeszutek Wilk 

> ---
>  governance.todo | 23 +++
>  1 file changed, 23 insertions(+)
>  create mode 100644 governance.todo
> 
> diff --git a/governance.todo b/governance.todo
> new file mode 100644
> index 000..81e068c
> --- /dev/null
> +++ b/governance.todo
> @@ -0,0 +1,23 @@
> +This document contains some governance related TODO items that at some point 
> +need to be addressed. The items do not directly affect governance.pandoc
> +
> +### Maintainers
> +
> +CONSISTENCY ISSUES that probably ought to be cleaned up at some point
> +- The xen.git MAINTAINERS file does not list our release managers and 
> +  stable branch maintainers
> +- We do have a number of repos without MAINTAINERS files, e.g. mini-os.git, 
> +  osstest.git
> +- For projects with many repositories (e.g. XAPI and Mirage OS), using 
> MAINTAINERS 
> +  files is not very practical. XAPI seems to sometimes use MAINTAINERS and 
> README 
> +  files at other times. We may need a more central place to state roles.
> +
> +### Project Leadership Team and Project Lead
> +
> +CONSISTENCY ISSUES that probably ought to be cleaned up at some point
> +- XAPI and Mirage OS ought to decide who their leadership team is 
> +  (I made some assumptions for now)
> +
> +### Per Sub-Project Governance Specialisation 
> +
> +- XAPI, WinPV and MirageOS need to provide this information, if they deviate
> \ No newline at end of file
> -- 
> 2.5.4 (Apple Git-61)
> 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  20295ab63ce7f57edca9c450602ac2dace1fc721
baseline version:
 xen  a709a3a646302e95ba42beac89264f6cdacd0c64

Last test of basis   101448  2016-10-14 14:02:45 Z0 days
Testing same since   101458  2016-10-14 18:01:32 Z0 days1 attempts


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

Re: [Xen-devel] [PATCH v3 1/4] Code motion changes to make real patches easier to read

[Konrad Rzeszutek Wilk]

On Fri, Sep 23, 2016 at 07:55:26PM +0100, Lars Kurth wrote:
> Added TOC
> Re-arranged sections compared to previous version of document
> Added new anchors where needed
> Split Roles section into two sections
> 
> The actual content was not changed (with the exception of minor
> typos that I spotted)
> 
> Signed-off-by: Lars Kurth 

Reviewed-by: Konrad Rzeszutek Wilk 

> ---
>  governance.pandoc | 207 
> +-
>  1 file changed, 113 insertions(+), 94 deletions(-)
> 
> diff --git a/governance.pandoc b/governance.pandoc
> index 60fc942..2ce780c 100644
> --- a/governance.pandoc
> +++ b/governance.pandoc
> @@ -1,9 +1,20 @@
> -
> -This document has come in effect in June 2011 and will be 
> -reviewed periodically (see revision sections). The last modification has 
> been 
> -made in May 2013.
> -
> -Goals
> +This document has come in effect in June 2011 and will be reviewed 
> periodically 
> +(see revision sections). The last modification has been made in July 2016.
> +
> +Content
> +---
> +
> +-   [Goals](#goals)
> +-   [Principles](#principles)
> +-   [Xen Project Wide Roles](#roles-global)
> +-   [Project Team Roles](#roles-local)
> +-   [Making Contributions](#contributions)
> +-   [Decision Making, Conflict Resolution, Role Nominations and 
> +Elections](#decisions)
> +-   [Formal Votes](#formal-votes)
> +-   [Project Governance](#project-governance)
> +
> +Goals {#goals}
>  -
>  
>  The goals of Xen Project Governance are to:
> @@ -22,7 +33,7 @@ going elsewhere
>  -   Set clear expectations to vendors, upstream and downstream projects and 
>  community members
>  
> -Principles
> +Principles {#principles}
>  --
>  
>  ### Openness
> @@ -43,71 +54,8 @@ The Xen Project is a meritocracy. The more you contribute 
> the more
>  responsibility you will earn. Leadership roles in Xen are also merit-based 
> and 
>  earned by peer acclaim.
>  
> -### Consensus Decision Making
> -
> -Sub-projects or teams hosted on Xenproject.org are normally auto-governing 
> and 
> -driven by the people who volunteer for the job. This functions well for most 
> -cases. When more formal decision making and coordination is required, 
> decisions 
> -are taken with a lazy consensus approach: a few positive votes with no 
> negative 
> -vote are enough to get going.
> -
> -Voting is done with numbers:
> -
> --   +1 : a positive vote
> --   0 : abstain, have no opinion
> --   -1 : a negative vote
> -
> -A negative vote should include an alternative proposal or a detailed 
> -explanation of the reasons for the negative vote. The project community then 
> -tries to gather consensus on an alternative proposal that resolves the 
> issue. 
> -In the great majority of cases, the concerns leading to the negative vote 
> can 
> -be addressed.
> -
> -### Conflict Resolution
> -
> - Refereeing
> -
> -Sub-projects and teams hosted on Xenproject.org are not democracies but 
> -meritocracies. In situations where there is disagreement on issues related 
> to 
> -the day-to-day running of the project, Committers and Project Leads are 
> -expected to act as referees and make a decision on behalf of the community. 
> -Referees should however consider whether making a decision may be divisive 
> and 
> -damaging for the community. In such cases, the committer community of the 
> -project can privately vote on an issue, giving the decision more weight.
> -
> - Last Resort
> -
> -In some rare cases, the lazy consensus approach may lead to the community 
> being 
> -paralyzed. Thus, as a last resort when consensus cannot be achieved on a 
> -question internal to a project, the final decision will be made by a private 
> -majority vote amongst the committers and project lead. If the vote is tied, 
> the 
> -project lead gets an extra vote to break the tie.
> -
> -For questions that affect several projects, committers and project leads of 
> -mature projects will hold a private majority vote. If the vote is tied, the 
> -[Xen Project Advisory Board](/join.html) will break the tie through a 
> casting 
> -vote.
> -
> -Roles
> --
> -
> -### Maintainers
> -
> -Maintainers own one or several components in the Xen tree. A maintainer 
> reviews 
> -and approves changes that affect their components. It is a maintainer's 
> prime 
> -responsibility to review, comment on, co-ordinate and accept patches from 
> other 
> -community member's and to maintain the design cohesion of their components. 
> -Maintainers are listed in a MAINTAINERS file in the root of the source tree.
> -
> -### Committers
> -
> -Committers are Maintainers that are allowed to commit changes into the 
> source 
> -code repository. The committer acts on the wishes of the maintainers and 
> -applies changes that have been approved by the respective maintainer(s) to 
> the 
> -source tree. Due to their status in the community, committers can also act 
> as 
> -referees 

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

[Stefano Stabellini]

On Fri, 14 Oct 2016, Jan Beulich wrote:
> >>> On 14.10.16 at 11:59,  wrote:
> > On 14/10/16 07:36, Jan Beulich wrote:
> > On 14.10.16 at 02:58,  wrote:
> >>> On Fri, 14 Oct 2016, Andrew Cooper wrote:
>  There should be a high barrier to "Supported" status, because the cost
>  of getting it wrong is equally high.  However, there are perfectly
>  legitimate intermediate stages such as "Supported in these limited set
>  of circumstances".  A number of features are not plausibly for use in
>  production environments, but otherwise function fine for
>  development/investigatory purposes.  In these cases, something like "no
>  security support, but believed to be working fine" might be appropriate.
> >>>
> >>> I agree on this. I think we need an intermediate step: "working but not
> >>> supported for security" is completely reasonable. When we say that it is
> >>> "working", it should be because we have automated testing for it (I
> >>> don't know if I would go as far as requiring it to be in OSSTest, any
> >>> automated testing, even third party, would do). If it is not
> >>> automatically tested, then it is just "best effort".
> >> 
> >> I don't think this is a reasonable expectation - how would you envision
> >> testing the dozens of command line options alone, not to speak of
> >> things depending on hardware characteristics?
> > 
> > Well there may be situations where we can make reasonable exceptions.
> > But it would certainly be a lot better if a feature wasn't considered
> > "done" until there was something in place to make sure that it worked
> > and continued to work, other than "we hope people use it and report any
> > bugs they find".
> 
> Perhaps an earlier question here is what a "feature" is. My command
> line option example was specifically chosen to make it possibly very
> small scope, yet indicate an area where we would likely say "using
> this and that option is not supported" (depending on the instance
> with either of the two meanings you name below).

This is another one of those cases where we need to apply our judgement
on a case by case basis.


> > The more interesting aspect of Stefano's suggestion here is whether
> > there should be two levels of "supported" -- "supported" as in, "this
> > works but it's not in our security boundary", and "supported" as in,
> > "this works and it *is* in our security boundary".
> 
> To me the question is how far that would matter for people
> wanting to use Xen in production: I for one wouldn't feel well
> using features which aren't security supported.

Sure, but Xen isn't only used in high availability production systems.
For example one use case for Xen on ARM is IoT, a space where most
devices don't even have a way to be securely updated yet. (I hope that
people using Xen on ARM in those scenarios do have a way to patch theirs
devices.)

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

Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

[Boris Ostrovsky]

On 10/14/2016 03:51 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 14, 2016 at 03:43:19PM -0400, Boris Ostrovsky wrote:
>> On 10/14/2016 03:19 PM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Oct 14, 2016 at 02:05:16PM -0400, Boris Ostrovsky wrote:
>>>
>>> Perhaps add in here:
>>>
>>> PVH is like PV in that there are no PCI devices - which HVM
>>> code would piggyback on to find the Xen PCI platform device and
>>> use its MMIO space to stash the grants in.
>>>
>>> For PVH we balloon out memory and stash the grants in there.
>>>
>>> (Which begs the next question - where and when do we balloon out the
>>> normal memory back in?)
>> Are you saying that we should get back memory that we gave to grant tables?
> Yes.
>
> In pure HVM that area is MMIO - which hvmloader has balloonned out.
>
> The hvmloader then balloons that number of pages back  at the end of
> guest memory (after 4GB).

We don't do this for PV though, do we?

-boris

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

Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

[Konrad Rzeszutek Wilk]

On Fri, Oct 14, 2016 at 03:43:19PM -0400, Boris Ostrovsky wrote:
> On 10/14/2016 03:19 PM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 14, 2016 at 02:05:16PM -0400, Boris Ostrovsky wrote:
> >
> > Perhaps add in here:
> >
> > PVH is like PV in that there are no PCI devices - which HVM
> > code would piggyback on to find the Xen PCI platform device and
> > use its MMIO space to stash the grants in.
> >
> > For PVH we balloon out memory and stash the grants in there.
> >
> > (Which begs the next question - where and when do we balloon out the
> > normal memory back in?)
> 
> Are you saying that we should get back memory that we gave to grant tables?

Yes.

In pure HVM that area is MMIO - which hvmloader has balloonned out.

The hvmloader then balloons that number of pages back  at the end of
guest memory (after 4GB).

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

[Xen-devel] [PATCH v3 1/2] x86/Intel: Expose cpuid_faulting_enabled so it can be used elsewhere

[Kyle Huey]

While we're here, use bool instead of bool_t.

Signed-off-by: Kyle Huey 
---
 xen/arch/x86/cpu/intel.c| 9 +
 xen/include/asm-x86/cpuid.h | 3 +++
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index 7b60aaa..2e11662 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -13,34 +13,35 @@
 #include 
 #include 
 #include 
 
 #include "cpu.h"
 
 #define select_idle_routine(x) ((void)0)
 
-static bool_t __init probe_intel_cpuid_faulting(void)
+static bool __init probe_intel_cpuid_faulting(void)
 {
uint64_t x;
 
if (rdmsr_safe(MSR_INTEL_PLATFORM_INFO, x) ||
!(x & MSR_PLATFORM_INFO_CPUID_FAULTING))
return 0;
 
expected_levelling_cap |= LCAP_faulting;
levelling_caps |=  LCAP_faulting;
__set_bit(X86_FEATURE_CPUID_FAULTING, boot_cpu_data.x86_capability);
return 1;
 }
 
-static void set_cpuid_faulting(bool_t enable)
+DEFINE_PER_CPU(bool, cpuid_faulting_enabled);
+
+static void set_cpuid_faulting(bool enable)
 {
-   static DEFINE_PER_CPU(bool_t, cpuid_faulting_enabled);
-   bool_t *this_enabled = _cpu(cpuid_faulting_enabled);
+   bool *this_enabled = _cpu(cpuid_faulting_enabled);
uint32_t hi, lo;
 
ASSERT(cpu_has_cpuid_faulting);
 
if (*this_enabled == enable)
return;
 
rdmsr(MSR_INTEL_MISC_FEATURES_ENABLES, lo, hi);
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 8e3f639..2372474 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -59,16 +59,19 @@ struct cpuidmasks
 };
 
 /* Per CPU shadows of masking MSR values, for lazy context switching. */
 DECLARE_PER_CPU(struct cpuidmasks, cpuidmasks);
 
 /* Default masking MSR values, calculated at boot. */
 extern struct cpuidmasks cpuidmask_defaults;
 
+/* Whether or not cpuid faulting is available for the current domain. */
+DECLARE_PER_CPU(bool, cpuid_faulting_enabled);
+
 #endif /* __ASSEMBLY__ */
 #endif /* !__X86_CPUID_H__ */
 
 /*
  * Local variables:
  * mode: C
  * c-file-style: "BSD"
  * c-basic-offset: 4

base-commit: 71b8b46111219a2f83f4f9ae06ac5409744ea86e
-- 
2.10.1


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

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

[Kyle Huey]

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

Changes since v2:
Patch 1:
- s/bool_t/bool
- Added missing Signed-off-by.

Patch 2:
- Style nits.
- Made comments in traps.c more descriptive.
- Don't advance IP past the CPUID when faulting from vmx_do_cpuid.
- Do advance IP past the undefined prefix in emulate_forced_invalid_op.
- Deliver a #GP when faulting in emulate_forced_invalid_op (instead of #UD).
- Rearrange cpuid_fault within arch_vcpu.


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

Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

[Boris Ostrovsky]

On 10/14/2016 03:19 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 14, 2016 at 02:05:16PM -0400, Boris Ostrovsky wrote:
>
> Perhaps add in here:
>
> PVH is like PV in that there are no PCI devices - which HVM
> code would piggyback on to find the Xen PCI platform device and
> use its MMIO space to stash the grants in.
>
> For PVH we balloon out memory and stash the grants in there.
>
> (Which begs the next question - where and when do we balloon out the
> normal memory back in?)

Are you saying that we should get back memory that we gave to grant tables?

-boris


>
>> Signed-off-by: Boris Ostrovsky 
>> ---
>>  drivers/xen/grant-table.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
>> index bb36b1e..d6786b8 100644
>> --- a/drivers/xen/grant-table.c
>> +++ b/drivers/xen/grant-table.c
>> @@ -1146,13 +1146,13 @@ int gnttab_init(void)
>>  
>>  static int __gnttab_init(void)
>>  {
>> +if (!xen_domain())
>> +return -ENODEV;
>> +
>>  /* Delay grant-table initialization in the PV on HVM case */
>> -if (xen_hvm_domain())
>> +if (xen_hvm_domain() && !xen_pvh_domain())
>>  return 0;
>>  
>> -if (!xen_pv_domain())
>> -return -ENODEV;
>> -
>>  return gnttab_init();
>>  }
>>  /* Starts after core_initcall so that xen_pvh_gnttab_setup can be called
>> -- 
>> 1.8.3.1
>>
>>
>> ___
>> 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 v3 2/2] x86/Intel: virtualize support for cpuid faulting

[Kyle Huey]

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

On PV guests, hardware support is required so that userspace cpuid will trap
to xen. Xen already enables cpuid faulting on supported CPUs for pv guests (that
aren't the control domain, see the comment in intel_ctxt_switch_levelling).
Every PV guest cpuid will trap via a GP(0) to emulate_privileged_op (via
do_general_protection). Once there we simply decline to emulate cpuid if the
CPL > 0 and faulting is enabled, leaving the GP(0) for the guest kernel to
handle.

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

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b9102ce..c038393 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2427,16 +2427,25 @@ static void vmx_cpuid_intercept(
 
 HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
 }
 
 static int vmx_do_cpuid(struct cpu_user_regs *regs)
 {
 unsigned int eax, ebx, ecx, edx;
 unsigned int leaf, subleaf;
+struct segment_register sreg;
+struct vcpu *v = current;
+
+hvm_get_segment_register(v, x86_seg_ss, );
+if ( v->arch.cpuid_fault && sreg.attr.fields.dpl > 0 )
+{
+hvm_inject_hw_exception(TRAP_gp_fault, 0);
+return 1; /* Don't advance the guest IP! */
+}
 
 eax = regs->eax;
 ebx = regs->ebx;
 ecx = regs->ecx;
 edx = regs->edx;
 
 leaf = regs->eax;
 subleaf = regs->ecx;
@@ -2694,19 +2703,23 @@ static int vmx_msr_read_intercept(unsigned int msr, 
uint64_t *msr_content)
 case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
 case MSR_IA32_PEBS_ENABLE:
 case MSR_IA32_DS_AREA:
 if ( vpmu_do_rdmsr(msr, msr_content) )
 goto gp_fault;
 break;
 
 case MSR_INTEL_PLATFORM_INFO:
-if ( rdmsr_safe(MSR_INTEL_PLATFORM_INFO, *msr_content) )
-goto gp_fault;
+*msr_content = MSR_PLATFORM_INFO_CPUID_FAULTING;
+break;
+
+case MSR_INTEL_MISC_FEATURES_ENABLES:
 *msr_content = 0;
+if ( current->arch.cpuid_fault )
+*msr_content |= MSR_MISC_FEATURES_CPUID_FAULTING;
 break;
 
 default:
 if ( passive_domain_do_rdmsr(msr, msr_content) )
 goto done;
 switch ( long_mode_do_msr_read(msr, msr_content) )
 {
 case HNDL_unhandled:
@@ -2925,16 +2938,23 @@ static int vmx_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
 break;
 
 case MSR_INTEL_PLATFORM_INFO:
 if ( msr_content ||
  rdmsr_safe(MSR_INTEL_PLATFORM_INFO, msr_content) )
 goto gp_fault;
 break;
 
+case MSR_INTEL_MISC_FEATURES_ENABLES:
+if ( msr_content & ~MSR_MISC_FEATURES_CPUID_FAULTING )
+goto gp_fault;
+v->arch.cpuid_fault =
+!!(msr_content & MSR_MISC_FEATURES_CPUID_FAULTING);
+break;
+
 default:
 if ( passive_domain_do_wrmsr(msr, msr_content) )
 return X86EMUL_OKAY;
 
 if ( wrmsr_viridian_regs(msr, msr_content) ) 
 break;
 
 switch ( long_mode_do_msr_write(msr, msr_content) )
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 293ff8d..12322bd 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1315,16 +1315,24 @@ static int emulate_forced_invalid_op(struct 
cpu_user_regs *regs)
 /* We only emulate CPUID. */
 if ( ( rc = copy_from_user(instr, (char *)eip, sizeof(instr))) != 0 )
 {
 propagate_page_fault(eip + sizeof(instr) - rc, 0);
 return EXCRET_fault_fixed;
 }
 if ( memcmp(instr, "\xf\xa2", sizeof(instr)) )
 return 0;
+
+/* If cpuid faulting is enabled and CPL>0 inject a #GP in place of #UD. */
+if ( current->arch.cpuid_fault && !guest_kernel_mode(current, regs) ) {
+regs->eip = eip;
+do_guest_trap(TRAP_gp_fault, regs);
+return EXCRET_fault_fixed;
+}
+
 eip += sizeof(instr);
 
 pv_cpuid(regs);
 
 instruction_done(regs, eip, 0);
 
 trace_trap_one_addr(TRC_PV_FORCED_INVALID_OP, regs->eip);
 
@@ -2474,16 +2482,27 @@ static int priv_op_read_msr(unsigned int reg, uint64_t 
*val,
 *val = 0;
 return X86EMUL_OKAY;
 
 case MSR_INTEL_PLATFORM_INFO:
 if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
  rdmsr_safe(MSR_INTEL_PLATFORM_INFO, *val) )
 break;
 *val = 0;
+if ( this_cpu(cpuid_faulting_enabled) )
+*val |= MSR_PLATFORM_INFO_CPUID_FAULTING;
+return X86EMUL_OKAY;
+
+case 

Re: [Xen-devel] [PATCH v2 2/2] x86/Intel: virtualize support for cpuid faulting

[Kyle Huey]

On Fri, Oct 14, 2016 at 10:18 AM, Andrew Cooper
 wrote:
> On a slightly separate note, as you have just been a successful
> guinea-pig for XTF, how did you find it?  It is a very new (still
> somewhat in development) system but the project is looking to try and
> improve regression testing in this way, especially for new features.  I
> welcome any feedback.

It's pretty slick.  Much better than what Linux has ;)

I do think it's a bit confusing that xtf_has_fep is false on PV guests.

It might also be nice to (at least optionally) have xtf_assert(cond,
message) so instead of

if ( cond )
xtf_failure(message);

you can write

xtf_assert(!cond, message);

A bonus of doing this is that the framework could actually count how
many checks were run.  So for the HVM tests (which don't run the FEP
bits) instead of getting "Test result: SKIP" you could say "Test
result: 9 PASS 1 SKIP" or something similar.

- Kyle

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

Re: [Xen-devel] [PATCH 5/8] xen/pvh: Prevent PVH guests from using PIC, RTC and IOAPIC

[Boris Ostrovsky]

On 10/14/2016 03:16 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 14, 2016 at 02:05:15PM -0400, Boris Ostrovsky wrote:
>> Make sure they don't use these devices since they are not emulated
>> for unprivileged PVH guest.
> Which means they would just return 0 ? Or would it get worst since
> the in/out would go to the hypervisor which would kill the guest?

For PIC and IOAPIC (and I think RTC too) we will get a warning (with a
splat) that SCI cannot be initialized. But the guest will continue
running without problems.

-boris

>> Also don't initialize hypercall page for them in init_hvm_pv_info()
>> since this has already been done.
>>
>> Signed-off-by: Boris Ostrovsky 
>> ---
>>  arch/x86/xen/enlighten.c | 24 +---
>>  1 file changed, 17 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>> index d38d568..6c1a330 100644
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -1803,10 +1803,21 @@ static void __init init_hvm_pv_info(void)
>>  minor = eax & 0x;
>>  printk(KERN_INFO "Xen version %d.%d.\n", major, minor);
>>  
>> -cpuid(base + 2, , , , );
>> +xen_domain_type = XEN_HVM_DOMAIN;
>>  
>> -pfn = __pa(hypercall_page);
>> -wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
>> +/* PVH set up hypercall page earlier in xen_prepare_pvh() */
> A period at the end?
>> +if (xen_pvh_domain()) {
>> +pv_info.name = "Xen PVH";
>> +#ifdef CONFIG_ACPI
>> +/* No PIC or IOAPIC */
> Here?
>> +acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
>> +#endif
>> +} else {
>> +pv_info.name = "Xen HVM";
>> +cpuid(base + 2, , , , );
> Could you use cpuid_ebx ?
>> +pfn = __pa(hypercall_page);
>> +wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
>> +}
>>  
>>  xen_setup_features();
>>  
>> @@ -1815,10 +1826,6 @@ static void __init init_hvm_pv_info(void)
>>  this_cpu_write(xen_vcpu_id, ebx);
>>  else
>>  this_cpu_write(xen_vcpu_id, smp_processor_id());
>> -
>> -pv_info.name = "Xen HVM";
>> -
>> -xen_domain_type = XEN_HVM_DOMAIN;
>>  }
>>  
>>  static int xen_cpu_up_prepare(unsigned int cpu)
>> @@ -1892,6 +1899,9 @@ static void __init xen_hvm_guest_init(void)
>>  
>>  init_hvm_pv_info();
>>  
>> +if (xen_pvh_domain())
>> +x86_platform.legacy.rtc = 0;
>> +
>>  xen_hvm_init_shared_info();
>>  
>>  xen_panic_handler_init();
>> -- 
>> 1.8.3.1
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel


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

Re: [Xen-devel] [PATCH 4/8] xen/pvh: Bootstrap PVH guest

[Boris Ostrovsky]

On 10/14/2016 03:14 PM, Konrad Rzeszutek Wilk wrote:
>
>> +
>> +memset(_bootparams, 0, sizeof(pvh_bootparams));
>> +
>> +memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_map);
>> +set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_map);
>> +if (HYPERVISOR_memory_op(XENMEM_memory_map, )) {
>> +xen_raw_console_write("XENMEM_memory_map failed\n");
> Should we print the error value at least?

I will have to check again but IIRC there was something about not being
able to format strings properly this early. But if we can --- sure.

>> +BUG();
>> +}
>> +
>> +pvh_bootparams.e820_map[memmap.nr_entries].addr =
>> +ISA_START_ADDRESS;
> What if nr_entries is 128? Should we double-check for that?
>

OK.



>> + */
>> +void __init xen_prepare_pvh(void)
>> +{
>> +u32 eax, ecx, edx, msr;
> msr = 0 ?

Won't cpuid() (or cpuid_ebx()) overwrite it anyway?

>> +u64 pfn;
>> +
>> +xen_pvh = 1;
>> +
>> +cpuid(xen_cpuid_base() + 2, , , , );
> cpuid_ebx ? And that way you don't have have ecx and edx?



>> +cli
>> +cld
>> +
>> +mov $_pa(gdt), %eax
>> +lgdt (%eax)
>> +
>> +movl $(__BOOT_DS),%eax
>> +movl %eax,%ds
>> +movl %eax,%es
>> +movl %eax,%ss
>> +
>> +/* Stash hvm_start_info */
>> +mov $_pa(pvh_start_info), %edi
>> +mov %ebx, %esi
> Should we derference the first byte or such to check for the magic
> string? Actually I am not even seeing the check in the C code?


Yes, good idea.


>> +.code64
>> +1:
>> +call xen_prepare_pvh
>> +
>> +/* startup_64 expects boot_params in %rsi */
> ..
>> +mov $_pa(pvh_bootparams), %rsi
>> +movq $_pa(startup_64), %rax
>> +jmp *%rax
>> +
>> +#else /* CONFIG_X86_64 */
>> +
>> +call setup_pgtable_32
>> +
>> +mov $_pa(initial_page_table), %eax
>> +movl %eax, %cr3
>> +
>> +movl %cr0, %eax
>> +orl $(X86_CR0_PG | X86_CR0_PE), %eax
>> +movl %eax, %cr0
>> +
>> +ljmp $__BOOT_CS,$1f
>> +1:
>> +call xen_prepare_pvh
>> +mov $_pa(pvh_bootparams), %esi
>> +
>> +/* startup_32 doesn't expect paging and PAE to be on */
> Should 'startup_32' be documented with this?

It is documented in Documentation/x86/boot.txt and in the startup_64 code.


-boris

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

Re: [Xen-devel] [PATCH v2 2/2] x86/Intel: virtualize support for cpuid faulting

[Kyle Huey]

> :) I am now curious as to which bit I missed.

I made these changes.

- Kyle

---
 tests/cpuid-faulting/main.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/tests/cpuid-faulting/main.c b/tests/cpuid-faulting/main.c
index 3e782a2..221567d 100644
--- a/tests/cpuid-faulting/main.c
+++ b/tests/cpuid-faulting/main.c
@@ -37,36 +37,39 @@ bool ex_record_fault_ebx(struct cpu_regs *regs,
 }
 
 unsigned int stub_rdmsr(uint32_t idx, uint64_t *val)
 {
 unsigned int fault = 0;
 uint32_t lo, hi;
 
 *val = 0;
-asm volatile("1: rdmsr; 2:"
+asm volatile("1: rdmsr;"
+ "xor %%ebx, %%ebx; 2:"
  _ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_ebx)
  : "=a" (lo), "=d" (hi), "=" (fault)
  : "c" (idx));
 
 if ( !fault )
 *val = (((uint64_t)hi) << 32) | lo;
 
 return fault;
 }
 
 unsigned int stub_wrmsr(uint32_t idx, uint64_t val)
 {
 unsigned int fault = 0;
 
-asm volatile("1: rdmsr; 2:"
+asm volatile("1: wrmsr;"
+ "xor %%ebx, %%ebx; 2:"
  _ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_ebx)
  : "=" (fault)
  : "c" (idx), "a" ((uint32_t)val),
-   "d" ((uint32_t)(val >> 32)));
+   "d" ((uint32_t)(val >> 32))
+ : "memory");
 
 return fault;
 }
 
 unsigned long stub_cpuid(void)
 {
 unsigned int fault = 0;
 

base-commit: 0342fd279b05d0c2e31c8418fcffcdc9e48eb42f
-- 
2.10.1


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

Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

[Konrad Rzeszutek Wilk]

On Fri, Oct 14, 2016 at 02:05:16PM -0400, Boris Ostrovsky wrote:

Perhaps add in here:

PVH is like PV in that there are no PCI devices - which HVM
code would piggyback on to find the Xen PCI platform device and
use its MMIO space to stash the grants in.

For PVH we balloon out memory and stash the grants in there.

(Which begs the next question - where and when do we balloon out the
normal memory back in?)

> Signed-off-by: Boris Ostrovsky 
> ---
>  drivers/xen/grant-table.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index bb36b1e..d6786b8 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -1146,13 +1146,13 @@ int gnttab_init(void)
>  
>  static int __gnttab_init(void)
>  {
> + if (!xen_domain())
> + return -ENODEV;
> +
>   /* Delay grant-table initialization in the PV on HVM case */
> - if (xen_hvm_domain())
> + if (xen_hvm_domain() && !xen_pvh_domain())
>   return 0;
>  
> - if (!xen_pv_domain())
> - return -ENODEV;
> -
>   return gnttab_init();
>  }
>  /* Starts after core_initcall so that xen_pvh_gnttab_setup can be called
> -- 
> 1.8.3.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH 7/8] xen/pvh: PVH guests always have PV devices

[Konrad Rzeszutek Wilk]

On Fri, Oct 14, 2016 at 02:05:17PM -0400, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Konrad Rzeszutek Wilk 
> ---
>  arch/x86/xen/platform-pci-unplug.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/platform-pci-unplug.c 
> b/arch/x86/xen/platform-pci-unplug.c
> index 90d1b83..33a783c 100644
> --- a/arch/x86/xen/platform-pci-unplug.c
> +++ b/arch/x86/xen/platform-pci-unplug.c
> @@ -73,8 +73,8 @@ bool xen_has_pv_devices(void)
>   if (!xen_domain())
>   return false;
>  
> - /* PV domains always have them. */
> - if (xen_pv_domain())
> + /* PV and PVH domains always have them. */
> + if (xen_pv_domain() || xen_pvh_domain())
>   return true;
>  
>   /* And user has xen_platform_pci=0 set in guest config as
> -- 
> 1.8.3.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

[Boris Ostrovsky]

On 10/14/2016 03:04 PM, h...@zytor.com wrote:
> On October 14, 2016 11:44:18 AM PDT, Boris Ostrovsky 
>  wrote:
>> On 10/14/2016 02:31 PM, h...@zytor.com wrote:
>>> On October 14, 2016 11:05:12 AM PDT, Boris Ostrovsky
>>  wrote:
 From: Matt Fleming 

 The new Xen PVH entry point requires page tables to be setup by the
 kernel since it is entered with paging disabled.

 Pull the common code out of head_32.S and into pgtable_32.S so that
 setup_pgtable_32 can be invoked from both the new Xen entry point
>> and
 the existing startup_32 code.

>>> And why does it need a separate entry point as opposed to the plain
>> one?
>>
>> One reason is that we need to prepare boot_params before jumping to
>> startup_{32|64}.
>>
>> When the guest is loaded (always in 32-bit mode) the only thing we have
>> is a pointer to Xen-specific datastructure. The early PVH code will
>> prepare zeropage based on that structure and then jump to regular
>> startup_*() code.
>>
>> -boris
> And why not just resume execution at start_32 then?

I am not sure what start_32 is.

If you meant startup_32 then that's exactly what we do (for 32-bit
guests) once zeropage is set up.

-boris


-boris


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

Re: [Xen-devel] [PATCH 5/8] xen/pvh: Prevent PVH guests from using PIC, RTC and IOAPIC

[Konrad Rzeszutek Wilk]

On Fri, Oct 14, 2016 at 02:05:15PM -0400, Boris Ostrovsky wrote:
> Make sure they don't use these devices since they are not emulated
> for unprivileged PVH guest.

Which means they would just return 0 ? Or would it get worst since
the in/out would go to the hypervisor which would kill the guest?
> 
> Also don't initialize hypercall page for them in init_hvm_pv_info()
> since this has already been done.
> 
> Signed-off-by: Boris Ostrovsky 
> ---
>  arch/x86/xen/enlighten.c | 24 +---
>  1 file changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index d38d568..6c1a330 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1803,10 +1803,21 @@ static void __init init_hvm_pv_info(void)
>   minor = eax & 0x;
>   printk(KERN_INFO "Xen version %d.%d.\n", major, minor);
>  
> - cpuid(base + 2, , , , );
> + xen_domain_type = XEN_HVM_DOMAIN;
>  
> - pfn = __pa(hypercall_page);
> - wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
> + /* PVH set up hypercall page earlier in xen_prepare_pvh() */

A period at the end?
> + if (xen_pvh_domain()) {
> + pv_info.name = "Xen PVH";
> +#ifdef CONFIG_ACPI
> + /* No PIC or IOAPIC */

Here?
> + acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
> +#endif
> + } else {
> + pv_info.name = "Xen HVM";
> + cpuid(base + 2, , , , );

Could you use cpuid_ebx ?
> + pfn = __pa(hypercall_page);
> + wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
> + }
>  
>   xen_setup_features();
>  
> @@ -1815,10 +1826,6 @@ static void __init init_hvm_pv_info(void)
>   this_cpu_write(xen_vcpu_id, ebx);
>   else
>   this_cpu_write(xen_vcpu_id, smp_processor_id());
> -
> - pv_info.name = "Xen HVM";
> -
> - xen_domain_type = XEN_HVM_DOMAIN;
>  }
>  
>  static int xen_cpu_up_prepare(unsigned int cpu)
> @@ -1892,6 +1899,9 @@ static void __init xen_hvm_guest_init(void)
>  
>   init_hvm_pv_info();
>  
> + if (xen_pvh_domain())
> + x86_platform.legacy.rtc = 0;
> +
>   xen_hvm_init_shared_info();
>  
>   xen_panic_handler_init();
> -- 
> 1.8.3.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH 4/8] xen/pvh: Bootstrap PVH guest

[Konrad Rzeszutek Wilk]

On Fri, Oct 14, 2016 at 02:05:14PM -0400, Boris Ostrovsky wrote:
> Start PVH guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall
> page, initialize boot_params, enable early page tables.
> 
> Since this stub is executed before kernel entry point we cannot use
> variables in .bss which is cleared by kernel. We explicitly place
> variables that are initialized here into .data.
> 
> Signed-off-by: Boris Ostrovsky 
> Signed-off-by: Matt Fleming 
> ---
>  arch/x86/xen/Kconfig |   2 +-
>  arch/x86/xen/Makefile|   1 +
>  arch/x86/xen/enlighten.c |  87 +++-
>  arch/x86/xen/xen-pvh.S   | 143 
> +++
>  include/xen/xen.h|   5 ++
>  5 files changed, 236 insertions(+), 2 deletions(-)
>  create mode 100644 arch/x86/xen/xen-pvh.S
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index c7b15f3..76b6dbd 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -53,5 +53,5 @@ config XEN_DEBUG_FS
>  
>  config XEN_PVH
>   bool "Support for running as a PVH guest"
> - depends on X86_64 && XEN && XEN_PVHVM
> + depends on XEN && XEN_PVHVM && ACPI
>   def_bool n
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index e47e527..cb0164a 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -23,3 +23,4 @@ obj-$(CONFIG_XEN_DEBUG_FS)  += debugfs.o
>  obj-$(CONFIG_XEN_DOM0)   += vga.o
>  obj-$(CONFIG_SWIOTLB_XEN)+= pci-swiotlb-xen.o
>  obj-$(CONFIG_XEN_EFI)+= efi.o
> +obj-$(CONFIG_XEN_PVH)+= xen-pvh.o
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index dc4ed0c..d38d568 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -45,6 +45,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -121,7 +122,8 @@
>  DEFINE_PER_CPU(uint32_t, xen_vcpu_id);
>  EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
>  
> -enum xen_domain_type xen_domain_type = XEN_NATIVE;
> +enum xen_domain_type xen_domain_type
> + __attribute__((section(".data"))) = XEN_NATIVE;
>  EXPORT_SYMBOL_GPL(xen_domain_type);
>  
>  unsigned long *machine_to_phys_mapping = (void *)MACH2PHYS_VIRT_START;
> @@ -176,6 +178,17 @@ struct tls_descs {
>   */
>  static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
>  
> +#ifdef CONFIG_XEN_PVH
> +/*
> + * PVH variables. These need to live in data segment since they are
> + * initialized before startup_{32|64}, which clear .bss, are invoked.
> + */
> +int xen_pvh __attribute__((section(".data"))) = 0;

unsigned int?
> +struct hvm_start_info pvh_start_info __attribute__((section(".data")));
> +uint pvh_start_info_sz = sizeof(pvh_start_info);

unsigned int please. Typedefs in Linux are frowned upon.

> +struct boot_params pvh_bootparams __attribute__((section(".data")));
> +#endif
> +
>  static void clamp_max_cpus(void)
>  {
>  #ifdef CONFIG_SMP
> @@ -1669,6 +1682,78 @@ asmlinkage __visible void __init xen_start_kernel(void)
>  #endif
>  }
>  
> +#ifdef CONFIG_XEN_PVH
> +static void __init init_pvh_bootparams(void)
> +{
> + struct xen_memory_map memmap;
> + int i;

unsigned int?
> +
> + memset(_bootparams, 0, sizeof(pvh_bootparams));
> +
> + memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_map);
> + set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_map);
> + if (HYPERVISOR_memory_op(XENMEM_memory_map, )) {
> + xen_raw_console_write("XENMEM_memory_map failed\n");

Should we print the error value at least?
> + BUG();
> + }
> +
> + pvh_bootparams.e820_map[memmap.nr_entries].addr =
> + ISA_START_ADDRESS;

What if nr_entries is 128? Should we double-check for that?

> + pvh_bootparams.e820_map[memmap.nr_entries].size =
> + ISA_END_ADDRESS - ISA_START_ADDRESS;
> + pvh_bootparams.e820_map[memmap.nr_entries++].type =
> + E820_RESERVED;
> +
> + sanitize_e820_map(pvh_bootparams.e820_map,
> +   ARRAY_SIZE(pvh_bootparams.e820_map),
> +   _entries); 
> +
> + pvh_bootparams.e820_entries = memmap.nr_entries;
> + for (i = 0; i < pvh_bootparams.e820_entries; i++)
> + e820_add_region(pvh_bootparams.e820_map[i].addr,
> + pvh_bootparams.e820_map[i].size,
> + pvh_bootparams.e820_map[i].type);
> +
> + pvh_bootparams.hdr.cmd_line_ptr =
> + pvh_start_info.cmdline_paddr;
> +
> + /* The first module is always ramdisk */

Could you add an period at end please?
> + if (pvh_start_info.nr_modules) {
> + struct hvm_modlist_entry *modaddr =
> + __va(pvh_start_info.modlist_paddr);
> + pvh_bootparams.hdr.ramdisk_image = modaddr->paddr;
> + pvh_bootparams.hdr.ramdisk_size = modaddr->size;
> + }
> +
> + /*
> +  * See 

Re: [Xen-devel] [PATCH 4/8] xen/pvh: Bootstrap PVH guest

[Andrew Cooper]

On 14/10/16 19:55, Boris Ostrovsky wrote:
> On 10/14/2016 02:38 PM, Andrew Cooper wrote:
>>> +   jmp *%rax
>>> +
>>> +#else /* CONFIG_X86_64 */
>>> +
>>> +   call setup_pgtable_32
>>> +
>>> +   mov $_pa(initial_page_table), %eax
>>> +   movl %eax, %cr3
>>> +
>>> +   movl %cr0, %eax
>>> +   orl $(X86_CR0_PG | X86_CR0_PE), %eax
>>> +   movl %eax, %cr0
>>> +
>>> +   ljmp $__BOOT_CS,$1f
>>> +1:
>>> +   call xen_prepare_pvh
>> Why does xen_prepare_pvh need paging?  I can't spot anything which
>> should need it, and it feels conceptually wrong.
> xen_prepare_pvh() deals with virtual addresses. How can we run without paging?

Ah yes - with a high-half kernel, that way around doesn't work.  Sorry
for the noise - I have been spending too long working with virtual
addresses down round 0, where that specifically can be solved by setting
%ds with a suitable non-zero base.

~Andrew

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

Re: [Xen-devel] [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

[hpa]

On October 14, 2016 11:44:18 AM PDT, Boris Ostrovsky 
 wrote:
>On 10/14/2016 02:31 PM, h...@zytor.com wrote:
>> On October 14, 2016 11:05:12 AM PDT, Boris Ostrovsky
> wrote:
>>> From: Matt Fleming 
>>>
>>> The new Xen PVH entry point requires page tables to be setup by the
>>> kernel since it is entered with paging disabled.
>>>
>>> Pull the common code out of head_32.S and into pgtable_32.S so that
>>> setup_pgtable_32 can be invoked from both the new Xen entry point
>and
>>> the existing startup_32 code.
>>>
>> And why does it need a separate entry point as opposed to the plain
>one?
>
>One reason is that we need to prepare boot_params before jumping to
>startup_{32|64}.
>
>When the guest is loaded (always in 32-bit mode) the only thing we have
>is a pointer to Xen-specific datastructure. The early PVH code will
>prepare zeropage based on that structure and then jump to regular
>startup_*() code.
>
>-boris

And why not just resume execution at start_32 then?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: [Xen-devel] [PATCH 8/8] xen/pvh: Enable CPU hotplug

[Boris Ostrovsky]

On 10/14/2016 02:41 PM, Andrew Cooper wrote:
> On 14/10/16 19:05, Boris Ostrovsky wrote:
>> PVH guests don't receive ACPI hotplug interrupts and therefore
>> need to monitor xenstore for CPU hotplug event.
> Why not?  If they don't, they should.  As we are providing ACPI anyway,
> we should provide all bits of it.

We don't have IOAPIC, which is how these interrupts are typically
delivered. I suppose we might be able to specify it as something else.

I'll look into this.

-boris


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

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

[Stefano Stabellini]

On Fri, 14 Oct 2016, George Dunlap wrote:
> On 14/10/16 07:36, Jan Beulich wrote:
>  On 14.10.16 at 02:58,  wrote:
> >> On Fri, 14 Oct 2016, Andrew Cooper wrote:
> >>> There should be a high barrier to "Supported" status, because the cost
> >>> of getting it wrong is equally high.  However, there are perfectly
> >>> legitimate intermediate stages such as "Supported in these limited set
> >>> of circumstances".  A number of features are not plausibly for use in
> >>> production environments, but otherwise function fine for
> >>> development/investigatory purposes.  In these cases, something like "no
> >>> security support, but believed to be working fine" might be appropriate.
> >>
> >> I agree on this. I think we need an intermediate step: "working but not
> >> supported for security" is completely reasonable. When we say that it is
> >> "working", it should be because we have automated testing for it (I
> >> don't know if I would go as far as requiring it to be in OSSTest, any
> >> automated testing, even third party, would do). If it is not
> >> automatically tested, then it is just "best effort".
> > 
> > I don't think this is a reasonable expectation - how would you envision
> > testing the dozens of command line options alone, not to speak of
> > things depending on hardware characteristics?
>
> Well there may be situations where we can make reasonable exceptions.
> But it would certainly be a lot better if a feature wasn't considered
> "done" until there was something in place to make sure that it worked
> and continued to work, other than "we hope people use it and report any
> bugs they find".

It is difficult to generalize, because, as Jan wrote, some things come
with dozen of command line options, some other things come with none.
This is were we'll have to apply our judgment on a case by case basis.
But indeed the basic idea is that it is "done" when there is some
testing for it, where "some" is case specific. Community testing is
great, but automated testing is more reliable and predictable.

At the same time this is an Open Source community and we might get
contributions from people that aren't paid to work on Xen. We cannot
ask all contributors to write automated testing scripts, and maybe offer
security support. A contributor might write good code for a new feature
but refuse to write the testing for it. I think that's OK, we can take
that code, but then we need to clarify the state of that feature with
the community.

On one hand we don't want users to think a feature is fully stable and
supported when actually it is not. It negatively impacts Xen brand and
reputation. On the other hand we don't want to discourage contributions
by asking to commit to security support, automated testing, ABI
stability etc. from the start. Rome wasn't built in a day :-)
Can you imagine if we accepted ARM patches in Xen only after Xen on ARM
was ready for automated testing and security support?

The best way to achieve both goals at the same time is to clarify the
right level of quality/stability/support for each feature.


> The more interesting aspect of Stefano's suggestion here is whether
> there should be two levels of "supported" -- "supported" as in, "this
> works but it's not in our security boundary", and "supported" as in,
> "this works and it *is* in our security boundary".

I think the security team should be free to refuse to offer support for
something, which otherwise might be considered working and stable. It
might not even be a vote of distrust: after all the security team has
only a finite amount of resources, maybe not enough to cover all areas
of the project.


> But as we don't *yet* have such a decision-making process in place, I
> think we need to approach each change in an ad-hoc manner.  Having a
> discussion about *credit2* which includes the security aspects makes
> sense, and I don't think we need to wait until we've got a generalized
> framework to make a reasonable decision about that.

By no means I meant to delay Dario's work.

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

Re: [Xen-devel] [PATCH 4/8] xen/pvh: Bootstrap PVH guest

[Boris Ostrovsky]

On 10/14/2016 02:38 PM, Andrew Cooper wrote:
>> +jmp *%rax
>> +
>> +#else /* CONFIG_X86_64 */
>> +
>> +call setup_pgtable_32
>> +
>> +mov $_pa(initial_page_table), %eax
>> +movl %eax, %cr3
>> +
>> +movl %cr0, %eax
>> +orl $(X86_CR0_PG | X86_CR0_PE), %eax
>> +movl %eax, %cr0
>> +
>> +ljmp $__BOOT_CS,$1f
>> +1:
>> +call xen_prepare_pvh
> Why does xen_prepare_pvh need paging?  I can't spot anything which
> should need it, and it feels conceptually wrong.

xen_prepare_pvh() deals with virtual addresses. How can we run without paging?

(Also, startup_64, which is where we jump from here in 64-bit mode expects 
paging to be on).

-boris



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

Re: [Xen-devel] [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

[Boris Ostrovsky]

On 10/14/2016 02:31 PM, h...@zytor.com wrote:
> On October 14, 2016 11:05:12 AM PDT, Boris Ostrovsky 
>  wrote:
>> From: Matt Fleming 
>>
>> The new Xen PVH entry point requires page tables to be setup by the
>> kernel since it is entered with paging disabled.
>>
>> Pull the common code out of head_32.S and into pgtable_32.S so that
>> setup_pgtable_32 can be invoked from both the new Xen entry point and
>> the existing startup_32 code.
>>
> And why does it need a separate entry point as opposed to the plain one?

One reason is that we need to prepare boot_params before jumping to
startup_{32|64}.

When the guest is loaded (always in 32-bit mode) the only thing we have
is a pointer to Xen-specific datastructure. The early PVH code will
prepare zeropage based on that structure and then jump to regular
startup_*() code.

-boris

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

Re: [Xen-devel] [PATCH 8/8] xen/pvh: Enable CPU hotplug

[Andrew Cooper]

On 14/10/16 19:05, Boris Ostrovsky wrote:
> PVH guests don't receive ACPI hotplug interrupts and therefore
> need to monitor xenstore for CPU hotplug event.

Why not?  If they don't, they should.  As we are providing ACPI anyway,
we should provide all bits of it.

~Andrew

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

Re: [Xen-devel] [PATCH 4/8] xen/pvh: Bootstrap PVH guest

[Andrew Cooper]

On 14/10/16 19:05, Boris Ostrovsky wrote:
> diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
> new file mode 100644
> index 000..58c477b
> --- /dev/null
> +++ b/arch/x86/xen/xen-pvh.S
> @@ -0,0 +1,143 @@
> +/*
> + * Copyright C 2016, Oracle and/or its affiliates. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program.  If not, see .
> + */
> +
> + .code32
> + .text
> +#define _pa(x)  ((x) - __START_KERNEL_map)
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> + __HEAD
> + .code32

Duplicated .code32

> +
> +/* Entry point for PVH guests */
> +ENTRY(pvh_start_xen)
> + cli
> + cld

The ABI states that these will be clear.

> +
> + mov $_pa(gdt), %eax
> + lgdt (%eax)

I am fairly sure you can express this without an intermediate in %eax.

> +
> + movl $(__BOOT_DS),%eax
> + movl %eax,%ds
> + movl %eax,%es
> + movl %eax,%ss
> +
> + /* Stash hvm_start_info */
> + mov $_pa(pvh_start_info), %edi
> + mov %ebx, %esi
> + mov $_pa(pvh_start_info_sz), %ecx
> + mov (%ecx), %ecx

No need for an intermediate.

> + rep
> + movsb

Surely we can guarentee the size is a multiple of 4? movsl would be better.

> +
> + movl $_pa(early_stack_end), %eax
> + movl %eax, %esp

You can mov straight into %esp.

> +
> + /* Enable PAE mode */
> + movl %cr4, %eax
> + orl $X86_CR4_PAE, %eax
> + movl %eax, %cr4
> +
> +#ifdef CONFIG_X86_64
> + /* Enable Long mode */
> + movl $MSR_EFER, %ecx
> + rdmsr
> + btsl $_EFER_LME, %eax
> + wrmsr
> +
> + /* Enable pre-constructed page tables */
> + mov $_pa(init_level4_pgt), %eax
> + movl %eax, %cr3
> + movl $(X86_CR0_PG | X86_CR0_PE), %eax
> + movl %eax, %cr0
> +
> + /* Jump to 64-bit mode. */
> + pushl $__KERNEL_CS
> + leal _pa(1f), %eax
> + pushl %eax
> + lret

You are still in compat mode, so can ljmp $__KERNEL_CS, $_pa(1f)

> +
> + /* 64-bit entry point */
> + .code64
> +1:
> + call xen_prepare_pvh
> +
> + /* startup_64 expects boot_params in %rsi */
> + mov $_pa(pvh_bootparams), %rsi
> + movq $_pa(startup_64), %rax

You seem to have an inconsistent mix of writing the explicit suffixes
when they aren't required.

> + jmp *%rax
> +
> +#else /* CONFIG_X86_64 */
> +
> + call setup_pgtable_32
> +
> + mov $_pa(initial_page_table), %eax
> + movl %eax, %cr3
> +
> + movl %cr0, %eax
> + orl $(X86_CR0_PG | X86_CR0_PE), %eax
> + movl %eax, %cr0
> +
> + ljmp $__BOOT_CS,$1f
> +1:
> + call xen_prepare_pvh

Why does xen_prepare_pvh need paging?  I can't spot anything which
should need it, and it feels conceptually wrong.

~Andrew

> + mov $_pa(pvh_bootparams), %esi
> +
> + /* startup_32 doesn't expect paging and PAE to be on */
> + ljmp $__BOOT_CS,$_pa(2f)
> +2:
> + movl %cr0, %eax
> + andl $~X86_CR0_PG, %eax
> + movl %eax, %cr0
> + movl %cr4, %eax
> + andl $~X86_CR4_PAE, %eax
> + movl %eax, %cr4
> +
> + ljmp$0x10, $_pa(startup_32)
> +#endif
> +
> + .data
> +gdt:
> + .word   gdt_end - gdt
> + .long   _pa(gdt)
> + .word   0
> + .quad   0x /* NULL descriptor */
> +#ifdef CONFIG_X86_64
> + .quad   0x00af9a00 /* __KERNEL_CS */
> +#else
> + .quad   0x00cf9a00 /* __KERNEL_CS */
> +#endif
> + .quad   0x00cf9200 /* __KERNEL_DS */
> +gdt_end:
> +
> + .bss
> + .balign 4
> +early_stack:
> + .fill 16, 1, 0
> +early_stack_end:
> +
> + ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY,
> +  _ASM_PTR (pvh_start_xen - __START_KERNEL_map))
>


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

Re: [Xen-devel] [PATCH 1/8] xen/x86: Remove PVH support

[Konrad Rzeszutek Wilk]

On Fri, Oct 14, 2016 at 02:05:11PM -0400, Boris Ostrovsky wrote:
> We are replacing existing PVH guests with new implementation.
> 
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Konrad Rzeszutek Wilk 

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

[Xen-devel] [ovmf baseline-only test] 67881: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ad9448408a5d2863db4aa2cb5d1f0d4a27689528
baseline version:
 ovmf a2d59ef2912079fe0631f7ee7661dad2ddb472c8

Last test of basis67879  2016-10-14 10:50:57 Z0 days
Testing same since67881  2016-10-14 16:46:16 Z0 days1 attempts


People who touched revisions under test:
  Giri P Mudusuru 

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.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

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

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


Push not applicable.


commit ad9448408a5d2863db4aa2cb5d1f0d4a27689528
Author: Giri P Mudusuru 
Date:   Tue Oct 11 22:13:56 2016 -0700

IntelSiliconPkg: Add Intel Firmware Version Info (FVI) definitions

Adding Intel Firmware Version Info (FVI) related defines & structures.
FVI enables reporting the Firmware Versions using SMBIOS OEM Type.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Giri P Mudusuru 
Reviewed-by: Jiewen Yao 
Reviewed-by: Star Zeng 

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

Re: [Xen-devel] [PATCH 3/8] xen/pvh: Import PVH-related Xen public interfaces

[Konrad Rzeszutek Wilk]

On Fri, Oct 14, 2016 at 02:05:13PM -0400, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Konrad Rzeszutek Wilk 

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

Re: [Xen-devel] [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

[hpa]

On October 14, 2016 11:05:12 AM PDT, Boris Ostrovsky 
 wrote:
>From: Matt Fleming 
>
>The new Xen PVH entry point requires page tables to be setup by the
>kernel since it is entered with paging disabled.
>
>Pull the common code out of head_32.S and into pgtable_32.S so that
>setup_pgtable_32 can be invoked from both the new Xen entry point and
>the existing startup_32 code.
>
>Cc: Boris Ostrovsky 
>Cc: Thomas Gleixner 
>Cc: Ingo Molnar 
>Cc: "H. Peter Anvin" 
>Cc: x...@kernel.org
>Signed-off-by: Matt Fleming 
>---
> arch/x86/Makefile|   2 +
> arch/x86/kernel/Makefile |   2 +
>arch/x86/kernel/head_32.S| 168
>+
>arch/x86/kernel/pgtable_32.S | 196
>+++
> 4 files changed, 201 insertions(+), 167 deletions(-)
> create mode 100644 arch/x86/kernel/pgtable_32.S
>
>diff --git a/arch/x86/Makefile b/arch/x86/Makefile
>index 2d44933..67cc771 100644
>--- a/arch/x86/Makefile
>+++ b/arch/x86/Makefile
>@@ -204,6 +204,8 @@ head-y += arch/x86/kernel/head$(BITS).o
> head-y += arch/x86/kernel/ebda.o
> head-y += arch/x86/kernel/platform-quirks.o
> 
>+head-$(CONFIG_X86_32) += arch/x86/kernel/pgtable_32.o
>+
> libs-y  += arch/x86/lib/
> 
> # See arch/x86/Kbuild for content of core part of the kernel
>diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
>index 4dd5d50..eae85a5 100644
>--- a/arch/x86/kernel/Makefile
>+++ b/arch/x86/kernel/Makefile
>@@ -8,6 +8,8 @@ extra-y+= ebda.o
> extra-y   += platform-quirks.o
> extra-y   += vmlinux.lds
> 
>+extra-$(CONFIG_X86_32) += pgtable_32.o
>+
> CPPFLAGS_vmlinux.lds += -U$(UTS_MACHINE)
> 
> ifdef CONFIG_FUNCTION_TRACER
>diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
>index 5f40126..0db066e 100644
>--- a/arch/x86/kernel/head_32.S
>+++ b/arch/x86/kernel/head_32.S
>@@ -41,51 +41,6 @@
> #define X86_VENDOR_ID new_cpu_data+CPUINFO_x86_vendor_id
> 
> /*
>- * This is how much memory in addition to the memory covered up to
>- * and including _end we need mapped initially.
>- * We need:
>- * (KERNEL_IMAGE_SIZE/4096) / 1024 pages (worst case, non PAE)
>- * (KERNEL_IMAGE_SIZE/4096) / 512 + 4 pages (worst case for PAE)
>- *
>- * Modulo rounding, each megabyte assigned here requires a kilobyte of
>- * memory, which is currently unreclaimed.
>- *
>- * This should be a multiple of a page.
>- *
>- * KERNEL_IMAGE_SIZE should be greater than pa(_end)
>- * and small than max_low_pfn, otherwise will waste some page table
>entries
>- */
>-
>-#if PTRS_PER_PMD > 1
>-#define PAGE_TABLE_SIZE(pages) (((pages) / PTRS_PER_PMD) +
>PTRS_PER_PGD)
>-#else
>-#define PAGE_TABLE_SIZE(pages) ((pages) / PTRS_PER_PGD)
>-#endif
>-
>-/*
>- * Number of possible pages in the lowmem region.
>- *
>- * We shift 2 by 31 instead of 1 by 32 to the left in order to avoid a
>- * gas warning about overflowing shift count when gas has been
>compiled
>- * with only a host target support using a 32-bit type for internal
>- * representation.
>- */
>-LOWMEM_PAGES = (((2<<31) - __PAGE_OFFSET) >> PAGE_SHIFT)
>-
>-/* Enough space to fit pagetables for the low memory linear map */
>-MAPPING_BEYOND_END = PAGE_TABLE_SIZE(LOWMEM_PAGES) << PAGE_SHIFT
>-
>-/*
>- * Worst-case size of the kernel mapping we need to make:
>- * a relocatable kernel can live anywhere in lowmem, so we need to be
>able
>- * to map all of lowmem.
>- */
>-KERNEL_PAGES = LOWMEM_PAGES
>-
>-INIT_MAP_SIZE = PAGE_TABLE_SIZE(KERNEL_PAGES) * PAGE_SIZE
>-RESERVE_BRK(pagetables, INIT_MAP_SIZE)
>-
>-/*
>  * 32-bit kernel entrypoint; only used by the boot CPU.  On entry,
>  * %esi points to the real-mode code as a 32-bit pointer.
>  * CS and DS must be 4 GB flat segments, but we don't depend on
>@@ -157,92 +112,7 @@ ENTRY(startup_32)
>   call load_ucode_bsp
> #endif
> 
>-/*
>- * Initialize page tables.  This creates a PDE and a set of page
>- * tables, which are located immediately beyond __brk_base.  The
>variable
>- * _brk_end is set up to point to the first "safe" location.
>- * Mappings are created both at virtual address 0 (identity mapping)
>- * and PAGE_OFFSET for up to _end.
>- */
>-#ifdef CONFIG_X86_PAE
>-
>-  /*
>-   * In PAE mode initial_page_table is statically defined to contain
>-   * enough entries to cover the VMSPLIT option (that is the top 1, 2
>or 3
>-   * entries). The identity mapping is handled by pointing two PGD
>entries
>-   * to the first kernel PMD.
>-   *
>-   * Note the upper half of each PMD or PTE are always zero at this
>stage.
>-   */
>-
>-#define KPMDS (((-__PAGE_OFFSET) >> 30) & 3) /* Number of kernel PMDs
>*/
>-
>-  xorl %ebx,%ebx  /* %ebx is kept at zero */
>-
>-  movl $pa(__brk_base), %edi
>-  movl $pa(initial_pg_pmd), %edx
>-  movl $PTE_IDENT_ATTR, %eax
>-10:
>-  

Re: [Xen-devel] Debugging your environment...

[tevin.k.mallory]

Hi Jesus,
Since our last chat here is what I have done. I have created a new 
virtualenv with "--no-site-packages" to insure a fresh clean environment. After 
I followed your instructions and pulled up my "dir" data. I notice I didn't 
have a "bin" directory and researched why. It turns out a "bin" directory is 
created on POSIZ systems only. Also some paths within the virtualenv are 
different on Windows: scripts and executables on Windows go in "ENV\Scripts\" 
instead of "ENV/bin". I don't know if this will have a problem with perceval 
command scripts. 
I install perceval into my virtualenv and tried to run Perceval again. 
It still isn’t working for me, so I am going to try changing my OS to Unbuntu 
and try again there. I inserted my command prompt below.  


Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Users\Tevin>cd Desktop

C:\Users\Tevin\Desktop>md perceval

C:\Users\Tevin\Desktop>md project

C:\Users\Tevin\Desktop>cd project

C:\Users\Tevin\Desktop\project>virtualenv --no-site-packages perceval
Using base prefix 
'c:\\users\\tevin\\appdata\\local\\programs\\python\\python35-32'
New python executable in 
C:\Users\Tevin\Desktop\project\perceval\Scripts\python.exe
Installing setuptools, pip, wheel...done.

C:\Users\Tevin\Desktop\project>cd perceval

C:\Users\Tevin\Desktop\project\perceval>dir
 Volume in drive C is OS
 Volume Serial Number is 2606-BFCB

 Directory of C:\Users\Tevin\Desktop\project\perceval

10/14/2016  01:25 PM  .
10/14/2016  01:25 PM  ..
10/07/2016  12:24 AM  Include
10/14/2016  01:24 PM  Lib
10/14/2016  01:25 PM60 pip-selfcheck.json
10/14/2016  01:25 PM  Scripts
10/14/2016  01:24 PM  tcl
   1 File(s) 60 bytes
   6 Dir(s)  416,644,304,896 bytes free

C:\Users\Tevin\Desktop\project\perceval>scripts\activate

(perceval) C:\Users\Tevin\Desktop\project\perceval>pip install perceval
Collecting perceval
  Using cached perceval-0.3.0-py3-none-any.whl
Collecting python-dateutil>=2.0.0 (from perceval)
  Using cached python_dateutil-2.5.3-py2.py3-none-any.whl
Collecting requests>=2.7.0 (from perceval)
  Using cached requests-2.11.1-py2.py3-none-any.whl
Collecting beautifulsoup4>=4.3.2 (from perceval)
  Using cached beautifulsoup4-4.5.1-py3-none-any.whl
Collecting six>=1.5 (from python-dateutil>=2.0.0->perceval)
  Using cached six-1.10.0-py2.py3-none-any.whl
Installing collected packages: six, python-dateutil, requests, beautifulsoup4, 
perceval
Successfully installed beautifulsoup4-4.5.1 perceval-0.3.0 
python-dateutil-2.5.3 requests-2.11.1 six-1.10.0

(perceval) C:\Users\Tevin\Desktop\project\perceval>dir
 Volume in drive C is OS
 Volume Serial Number is 2606-BFCB

 Directory of C:\Users\Tevin\Desktop\project\perceval

10/14/2016  01:25 PM  .
10/14/2016  01:25 PM  ..
10/07/2016  12:24 AM  Include
10/14/2016  01:24 PM  Lib
10/14/2016  01:25 PM60 pip-selfcheck.json
10/14/2016  01:31 PM  Scripts
10/14/2016  01:24 PM  tcl
   1 File(s) 60 bytes
   6 Dir(s)  416,637,894,656 bytes free

(perceval) C:\Users\Tevin\Desktop\project\perceval>echo %PATH%
C:\Users\Tevin\Desktop\project\perceval\Scripts;C:\ProgramData\Oracle\Java\javapath;C:\Program
 Files (x86)\Intel\TXE Components\TCS\;C:\Program Files\Intel\TXE 
Components\TCS\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program
 Files (x86)\Common Files\Adobe\AGL;C:\Program Files 
(x86)\DevDesktop\drush;C:\Program Files\Java\jdk\bin;C:\Program 
Files\Java\jre\bin;C:\Users\Tevin\AppData\Local\Programs\Python\Python35-32\Scripts\;C:\Users\Tevin\AppData\Local\Programs\Python\Python35-32\;C:\Users\Tevin\AppData\Local\Microsoft\WindowsApps;C:\Windows\System32;C:\Users\Tevin\Documents\project\mtask\Lib\site-packages

(perceval) C:\Users\Tevin\Desktop\project\perceval>echo %PYTHONPATH
%PYTHONPATH

(perceval) C:\Users\Tevin\Desktop\project\perceval>path
PATH=C:\Users\Tevin\Desktop\project\perceval\Scripts;C:\ProgramData\Oracle\Java\javapath;C:\Program
 Files (x86)\Intel\TXE Components\TCS\;C:\Program Files\Intel\TXE 
Components\TCS\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program
 Files (x86)\Common Files\Adobe\AGL;C:\Program Files 
(x86)\DevDesktop\drush;C:\Program Files\Java\jdk\bin;C:\Program 
Files\Java\jre\bin;C:\Users\Tevin\AppData\Local\Programs\Python\Python35-32\Scripts\;C:\Users\Tevin\AppData\Local\Programs\Python\Python35-32\;C:\Users\Tevin\AppData\Local\Microsoft\WindowsApps;C:\Windows\System32;C:\Users\Tevin\Documents\project\mtask\Lib\site-packages

(perceval) C:\Users\Tevin\Desktop\project\perceval>perceval
'perceval' is not recognized as an internal or external command,
operable program or batch file.

(perceval) 

[Xen-devel] [PATCH 5/8] xen/pvh: Prevent PVH guests from using PIC, RTC and IOAPIC

[Boris Ostrovsky]

Make sure they don't use these devices since they are not emulated
for unprivileged PVH guest.

Also don't initialize hypercall page for them in init_hvm_pv_info()
since this has already been done.

Signed-off-by: Boris Ostrovsky 
---
 arch/x86/xen/enlighten.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index d38d568..6c1a330 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1803,10 +1803,21 @@ static void __init init_hvm_pv_info(void)
minor = eax & 0x;
printk(KERN_INFO "Xen version %d.%d.\n", major, minor);
 
-   cpuid(base + 2, , , , );
+   xen_domain_type = XEN_HVM_DOMAIN;
 
-   pfn = __pa(hypercall_page);
-   wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+   /* PVH set up hypercall page earlier in xen_prepare_pvh() */
+   if (xen_pvh_domain()) {
+   pv_info.name = "Xen PVH";
+#ifdef CONFIG_ACPI
+   /* No PIC or IOAPIC */
+   acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
+#endif
+   } else {
+   pv_info.name = "Xen HVM";
+   cpuid(base + 2, , , , );
+   pfn = __pa(hypercall_page);
+   wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+   }
 
xen_setup_features();
 
@@ -1815,10 +1826,6 @@ static void __init init_hvm_pv_info(void)
this_cpu_write(xen_vcpu_id, ebx);
else
this_cpu_write(xen_vcpu_id, smp_processor_id());
-
-   pv_info.name = "Xen HVM";
-
-   xen_domain_type = XEN_HVM_DOMAIN;
 }
 
 static int xen_cpu_up_prepare(unsigned int cpu)
@@ -1892,6 +1899,9 @@ static void __init xen_hvm_guest_init(void)
 
init_hvm_pv_info();
 
+   if (xen_pvh_domain())
+   x86_platform.legacy.rtc = 0;
+
xen_hvm_init_shared_info();
 
xen_panic_handler_init();
-- 
1.8.3.1


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

[Xen-devel] [PATCH 4/8] xen/pvh: Bootstrap PVH guest

[Boris Ostrovsky]

Start PVH guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall
page, initialize boot_params, enable early page tables.

Since this stub is executed before kernel entry point we cannot use
variables in .bss which is cleared by kernel. We explicitly place
variables that are initialized here into .data.

Signed-off-by: Boris Ostrovsky 
Signed-off-by: Matt Fleming 
---
 arch/x86/xen/Kconfig |   2 +-
 arch/x86/xen/Makefile|   1 +
 arch/x86/xen/enlighten.c |  87 +++-
 arch/x86/xen/xen-pvh.S   | 143 +++
 include/xen/xen.h|   5 ++
 5 files changed, 236 insertions(+), 2 deletions(-)
 create mode 100644 arch/x86/xen/xen-pvh.S

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index c7b15f3..76b6dbd 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -53,5 +53,5 @@ config XEN_DEBUG_FS
 
 config XEN_PVH
bool "Support for running as a PVH guest"
-   depends on X86_64 && XEN && XEN_PVHVM
+   depends on XEN && XEN_PVHVM && ACPI
def_bool n
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index e47e527..cb0164a 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_XEN_DEBUG_FS)+= debugfs.o
 obj-$(CONFIG_XEN_DOM0) += vga.o
 obj-$(CONFIG_SWIOTLB_XEN)  += pci-swiotlb-xen.o
 obj-$(CONFIG_XEN_EFI)  += efi.o
+obj-$(CONFIG_XEN_PVH)  += xen-pvh.o
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index dc4ed0c..d38d568 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -121,7 +122,8 @@
 DEFINE_PER_CPU(uint32_t, xen_vcpu_id);
 EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
 
-enum xen_domain_type xen_domain_type = XEN_NATIVE;
+enum xen_domain_type xen_domain_type
+   __attribute__((section(".data"))) = XEN_NATIVE;
 EXPORT_SYMBOL_GPL(xen_domain_type);
 
 unsigned long *machine_to_phys_mapping = (void *)MACH2PHYS_VIRT_START;
@@ -176,6 +178,17 @@ struct tls_descs {
  */
 static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
 
+#ifdef CONFIG_XEN_PVH
+/*
+ * PVH variables. These need to live in data segment since they are
+ * initialized before startup_{32|64}, which clear .bss, are invoked.
+ */
+int xen_pvh __attribute__((section(".data"))) = 0;
+struct hvm_start_info pvh_start_info __attribute__((section(".data")));
+uint pvh_start_info_sz = sizeof(pvh_start_info);
+struct boot_params pvh_bootparams __attribute__((section(".data")));
+#endif
+
 static void clamp_max_cpus(void)
 {
 #ifdef CONFIG_SMP
@@ -1669,6 +1682,78 @@ asmlinkage __visible void __init xen_start_kernel(void)
 #endif
 }
 
+#ifdef CONFIG_XEN_PVH
+static void __init init_pvh_bootparams(void)
+{
+   struct xen_memory_map memmap;
+   int i;
+
+   memset(_bootparams, 0, sizeof(pvh_bootparams));
+
+   memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_map);
+   set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_map);
+   if (HYPERVISOR_memory_op(XENMEM_memory_map, )) {
+   xen_raw_console_write("XENMEM_memory_map failed\n");
+   BUG();
+   }
+
+   pvh_bootparams.e820_map[memmap.nr_entries].addr =
+   ISA_START_ADDRESS;
+   pvh_bootparams.e820_map[memmap.nr_entries].size =
+   ISA_END_ADDRESS - ISA_START_ADDRESS;
+   pvh_bootparams.e820_map[memmap.nr_entries++].type =
+   E820_RESERVED;
+
+   sanitize_e820_map(pvh_bootparams.e820_map,
+ ARRAY_SIZE(pvh_bootparams.e820_map),
+ _entries);
+
+   pvh_bootparams.e820_entries = memmap.nr_entries;
+   for (i = 0; i < pvh_bootparams.e820_entries; i++)
+   e820_add_region(pvh_bootparams.e820_map[i].addr,
+   pvh_bootparams.e820_map[i].size,
+   pvh_bootparams.e820_map[i].type);
+
+   pvh_bootparams.hdr.cmd_line_ptr =
+   pvh_start_info.cmdline_paddr;
+
+   /* The first module is always ramdisk */
+   if (pvh_start_info.nr_modules) {
+   struct hvm_modlist_entry *modaddr =
+   __va(pvh_start_info.modlist_paddr);
+   pvh_bootparams.hdr.ramdisk_image = modaddr->paddr;
+   pvh_bootparams.hdr.ramdisk_size = modaddr->size;
+   }
+
+   /*
+* See Documentation/x86/boot.txt.
+*
+* Version 2.12 supports Xen entry point but we will use default x86/PC
+* environment (i.e. hardware_subarch 0).
+*/
+   pvh_bootparams.hdr.version = 0x212;
+   pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
+}
+
+/*
+ * This routine (and those that it might call) should not use
+ * anything that lives in .bss since that segment will be cleared later
+ */
+void __init xen_prepare_pvh(void)
+{
+

[Xen-devel] [PATCH 1/8] xen/x86: Remove PVH support

[Boris Ostrovsky]

We are replacing existing PVH guests with new implementation.

Signed-off-by: Boris Ostrovsky 
---
 arch/x86/xen/enlighten.c | 140 ++-
 arch/x86/xen/mmu.c   |  21 +-
 arch/x86/xen/setup.c |  37 +--
 arch/x86/xen/smp.c   |  78 --
 arch/x86/xen/smp.h   |   8 ---
 arch/x86/xen/xen-head.S  |  62 ++---
 arch/x86/xen/xen-ops.h   |   1 -
 drivers/xen/events/events_base.c |   1 -
 include/xen/xen.h|  13 +---
 9 files changed, 54 insertions(+), 307 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index c0fdd57..dc4ed0c 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1149,10 +1149,11 @@ void xen_setup_vcpu_info_placement(void)
xen_vcpu_setup(cpu);
}
 
-   /* xen_vcpu_setup managed to place the vcpu_info within the
-* percpu area for all cpus, so make use of it. Note that for
-* PVH we want to use native IRQ mechanism. */
-   if (have_vcpu_info_placement && !xen_pvh_domain()) {
+   /*
+* xen_vcpu_setup managed to place the vcpu_info within the
+* percpu area for all cpus, so make use of it.
+*/
+   if (have_vcpu_info_placement) {
pv_irq_ops.save_fl = __PV_IS_CALLEE_SAVE(xen_save_fl_direct);
pv_irq_ops.restore_fl = 
__PV_IS_CALLEE_SAVE(xen_restore_fl_direct);
pv_irq_ops.irq_disable = 
__PV_IS_CALLEE_SAVE(xen_irq_disable_direct);
@@ -1426,49 +1427,9 @@ static void __init xen_boot_params_init_edd(void)
  * Set up the GDT and segment registers for -fstack-protector.  Until
  * we do this, we have to be careful not to call any stack-protected
  * function, which is most of the kernel.
- *
- * Note, that it is __ref because the only caller of this after init
- * is PVH which is not going to use xen_load_gdt_boot or other
- * __init functions.
  */
-static void __ref xen_setup_gdt(int cpu)
+static void xen_setup_gdt(int cpu)
 {
-   if (xen_feature(XENFEAT_auto_translated_physmap)) {
-#ifdef CONFIG_X86_64
-   unsigned long dummy;
-
-   load_percpu_segment(cpu); /* We need to access per-cpu area */
-   switch_to_new_gdt(cpu); /* GDT and GS set */
-
-   /* We are switching of the Xen provided GDT to our HVM mode
-* GDT. The new GDT has  __KERNEL_CS with CS.L = 1
-* and we are jumping to reload it.
-*/
-   asm volatile ("pushq %0\n"
- "leaq 1f(%%rip),%0\n"
- "pushq %0\n"
- "lretq\n"
- "1:\n"
- : "=" (dummy) : "0" (__KERNEL_CS));
-
-   /*
-* While not needed, we also set the %es, %ds, and %fs
-* to zero. We don't care about %ss as it is NULL.
-* Strictly speaking this is not needed as Xen zeros those
-* out (and also MSR_FS_BASE, MSR_GS_BASE, MSR_KERNEL_GS_BASE)
-*
-* Linux zeros them in cpu_init() and in secondary_startup_64
-* (for BSP).
-*/
-   loadsegment(es, 0);
-   loadsegment(ds, 0);
-   loadsegment(fs, 0);
-#else
-   /* PVH: TODO Implement. */
-   BUG();
-#endif
-   return; /* PVH does not need any PV GDT ops. */
-   }
pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
pv_cpu_ops.load_gdt = xen_load_gdt_boot;
 
@@ -1479,59 +1440,6 @@ static void __ref xen_setup_gdt(int cpu)
pv_cpu_ops.load_gdt = xen_load_gdt;
 }
 
-#ifdef CONFIG_XEN_PVH
-/*
- * A PV guest starts with default flags that are not set for PVH, set them
- * here asap.
- */
-static void xen_pvh_set_cr_flags(int cpu)
-{
-
-   /* Some of these are setup in 'secondary_startup_64'. The others:
-* X86_CR0_TS, X86_CR0_PE, X86_CR0_ET are set by Xen for HVM guests
-* (which PVH shared codepaths), while X86_CR0_PG is for PVH. */
-   write_cr0(read_cr0() | X86_CR0_MP | X86_CR0_NE | X86_CR0_WP | 
X86_CR0_AM);
-
-   if (!cpu)
-   return;
-   /*
-* For BSP, PSE PGE are set in probe_page_size_mask(), for APs
-* set them here. For all, OSFXSR OSXMMEXCPT are set in fpu__init_cpu().
-   */
-   if (boot_cpu_has(X86_FEATURE_PSE))
-   cr4_set_bits_and_update_boot(X86_CR4_PSE);
-
-   if (boot_cpu_has(X86_FEATURE_PGE))
-   cr4_set_bits_and_update_boot(X86_CR4_PGE);
-}
-
-/*
- * Note, that it is ref - because the only caller of this after init
- * is PVH which is not going to use xen_load_gdt_boot or other
- * __init functions.
- */
-void __ref xen_pvh_secondary_vcpu_init(int cpu)
-{
-   xen_setup_gdt(cpu);
-   

[Xen-devel] [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

[Boris Ostrovsky]

From: Matt Fleming 

The new Xen PVH entry point requires page tables to be setup by the
kernel since it is entered with paging disabled.

Pull the common code out of head_32.S and into pgtable_32.S so that
setup_pgtable_32 can be invoked from both the new Xen entry point and
the existing startup_32 code.

Cc: Boris Ostrovsky 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Signed-off-by: Matt Fleming 
---
 arch/x86/Makefile|   2 +
 arch/x86/kernel/Makefile |   2 +
 arch/x86/kernel/head_32.S| 168 +
 arch/x86/kernel/pgtable_32.S | 196 +++
 4 files changed, 201 insertions(+), 167 deletions(-)
 create mode 100644 arch/x86/kernel/pgtable_32.S

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 2d44933..67cc771 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -204,6 +204,8 @@ head-y += arch/x86/kernel/head$(BITS).o
 head-y += arch/x86/kernel/ebda.o
 head-y += arch/x86/kernel/platform-quirks.o
 
+head-$(CONFIG_X86_32) += arch/x86/kernel/pgtable_32.o
+
 libs-y  += arch/x86/lib/
 
 # See arch/x86/Kbuild for content of core part of the kernel
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 4dd5d50..eae85a5 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -8,6 +8,8 @@ extra-y += ebda.o
 extra-y+= platform-quirks.o
 extra-y+= vmlinux.lds
 
+extra-$(CONFIG_X86_32) += pgtable_32.o
+
 CPPFLAGS_vmlinux.lds += -U$(UTS_MACHINE)
 
 ifdef CONFIG_FUNCTION_TRACER
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 5f40126..0db066e 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -41,51 +41,6 @@
 #define X86_VENDOR_ID  new_cpu_data+CPUINFO_x86_vendor_id
 
 /*
- * This is how much memory in addition to the memory covered up to
- * and including _end we need mapped initially.
- * We need:
- * (KERNEL_IMAGE_SIZE/4096) / 1024 pages (worst case, non PAE)
- * (KERNEL_IMAGE_SIZE/4096) / 512 + 4 pages (worst case for PAE)
- *
- * Modulo rounding, each megabyte assigned here requires a kilobyte of
- * memory, which is currently unreclaimed.
- *
- * This should be a multiple of a page.
- *
- * KERNEL_IMAGE_SIZE should be greater than pa(_end)
- * and small than max_low_pfn, otherwise will waste some page table entries
- */
-
-#if PTRS_PER_PMD > 1
-#define PAGE_TABLE_SIZE(pages) (((pages) / PTRS_PER_PMD) + PTRS_PER_PGD)
-#else
-#define PAGE_TABLE_SIZE(pages) ((pages) / PTRS_PER_PGD)
-#endif
-
-/*
- * Number of possible pages in the lowmem region.
- *
- * We shift 2 by 31 instead of 1 by 32 to the left in order to avoid a
- * gas warning about overflowing shift count when gas has been compiled
- * with only a host target support using a 32-bit type for internal
- * representation.
- */
-LOWMEM_PAGES = (((2<<31) - __PAGE_OFFSET) >> PAGE_SHIFT)
-
-/* Enough space to fit pagetables for the low memory linear map */
-MAPPING_BEYOND_END = PAGE_TABLE_SIZE(LOWMEM_PAGES) << PAGE_SHIFT
-
-/*
- * Worst-case size of the kernel mapping we need to make:
- * a relocatable kernel can live anywhere in lowmem, so we need to be able
- * to map all of lowmem.
- */
-KERNEL_PAGES = LOWMEM_PAGES
-
-INIT_MAP_SIZE = PAGE_TABLE_SIZE(KERNEL_PAGES) * PAGE_SIZE
-RESERVE_BRK(pagetables, INIT_MAP_SIZE)
-
-/*
  * 32-bit kernel entrypoint; only used by the boot CPU.  On entry,
  * %esi points to the real-mode code as a 32-bit pointer.
  * CS and DS must be 4 GB flat segments, but we don't depend on
@@ -157,92 +112,7 @@ ENTRY(startup_32)
call load_ucode_bsp
 #endif
 
-/*
- * Initialize page tables.  This creates a PDE and a set of page
- * tables, which are located immediately beyond __brk_base.  The variable
- * _brk_end is set up to point to the first "safe" location.
- * Mappings are created both at virtual address 0 (identity mapping)
- * and PAGE_OFFSET for up to _end.
- */
-#ifdef CONFIG_X86_PAE
-
-   /*
-* In PAE mode initial_page_table is statically defined to contain
-* enough entries to cover the VMSPLIT option (that is the top 1, 2 or 3
-* entries). The identity mapping is handled by pointing two PGD entries
-* to the first kernel PMD.
-*
-* Note the upper half of each PMD or PTE are always zero at this stage.
-*/
-
-#define KPMDS (((-__PAGE_OFFSET) >> 30) & 3) /* Number of kernel PMDs */
-
-   xorl %ebx,%ebx  /* %ebx is kept at zero */
-
-   movl $pa(__brk_base), %edi
-   movl $pa(initial_pg_pmd), %edx
-   movl $PTE_IDENT_ATTR, %eax
-10:
-   leal PDE_IDENT_ATTR(%edi),%ecx  /* Create PMD entry */
-   movl %ecx,(%edx)/* Store PMD entry */
-   /* Upper half already zero */
-   addl 

[Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
 drivers/xen/grant-table.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bb36b1e..d6786b8 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1146,13 +1146,13 @@ int gnttab_init(void)
 
 static int __gnttab_init(void)
 {
+   if (!xen_domain())
+   return -ENODEV;
+
/* Delay grant-table initialization in the PV on HVM case */
-   if (xen_hvm_domain())
+   if (xen_hvm_domain() && !xen_pvh_domain())
return 0;
 
-   if (!xen_pv_domain())
-   return -ENODEV;
-
return gnttab_init();
 }
 /* Starts after core_initcall so that xen_pvh_gnttab_setup can be called
-- 
1.8.3.1


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

[Xen-devel] [PATCH 7/8] xen/pvh: PVH guests always have PV devices

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
 arch/x86/xen/platform-pci-unplug.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/platform-pci-unplug.c 
b/arch/x86/xen/platform-pci-unplug.c
index 90d1b83..33a783c 100644
--- a/arch/x86/xen/platform-pci-unplug.c
+++ b/arch/x86/xen/platform-pci-unplug.c
@@ -73,8 +73,8 @@ bool xen_has_pv_devices(void)
if (!xen_domain())
return false;
 
-   /* PV domains always have them. */
-   if (xen_pv_domain())
+   /* PV and PVH domains always have them. */
+   if (xen_pv_domain() || xen_pvh_domain())
return true;
 
/* And user has xen_platform_pci=0 set in guest config as
-- 
1.8.3.1


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

[Xen-devel] [PATCH 8/8] xen/pvh: Enable CPU hotplug

[Boris Ostrovsky]

PVH guests don't receive ACPI hotplug interrupts and therefore
need to monitor xenstore for CPU hotplug event.

Signed-off-by: Boris Ostrovsky 
---
 drivers/xen/cpu_hotplug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 5676aef..0bab60a3 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -107,7 +107,7 @@ static int __init setup_vcpu_hotplug_event(void)
.notifier_call = setup_cpu_watcher };
 
 #ifdef CONFIG_X86
-   if (!xen_pv_domain())
+   if (!xen_pv_domain() && !xen_pvh_domain())
 #else
if (!xen_domain())
 #endif
-- 
1.8.3.1


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

[Xen-devel] [PATCH 0/8] PVH v2 support

[Boris Ostrovsky]

(Resending with proper mailing lists included)

PVH v2 support for unprivileged guests.

Previous version was posted long time ago. Major changes:
1. Drop PVH v1 support
2. Enable ACPI. This allows us to use much more of native code and
   results in making this series much simpler (for example, PV-style
   VCPU bringup is no longer necessary).
3. Refactor 32-bit pagetable setup from native code (by Matt Fleming)

This has been tested on Intel/AMD, both 32- and 64-bit, including CPU
hotplug and save/restore. Compile-tested for ARM.


Boris Ostrovsky (8):
  xen/x86: Remove PVH support
  x86/head: Refactor 32-bit pgtable setup
  xen/pvh: Import PVH-related Xen public interfaces
  xen/pvh: Bootstrap PVH guest
  xen/pvh: Prevent PVH guests from using PIC, RTC and IOAPIC
  xen/pvh: Initialize grant table for PVH guests
  xen/pvh: PVH guests always have PV devices
  xen/pvh: Enable CPU hotplug

 arch/x86/Makefile  |   2 +
 arch/x86/kernel/Makefile   |   2 +
 arch/x86/kernel/head_32.S  | 168 +-
 arch/x86/kernel/pgtable_32.S   | 196 +
 arch/x86/xen/Kconfig   |   2 +-
 arch/x86/xen/Makefile  |   1 +
 arch/x86/xen/enlighten.c   | 251 -
 arch/x86/xen/mmu.c |  21 +--
 arch/x86/xen/platform-pci-unplug.c |   4 +-
 arch/x86/xen/setup.c   |  37 +
 arch/x86/xen/smp.c |  78 --
 arch/x86/xen/smp.h |   8 --
 arch/x86/xen/xen-head.S|  62 +---
 arch/x86/xen/xen-ops.h |   1 -
 arch/x86/xen/xen-pvh.S | 143 +++
 drivers/xen/cpu_hotplug.c  |   2 +-
 drivers/xen/events/events_base.c   |   1 -
 drivers/xen/grant-table.c  |   8 +-
 include/xen/interface/elfnote.h|  12 +-
 include/xen/interface/hvm/hvm_vcpu.h   | 143 +++
 include/xen/interface/hvm/start_info.h |  98 +
 include/xen/xen.h  |  12 +-
 22 files changed, 764 insertions(+), 488 deletions(-)
 create mode 100644 arch/x86/kernel/pgtable_32.S
 create mode 100644 arch/x86/xen/xen-pvh.S
 create mode 100644 include/xen/interface/hvm/hvm_vcpu.h
 create mode 100644 include/xen/interface/hvm/start_info.h

-- 
1.8.3.1


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

[Xen-devel] [PATCH 3/8] xen/pvh: Import PVH-related Xen public interfaces

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
 include/xen/interface/elfnote.h|  12 ++-
 include/xen/interface/hvm/hvm_vcpu.h   | 143 +
 include/xen/interface/hvm/start_info.h |  98 ++
 3 files changed, 252 insertions(+), 1 deletion(-)
 create mode 100644 include/xen/interface/hvm/hvm_vcpu.h
 create mode 100644 include/xen/interface/hvm/start_info.h

diff --git a/include/xen/interface/elfnote.h b/include/xen/interface/elfnote.h
index f90b034..9e9f9bf 100644
--- a/include/xen/interface/elfnote.h
+++ b/include/xen/interface/elfnote.h
@@ -193,9 +193,19 @@
 #define XEN_ELFNOTE_SUPPORTED_FEATURES 17
 
 /*
+ * Physical entry point into the kernel.
+ *
+ * 32bit entry point into the kernel. When requested to launch the
+ * guest kernel in a HVM container, Xen will use this entry point to
+ * launch the guest in 32bit protected mode with paging disabled.
+ * Ignored otherwise.
+ */
+#define XEN_ELFNOTE_PHYS32_ENTRY 18
+
+/*
  * The number of the highest elfnote defined.
  */
-#define XEN_ELFNOTE_MAX XEN_ELFNOTE_SUPPORTED_FEATURES
+#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_ENTRY
 
 #endif /* __XEN_PUBLIC_ELFNOTE_H__ */
 
diff --git a/include/xen/interface/hvm/hvm_vcpu.h 
b/include/xen/interface/hvm/hvm_vcpu.h
new file mode 100644
index 000..32ca83e
--- /dev/null
+++ b/include/xen/interface/hvm/hvm_vcpu.h
@@ -0,0 +1,143 @@
+/*
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2015, Roger Pau Monne 
+ */
+
+#ifndef __XEN_PUBLIC_HVM_HVM_VCPU_H__
+#define __XEN_PUBLIC_HVM_HVM_VCPU_H__
+
+#include "../xen.h"
+
+struct vcpu_hvm_x86_32 {
+uint32_t eax;
+uint32_t ecx;
+uint32_t edx;
+uint32_t ebx;
+uint32_t esp;
+uint32_t ebp;
+uint32_t esi;
+uint32_t edi;
+uint32_t eip;
+uint32_t eflags;
+
+uint32_t cr0;
+uint32_t cr3;
+uint32_t cr4;
+
+uint32_t pad1;
+
+/*
+ * EFER should only be used to set the NXE bit (if required)
+ * when starting a vCPU in 32bit mode with paging enabled or
+ * to set the LME/LMA bits in order to start the vCPU in
+ * compatibility mode.
+ */
+uint64_t efer;
+
+uint32_t cs_base;
+uint32_t ds_base;
+uint32_t ss_base;
+uint32_t es_base;
+uint32_t tr_base;
+uint32_t cs_limit;
+uint32_t ds_limit;
+uint32_t ss_limit;
+uint32_t es_limit;
+uint32_t tr_limit;
+uint16_t cs_ar;
+uint16_t ds_ar;
+uint16_t ss_ar;
+uint16_t es_ar;
+uint16_t tr_ar;
+
+uint16_t pad2[3];
+};
+
+/*
+ * The layout of the _ar fields of the segment registers is the
+ * following:
+ *
+ * Bits   [0,3]: type (bits 40-43).
+ * Bit4: s(descriptor type, bit 44).
+ * Bit[5,6]: dpl  (descriptor privilege level, bits 45-46).
+ * Bit7: p(segment-present, bit 47).
+ * Bit8: avl  (available for system software, bit 52).
+ * Bit9: l(64-bit code segment, bit 53).
+ * Bit   10: db   (meaning depends on the segment, bit 54).
+ * Bit   11: g(granularity, bit 55)
+ * Bits [12,15]: unused, must be blank.
+ *
+ * A more complete description of the meaning of this fields can be
+ * obtained from the Intel SDM, Volume 3, section 3.4.5.
+ */
+
+struct vcpu_hvm_x86_64 {
+uint64_t rax;
+uint64_t rcx;
+uint64_t rdx;
+uint64_t rbx;
+uint64_t rsp;
+uint64_t rbp;
+uint64_t rsi;
+uint64_t rdi;
+uint64_t rip;
+uint64_t rflags;
+
+uint64_t cr0;
+uint64_t cr3;
+uint64_t cr4;
+uint64_t efer;
+
+/*
+ * Using VCPU_HVM_MODE_64B implies that the vCPU is launched
+ * directly in long mode, so the cached parts of the segment
+ * registers get set to match that environment.
+ *
+ * If the user wants to launch the vCPU in compatibility mode
+ * the 32-bit structure should be used instead.
+ */
+};
+
+struct vcpu_hvm_context {
+#define 

[Xen-devel] QEMU XenServer/XenProject Working group meeting 29th September 2016

[Jennifer Herbert]

QEMU XenServer/XenProject Working group meeting 29th September 2016
===

Attendees
-

David Vrabel
Jennifer Herbert
Ian Jackson
Andrew Cooper
Paul Durrant
Lars Kurth

QEMU depriv
===

DMOP


There has been agreement on list on the DMOP proposal.  The HVMCTL
patch series, which was proposed  should need only mechanical changes
to use it as a basis for DMOP.

Privcmd
---

The privcmd changes should be fairly trivial to implement. Libxc
would need changing, but this code is also in the HVMCTL patch
series.  This mean only thing needed for QEMU it to call the restrict
ioctl, to enable it.  If restrict ioctl missing, an error would be
returned.  QEMU would probably want an option to it, to indicate
de-priv is required.  Given this option, the QEMU would raise an error
if the restrict ioctl was not present.

In order to avoid accidents due to ABI instability, old DMOP numbers would
be retired when a DMOP in changed in an ABI-incompatible way - there is
no shortage of new DMOP numbers.

Eventchan
-

Eventchan has resections in 4.7, but the libxc parts need to be done.
This should not be much work.

XenStore


For the non-pv part of QEMU, XenStore is only used in two places.
There is the DM state, and the physmap mechanism.  Although there is a
vague plan for replacing the physmap mechanism, it is some way off.

The DM state key is used for knowing when the qemu process is running
etcetera, QMP would seem to be an option to replace it - however there
is no (nice) way to wait on a socket until it has been opened.  One
solution might be to use Xenstore to let you know the QMP sockets
where available, before QEMU drops privileges,  and then QMP could be
used to know QEMU is in the running state.

To avoid the need to use xs-restrict, you would need to both replace
physmap and rework qemu startup procedure. The use of xs-restrict would
be more expedient, and does not look to need that much work.

Discussion was had over how secure it would be to allow a guest access
to these Xenstore keys - it was concluded that a guest could mostly
only mess itself up.  If I guest attempted to prevent itself from being
migrated, the tool stack time it out, and could kill it.

There followed a discussion on the Xenbus protocol, and additions
needed.  The aim is to merely restrict the permission for the command,
to that of the guest who's domID you provide.  It was proposed that
it uses the header as is, with its  16 bytes, with the command
'one-time-restrict' , and then the payload would have two additional
field at the start.  These two field would correspond to the domid to
restrict as, and the real command. Transaction ID and tags would be
taken from the real header.

Although inter domain xs-restrict is not specifically needed for this
project, it is thought it might be a blocking items for upstream
acceptance.  It it thoughts these changes would not require that much
work to implement, and may be useful in use use cases. Only a few
changes to QEMU would be needed, and libxl should be able to track
QEMU versions.  Ian Jackson volunteered to look at this, with David
helping  with the kernel bits.  Ian won't have time to look at this
until after Xen 4.8 is released.

There discussion about what may fail once privileges are taken away,
which would include CDs and PCI pass though.  It is thought the full
list can only be known by trying.  Not everything needs to work for
acceptance upstream, such as PCI pass though.   If such an
incompatible feature is needed, restrictions can be turned off.  These
problems can be fixed in a later phase, with CDs likely being at teh
top of the list.


Action items


Hypervisor bits really needed first, but can't be done until 4.8 has
been.

Ian to look at the Xenstore items David is to look at the kernel
items.  Paul is to audit the HVMops, checking parameters etc;

It is too late to get this in 4.8, but it is desired to get this in
early into 4.9 so that there can be a period of stabilisation.  With
the release of 4.8 imminent, little work will happen until after that.
However Paul, David and Ian are asked to have a think about their
respective areas, and have a plan for when they can be done.  They are
welcome to start tackling them if they have time.



disaggregation
=

A disaggregation proposal which had previously been posted to a QEMU
forum was discussed.  It was not previously accepted by all. The big
question was how to separate the device models from the machine, with
a particular point of contention being around PIIX and the idea of
starting a QEMU instance without one.  The general desire from us is
we want to have a specific device emulated and nothing else.  It is
suggested you would have a software interface between each device that
looked a software version of PCI.  The PIIX device could be attached to
CPU this pseudo PCI interface.  This would fit in well 

Re: [Xen-devel] [PATCH v2 2/2] x86/Intel: virtualize support for cpuid faulting

[Andrew Cooper]

On 14/10/16 18:05, Kyle Huey wrote:
> On Fri, Oct 14, 2016 at 7:46 AM, Andrew Cooper
>  wrote:
>> On 14/10/16 13:04, Jan Beulich wrote:
>> On 13.10.16 at 23:09,  wrote:
 --- a/xen/arch/x86/traps.c
 +++ b/xen/arch/x86/traps.c
 @@ -1315,16 +1315,20 @@ static int emulate_forced_invalid_op(struct 
 cpu_user_regs *regs)
  /* We only emulate CPUID. */
  if ( ( rc = copy_from_user(instr, (char *)eip, sizeof(instr))) != 0 )
  {
  propagate_page_fault(eip + sizeof(instr) - rc, 0);
  return EXCRET_fault_fixed;
  }
  if ( memcmp(instr, "\xf\xa2", sizeof(instr)) )
  return 0;
 +/* Let the guest have this one */
 +if ( current->arch.cpuid_fault && !guest_kernel_mode(current, regs) )
 +return 0;
 +
>>> I think another blank line ahead of the addition would be nice. I also
>>> think the comment should include the conditional aspect of what is
>>> says (same on the second instance below).
>>>
>>> And then there is the question of state here: There's no rIP update
>>> ahead of here, yet I'm uncertain whether we can expect the guest
>>> kernel to handle both bare and Xen-prefixed CPUID instructions.
>>> Andrew, what do you think?
>> The #GP fault handed back to the guest kernel should point at the cpuid
>> instruction, not the ud2 of the FEP.
>>
>> In reality, the only real use of this path from userspace is the
>> `xen-detect` utility.  Regular userspace shouldn't know or care.
>> Therefore, I am not concerned about the fact that it causes an implicit
>> change of information source.
>>
>>
>> I have taken the liberty of writing a CPUID Faulting XTF test, which
>> should cover all the intended guest-side behaviour (although I did code
>> it without a hypervisor side implementation, so I don't guarantee it is
>> bug-free).
>>
>> The test can be found
>> http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen-test-framework.git;a=shortlog;h=refs/heads/cpuid-faulting
>> and general docs on using XTF can be found
>> http://xenbits.xen.org/docs/xtf/index.html  After cloning and building,
>> use "./xtf-runner cpuid-faulting" to run the test in all types of VM.
>>
>> In particular, it will catch this specific issue when the exception
>> frame from an emulated cpuid doesn't point at the cpuid instruction.
>>
>> Would you mind trying out this test?  Ideally, we would look to putting
>> it (or a bugfixed version of it) into our CI system at the same time as
>> the hypervisor support gets accepted.
> Thanks for the test.  It almost works out of the box (will post a diff
> later).

:) I am now curious as to which bit I missed.

> It also found another bug: my patches currently advance the
> ip when cpuid faults in an HVM guest.  Will fix that too.

Ah of course.  Looks like you need to return 1 avoid the eip update, but
I have to admit that this is quite a poor interface.

In some copious free time, I will see about updating it to use the
X86EMUL_* interface.


On a slightly separate note, as you have just been a successful
guinea-pig for XTF, how did you find it?  It is a very new (still
somewhat in development) system but the project is looking to try and
improve regression testing in this way, especially for new features.  I
welcome any feedback.

~Andrew

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

Re: [Xen-devel] [PATCH for-4.8 0/3] libacpi fixes

[Andrew Cooper]

On 14/10/16 18:02, Wei Liu wrote:
> Wei Liu (3):
>   libacpi: fix arm64 build
>   libacpi: require ACPI_BUILD_DIR to be set
>   libacpi: add back the "G" in "GNU" in licence header

All Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 0/3 for 4.8] docs: feature documents for the schedulers

[Wei Liu]

On Fri, Oct 14, 2016 at 04:03:18PM +0100, Andrew Cooper wrote:
> On 14/10/16 14:24, Wei Liu wrote:
> > On Fri, Oct 14, 2016 at 10:59:55AM +0100, Dario Faggioli wrote:
> >> Hi,
> >>
> >> Here's v2.
> >>
> >> The differences are:
> >>  - review comments taken into account.
> >>  - I'm *NOT* claiming 'SuppOrted' status for Credit2. I'll do that in a
> >>separate patch.
> >>
> >> v1 is here:
> >>
> >>  https://lists.xen.org/archives/html/xen-devel/2016-10/msg00857.html
> >>
> >> And there is a git branch for this new version:
> >>
> >>  git://xenbits.xen.org/people/dariof/xen.git  rel/sched/feature-docs
> >>  
> >> http://xenbits.xen.org/gitweb/?p=people/dariof/xen.git;a=shortlog;h=refs/heads/rel/sched/feature-docs
> >>
> >> Thanks and Regards,
> >> Dario
> >> ---
> >> Dario Faggioli (3):
> >>   docs: Credit1 feature document.
> >>   docs: Credit2 feature document.
> >>   docs: RTDS feature document.
> >>
> > All three:
> >
> > Acked-by: Wei Liu 
> 
> All LGTM as well.
> 

Series pushed.

> ~Andrew

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

Re: [Xen-devel] [PATCH v2 2/2] x86/Intel: virtualize support for cpuid faulting

[Kyle Huey]

On Fri, Oct 14, 2016 at 7:46 AM, Andrew Cooper
 wrote:
> On 14/10/16 13:04, Jan Beulich wrote:
> On 13.10.16 at 23:09,  wrote:
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -1315,16 +1315,20 @@ static int emulate_forced_invalid_op(struct 
>>> cpu_user_regs *regs)
>>>  /* We only emulate CPUID. */
>>>  if ( ( rc = copy_from_user(instr, (char *)eip, sizeof(instr))) != 0 )
>>>  {
>>>  propagate_page_fault(eip + sizeof(instr) - rc, 0);
>>>  return EXCRET_fault_fixed;
>>>  }
>>>  if ( memcmp(instr, "\xf\xa2", sizeof(instr)) )
>>>  return 0;
>>> +/* Let the guest have this one */
>>> +if ( current->arch.cpuid_fault && !guest_kernel_mode(current, regs) )
>>> +return 0;
>>> +
>> I think another blank line ahead of the addition would be nice. I also
>> think the comment should include the conditional aspect of what is
>> says (same on the second instance below).
>>
>> And then there is the question of state here: There's no rIP update
>> ahead of here, yet I'm uncertain whether we can expect the guest
>> kernel to handle both bare and Xen-prefixed CPUID instructions.
>> Andrew, what do you think?
>
> The #GP fault handed back to the guest kernel should point at the cpuid
> instruction, not the ud2 of the FEP.
>
> In reality, the only real use of this path from userspace is the
> `xen-detect` utility.  Regular userspace shouldn't know or care.
> Therefore, I am not concerned about the fact that it causes an implicit
> change of information source.
>
>
> I have taken the liberty of writing a CPUID Faulting XTF test, which
> should cover all the intended guest-side behaviour (although I did code
> it without a hypervisor side implementation, so I don't guarantee it is
> bug-free).
>
> The test can be found
> http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen-test-framework.git;a=shortlog;h=refs/heads/cpuid-faulting
> and general docs on using XTF can be found
> http://xenbits.xen.org/docs/xtf/index.html  After cloning and building,
> use "./xtf-runner cpuid-faulting" to run the test in all types of VM.
>
> In particular, it will catch this specific issue when the exception
> frame from an emulated cpuid doesn't point at the cpuid instruction.
>
> Would you mind trying out this test?  Ideally, we would look to putting
> it (or a bugfixed version of it) into our CI system at the same time as
> the hypervisor support gets accepted.

Thanks for the test.  It almost works out of the box (will post a diff
later).  It also found another bug: my patches currently advance the
ip when cpuid faults in an HVM guest.  Will fix that too.

- Kyle

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

[Xen-devel] [PATCH for-4.8 0/3] libacpi fixes

[Wei Liu]

Wei Liu (3):
  libacpi: fix arm64 build
  libacpi: require ACPI_BUILD_DIR to be set
  libacpi: add back the "G" in "GNU" in licence header

 tools/libacpi/Makefile | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH for-4.8 3/3] libacpi: add back the "G" in "GNU" in licence header

[Wei Liu]

Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
---
 tools/libacpi/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index c1f0af8..18a5cd4 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -9,7 +9,7 @@
 # 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
-# NU Lesser General Public License for more details.
+# GNU Lesser General Public License for more details.
 #
 
 XEN_ROOT = $(CURDIR)/../..
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.8 2/3] libacpi: require ACPI_BUILD_DIR to be set

[Wei Liu]

It's better to have a explicit error than a build failure returned by
gcc.

Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
---
 tools/libacpi/Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index 24eb0c2..c1f0af8 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -15,6 +15,10 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+ifeq ($(ACPI_BUILD_DIR),)
+$(error ACPI_BUILD_DIR not set)
+endif
+
 MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
 
 C_SRC-$(GPL) = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.8 1/3] libacpi: fix arm64 build

[Wei Liu]

The arm64 build for libacpi was broken due to two reasons:

1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c.
2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which
   made CONFIG_ARM disappear.

Fix those by:

1. Correctly generate full path for dsdt_anaycpu_arm.c.
2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely
   on settings in firmware/Rules.mk.

While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more
accurate.

Reported-by: Julien Grall 
Signed-off-by: Wei Liu 
---
Cc: Julien Grall 
Cc: Wei Chen 
Cc: Steve Capper 
Cc: Jan Beulich 
Cc: Boris Ostrovsky 
Cc: Shannon Zhao 
Cc: Stefano Stebellini 

Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant
on arm64.

Would appreciate any build test report from ARM people.
---
 tools/libacpi/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index db7a3a9..24eb0c2 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -13,12 +13,12 @@
 #
 
 XEN_ROOT = $(CURDIR)/../..
-include $(XEN_ROOT)/tools/firmware/Rules.mk
+include $(XEN_ROOT)/tools/Rules.mk
 
 MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
 
 C_SRC-$(GPL) = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
-C_SRC-$(CONFIG_ARM) = $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c
+C_SRC-$(CONFIG_ARM_64) = dsdt_anycpu_arm.c
 C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_pvh.c $(C_SRC-y))
 H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
ssdt_tpm.h)
 
-- 
2.1.4


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  a709a3a646302e95ba42beac89264f6cdacd0c64
baseline version:
 xen  ed00f1761689ac7b9c074e9084c81e47c25d460c

Last test of basis   101445  2016-10-14 12:02:56 Z0 days
Testing same since   101448  2016-10-14 14:02:45 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ad9448408a5d2863db4aa2cb5d1f0d4a27689528
baseline version:
 ovmf a2d59ef2912079fe0631f7ee7661dad2ddb472c8

Last test of basis   101435  2016-10-14 03:15:52 Z0 days
Testing same since   101442  2016-10-14 10:46:25 Z0 days1 attempts


People who touched revisions under test:
  Giri P Mudusuru 

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

Re: [Xen-devel] [PATCH 3/3] x86/svm: Drop adjustment of X86_FEATURE_APIC

[Boris Ostrovsky]

On 10/14/2016 12:02 PM, Andrew Cooper wrote:
> The common hvm_cpuid() code already does this.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Boris Ostrovsky 
> CC: Suravee Suthikulpanit 

Reviewed-by: Boris Ostrovsky 


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

[Xen-devel] [PATCH] x86/emul: Reorder the user segments in x86_segment to match SReg3 encoding

[Andrew Cooper]

This avoids needing a translation table between hardware ordering and Xen's
ordering.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 35 +++---
 xen/arch/x86/x86_emulate/x86_emulate.h |  4 ++--
 2 files changed, 17 insertions(+), 22 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 38147c5..32c45c4 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1557,22 +1557,6 @@ decode_register(
 return p;
 }
 
-#define decode_segment_failed x86_seg_tr
-static enum x86_segment
-decode_segment(uint8_t modrm_reg)
-{
-switch ( modrm_reg )
-{
-case 0: return x86_seg_es;
-case 1: return x86_seg_cs;
-case 2: return x86_seg_ss;
-case 3: return x86_seg_ds;
-case 4: return x86_seg_fs;
-case 5: return x86_seg_gs;
-}
-return decode_segment_failed;
-}
-
 static bool is_aligned(enum x86_segment seg, unsigned long offs,
unsigned int size, struct x86_emulate_ctxt *ctxt,
const struct x86_emulate_ops *ops)
@@ -2980,8 +2964,8 @@ x86_emulate(
 break;
 
 case 0x8c: /* mov Sreg,r/m */
-seg = decode_segment(modrm_reg);
-generate_exception_if(seg == decode_segment_failed, EXC_UD, -1);
+seg = modrm_reg;
+generate_exception_if(!is_x86_user_segment(seg), EXC_UD, -1);
 store_selector:
 fail_if(ops->read_segment == NULL);
 if ( (rc = ops->read_segment(seg, , ctxt)) != 0 )
@@ -2992,8 +2976,8 @@ x86_emulate(
 break;
 
 case 0x8e: /* mov r/m,Sreg */
-seg = decode_segment(modrm_reg);
-generate_exception_if(seg == decode_segment_failed, EXC_UD, -1);
+seg = modrm_reg;
+generate_exception_if(!is_x86_user_segment(seg), EXC_UD, -1);
 generate_exception_if(seg == x86_seg_cs, EXC_UD, -1);
 if ( (rc = load_seg(seg, src.val, 0, NULL, ctxt, ops)) != 0 )
 goto done;
@@ -5520,4 +5504,15 @@ x86_insn_length(const struct x86_emulate_state *state,
 return state->eip - ctxt->regs->eip;
 }
 
+static void __init __maybe_unused build_assertions(void)
+{
+/* Check the values against SReg3 encoding in opcode/ModRM bytes. */
+BUILD_BUG_ON(x86_seg_es != 0);
+BUILD_BUG_ON(x86_seg_cs != 1);
+BUILD_BUG_ON(x86_seg_ss != 2);
+BUILD_BUG_ON(x86_seg_ds != 3);
+BUILD_BUG_ON(x86_seg_fs != 4);
+BUILD_BUG_ON(x86_seg_gs != 5);
+}
+
 #endif
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h 
b/xen/arch/x86/x86_emulate/x86_emulate.h
index 641711e..00ceade 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -29,11 +29,11 @@ struct x86_emulate_ctxt;
 
 /* Comprehensive enumeration of x86 segment registers. */
 enum x86_segment {
-/* General purpose. */
+/* General purpose.  Matches the SReg3 encoding in opcode/ModRM bytes. */
+x86_seg_es,
 x86_seg_cs,
 x86_seg_ss,
 x86_seg_ds,
-x86_seg_es,
 x86_seg_fs,
 x86_seg_gs,
 /* System. */
-- 
2.1.4


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

[Xen-devel] [PATCH 1/3] xen/x86: Fixup misc stale issues

[Andrew Cooper]

 * Dom0 does now have an arch_config passed.
 * hypercall() and smp_alloc_memory() no longer exist.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/setup.c| 6 +-
 xen/include/asm-x86/processor.h | 2 --
 xen/include/asm-x86/smp.h   | 2 --
 3 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 8ae897a..41f9a5b 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1493,11 +1493,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 if ( opt_dom0pvh )
 domcr_flags |= DOMCRF_pvh | DOMCRF_hap;
 
-/*
- * Create initial domain 0.
- * x86 doesn't support arch-configuration. So it's fine to pass
- * NULL.
- */
+/* Create initial domain 0. */
 dom0 = domain_create(0, domcr_flags, 0, );
 if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
 panic("Error creating domain 0");
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index 3e6e355..6378afd 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -612,8 +612,6 @@ struct stubs {
 DECLARE_PER_CPU(struct stubs, stubs);
 unsigned long alloc_stub_page(unsigned int cpu, unsigned long *mfn);
 
-extern int hypercall(void);
-
 int cpuid_hypervisor_leaves( uint32_t idx, uint32_t sub_idx,
   uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx);
 int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val);
diff --git a/xen/include/asm-x86/smp.h b/xen/include/asm-x86/smp.h
index 33c2c32..e3782bb 100644
--- a/xen/include/asm-x86/smp.h
+++ b/xen/include/asm-x86/smp.h
@@ -23,8 +23,6 @@
 /*
  * Private routines/data
  */
- 
-extern void smp_alloc_memory(void);
 DECLARE_PER_CPU(cpumask_var_t, cpu_sibling_mask);
 DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
 
-- 
2.1.4


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

[Xen-devel] [PATCH 2/3] x86/mm: Use IS_ALIGNED() rather than open coding it

[Andrew Cooper]

Drop repeated identical BUILD_BUG_ON()'s

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: George Dunlap 
---
 xen/arch/x86/x86_64/mm.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index b8b6b70..0083beb 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -540,7 +540,7 @@ void __init paging_init(void)
  sizeof(*machine_to_phys_mapping));
 for ( i = 0; i < (mpt_size >> L2_PAGETABLE_SHIFT); i++ )
 {
-BUILD_BUG_ON(RO_MPT_VIRT_START & ((1UL << L3_PAGETABLE_SHIFT) - 1));
+BUILD_BUG_ON(!IS_ALIGNED(RO_MPT_VIRT_START, L3_PAGETABLE_SHIFT));
 va = RO_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT);
 memflags = MEMF_node(phys_to_nid(i <<
 (L2_PAGETABLE_SHIFT - 3 + PAGE_SHIFT)));
@@ -776,8 +776,8 @@ static int setup_frametable_chunk(void *start, void *end,
 unsigned long mfn;
 int err;
 
-ASSERT(!(s & ((1 << L2_PAGETABLE_SHIFT) - 1)));
-ASSERT(!(e & ((1 << L2_PAGETABLE_SHIFT) - 1)));
+ASSERT(IS_ALIGNED(s, L2_PAGETABLE_SHIFT));
+ASSERT(IS_ALIGNED(e, L2_PAGETABLE_SHIFT));
 
 for ( ; s < e; s += (1UL << L2_PAGETABLE_SHIFT))
 {
@@ -838,8 +838,8 @@ void __init subarch_init_memory(void)
 l3_pgentry_t l3e;
 l2_pgentry_t l2e;
 
-BUILD_BUG_ON(RDWR_MPT_VIRT_START & ((1UL << L3_PAGETABLE_SHIFT) - 1));
-BUILD_BUG_ON(RDWR_MPT_VIRT_END   & ((1UL << L3_PAGETABLE_SHIFT) - 1));
+BUILD_BUG_ON(!IS_ALIGNED(RDWR_MPT_VIRT_START, L3_PAGETABLE_SHIFT));
+BUILD_BUG_ON(!IS_ALIGNED(RDWR_MPT_VIRT_END,   L3_PAGETABLE_SHIFT));
 /* M2P table is mappable read-only by privileged domains. */
 for ( v  = RDWR_MPT_VIRT_START;
   v != RDWR_MPT_VIRT_END;
@@ -934,8 +934,6 @@ long subarch_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( copy_from_guest(, arg, 1) )
 return -EFAULT;
 
-BUILD_BUG_ON(RDWR_MPT_VIRT_START & ((1UL << L3_PAGETABLE_SHIFT) - 1));
-BUILD_BUG_ON(RDWR_MPT_VIRT_END   & ((1UL << L3_PAGETABLE_SHIFT) - 1));
 for ( i = 0, v = RDWR_MPT_VIRT_START, last_mfn = 0;
   (i != xmml.max_extents) &&
   (v < (unsigned long)(machine_to_phys_mapping + max_page));
-- 
2.1.4


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

[Xen-devel] [PATCH 3/3] x86/svm: Drop adjustment of X86_FEATURE_APIC

[Andrew Cooper]

The common hvm_cpuid() code already does this.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/svm/svm.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 0ed3e73..16427f6 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1572,11 +1572,6 @@ static void svm_cpuid_intercept(
 hvm_cpuid(input, eax, ebx, ecx, edx);
 
 switch (input) {
-case 0x8001:
-/* Fix up VLAPIC details. */
-if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
-__clear_bit(X86_FEATURE_APIC & 31, edx);
-break;
 case 0x801c: 
 {
 /* LWP capability CPUID */
-- 
2.1.4


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

[Xen-devel] [PATCH] RFC x86/hvm: Don't truncate the hvm hypercall index before range checking it

[Andrew Cooper]

When the compat hypercall ABI was added for HVM guests (i.e. supporting 32bit
operating systems making hypercalls against a 64bit Xen), an ABI breakage was
introduced for non-compat guests, as the 64bit hypercall index became
truncated to 32 bits.

This has been the case for a very long time, but is not very obvious from the
code, and definitely counterintuitive, seeing as all other 64bit parameters
are passed without truncation.

However, the only supported method of making hypercalls is to call into the
hypercall page, which in practice means that only hypercall index up to 63 are
supported.

Therefore, take the opportunity to fix the ABI before it becomes impossible to
fix.

While tweaking this area, fix one piece of trailing whitespace.

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

RFC because this might manifest as an ABI change for guests making hypercalls
via an unsupported mechanism.  However, I feel that fixing the bug is the less
bad option.
---
 xen/arch/x86/hvm/hvm.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 3c90ecd..563f029 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4265,11 +4265,11 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
 struct domain *currd = curr->domain;
 struct segment_register sreg;
 int mode = hvm_guest_x86_mode(curr);
-uint32_t eax = regs->eax;
+unsigned long eax;
 
 switch ( mode )
 {
-case 8:
+case 8:
 case 4:
 case 2:
 hvm_get_segment_register(curr, x86_seg_ss, );
@@ -4283,6 +4283,8 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
 break;
 }
 
+eax = (mode == 8) ? regs->eax : regs->_eax;
+
 if ( (eax & 0x8000) && is_viridian_domain(currd) )
 return viridian_hypercall(regs);
 
@@ -4307,7 +4309,7 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
 unsigned long r8 = regs->r8;
 unsigned long r9 = regs->r9;
 
-HVM_DBG_LOG(DBG_LEVEL_HCALL, "hcall%u(%lx, %lx, %lx, %lx, %lx, %lx)",
+HVM_DBG_LOG(DBG_LEVEL_HCALL, "hcall%lu(%lx, %lx, %lx, %lx, %lx, %lx)",
 eax, rdi, rsi, rdx, r10, r8, r9);
 
 #ifndef NDEBUG
@@ -4354,7 +4356,7 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
 unsigned int edi = regs->_edi;
 unsigned int ebp = regs->_ebp;
 
-HVM_DBG_LOG(DBG_LEVEL_HCALL, "hcall%u(%x, %x, %x, %x, %x, %x)", eax,
+HVM_DBG_LOG(DBG_LEVEL_HCALL, "hcall%lu(%x, %x, %x, %x, %x, %x)", eax,
 ebx, ecx, edx, esi, edi, ebp);
 
 #ifndef NDEBUG
@@ -4390,7 +4392,7 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
 #endif
 }
 
-HVM_DBG_LOG(DBG_LEVEL_HCALL, "hcall%u -> %lx",
+HVM_DBG_LOG(DBG_LEVEL_HCALL, "hcall%lu -> %lx",
 eax, (unsigned long)regs->eax);
 
 if ( curr->arch.hvm_vcpu.hcall_preempted )
-- 
2.1.4


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

Re: [Xen-devel] Debugging your environment...

[tevin.k.mallory]

Hello Jesus,

I’ll get started on debugging my environment right away. Thanks a lot for your 
time. I have attached the logs of our IRC meeting today…I’ll email you with my 
debugging results soon. 



Sent from Mail for Windows 10

From: Jesus M. Gonzalez-Barahona
Sent: Friday, October 14, 2016 11:39 AM
To: tevin.k.mall...@gmail.com
Subject: Debugging your environment...

Hi, Tevin,

After our conversation via irc, please do the following:

* Let's assume you have the "C:\Users\Tevin\Desktop\project" directory 
created already, with no "perceval" subdirectory in it.

* Run "venv C:\Users\Tevin\Desktop\project\perceval"

Now you should have a "C:\Users\Tevin\Desktop\project\perceval"
directory. Change to it:

* "cd C:\Users\Tevin\Desktop\project\perceval"

* Get a listing of its contents, and in particular of its bin
directory:

"dir ."
"dir bin"

* Now, activate the environment.

* Once the environment is activated, run

"pip install perceval"

And then again

"dir ."
"dir bin"

* and let's get some environment variables:

"echo %PATH%"
"echo %PYTHONPATH"

* Then, try to run perceval:

"perceval"

* and python:

"python --version"

(of course, after activation, everything from the same console).

Plese, copy and paste in a message all what you typed and the answer by
the system. And let's see if we can progress from that...

Saludos,

Jesus.



-- 
http://twitter.com/jgbarah  http://gsyc.es/~jgb


Session Start: Mon Oct 03 17:36:20 2016
Session Ident: #metrics-grimoire
03[17:36] * Now talking in #metrics-grimoire
02[17:40] * gayathri___ (uid69915@gateway/web/irccloud.com/x-zbftnjrevqetnmfh) 
Quit (Quit: Connection closed for inactivity)
03[19:48] * _acs_ (~a...@114.red-79-153-216.dynamicip.rima-tde.net) has joined 
#metrics-grimoire
02[20:00] * _acs_ (~a...@114.red-79-153-216.dynamicip.rima-tde.net) Quit 
(Quit: Leaving.)
02[20:11] * jgbarah (~j...@149.red-79-151-31.dynamicip.rima-tde.net) Quit 
(Ping timeout: 248 seconds)
02[21:56] * Disconnected
Session Close: Mon Oct 03 21:56:33 2016

Session Start: Mon Oct 03 21:56:33 2016
Session Ident: #metrics-grimoire
02[21:56] * Attempting to rejoin channel #metrics-grimoire
03[21:56] * Rejoined channel #metrics-grimoire
02[23:03] * Disconnected
Session Close: Mon Oct 03 23:03:21 2016

Session Start: Fri Oct 07 10:31:01 2016
Session Ident: #metrics-grimoire
03[10:31] * Now talking in #metrics-grimoire
03[10:31] * _acs_ (~acs@150.214.223.90) has joined #metrics-grimoire
01[10:32]  Hello Everyone, I am Tevin Mallory. How are you all doing 
today?
[10:33]  Hi Tevin!
[10:34]  tmallory: How do you do? Is the hurricane being a problem?
[10:35]  tmallory: Are you there?
01[10:35]  I am doing well so far, the hurrican hasn't hit my area 
yet. 
[10:36]  ok. I hope it doesn't become a big problem for you...
[10:36]  Anyway, could you have a look a the microtask description?
01[10:37]  Thank you. I hope so as well. I have the microtask 
description in fornt me. 
01[10:38]  I started on it yesterday and have been installing the 
requirements for perceval
[10:38]  ok. I have to leave in 10 min, but will be back in 30, so 
let's start, and if needed and you can, we can follow up later
[10:38]  Good. Any trouuble with Perceval?
01[10:39]  Okay
01[10:40]  I haven't started using Perceval yet, but i shouldn't 
have any trouble with it.
01[10:41]  I just started learning python a little while ago, so i 
spent a great amount of time getting a good grasp 
[10:41]  OK. The other stuff that could block you is installing 
ElasticSearch and maybe Kibana. I would start with ElasticSearch, which is all 
you'll need for onow
01[10:42]  Ok i'll work on installing that next
[10:42]  ok, let me know if you need some help for Python. I can point 
you to courses and material if you happen to need those
[10:42]  For elasticSearch, you'll mainly need a working Java vm on 
your computer, not much more than that.
01[10:43]  Okay I'am taking note of that
[10:43]  Can I help you in some way now, or you're on your way?
01[10:44]  I am pretty much on my way. 
01[10:45]  no major problems
[10:45]  Perfect. Then, maybe we can just schedule a meeting for next 
week
[10:45]  Meanwhile you can ping me here, or via email
01[10:45]  Ok. perfect
[10:46]  For the meeting here, we can consider tentatively next 
Friday, but 45 min. later
[10:46]  Is that ok with you?
01[10:46]  yes it is great
[10:46]  I guess that would be 17:15 CEST, 11:15am EST
[10:47]  Good!
[10:47]  There is a slight chance that I cannot make that time, in 
that case I will suggest meeting a bit later
[10:47]  Anthing else from your side?
01[10:48]  No I am all green lights on my side, if anything comes up 
I'll let you know
01[10:48]  Thank you for your time.
[10:49]  Perfect! It was great meeting you. See you next week! If you 
don't mind, please send Lars and me the log for his meeting via email
01[10:50]  No problem, I'll send it right away.
01[10:50]  It was great meeting with you as 

Re: [Xen-devel] [RFC PATCH 9/9] x86/SVM: Hook up miscellaneous AVIC functions

[Konrad Rzeszutek Wilk]

On Mon, Sep 19, 2016 at 12:52:48AM -0500, Suravee Suthikulpanit wrote:
> Hook up virtual_intr_delivery_enabled and deliver_posted_intr functions
> when AVIC is enabled.
> 
> Signed-off-by: Suravee Suthikulpanit 
> ---
>  xen/arch/x86/hvm/svm/svm.c | 10 ++
>  xen/include/asm-x86/hvm/svm/avic.h |  5 +
>  2 files changed, 15 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index caf9984..a9c09a7 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1495,6 +1495,16 @@ const struct hvm_function_table * __init 
> start_svm(void)
>  svm_function_table.hap_capabilities = HVM_HAP_SUPERPAGE_2MB |
>  ((cpuid_edx(0x8001) & 0x0400) ? HVM_HAP_SUPERPAGE_1GB : 0);
>  
> +if ( !cpu_has_svm_avic )
> +svm_avic = 0;
> +
> +if ( svm_avic )
> +{
> +svm_function_table.deliver_posted_intr  = 
> svm_avic_deliver_posted_intr,
> +svm_function_table.virtual_intr_delivery_enabled = svm_avic_enabled,
> +printk("SVM: AVIC enabled\n");

Is this needed? Doesn't the P(..) macro already give you that
information?

Or you could remove the P(..) call for AVIC and make this a bit more
custom where you print something like "- SVM AVIC (detected and %s)'
where %s is either disabled or enabled ?


> +}
> +
>  return _function_table;
>  }
>  
> diff --git a/xen/include/asm-x86/hvm/svm/avic.h 
> b/xen/include/asm-x86/hvm/svm/avic.h
> index e1eb66c..8411854 100644
> --- a/xen/include/asm-x86/hvm/svm/avic.h
> +++ b/xen/include/asm-x86/hvm/svm/avic.h
> @@ -41,4 +41,9 @@ void svm_avic_vmexit_do_incomp_ipi(struct cpu_user_regs 
> *regs);
>  void svm_avic_vmexit_do_noaccel(struct cpu_user_regs *regs);
>  
>  void svm_avic_deliver_posted_intr(struct vcpu *v, u8 vector);
> +
> +static inline int svm_avic_enabled(void)
> +{
> +return svm_avic;
> +}
>  #endif /* _SVM_AVIC_H_ */
> -- 
> 1.9.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [RFC PATCH 8/9] x86/SVM: Add interrupt management code via AVIC

[Konrad Rzeszutek Wilk]

On Mon, Sep 19, 2016 at 12:52:47AM -0500, Suravee Suthikulpanit wrote:
> Enabling AVIC implicitly disables the V_IRQ, V_INTR_PRIO, V_IGN_TPR,
> and V_INTR_VECTOR fields in the VMCB Control Word. Therefore, this patch
> introduces new interrupt injection code via AVIC backing page.
> 
> Also, the AVIC hardware automatically synchronizes TPR and CR8/vTPR, when
> values are updated. Therefore, xen does not need to handle this when enable
> AVIC.

s/this when enable AVIC/when AVIC is enabled/

> 
> Signed-off-by: Suravee Suthikulpanit 
> ---
>  xen/arch/x86/hvm/svm/avic.c| 31 +++
>  xen/arch/x86/hvm/svm/intr.c|  4 
>  xen/arch/x86/hvm/svm/svm.c | 12 ++--
>  xen/arch/x86/hvm/svm/vmcb.c|  6 +-
>  xen/include/asm-x86/hvm/svm/avic.h |  1 +
>  5 files changed, 51 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
> index cd8a9d4..4144223 100644
> --- a/xen/arch/x86/hvm/svm/avic.c
> +++ b/xen/arch/x86/hvm/svm/avic.c
> @@ -576,3 +576,34 @@ void svm_avic_vmexit_do_noaccel(struct cpu_user_regs 
> *regs)
>  
>  return;
>  }
> +
> +/***

Twinkle twinkle little stars, there are too many of you..

> + * AVIC INTR INJECTION

Also the comment could be deleted as it explains pretty well the flow.
> + */
> +void svm_avic_deliver_posted_intr(struct vcpu *v, u8 vec)
> +{
> +struct vlapic *vlapic = vcpu_vlapic(v);
> +
> +/* Fallback to use non-AVIC if vcpu is not enabled with AVIC */

Please add an period at the end.

> +if ( !svm_avic_vcpu_enabled(v) )
> +{
> +if ( !vlapic_test_and_set_vector(vec, >regs->data[APIC_IRR]) 
> )
> +vcpu_kick(v);
> +return;
> +}
> +
> +if ( !(guest_cpu_user_regs()->eflags & X86_EFLAGS_IF) )
> +return;
> +
> +if ( vlapic_test_and_set_vector(vec, >regs->data[APIC_IRR]) )
> +return;
> +
> +/*
> + * If vcpu is running on another cpu, hit the doorbell to signal
> + * it to process interrupt. Otherwise, kick it.
> + */
> +if ( v->is_running && (v != current) )
> +wrmsrl(AVIC_DOORBELL, cpu_data[v->processor].apicid);

What is the consequence if say the destination CPU ends up switching to
a different guest - and the doorball hits at that point?

If the different guest is not AVIC enabled .. what then? The CPU ignores
it? Say the CPU is running at that point without VMCB (it is running
dom0), or with an HVM guest without AVIC? Will we get AVIC IPI delievery
not completed #VMEXIT on the destination CPU? (or on this one?)

And what if this new guest is AVIC enabled and there are no IRR in the
backing page? [I presume nothing will happen]

> +else
> +vcpu_kick(v);
> +}

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

Re: [Xen-devel] [RFC PATCH 7/9] x86/SVM: Add vcpu scheduling support for AVIC

[Konrad Rzeszutek Wilk]

On Mon, Sep 19, 2016 at 12:52:46AM -0500, Suravee Suthikulpanit wrote:
> Add hooks to manage AVIC data structure during vcpu scheduling.
> 
> Signed-off-by: Suravee Suthikulpanit 
> ---
>  xen/arch/x86/hvm/svm/avic.c | 82 
> +
>  xen/arch/x86/hvm/svm/svm.c  | 10 ++
>  2 files changed, 92 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
> index 90df181..cd8a9d4 100644
> --- a/xen/arch/x86/hvm/svm/avic.c
> +++ b/xen/arch/x86/hvm/svm/avic.c
> @@ -45,6 +45,83 @@ avic_get_phy_ait_entry(struct vcpu *v, int index)
>  }
>  
>  /***
> + * AVIC VCPU SCHEDULING
> + */
> +static void avic_vcpu_load(struct vcpu *v)
> +{
> +struct arch_svm_struct *s = >arch.hvm_svm;
> +int h_phy_apic_id;
> +struct svm_avic_phy_ait_entry entry;
> +
> +if ( !svm_avic || !s->avic_phy_id_cache )
> +return;
> +
> +if ( test_bit(_VPF_blocked, >pause_flags) )
> +return;
> +
> +/* Note: APIC ID = 0xff is used for broadcast.

Please put the Note: .. on a newline.

So you have it like so:

/*
 * Note: ...


> + *   APIC ID > 0xff is reserved.
> + */
> +h_phy_apic_id = cpu_data[v->processor].apicid;
> +if ( h_phy_apic_id >= AVIC_PHY_APIC_ID_MAX )

What does that mean to the guest? I presume it means it will always
get an VMEXIT b/c the is_running is not set?

Meaning whatever guest ends up unhappily on an physical CPU with
the APIC ID of 255 is screwed :-(?

Perhaps at bootup time when SVM AVIC is initialized we have a check
for APIC ID of 255 and put a blurb saying:

"You have CPU%u with APIC ID 255. That value for SVM AVIC is reserved
which has the unfortunate consequence that AVIC is disabled on CPU%u."

So that the admin can perhaps schedule/pin dom0 on that CPU?


> +return;
> +
> +entry = *(s->avic_phy_id_cache);

Perhaps instead of '_cache' say '_last' ?
Like 'avic_last_phy_id'?

> +smp_rmb();
> +entry.host_phy_apic_id = h_phy_apic_id;
> +entry.is_running = 1;
> +*(s->avic_phy_id_cache) = entry;
> +smp_wmb();
> +}
> +
> +static void avic_vcpu_put(struct vcpu *v)
> +{
> +struct arch_svm_struct *s = >arch.hvm_svm;
> +struct svm_avic_phy_ait_entry entry;
> +
> +if ( !svm_avic || !s->avic_phy_id_cache )
> +return;
> +
> +entry = *(s->avic_phy_id_cache);
> +smp_rmb();
> +entry.is_running = 0;
> +*(s->avic_phy_id_cache) = entry;
> +smp_wmb();
> +}
> +
> +static void avic_vcpu_resume(struct vcpu *v)
> +{
> +struct svm_avic_phy_ait_entry entry;
> +struct arch_svm_struct *s = >arch.hvm_svm;
> +
> +if ( !svm_avic_vcpu_enabled(v) || !s->avic_phy_id_cache )
> +return;
> +
> +ASSERT(!test_bit(_VPF_blocked, >pause_flags));
> +
> +entry = *(s->avic_phy_id_cache);
> +smp_rmb();
> +entry.is_running = 1;
> +*(s->avic_phy_id_cache)= entry;
  ^
Please add a space here.

> +smp_wmb();
> +}
> +
> +static void avic_vcpu_block(struct vcpu *v)
> +{
> +struct svm_avic_phy_ait_entry entry;
> +struct arch_svm_struct *s = >arch.hvm_svm;
> +
> +if ( !svm_avic_vcpu_enabled(v) || !s->avic_phy_id_cache )
> +return;
> +

Should there be a corresponding ASSERT? Or is that
done after these hooks are called?

> +entry = *(s->avic_phy_id_cache);
> +smp_rmb();
> +entry.is_running = 0;
> +*(s->avic_phy_id_cache) = entry;
> +smp_wmb();
> +}
> +
> +/***
>   * AVIC APIs
>   */
>  int svm_avic_dom_init(struct domain *d)
> @@ -97,6 +174,11 @@ int svm_avic_dom_init(struct domain *d)
>  clear_domain_page(_mfn(mfn));
>  d->arch.hvm_domain.svm.avic_phy_ait_mfn = mfn;
>  
> +d->arch.hvm_domain.pi_ops.pi_switch_to = avic_vcpu_put;
> +d->arch.hvm_domain.pi_ops.pi_switch_from = avic_vcpu_load;
> +d->arch.hvm_domain.pi_ops.vcpu_block = avic_vcpu_block;
> +d->arch.hvm_domain.pi_ops.pi_do_resume = avic_vcpu_resume;
> +
>  return ret;
>  err_out:
>  svm_avic_dom_destroy(d);
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 409096a..aafbfa1 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1011,6 +1011,10 @@ static void svm_ctxt_switch_from(struct vcpu *v)
>  svm_tsc_ratio_save(v);
>  
>  svm_sync_vmcb(v);
> +
> +if ( v->domain->arch.hvm_domain.pi_ops.pi_switch_from )
> +v->domain->arch.hvm_domain.pi_ops.pi_switch_from(v);
> +
>  svm_vmload(per_cpu(root_vmcb, cpu));
>  
>  /* Resume use of ISTs now that the host TR is reinstated. */
> @@ -1050,6 +1054,9 @@ static void svm_ctxt_switch_to(struct vcpu *v)
>  svm_lwp_load(v);
>  svm_tsc_ratio_load(v);
>  
> +if ( v->domain->arch.hvm_domain.pi_ops.pi_switch_to )
> +v->domain->arch.hvm_domain.pi_ops.pi_switch_to(v);
> +
>  if ( 

Re: [Xen-devel] [RFC PATCH 6/9] x86/SVM: Add AVIC vmexit handlers

[Konrad Rzeszutek Wilk]

On Mon, Sep 19, 2016 at 12:52:45AM -0500, Suravee Suthikulpanit wrote:
> AVIC introduces two #vmexit handlers:
>   * VMEXIT_INCOMP_IPI
>   * VMEXIT_DO_NOACCEL

Great.. Can you describe what you are suppose to do with them?

Please keep in mind that the point of the commit description is to
say something about the behavior or what not.

You can also just point to the AMD manual, but it would be better
if you included some explanation of why you wrote the code this way
or such.
> 
> Signed-off-by: Suravee Suthikulpanit 
> ---
>  xen/arch/x86/hvm/svm/avic.c| 279 
> +
>  xen/arch/x86/hvm/svm/svm.c |   8 ++
>  xen/include/asm-x86/hvm/svm/avic.h |   3 +
>  xen/include/asm-x86/hvm/svm/vmcb.h |   2 +
>  4 files changed, 292 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
> index 70bac69..90df181 100644
> --- a/xen/arch/x86/hvm/svm/avic.c
> +++ b/xen/arch/x86/hvm/svm/avic.c
> @@ -18,6 +18,7 @@
>  #define AVIC_DOORBELL   0xc001011b
>  #define AVIC_HPA_MASK   ~((0xFFFULL << 52) || 0xFFF)
>  #define AVIC_APIC_BAR_MASK  0xFF000ULL
> +#define AVIC_UNACCEL_ACCESS_OFFSET_MASK0xFF0
>  
>  bool_t svm_avic = 0;
>  boolean_param("svm-avic", svm_avic);
> @@ -215,3 +216,281 @@ int svm_avic_init_vmcb(struct vcpu *v)
>  
>  return 0;
>  }
> +
> +/***

That is a lot of stars. Please shrink to one.
> + * AVIC INCOMP IPI VMEXIT

Hmm, I think I figured that out from the name of the function.
Perhaps you want to say what the function is suppose to do or
under what conditions this would be called instead of bouncing
inside the guest?

Or perhaps just say under what conditions we would _not_
enter here and the guest would run on its merry way?

Or if that is explained in details in the comments in switch statements
then just remove the comment altogether?
> + */
> +void svm_avic_vmexit_do_incomp_ipi(struct cpu_user_regs *regs)
> +{
> +struct vcpu *v = current;
> +struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> +u32 icrh = vmcb->exitinfo1 >> 32;
> +u32 icrl = vmcb->exitinfo1;
> +u32 id = vmcb->exitinfo2 >> 32;
> +u32 index = vmcb->exitinfo2 && 0xFF;
> +
> +dprintk(XENLOG_DEBUG, "SVM: %s: cpu=%#x, vcpu=%#x, "
> +   "icrh:icrl=%#010x:%08x, id=%u, index=%u\n",
> +   __func__, v->processor, v->vcpu_id, icrh, icrl, id, index);



Please remove this.
> +
> +switch ( id )
> +{
> +case AVIC_INCMP_IPI_ERR_INVALID_INT_TYPE:
> +/*
> + * AVIC hardware handles the generation of

generation? Did you mean 'delivery' ?
> + * IPIs when the specified Message Type is Fixed
> + * (also known as fixed delivery mode) and
> + * the Trigger Mode is edge-triggered. The hardware
> + * also supports self and broadcast delivery modes
> + * specified via the Destination Shorthand(DSH)
> + * field of the ICRL. Logical and physical APIC ID
> + * formats are supported. All other IPI types cause
> + * a #VMEXIT, which needs to emulated.
> + */
> +vlapic_reg_write(v, APIC_ICR2, icrh);
> +vlapic_reg_write(v, APIC_ICR, icrl);
> +break;
> +case AVIC_INCMP_IPI_ERR_TARGET_NOT_RUN:
> +{
> +/*
> + * At this point, we expect that the AVIC HW has already
> + * set the appropriate IRR bits on the valid target
> + * vcpus. So, we just need to kick the appropriate vcpu.

Is there a pattern to this? Meaning does the CPU go sequentially
through the logical APIC ids - which (if say the guest is using
logical APIC ids which gives you pretty much 1-1 to physical) - means
that this VMEXIT would occur in a sequence of the vCPUs that are not
running? Because if so, then ..
> + */
> +struct vcpu *c;
> +struct domain *d = v->domain;
> +uint32_t dest = GET_xAPIC_DEST_FIELD(icrh);
> +uint32_t short_hand = icrl & APIC_SHORT_MASK;
> +bool_t dest_mode = !!(icrl & APIC_DEST_MASK);

bool
> +
> +for_each_vcpu ( d, c )

.. you could optimize this a bit and start at vCPU+1 (since you know
that this current vCPU most certainyl got the vCPU) ?

> +{
> +if ( vlapic_match_dest(vcpu_vlapic(c), vcpu_vlapic(v),
> +   short_hand, dest, dest_mode) )
> +{
> +vcpu_kick(c);
> +break;
> +}
> +}
> +break;
> +}
> +case AVIC_INCMP_IPI_ERR_INV_TARGET:
> +dprintk(XENLOG_ERR,
> +"SVM: %s: Invalid IPI target (icr=%#08x:%08x, idx=%u)\n",
> +__func__, icrh, icrl, index);

Please remove this dprintk.

> +break;
> +case AVIC_INCMP_IPI_ERR_INV_BK_PAGE:
> +dprintk(XENLOG_ERR,
> +"SVM: %s: Invalid bk page (icr=%#08x:%08x, idx=%u)\n",
> + 

[Xen-devel] [ovmf baseline-only test] 67879: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf a2d59ef2912079fe0631f7ee7661dad2ddb472c8
baseline version:
 ovmf 08354c34486947da17a36a605f9a4b000132123f

Last test of basis67875  2016-10-13 16:18:57 Z0 days
Testing same since67879  2016-10-14 10:50:57 Z0 days1 attempts


People who touched revisions under test:
  Ye Ting 

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.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

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

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


Push not applicable.


commit a2d59ef2912079fe0631f7ee7661dad2ddb472c8
Author: Ye Ting 
Date:   Thu Sep 29 13:52:05 2016 +0800

NetworkPkg: Record user configured TargetIP/Port in iBFT

Current ISCSI driver records redirected iSCSI targetIP/Port in iBFT
once redirection occurs, which removes the possibility of the OS
to reconnect to the configured IP for load balancing. The behavior
is not explicitly described in IBFT spec, though the MSFT expert
confirm we should record original user setting rather than
publish the redirected IP.

Thanks Sriram for reviewing and validating this patch in his test-bed.

Cc: Subramanian Sriram 
Cc: Fu Siyuan 
Cc: Zhang Lubo 

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ye Ting 
Reviewed-by: Fu Siyuan 
Reviewed-by: Subramanian Sriram 

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

Re: [Xen-devel] [PATCH v2 0/3 for 4.8] docs: feature documents for the schedulers

[Andrew Cooper]

On 14/10/16 14:24, Wei Liu wrote:
> On Fri, Oct 14, 2016 at 10:59:55AM +0100, Dario Faggioli wrote:
>> Hi,
>>
>> Here's v2.
>>
>> The differences are:
>>  - review comments taken into account.
>>  - I'm *NOT* claiming 'SuppOrted' status for Credit2. I'll do that in a
>>separate patch.
>>
>> v1 is here:
>>
>>  https://lists.xen.org/archives/html/xen-devel/2016-10/msg00857.html
>>
>> And there is a git branch for this new version:
>>
>>  git://xenbits.xen.org/people/dariof/xen.git  rel/sched/feature-docs
>>  
>> http://xenbits.xen.org/gitweb/?p=people/dariof/xen.git;a=shortlog;h=refs/heads/rel/sched/feature-docs
>>
>> Thanks and Regards,
>> Dario
>> ---
>> Dario Faggioli (3):
>>   docs: Credit1 feature document.
>>   docs: Credit2 feature document.
>>   docs: RTDS feature document.
>>
> All three:
>
> Acked-by: Wei Liu 

All LGTM as well.

~Andrew

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

Re: [Xen-devel] [PATCH v2 2/2] x86/Intel: virtualize support for cpuid faulting

[Andrew Cooper]

On 14/10/16 13:04, Jan Beulich wrote:
 On 13.10.16 at 23:09,  wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -1315,16 +1315,20 @@ static int emulate_forced_invalid_op(struct 
>> cpu_user_regs *regs)
>>  /* We only emulate CPUID. */
>>  if ( ( rc = copy_from_user(instr, (char *)eip, sizeof(instr))) != 0 )
>>  {
>>  propagate_page_fault(eip + sizeof(instr) - rc, 0);
>>  return EXCRET_fault_fixed;
>>  }
>>  if ( memcmp(instr, "\xf\xa2", sizeof(instr)) )
>>  return 0;
>> +/* Let the guest have this one */
>> +if ( current->arch.cpuid_fault && !guest_kernel_mode(current, regs) )
>> +return 0;
>> +
> I think another blank line ahead of the addition would be nice. I also
> think the comment should include the conditional aspect of what is
> says (same on the second instance below).
>
> And then there is the question of state here: There's no rIP update
> ahead of here, yet I'm uncertain whether we can expect the guest
> kernel to handle both bare and Xen-prefixed CPUID instructions.
> Andrew, what do you think?

The #GP fault handed back to the guest kernel should point at the cpuid
instruction, not the ud2 of the FEP.

In reality, the only real use of this path from userspace is the
`xen-detect` utility.  Regular userspace shouldn't know or care. 
Therefore, I am not concerned about the fact that it causes an implicit
change of information source.


I have taken the liberty of writing a CPUID Faulting XTF test, which
should cover all the intended guest-side behaviour (although I did code
it without a hypervisor side implementation, so I don't guarantee it is
bug-free).

The test can be found
http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen-test-framework.git;a=shortlog;h=refs/heads/cpuid-faulting
and general docs on using XTF can be found
http://xenbits.xen.org/docs/xtf/index.html  After cloning and building,
use "./xtf-runner cpuid-faulting" to run the test in all types of VM.

In particular, it will catch this specific issue when the exception
frame from an emulated cpuid doesn't point at the cpuid instruction.

Would you mind trying out this test?  Ideally, we would look to putting
it (or a bugfixed version of it) into our CI system at the same time as
the hypervisor support gets accepted.

~Andrew

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

Re: [Xen-devel] [PATCH 1/2] x86/hvm: Correct the position of the %cs L/D checks

[Konrad Rzeszutek Wilk]

On Fri, Oct 14, 2016 at 11:06:55AM +0100, Andrew Cooper wrote:
> Contrary to the description in the software manuals, in Long Mode, attempts to
> load %cs check that D is not set in combination with L before the present flag
> is checked.
> 
> This can be observed because the L/D check fails with #GP before the presence
> check failes with #NP

CC-ing Paul and Sherry.

Perhaps the SDMs should mention this as well?

> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> ---
>  xen/arch/x86/x86_emulate/x86_emulate.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
> b/xen/arch/x86/x86_emulate/x86_emulate.c
> index 793ce30..b23cd99 100644
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1405,6 +1405,14 @@ protmode_load_seg(
> /* Non-conforming segment: check RPL and DPL against CPL. */
> : rpl > cpl || dpl != cpl )
>  goto raise_exn;
> +/*
> + * 64-bit code segments (L bit set) must have D bit clear.
> + * Experimentally in long mode, the L and D bits are checked before
> + * the Present bit.
> + */
> +if ( in_longmode(ctxt, ops) &&
> + (desc.b & (1 << 21)) && (desc.b & (1 << 22)) )
> +goto raise_exn;
>  sel = (sel ^ rpl) | cpl;
>  break;
>  case x86_seg_ss:
> @@ -1444,11 +1452,6 @@ protmode_load_seg(
>  goto raise_exn;
>  }
>  
> -/* 64-bit code segments (L bit set) must have D bit clear. */
> -if ( seg == x86_seg_cs && in_longmode(ctxt, ops) &&
> - (desc.b & (1 << 21)) && (desc.b & (1 << 22)) )
> -goto raise_exn;
> -
>  /* Ensure Accessed flag is set. */
>  if ( a_flag && !(desc.b & a_flag) )
>  {
> -- 
> 2.1.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [RFC PATCH 5/9] x86/HVM/SVM: Add AVIC initialization code

[Konrad Rzeszutek Wilk]

. snip..

> diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
> new file mode 100644
> index 000..70bac69
> --- /dev/null
> +++ b/xen/arch/x86/hvm/svm/avic.c
> @@ -0,0 +1,217 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* NOTE: Current max index allowed for physical APIC ID table is 255 */
> +#define AVIC_PHY_APIC_ID_MAX0xFF
> +
> +#define AVIC_DOORBELL   0xc001011b
> +#define AVIC_HPA_MASK   ~((0xFFFULL << 52) || 0xFFF)
> +#define AVIC_APIC_BAR_MASK  0xFF000ULL
> +
> +bool_t svm_avic = 0;

static ? And also make it 'bool'

> +boolean_param("svm-avic", svm_avic);
> +
> +static struct svm_avic_phy_ait_entry *

This name resolves to 'SVM AVIC Physical APIC ID Table Entry'

That 'ait' keeps throwing me off as it sounds like 'eat' to me.

Perhaps  'avic_phy_apic_id_ent' ?

In other words s/ait/apic_id/ and s/svm_avic/avic/ followed by
s/_id_entry/id_ent/ ?


> +avic_get_phy_ait_entry(struct vcpu *v, int index)
> +{
> +struct svm_avic_phy_ait_entry *avic_phy_ait;
> +struct svm_domain *d = >domain->arch.hvm_domain.svm;
> +
> +if ( !d->avic_phy_ait_mfn )
> +return NULL;
> +
> +/**
> +* Note: APIC ID = 0xff is used for broadcast.
> +*   APIC ID > 0xff is reserved.
> +*/
> +if ( index >= 0xff )
> +return NULL;
> +
> +avic_phy_ait = mfn_to_virt(d->avic_phy_ait_mfn);
> +
> +return _phy_ait[index];
> +}
> +
> +/***
> + * AVIC APIs
> + */
> +int svm_avic_dom_init(struct domain *d)
> +{
> +int ret = 0;
> +struct page_info *pg;
> +unsigned long mfn;
> +
> +if ( !svm_avic )
> +return 0;
> +
> +/**
> + * Note:
> + * AVIC hardware walks the nested page table to check permissions,
> + * but does not use the SPA address specified in the leaf page
> + * table entry since it uses  address in the AVIC_BACKING_PAGE pointer
> + * field of the VMCB. Therefore, we set up a dummy page here _mfn(0).

s/here/for APIC/


> + */
> +if ( !d->arch.hvm_domain.svm.avic_access_page_done )
> +{
> +set_mmio_p2m_entry(d, paddr_to_pfn(APIC_DEFAULT_PHYS_BASE),
> +   _mfn(0), PAGE_ORDER_4K,
> +   p2m_get_hostp2m(d)->default_access);
> +d->arch.hvm_domain.svm.avic_access_page_done = true;
> +}
> +
> +/* Init AVIC log APIC ID table */

s/log/logical/
> +pg = alloc_domheap_page(d, MEMF_no_owner);
> +if ( !pg )
> +{
> +dprintk(XENLOG_ERR, "alloc AVIC logical APIC ID table error: %d\n",
> +d->domain_id);
> +ret = -ENOMEM;
> +goto err_out;
> +}
> +mfn = page_to_mfn(pg);
> +clear_domain_page(_mfn(mfn));
> +d->arch.hvm_domain.svm.avic_log_ait_mfn = mfn;
> +
> +/* Init AVIC phy APIC ID table */

physical ?

> +pg = alloc_domheap_page(d, MEMF_no_owner);
> +if ( !pg )
> +{
> +dprintk(XENLOG_ERR, "alloc AVIC physical APIC ID table error: %d\n",
> +d->domain_id);
> +ret = -ENOMEM;
> +goto err_out;
> +}
> +mfn = page_to_mfn(pg);
> +clear_domain_page(_mfn(mfn));
> +d->arch.hvm_domain.svm.avic_phy_ait_mfn = mfn;
> +
> +return ret;
> +err_out:
> +svm_avic_dom_destroy(d);
> +return ret;
> +}
> +
.. snip..
> +int svm_avic_init_vmcb(struct vcpu *v)
> +{
> +paddr_t ma;
> +u32 apic_id_reg;
> +struct arch_svm_struct *s = >arch.hvm_svm;
> +struct vmcb_struct *vmcb = s->vmcb;
> +struct svm_domain *d = >domain->arch.hvm_domain.svm;
> +struct svm_avic_phy_ait_entry entry;
> +
> +if ( !svm_avic )
> +return 0;
> +
> +vmcb->avic_bk_pg_pa = page_to_maddr(s->avic_bk_pg) & AVIC_HPA_MASK;
> +ma = d->avic_log_ait_mfn;
> +vmcb->avic_log_apic_id = (ma << PAGE_SHIFT) & AVIC_HPA_MASK;
> +ma = d->avic_phy_ait_mfn;

s/ait/apic_id/ ?

> +vmcb->avic_phy_apic_id = (ma << PAGE_SHIFT) & AVIC_HPA_MASK;
> +vmcb->avic_phy_apic_id |= AVIC_PHY_APIC_ID_MAX;
> +

After reading the spec these tables make a bit more sense - one to
translate logical APIC -> physical APIC id, and the last one to
translate to host APIC.

It may be good to include just an simple ASCII flow of how say
IPI for a two vCPU guest would go?

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  ed00f1761689ac7b9c074e9084c81e47c25d460c
baseline version:
 xen  b5283627de6b7ba2b8d75ecf1edf0a46bcd83edb

Last test of basis   101422  2016-10-13 15:02:57 Z0 days
Testing same since   101445  2016-10-14 12:02:56 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 0/3 for 4.8] docs: feature documents for the schedulers

[Wei Liu]

On Fri, Oct 14, 2016 at 10:59:55AM +0100, Dario Faggioli wrote:
> Hi,
> 
> Here's v2.
> 
> The differences are:
>  - review comments taken into account.
>  - I'm *NOT* claiming 'SuppOrted' status for Credit2. I'll do that in a
>separate patch.
> 
> v1 is here:
> 
>  https://lists.xen.org/archives/html/xen-devel/2016-10/msg00857.html
> 
> And there is a git branch for this new version:
> 
>  git://xenbits.xen.org/people/dariof/xen.git  rel/sched/feature-docs
>  
> http://xenbits.xen.org/gitweb/?p=people/dariof/xen.git;a=shortlog;h=refs/heads/rel/sched/feature-docs
> 
> Thanks and Regards,
> Dario
> ---
> Dario Faggioli (3):
>   docs: Credit1 feature document.
>   docs: Credit2 feature document.
>   docs: RTDS feature document.
> 

All three:

Acked-by: Wei Liu 

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

[Xen-devel] [linux-3.18 test] 101434: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 101000
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101000
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
101000
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-freebsd10-i386  6 xen-boot   fail REGR. vs. 101000

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-multivcpu 14 guest-saverestore fail in 101389 pass in 
101434
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101389 pass in 
101434
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 101398 pass in 
101434
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
101413 pass in 101434
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
101413 pass in 101434
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101389
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101398
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101398
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-bootfail pass in 101398
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 101413
 test-amd64-i386-libvirt   6 xen-boot   fail pass in 101413

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101000
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101000
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101000

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

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Andrew Cooper]

On 14/10/16 08:08, Haozhong Zhang wrote:
> On 10/13/16 20:33 +0100, Andrew Cooper wrote:
>> On 13/10/16 19:59, Dan Williams wrote:
>>> On Thu, Oct 13, 2016 at 9:01 AM, Andrew Cooper
>>>  wrote:
 On 13/10/16 16:40, Dan Williams wrote:
> On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich 
> wrote:
> [..]
>>> I think we can do the similar for Xen, like to lay another pseudo
>>> device on /dev/pmem and do the reservation, like 2. in my previous
>>> reply.
>> Well, my opinion certainly doesn't count much here, but I
>> continue to
>> consider this a bad idea. For entities like drivers it may well be
>> appropriate, but I think there ought to be an independent concept
>> of "OS reserved", and in the Xen case this could then be shared
>> between hypervisor and Dom0 kernel. Or if we were to consider Dom0
>> "just a guest", things should even be the other way around: Xen gets
>> all of the OS reserved space, and Dom0 needs something custom.
> You haven't made the case why Xen is special and other
> applications of
> persistent memory are not.
 In a Xen system, Xen runs in the baremetal root-mode ring0, and
 dom0 is
 a VM running in ring1/3 with the nvdimm driver.  This is the opposite
 way around to the KVM model.

 Dom0, being the hardware domain, has default ownership of all the
 hardware, but to gain access in the first place, it must request a
 mapping from Xen.
>>> This is where my understanding the Xen model breaks down.  Are you
>>> saying dom0 can't access the persistent memory range unless the ring0
>>> agent has metadata storage space for tracking what it maps into dom0?
>>
>> No.  I am trying to point out that the current suggestion wont work, and
>> needs re-designing.
>>
>> Xen *must* be able to properly configure mappings of the NVDIMM for
>> dom0, *without* modifying any content on the NVDIMM.  Otherwise, data
>> corruption will occur.
>>
>> Whether this means no Xen metadata, or the metadata living elsewhere in
>> regular ram, such as the main frametable, is an implementation detail.
>>
>>>
 Once dom0 has a mapping of the nvdimm, the nvdimm driver can go to
 work
 and figure out what is on the DIMM, and which areas are safe to use.
>>> I don't understand this ordering of events.  Dom0 needs to have a
>>> mapping to even write the on-media structure to indicate a
>>> reservation.  So, initial dom0 access can't depend on metadata
>>> reservation already being present.
>>
>> I agree.
>>
>> Overall, I think the following is needed.
>>
>> * Xen starts up.
>> ** Xen might find some NVDIMM SPA/MFN ranges in the NFIT table, and
>> needs to note this information somehow.
>> ** Xen might find some Type 7 E820 regions, and needs to note this
>> information somehow.
>
> IIUC, this is to collect MFNs and no need to create frame table and
> M2P at this stage. If so, what is different from ...
>
>> * Xen starts dom0.
>> * Once OSPM is running, a Xen component in Linux needs to collect and
>> report all NVDIMM SPA/MFN regions it knowns about.
>> ** This covers the AML-only case, and the hotplug case.
>
> ... the MFNs reported here, especially that the former is a subset
> (hotplug ones not included in the former) of latter.

Hopefully nothing.  However, Xen shouldn't exclusively rely on the dom0
when it is capable of working things out itself, (which can aid with
debugging one half of this arrangement).  Also, the MFNS found by Xen
alone can be present in the default memory map for dom0.

>
> (There is no E820 hole or SRAT entries to tell which address range is
> reserved for hotplugged NVDIMM)
>
>> * Dom0 requests a mapping of the NVDIMMs via the usual mechanism.
>
> Two questions:
> 1. Why is this request necessary? Even without such requests like what
>   my current implementation, Dom0 can still access NVDIMM.

Can it?  (if so, great, but I don't think this holds in the general
case.)  Is that a side effect of the NVDIMM being covered by a hole in
the E820?  The current logic for what dom0 may access by default is
somewhat ad-hoc, and I have a gut feeling that it won't work with E820
type 7 regions.

>
>   Or do you mean Xen hypervisor should by default disallow Dom0 to
>   access MFNs reported in previous step until they are requested?

No - I am not suggesting this.

>
> 2. Who initiates the requests? If it's the libnvdimm driver, that
>   means we still need to introduce Xen specific code to the driver.
>
>   Or the requests are issued by OSPM (or the Xen component you
>   mentioned above) when they probe new dimms?
>
>   For the latter, Dan, do you think it's acceptable in NFIT code to
>   call the Xen component to request the access permission of the pmem
>   regions, e.g. in apic_nfit_insert_resource(). Of course, it's only
>   used for Dom0 case.

The libnvdimm driver should continue to use ioremap() or whatever it
currently does.  There shouldn't be 

Re: [Xen-devel] [PATCH v2 2/2] x86/Intel: virtualize support for cpuid faulting

[Jan Beulich]

>>> On 13.10.16 at 23:09,  wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1315,16 +1315,20 @@ static int emulate_forced_invalid_op(struct 
> cpu_user_regs *regs)
>  /* We only emulate CPUID. */
>  if ( ( rc = copy_from_user(instr, (char *)eip, sizeof(instr))) != 0 )
>  {
>  propagate_page_fault(eip + sizeof(instr) - rc, 0);
>  return EXCRET_fault_fixed;
>  }
>  if ( memcmp(instr, "\xf\xa2", sizeof(instr)) )
>  return 0;
> +/* Let the guest have this one */
> +if ( current->arch.cpuid_fault && !guest_kernel_mode(current, regs) )
> +return 0;
> +

I think another blank line ahead of the addition would be nice. I also
think the comment should include the conditional aspect of what is
says (same on the second instance below).

And then there is the question of state here: There's no rIP update
ahead of here, yet I'm uncertain whether we can expect the guest
kernel to handle both bare and Xen-prefixed CPUID instructions.
Andrew, what do you think?

> @@ -2474,16 +2478,27 @@ static int priv_op_read_msr(unsigned int reg, 
> uint64_t *val,
>  *val = 0;
>  return X86EMUL_OKAY;
>  
>  case MSR_INTEL_PLATFORM_INFO:
>  if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
>   rdmsr_safe(MSR_INTEL_PLATFORM_INFO, *val) )
>  break;
>  *val = 0;
> +if ( this_cpu(cpuid_faulting_enabled) )
> +*val |= MSR_PLATFORM_INFO_CPUID_FAULTING;
> +return X86EMUL_OKAY;
> +
> +case MSR_INTEL_MISC_FEATURES_ENABLES:
> +if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
> + rdmsr_safe(MSR_INTEL_MISC_FEATURES_ENABLES, *val))

Missing blank before the final closing parenthesis.

> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -568,16 +568,19 @@ struct arch_vcpu
>  struct paging_vcpu paging;
>  
>  uint32_t gdbsx_vcpu_event;
>  
>  /* A secondary copy of the vcpu time info. */
>  XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
>  
>  struct arch_vm_event *vm_event;
> +
> +/* Has the guest enabled CPUID faulting? */
> +bool cpuid_fault;
>  };

This should be moved up into one of the available holes: Preferably
next to the other boolean, but aside gdbsx_vcpu_event would also
be better than putting it here.

Jan


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

Re: [Xen-devel] [PATCH] x86emul: honor MXCSR.MM

[Andrew Cooper]

On 14/10/16 07:20, Jan Beulich wrote:
 On 13.10.16 at 15:26,  wrote:
>> On 13/10/16 13:57, Jan Beulich wrote:
>>> Commit 6dc9ac9f52 ("x86emul: check alignment of SSE and AVX memory
>>> operands") didn't consider a specific AMD mode: Mis-alignment #GP
>>> faults can be masked on some of their hardware.
>>>
>>> Signed-off-by: Jan Beulich 
>> This highlights that the following CPUID dependency change is also required
>>
>> diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
>> index 33e68eb..e803654 100755
>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -185,8 +185,9 @@ def crunch_numbers(state):
>>  # the first place.
>>  APIC: [X2APIC],
>>  
>> -# AMD built MMXExtentions and 3DNow as extentions to MMX.
>> -MMX: [MMXEXT, _3DNOW],
>> +# AMD built MMXExtentions, 3DNow and SSE Misalignment as
>> extensions to
>> +# MMX.
>> +MMX: [MMXEXT, _3DNOW, MISALIGNSSE],
>>  
>>  # The FXSAVE/FXRSTOR instructions were introduced into hardware
>> before
>>  # SSE, which is why they behave differently based on
>> %CR4.OSFXSAVE and
> Hmm, for one this is an orthogonal change, so doesn't belong in this
> patch. And then - why is this an extension to MMX (which doesn't
> have any alignment requirements anyway) rather than SSE?

Sorry - I have no idea why I suggested MMX.  It should have been SSE.

>
>>> @@ -4675,7 +4679,13 @@ x86_emulate(
>>>  ea.bytes = vex.pfx & VEX_PREFIX_DOUBLE_MASK ? 8 : 4;
>>>  if ( ea.type == OP_MEM )
>>>  {
>>> -generate_exception_if((b >= 0x28) &&
>>> +uint32_t mxcsr = 0;
>>> +
>>> +if ( b < 0x28 )
>>> +mxcsr = MXCSR_MM;
>>> +else if ( vcpu_has_misalignsse() )
>>> +asm ( "stmxcsr %0" : "=m" (mxcsr) );
>>> +generate_exception_if(!(mxcsr & MXCSR_MM) &&
>>>!is_aligned(ea.mem.seg, ea.mem.off, 
>>> ea.bytes,
>>>ctxt, ops),
>>>EXC_GP, 0);
>>> @@ -4955,7 +4965,13 @@ x86_emulate(
>>>  }
>>>  if ( ea.type == OP_MEM )
>>>  {
>>> -generate_exception_if((vex.pfx == vex_66) &&
>>> +uint32_t mxcsr = 0;
>>> +
>>> +if ( vex.pfx != vex_66 )
>>> +mxcsr = MXCSR_MM;
>>> +else if ( vcpu_has_misalignsse() )
>>> +asm ( "stmxcsr %0" : "=m" (mxcsr) );
>>> +generate_exception_if(!(mxcsr & MXCSR_MM) &&
>>>!is_aligned(ea.mem.seg, ea.mem.off, 
>>> ea.bytes,
>>>ctxt, ops),
>>>EXC_GP, 0);
>> According to the docs, we should also be possibly raising #AC here.
> Well, you've said the same in a different context not so long ago,
> and my answer is then also the same: As long as we don't do any
> #AC generation, I see no reason why we would want to create an
> exception here.

Ah yes.  I had managed to let that slip my mind.

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 1/2] x86/Intel: Expose cpuid_faulting_enabled so it can be used elsewhere

[Jan Beulich]

>>> On 13.10.16 at 23:09,  wrote:
> ---

This is lacking an S-o-b. And it would also be nice if you switched the
bool_t instances to bool as you're touching them anyway.

Jan

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

Re: [Xen-devel] [PATCH v2 10/10] xl: allow to set the ratelimit value online for Credit2

[George Dunlap]

On 13/10/16 23:19, Jim Fehlig wrote:
> On 09/29/2016 08:54 PM, Dario Faggioli wrote:
>> Last part of the wiring necessary for allowing to
>> change the value of the ratelimit_us parameter online,
>> for Credit2 (like it is already for Credit1).
>>
>> Signed-off-by: Dario Faggioli 
>> Reviewed-by: George Dunlap 
> 
> Seeing this patch got me to thinking that it would be cool if libvirt
> supported Credit2 :-). Do you have any plans/time to do that?

Hmm, well, we can put it on our list of "things it would be good to do"
-- not sure when it might actually manage to get attention
unfortunately. :-/

 -George

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

Re: [Xen-devel] [PATCH RFC] xl_cmdimpl.c: Fix printf usage

[George Dunlap]

On 12/10/16 19:52, Ronald Rojas wrote:
> Change instances of printf, fprintf, and LOG where the specifier
> used is '%d' to be '%u' for domid.
> 
> Signed-off-by: Ronald Rojas 

Code looks good, thanks!

A couple of minor adjustments to the patch itself:

First, the traditional "tag" for this would probably be "tools/xl"
instead of the name of the file.  Secondly one-line description needs to
be a bit more specific, so people skimming through have an idea whether
they need to look further at what the patch does or not.  I think
something like "Use %u for uint32_t domids" would give the general idea.

Then in your full changelog, you want to say what the *intention* of the
patch is first, and *then* what the patch does.  That is, describe the
status quo, why that's a problem, and what you want to achieve.  You can
leave some of it out if it's obvious, but what you have now is a bit too
much left out.

Something like this:

domid is normally represented by uint32_t, but many format strings in
xl_cmdimpl.c use %d when printing it, which is signed.  Use %u instead.

With those changes you can re-send without the RFC.

Thanks,
 -George


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-xsm   9 debian-install   fail REGR. vs. 101365

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101365
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101365
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101365

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

version targeted for testing:
 qemuu6aa5a3679449cdf0b6fe5a6829b22e642ded57fd
baseline version:
 qemuu627eae7d729277c84f8e0ac07a8caab39c92c38d

Last test of basis   101365  2016-10-11 02:21:11 Z3 days
Failing since101395  2016-10-12 10:15:00 Z2 days4 attempts
Testing same since   101430  2016-10-14 00:16:31 Z0 days1 attempts


People who touched revisions under test:
  Cornelia Huck 
  Daniel P. Berrange 
  David Gibson 
  Eric Blake 
  Gerd Hoffmann 
  Hans de Goede 
  Lluís Vilanova 
  Marc-André Lureau 
  P J P 
  Peter Maydell 
  Stefan Hajnoczi 
  Thomas Huth 
  Vijay Kumar B 
  Vijay Kumar B. 

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
 

Re: [Xen-devel] [PATCH] x86/Viridian: don't depend on undefined register state

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 14 October 2016 05:38
> To: xen-devel 
> Cc: Paul Durrant 
> Subject: [PATCH] x86/Viridian: don't depend on undefined register state
> 
> The high halves of all GPRs are undefined in 32-bit and compat modes,
> and the dependency is being obfuscated by our structure field names not
> matching architectural register names (it was actually while putting
> together a patch to correct this when I noticed the issue here).
> 
> For consistency also use the architecturally correct names on the
> output side.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Paul Durrant 

> 
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -667,9 +667,9 @@ int viridian_hypercall(struct cpu_user_r
>  output_params_gpa = regs->r8;
>  break;
>  case 4:
> -input.raw = ((uint64_t)regs->edx << 32) | regs->eax;
> -input_params_gpa = ((uint64_t)regs->ebx << 32) | regs->ecx;
> -output_params_gpa = ((uint64_t)regs->edi << 32) | regs->esi;
> +input.raw = (regs->rdx << 32) | regs->_eax;
> +input_params_gpa = (regs->rbx << 32) | regs->_ecx;
> +output_params_gpa = (regs->rdi << 32) | regs->_esi;
>  break;
>  default:
>  goto out;
> @@ -770,8 +770,8 @@ out:
>  regs->rax = output.raw;
>  break;
>  default:
> -regs->edx = output.raw >> 32;
> -regs->eax = output.raw;
> +regs->rdx = output.raw >> 32;
> +regs->rax = (uint32_t)output.raw;
>  break;
>  }
> 
> 
> 

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

Re: [Xen-devel] [PATCH] features: declare the Credit2 scheduler as Supported.

[George Dunlap]

On 14/10/16 11:17, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli 

We don't have a general framework for declaring things "supported" yet,
and at the moment we only have a single level of "supported", which
includes XSAs.  I do think it makes sense to include an assessment of
the security risk when deciding whether to make such a declaration.

Here's a sort of checklist we could use to start a discussion.

Basically, there are a number of types of security vulnerabilities; we
could ask what the likelihood of any of these happening.

1. Guest -> host privilege escalation.  What functionality do
unprivileged guest have access to --  hypercalls / instructions?  Do
these include any buffers or pointers, and are these handled in a safe
manner -- not only checked, but with a "defensive programming" attitude
in mind?  An informal audit of any such interfaces should generally
suffice to answer this question I think.

2. Guest user -> guest kernel escalation.  Is there functionality
exposed to the guest kernel that must be limited to the kernel?  If so,
is it properly secured from guest user mode?  Might this feature have
any impact on any *other* functionality that the guest kernel uses to
protect itself from the guest user space?

3. Information leakage.  What additional information do the interfaces
expose to anything that has access to them?  Are there any buffers that
may copy hypervisor stack frames, ?

4. Denial-of-service.  Can anyone use any of the access they have to
crash the hypervisor, or monopolize resources in a way that
significantly impedes the performance of other guests, or other
processes within the same guest?

---

WRT Credit2:

I *think* the only interfaces exposed to *unprivileged* guests are the
SCHEDOP hypercalls -- block(), yield(),  -- and timers.  (Dario,
please correct me if I'm wrong.)  The only thing that the scheduler
gives is time on the cpu.  Neither block nor yield contain any pointers,
and so it should be trivial to verify that they contain no privilege
escalation paths.

WRT guest user -> guest kernel escalation, the guest kernel is not
relying on anything from the scheduler to protect itself or any data in
any way, so it's difficult to imagine how this might be done.

The only information which the scheduler exposes to unprivileged guests
is the timing information.  This may be able to be used for side-channel
attacks to probabilistically infer things about other vcpus running on
the same system; but this has not traditionally been considered within
the security boundary.

There have been denial-of-service attacks on credit1 before, where a
vcpu could "game the system" by going to sleep at particular times to
fool the accounting system into thinking that it wasn't running, and
thus run at BOOST priority and monopolize 95% of the cpu.  But this was
fixed by actually charging cpus for time they spent running rather than
probabilistycally, which credit2 already does.

It's worth taking stock again and thinking if there's any way to "game"
credit2 in such a way; but I think it's relatively unlikely that someone
will be able to monopolize the cpu 100% as with the credit1 bug; and
even if it did, it's a pretty low-profile XSA.

So on the whole, I'm inclined to say that from a security perspective,
credit2 is probably OK.  (It would help if Dario filled this out a bit,
I think.)

But I agree with Jan, that such an argument would go well to go in the
commit message. :-)

 -George

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

[Xen-devel] [libvirt test] 101436: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 libvirt  a564568f066c78ed250b67105977740b563232bd
baseline version:
 libvirt  e1a33ed18c0200e26d92eb2900943573fc0f7d60

Last test of basis   101412  2016-10-13 04:21:58 Z1 days
Testing same since   101436  2016-10-14 04:21:16 Z0 days1 attempts


People who touched revisions under test:
  Ivan Baldo 
  Martin Kletzander 
  Michal Privoznik 
  Peter Krempa 

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 fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 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


Not pushing.


commit a564568f066c78ed250b67105977740b563232bd
Author: Michal Privoznik 
Date:   Fri Oct 14 10:09:03 2016 +0800

virLogDefineOutputs: Fix build without syslog.h

Not every system out there has syslog, that's why we check for it
in our configure script. However, in 640b58abdf while fixing
another issue, some variables and functions are called that are
defined only when syslog.h is present. But these function
calls/variables were not guarded by #ifdef-s.

Signed-off-by: Michal Privoznik 

commit 

Re: [Xen-devel] [PATCH 1/2] x86/hvm: Correct the position of the %cs L/D checks

[Andrew Cooper]

On 14/10/16 11:28, Jan Beulich wrote:
 On 14.10.16 at 12:06,  wrote:
>> Contrary to the description in the software manuals, in Long Mode, attempts 
>> to
>> load %cs check that D is not set in combination with L before the present 
>> flag
>> is checked.
>>
>> This can be observed because the L/D check fails with #GP before the presence
>> check failes with #NP
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 
>
> But I think it would be worthwhile mentioning that this restores
> things to v1 of what became commit 78ff18c90.

I will update the comment to include this.

~Andrew

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

Re: [Xen-devel] [PATCH 2/2] x86/hvm: Clobber %cs.L when LME becomes set

[Jan Beulich]

>>> On 14.10.16 at 12:06,  wrote:
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH 1/2] x86/hvm: Correct the position of the %cs L/D checks

[Jan Beulich]

>>> On 14.10.16 at 12:06,  wrote:
> Contrary to the description in the software manuals, in Long Mode, attempts to
> load %cs check that D is not set in combination with L before the present flag
> is checked.
> 
> This can be observed because the L/D check fails with #GP before the presence
> check failes with #NP
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 

But I think it would be worthwhile mentioning that this restores
things to v1 of what became commit 78ff18c90.

Jan

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

Re: [Xen-devel] [PATCH] features: declare the Credit2 scheduler as Supported.

[Jan Beulich]

>>> On 14.10.16 at 12:17,  wrote:
> Signed-off-by: Dario Faggioli 

I have to admit that I would have expected a non-empty description,
at least briefly rationalizing the change of state.

Jan


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf a2d59ef2912079fe0631f7ee7661dad2ddb472c8
baseline version:
 ovmf 08354c34486947da17a36a605f9a4b000132123f

Last test of basis   101414  2016-10-13 05:59:09 Z1 days
Testing same since   101435  2016-10-14 03:15:52 Z0 days1 attempts


People who touched revisions under test:
  Ye Ting 

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

[Xen-devel] [PATCH] features: declare the Credit2 scheduler as Supported.

[Dario Faggioli]

Signed-off-by: Dario Faggioli 
---
This goes on top of:

 https://lists.xen.org/archives/html/xen-devel/2016-10/msg00944.html

I'm of course happy to rebase/resend, if the above mentioned series
changes.
---
Cc: secur...@xenproject.org
Cc: George Dunlap 
Cc: Anshul Makkar 
Cc: Wei Liu 
Cc: Lars Kurth 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
---
 docs/features/sched_credit2.pandoc |2 +-
 xen/common/sched_credit2.c |2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/docs/features/sched_credit2.pandoc 
b/docs/features/sched_credit2.pandoc
index 8609d9c..9c8e15b 100644
--- a/docs/features/sched_credit2.pandoc
+++ b/docs/features/sched_credit2.pandoc
@@ -5,7 +5,7 @@
 
 # Basics
  
- Status: **Experimental**
+ Status: **Supported**
 
   Component: Hypervisor
  
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index fe46e80..1f26553 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -2954,8 +2954,6 @@ csched2_init(struct scheduler *ops)
 struct csched2_private *prv;
 
 printk("Initializing Credit2 scheduler\n");
-printk(" WARNING: This is experimental software in development.\n" \
-   " Use at your own risk.\n");
 
 printk(XENLOG_INFO " load_precision_shift: %d\n"
XENLOG_INFO " load_window_shift: %d\n"


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

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Jan Beulich]

>>> On 13.10.16 at 17:46,  wrote:
> On 10/13/16 03:08 -0600, Jan Beulich wrote:
> On 13.10.16 at 10:53,  wrote:
>>> On 10/13/16 02:34 -0600, Jan Beulich wrote:
>>> On 12.10.16 at 18:19,  wrote:
> On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich  wrote:
> On 12.10.16 at 17:42,  wrote:
>>> On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich  wrote:
>>> On 12.10.16 at 16:58,  wrote:
> On 10/12/16 05:32 -0600, Jan Beulich wrote:
> On 12.10.16 at 12:33,  wrote:
>>> The layout is shown as the following diagram.
>>>
>>> +---+---+---+--+--+
>>> | whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
>>> |  by kernel|   Table   | Block | for Xen  |  |
>>> +---+---+---+--+--+
>>> \_ ___/
>>>   V
>>>  /dev/pmem0
>>
>>I have to admit that I dislike this, for not being OS-agnostic.
>>Neither should there be any Xen-specific region, nor should the
>>"whatever used by kernel" one be restricted to just Linux. What
>>I could see is an OS-reserved area ahead of the partition table,
>>the exact usage of which depends on which OS is currently
>>running (and in the Xen case this might be both Xen _and_ the
>>Dom0 kernel, arbitrated by a tbd protocol). After all, when
>>running under Xen, the Dom0 may not have a need for as much
>>control data as it has when running on bare hardware, for it
>>controlling less (if any) of the actual memory ranges when Xen
>>is present.
>>
>
> Isn't this OS-reserved area still not OS-agnostic, as it requires OS
> to know where the reserved area is?  Or do you mean it's not if it's
> defined by a protocol that is accepted by all OSes?

 The latter - we clearly won't get away without some agreement on
 where to retrieve position and size of this area. I was simply
 assuming that such a protocol already exists.

>>>
>>> No, we should not mix the struct page reservation that the Dom0 kernel
>>> may actively use with the Xen reservation that the Dom0 kernel does
>>> not consume.  Explain again what is wrong with the partition approach?
>>
>> Not sure what was unclear in my previous reply. I don't think there
>> should be apriori knowledge of whether Xen is (going to be) used on
>> a system, and even if it gets used, but just occasionally, it would
>> (apart from the abstract considerations already given) be a waste
>> of resources to set something aside that could be used for other
>> purposes while Xen is not running. Static partitioning should only be
>> needed for persistent data.
>
> The reservation needs to be persistent / static even if the data is
> volatile, as is the case with struct page, because we can't have the
> size of the device change depending on use.  So, from the aspect of
> wasting space while Xen is not in use, both partitions and the
> intrinsic reservation approach suffer the same problem. Setting that
> aside I don't want to mix 2 different use cases into the same
> reservation.

Then you didn't understand what I've said: I certainly didn't mean
the reservation to vary from a device perspective. However, when
Xen is in use I don't see why part of that static reservation couldn't
be used by Xen, and another part by the Dom0 kernel. The kernel
obviously would need to ask the hypervisor how much of the space
is left, and where that area starts.

>>>
>>> I think Dan means that there should be a clear separation between
>>> reservations for different usages (kernel/xen/...). The libnvdimm
>>> driver is for the linux kernel and only needs to maintain the
>>> reservation for kernel functionality. For others including xen/dm/...,
>>> if they want reservation for their own purpose, they should maintain
>>> their own reservations out of libnvdimm driver and avoid bothering the
>>> libnvdimm driver (e.g. add specific handling in libnvdimm driver).
>>>
>>> IIUC, one existing example is device-mapper device (dm) which needs to
>>> reserve on-device area for its own meta-data. Its choice is to store
>>> the meta-data on the block device (/dev/pmemN) provided by the
>>> libnvdimm driver.
>>>
>>> I think we can do the similar for Xen, like to lay another pseudo
>>> device on /dev/pmem and do the reservation, like 2. in my previous
>>> reply.
>>
>>Well, my opinion certainly doesn't 

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

[Jan Beulich]

>>> On 14.10.16 at 11:59,  wrote:
> On 14/10/16 07:36, Jan Beulich wrote:
> On 14.10.16 at 02:58,  wrote:
>>> On Fri, 14 Oct 2016, Andrew Cooper wrote:
 There should be a high barrier to "Supported" status, because the cost
 of getting it wrong is equally high.  However, there are perfectly
 legitimate intermediate stages such as "Supported in these limited set
 of circumstances".  A number of features are not plausibly for use in
 production environments, but otherwise function fine for
 development/investigatory purposes.  In these cases, something like "no
 security support, but believed to be working fine" might be appropriate.
>>>
>>> I agree on this. I think we need an intermediate step: "working but not
>>> supported for security" is completely reasonable. When we say that it is
>>> "working", it should be because we have automated testing for it (I
>>> don't know if I would go as far as requiring it to be in OSSTest, any
>>> automated testing, even third party, would do). If it is not
>>> automatically tested, then it is just "best effort".
>> 
>> I don't think this is a reasonable expectation - how would you envision
>> testing the dozens of command line options alone, not to speak of
>> things depending on hardware characteristics?
> 
> Well there may be situations where we can make reasonable exceptions.
> But it would certainly be a lot better if a feature wasn't considered
> "done" until there was something in place to make sure that it worked
> and continued to work, other than "we hope people use it and report any
> bugs they find".

Perhaps an earlier question here is what a "feature" is. My command
line option example was specifically chosen to make it possibly very
small scope, yet indicate an area where we would likely say "using
this and that option is not supported" (depending on the instance
with either of the two meanings you name below).

> The more interesting aspect of Stefano's suggestion here is whether
> there should be two levels of "supported" -- "supported" as in, "this
> works but it's not in our security boundary", and "supported" as in,
> "this works and it *is* in our security boundary".

To me the question is how far that would matter for people
wanting to use Xen in production: I for one wouldn't feel well
using features which aren't security supported.

> But as we don't *yet* have such a decision-making process in place, I
> think we need to approach each change in an ad-hoc manner.  Having a
> discussion about *credit2* which includes the security aspects makes
> sense, and I don't think we need to wait until we've got a generalized
> framework to make a reasonable decision about that.

Sure.

Jan

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail REGR. vs. 101383
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 101383

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

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

version targeted for testing:
 xen  b5283627de6b7ba2b8d75ecf1edf0a46bcd83edb
baseline version:
 xen  71b8b46111219a2f83f4f9ae06ac5409744ea86e

Last test of basis   101396  2016-10-12 11:16:02 Z1 days
Failing since101415  2016-10-13 06:04:49 Z1 days2 attempts
Testing same since   101429  2016-10-13 23:16:18 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Edgar E. Iglesias 
  Ian Jackson 
  Jan Beulich 
  Lan Tianyu 
  Wei Liu 

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

[Xen-devel] [PATCH 2/2] x86/hvm: Clobber %cs.L when LME becomes set

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/hvm/hvm.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ceb89c7..3c90ecd 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2037,6 +2037,30 @@ int hvm_set_efer(uint64_t value)
 return X86EMUL_EXCEPTION;
 }
 
+if ( (value & EFER_LME) && !(v->arch.hvm_vcpu.guest_efer & EFER_LME) )
+{
+struct segment_register cs;
+
+hvm_get_segment_register(v, x86_seg_cs, );
+
+/*
+ * %cs may be loaded with both .D and .L set in legacy mode, and both
+ * are captured in the VMCS/VMCB.
+ *
+ * If a guest does this and then tries to transition into long mode,
+ * the vmentry from setting LME fails due to invalid guest state,
+ * because %cr0.PG is still clear.
+ *
+ * When LME becomes set, clobber %cs.L to keep the guest firmly in
+ * compatibility mode until it reloads %cs itself.
+ */
+if ( cs.attr.fields.l )
+{
+cs.attr.fields.l = 0;
+hvm_set_segment_register(v, x86_seg_cs, );
+}
+}
+
 if ( nestedhvm_enabled(v->domain) && cpu_has_svm &&
((value & EFER_SVME) == 0 ) &&
((value ^ v->arch.hvm_vcpu.guest_efer) & EFER_SVME) )
-- 
2.1.4


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

[Xen-devel] [PATCH 1/2] x86/hvm: Correct the position of the %cs L/D checks

[Andrew Cooper]

Contrary to the description in the software manuals, in Long Mode, attempts to
load %cs check that D is not set in combination with L before the present flag
is checked.

This can be observed because the L/D check fails with #GP before the presence
check failes with #NP

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 793ce30..b23cd99 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1405,6 +1405,14 @@ protmode_load_seg(
/* Non-conforming segment: check RPL and DPL against CPL. */
: rpl > cpl || dpl != cpl )
 goto raise_exn;
+/*
+ * 64-bit code segments (L bit set) must have D bit clear.
+ * Experimentally in long mode, the L and D bits are checked before
+ * the Present bit.
+ */
+if ( in_longmode(ctxt, ops) &&
+ (desc.b & (1 << 21)) && (desc.b & (1 << 22)) )
+goto raise_exn;
 sel = (sel ^ rpl) | cpl;
 break;
 case x86_seg_ss:
@@ -1444,11 +1452,6 @@ protmode_load_seg(
 goto raise_exn;
 }
 
-/* 64-bit code segments (L bit set) must have D bit clear. */
-if ( seg == x86_seg_cs && in_longmode(ctxt, ops) &&
- (desc.b & (1 << 21)) && (desc.b & (1 << 22)) )
-goto raise_exn;
-
 /* Ensure Accessed flag is set. */
 if ( a_flag && !(desc.b & a_flag) )
 {
-- 
2.1.4


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

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Jan Beulich]

>>> On 13.10.16 at 17:40,  wrote:
> On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich  wrote:
> [..]
>>> I think we can do the similar for Xen, like to lay another pseudo
>>> device on /dev/pmem and do the reservation, like 2. in my previous
>>> reply.
>>
>> Well, my opinion certainly doesn't count much here, but I continue to
>> consider this a bad idea. For entities like drivers it may well be
>> appropriate, but I think there ought to be an independent concept
>> of "OS reserved", and in the Xen case this could then be shared
>> between hypervisor and Dom0 kernel. Or if we were to consider Dom0
>> "just a guest", things should even be the other way around: Xen gets
>> all of the OS reserved space, and Dom0 needs something custom.
> 
> You haven't made the case why Xen is special and other applications of
> persistent memory are not.

Well, I'm implying this from there being a special Linux reservation.
Xen (as explained by Andrew) sitting underneath the Dom0 kernel
(other than ...

>  The current struct page reservation
> supports fundamental address-ability of persistent memory namespaces
> for the rest of the kernel.  The Xen reservation is application
> specific.  XFS, EXT4, and DM also have application specific usages of
> persistent memory and consume metadata space out of a block device. If
> we don't need an XFS-mode nvdimm device, why do we need Xen-mode?

... all the examples you give) by implication is special then too. If
you made the kernel be no different than the other examples you
give, Xen probably shouldn't be any different anymore either.

Jan


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

[Xen-devel] [PATCH v2 3/3] docs: RTDS feature document.

[Dario Faggioli]

Signed-off-by: Dario Faggioli 
---
Cc: Meng Xu 
Cc: George Dunlap 
Cc: Wei Liu 
Cc: Lars Kurth 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
---
Changes from v1:
* file renamed from rtds.pandoc to sched_rtds.pandoc;
* feature name is now 'RTDS Scheduler';
* kill the 'e.g.'-s in the header (sorry!);
* removed 'Architecture' line from header, as this is arch independent;
* removed some text that was duplicated in other sched feature documents;
  it's redundant wrt what's in the wiki about schedulers, and the page
  is referenced.
---
 docs/features/sched_rtds.pandoc |  121 +++
 1 file changed, 121 insertions(+)
 create mode 100644 docs/features/sched_rtds.pandoc

diff --git a/docs/features/sched_rtds.pandoc b/docs/features/sched_rtds.pandoc
new file mode 100644
index 000..2843d97
--- /dev/null
+++ b/docs/features/sched_rtds.pandoc
@@ -0,0 +1,121 @@
+% RTDS Scheduler
+% Revision 1
+
+\clearpage
+
+# Basics
+ 
+ Status: **Experimental**
+
+  Component: Hypervisor
+ 
+
+# Overview
+
+RTDS is one of the virtual CPU (vCPU) scheduler available in the Xen
+hypervisor.
+
+RTDS is a real--time scheduler, so its purpose is enabling
+**deterministic** scheduling of the virtual machine's vCPUs. It has
+been originally developed in the context of the RT-Xen project.
+
+# User details
+
+RTDS is not in use by default. In order to use it as the Xen scheduler
+the following parameter should be passed to the hypervisor at boot:
+
+`sched=rtds`
+
+Once the system is live, for creating a cpupool with RTDS as its
+scheduler, either compile a cpupool configuration file, as described
+in `docs/man/xlcpupool.cfg.pod.5` (and as exemplified in
+`tools/examples/cpupool`), or use just `xl` directly:
+
+xl cpupool-create name=\"pool-rt\" sched=\"rtds\" cpus=[4,5,6,8]
+
+For checking or changing a VM's scheduling parameters from xl, do
+as follows:
+* `xl sched-rtds -d vm-rt`
+* `xl sched-rtds -d vm-rt -t 1 -b 25000`
+
+It is possible, for a multiple vCPUs VM, to change the parameters of
+each vCPU individually:
+* `xl sched-rtds -d vm-rt -v 0 -p 2 -b 1 -v 1 -p 45000 -b 12000`
+
+# Technical details
+
+Implementation entirely lives in the hypervisor. Xen has a pluggable,
+hook based, architecture for schedulers. Thanks to this, RTDS code
+is all contained in `xen/common/sched_rtds.c`.
+
+In libxl, the availability of the RTDS scheduler is advertised by
+the presence of the LIBXL\_HAVE\_SCHED\_RTDS symbol. The ability of
+specifying different scheduling parameters for each vcpu has been
+introduced later, and is available if the following symbols are defined:
+* `LIBXL\_HAVE\_VCPU\_SCHED\_PARAMS`,
+* `LIBXL\_HAVE\_SCHED\_RTDS\_VCPU\_PARAMS`.
+
+# Limitations
+
+RTDS is a special purpose scheduling. This is by design, and not at
+all a limitation, but it is certainly something to keep in mind when
+thinking about using it. The purpose of the scheduler is enabling
+deterministic and statically analyzable behavior (as per the
+real-time academic literature), according to the scheduling parameters
+assigned to each vCPU.
+
+Using RTDS a the Xen scheduler, and/or for general purpose workloads
+is definitely possible, but the vCPU scheduling parameters (of both
+Domain0 and of the various VMs) would probably require tweaking, with
+respect to their default values.
+
+# Testing
+
+Any change done in RTDS must be tested by doing the following:
+
+* create a cpupool with RTDS as its scheduler,
+* create a few virtual machines a move them in and out of the pool,
+* create a few virtual machines, directly inside the pool, and verify
+  that they boot and can run some basic workload (e.g., login into them
+  and run simple commands),
+* shutdown/reboot the virtual machines,
+
+The fact that the system boots fine when passing `sched=rtds` to Xen
+should also be verified.
+
+Finally, to check that the scheduler is working properly (although only
+at a macroscopic level), the following should be done:
+
+* create a VM with 1 vCPU and put it in the RTDS cpupool,
+* set the scheduling parameters such as it has a 50% reservation, with
+  `xl sched-rtds -d vm -t 10 -b 5`,
+* run a CPU-burning process inside the VM (e.g., `yes`),
+* check with `xentop` (in Domain0) that the VM is getting no more than
+  50% pCPU time.
+
+# Areas for improvement
+
+* Work-conserving mode to be added;
+* performance assessment, especially focusing on what level of real-time
+  behavior the scheduler enables.
+
+# Known issues
+
+* OSSTest reports