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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 8bb61740d47b0788bc313f113cbad4a78b55101e
baseline version:
 ovmf f4ac4354652b2bcf4f138b5ebd79b2f07710d4ef

Last test of basis   109316  2017-05-11 13:46:34 Z0 days
Testing same since   109337  2017-05-12 03:16:58 Z0 days1 attempts


People who touched revisions under test:
  Ruiyu Ni 

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=8bb61740d47b0788bc313f113cbad4a78b55101e
+ . ./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 
8bb61740d47b0788bc313f113cbad4a78b55101e
+ branch=ovmf
+ revision=8bb61740d47b0788bc313f113cbad4a78b55101e
+ . ./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.8-testing
+ '[' x8bb61740d47b0788bc313f113cbad4a78b55101e = 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] Added 5 additional Design sessions to Developer Summit Schedule

[Zhang, Yu C]

Thanks for pointing out, Yi. Our names may be confusing. :-)
And yes, I will have a discussion session on 5 level paging enabling with 
Juergen. 

B.R.
Yu 

> -Original Message-
> From: Yi Sun [mailto:yi.y@linux.intel.com]
> Sent: Friday, May 12, 2017 10:25 AM
> To: Lars Kurth
> Cc: xen-devel; Juergen Gross; Huang, Kai; Liu, Yi L; Sun, Yi Y; Zhang, Yu C
> Subject: Re: [Xen-devel] Added 5 additional Design sessions to Developer
> Summit Schedule
> 
> Hi, Lars,
> 
> Thank you very much! One correction below.
> 
> On 17-05-11 18:17:41, Lars Kurth wrote:
> > Hi everyone,
> >
> > I added the following sessions to the Design Part of the Summit: you can
> see them via
> https://xendeveloperanddesignsummit2017.sched.com/overview/type/Inte
> ractive+Design+%26+Problem+Solving+Session (just showing Design
> sessions)
> >
> > Please also make use of the "Add to my Sched(ule)" feature in
> https://xendeveloperanddesignsummit2017.sched.com: this will help me
> identify scheduling conflicts *before* the event and will make the event
> smoother: in other words we can make scheduling decisions using real data,
> before the event.
> >
> > Added Sessions:
> >
> > July 12
> > ===
> > Design Discussion: Intel New QoS (RDT) Features - Yi Sun, Intel
> >
> > Design Discussion: SGX virtualization - Kai Huang, Intel
> >
> > Design Discussion: Support for 5-level paging (including support for PV-
> guests) - Yi Liu, Intel & Jürgen Groß, SUSE
> > Note: We merged a proposal from Yi and Jürgen. If we need more time, we
> can add another session on the 13th
> >
> Should be "Yu Zhang, Intel".
> 
> > July 13
> > ===
> > Design Discussion: Shared Virtual Memory Virtualization Implementation
> on Xen - Yi Liu, Intel
> >
> > Best Regards
> > Lars
> > ___
> > 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] [linux-4.9 test] 109317: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2   6 xen-boot fail REGR. vs. 107358

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail in 109296 
pass in 109317
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 109296 
pass in 109317
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail in 109296 
pass in 109317
 test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail 
pass in 109296
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 16 guest-stop fail pass in 109296
 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail pass in 
109296
 test-amd64-amd64-amd64-pvgrub  9 debian-di-install fail pass in 109296
 test-amd64-amd64-xl-qemut-winxpsp3 17 guest-start/win.repeat fail pass in 
109296

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 107358
 test-amd64-amd64-xl-rtds  9 debian-install   fail REGR. vs. 107358

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail like 107358
 test-armhf-armhf-libvirt-raw  6 xen-boot fail  like 107358
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-start/win.repeat fail like 107358
 test-armhf-armhf-xl-rtds  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-xsm   6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-vhd   6 xen-boot fail  like 107358
 test-armhf-armhf-xl   6 xen-boot fail  like 107358
 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-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   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-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass

version targeted for testing:
 linux89f3b8d5f264d5dab9818c6667c71e3cc55b13f5
baseline version:
 linux37feaf8095d352014555b82adb4a04609ca17d3f

Last test of basis   107358  2017-04-10 19:42:52 Z   31 days
Failing since107396  2017-04-12 11:15:19 Z   29 days   50 attempts
Testing same since   109171  2017-05-08 09:58:59 Z3 days7 attempts


334 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] Added 5 additional Design sessions to Developer Summit Schedule

[Yi Sun]

Hi, Lars,

Thank you very much! One correction below.

On 17-05-11 18:17:41, Lars Kurth wrote:
> Hi everyone,
> 
> I added the following sessions to the Design Part of the Summit: you can see 
> them via 
> https://xendeveloperanddesignsummit2017.sched.com/overview/type/Interactive+Design+%26+Problem+Solving+Session
>  (just showing Design sessions)
> 
> Please also make use of the "Add to my Sched(ule)" feature in 
> https://xendeveloperanddesignsummit2017.sched.com: this will help me identify 
> scheduling conflicts *before* the event and will make the event smoother: in 
> other words we can make scheduling decisions using real data, before the 
> event.
> 
> Added Sessions:
> 
> July 12
> ===
> Design Discussion: Intel New QoS (RDT) Features - Yi Sun, Intel   
>   
> Design Discussion: SGX virtualization - Kai Huang, Intel
> 
> Design Discussion: Support for 5-level paging (including support for 
> PV-guests) - Yi Liu, Intel & Jürgen Groß, SUSE 
> Note: We merged a proposal from Yi and Jürgen. If we need more time, we can 
> add another session on the 13th
> 
Should be "Yu Zhang, Intel".

> July 13
> ===
> Design Discussion: Shared Virtual Memory Virtualization Implementation on Xen 
> - Yi Liu, Intel
> 
> Best Regards
> Lars
> ___
> 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] [linux-linus test] 109315: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-pvh-intel  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-pair  9 xen-boot/src_host fail REGR. vs. 59254
 test-amd64-amd64-pair 9 xen-boot/src_host fail REGR. vs. 59254
 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 59254
 test-amd64-amd64-pair10 xen-boot/dst_host fail REGR. vs. 59254
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-libvirt   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. 
vs. 59254
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-bootfail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
59254
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemut-rhel6hvm-amd  6 xen-bootfail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-bootfail REGR. vs. 59254
 test-amd64-amd64-xl-pvh-amd   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-freebsd10-i386  6 xen-bootfail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-win7-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-xsm6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 59254

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qcow2 6 xen-bootfail baseline untested
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot fail baseline untested
 test-amd64-amd64-i386-pvgrub  6 xen-bootfail baseline untested
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host  fail baseline untested
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host  fail baseline untested
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline 
untested
 test-amd64-amd64-pygrub   6 xen-bootfail baseline untested
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline 
untested
 test-amd64-amd64-libvirt-vhd  6 xen-bootfail baseline untested
 test-amd64-i386-rumprun-i386  6 xen-bootfail baseline untested
 test-amd64-i386-xl-raw6 xen-bootfail baseline untested
 test-amd64-amd64-amd64-pvgrub  6 xen-boot   fail baseline untested
 test-amd64-amd64-qemuu-nested-amd  6 xen-boot   fail baseline untested
 

Re: [Xen-devel] [PATCH v2] xen-netfront: avoid crashing on resume after a failure in talk_to_netback()

[David Miller]

From: Vitaly Kuznetsov 
Date: Thu, 11 May 2017 13:58:06 +0200

> Unavoidable crashes in netfront_resume() and netback_changed() after a
> previous fail in talk_to_netback() (e.g. when we fail to read MAC from
> xenstore) were discovered. The failure path in talk_to_netback() does
> unregister/free for netdev but we don't reset drvdata and we try accessing
> it after resume.
> 
> Fix the bug by removing the whole xen device completely with
> device_unregister(), this guarantees we won't have any calls into netfront
> after a failure.
> 
> Signed-off-by: Vitaly Kuznetsov 
> ---
> Changes since v1: instead of cleaning drvdata and checking for it in
> netfront_resume() and netback_changed() remove the device completely with
> device_unregister() [David Miller]

This looks a lot better, applied, thanks!

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  88454e5ece8fc9caa23a2fd377e7dd0fb1043499
baseline version:
 xtf  4e9d243198312a5052725b5380e456a171391de9

Last test of basis   109320  2017-05-11 15:17:41 Z0 days
Testing same since   109327  2017-05-11 22:16:09 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=88454e5ece8fc9caa23a2fd377e7dd0fb1043499
+ . ./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 
88454e5ece8fc9caa23a2fd377e7dd0fb1043499
+ branch=xtf
+ revision=88454e5ece8fc9caa23a2fd377e7dd0fb1043499
+ . ./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.8-testing
+ '[' x88454e5ece8fc9caa23a2fd377e7dd0fb1043499 = 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
++ '[' 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   5 xen-buildfail REGR. vs. 107636
 build-arm64   5 xen-buildfail REGR. vs. 107636
 build-i3865 xen-buildfail REGR. vs. 107636
 build-amd64-xsm   5 xen-buildfail REGR. vs. 107636
 build-amd64   5 xen-buildfail REGR. vs. 107636
 build-armhf-xsm   5 xen-buildfail REGR. vs. 107636
 build-i386-xsm5 xen-buildfail REGR. vs. 107636
 build-armhf   5 xen-buildfail REGR. vs. 107636

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 

[Xen-devel] Building Xen 4.9 for UEFI boot

[Bill Jacobs (billjac)]

Hi

I gather that with 4.9, UEFI secure boot of Xen should be possible.
Is this true?
If so, what are the options for utilizing UEFI secure boot? Do I need a 
MSFT-signed shim or grub? Any special changes required for Xen kernel 
(signing?) or has that been done?

Thanks
-Bill


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  4e9d243198312a5052725b5380e456a171391de9
baseline version:
 xtf  49bbe725286dd7b97974fb7de7be5463673c2ff2

Last test of basis   109184  2017-05-08 18:22:31 Z3 days
Testing same since   109320  2017-05-11 15:17:41 Z0 days1 attempts


People who touched revisions under test:
  Mohit Gambhir 

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=4e9d243198312a5052725b5380e456a171391de9
+ . ./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 
4e9d243198312a5052725b5380e456a171391de9
+ branch=xtf
+ revision=4e9d243198312a5052725b5380e456a171391de9
+ . ./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.8-testing
+ '[' x4e9d243198312a5052725b5380e456a171391de9 = 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
++ '[' 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 17 guest-start/win.repeat fail REGR. 
vs. 109136
 test-amd64-i386-xl-qemuu-winxpsp3 16 guest-stop  fail REGR. vs. 109165

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 109091
 test-amd64-i386-xl-qemut-winxpsp3 16 guest-stop   fail like 109112
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 109165
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail like 109165
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 109165
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 109165
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 109165
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 109165
 test-amd64-i386-libvirt  12 migrate-support-checkfail   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-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-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-libvirt-raw 11 migrate-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-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 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 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  0d1a96043a75b067498a33619e99df1276f4c1b1
baseline version:
 xen  8839be5c1fe339a1310b4e05e88c5a0230b7959d

Last test of basis   109165  2017-05-08 07:17:46 Z3 days
Failing since109186  2017-05-08 19:20:10 Z3 days6 attempts
Testing same since   109269  2017-05-10 16:45:58 Z1 days2 attempts


People who touched 

Re: [Xen-devel] [PATCH v5 2/2] xtf/vpmu: MSR read/write tests for VPMU

[Andrew Cooper]

On 04/05/17 22:33, Mohit Gambhir wrote:
> This patch tests VPMU functionality in the hypervisor on Intel machines.
> The tests write to all valid bits in the MSRs that get exposed to the guests
> when VPMU is enabled. The tests also write invalid values to the bits
> that should be masked and expect the wrmsr call to fault.
>
> The tests are currently unsupported for AMD machines and PV guests.
>
> Signed-off-by: Mohit Gambhir 
> ---
>  tests/vpmu/Makefile |   9 ++
>  tests/vpmu/main.c   | 442 
> 
>  2 files changed, 451 insertions(+)
>  create mode 100644 tests/vpmu/Makefile
>  create mode 100644 tests/vpmu/main.c
>
> diff --git a/tests/vpmu/Makefile b/tests/vpmu/Makefile
> new file mode 100644
> index 000..d457ab8
> --- /dev/null
> +++ b/tests/vpmu/Makefile
> @@ -0,0 +1,9 @@
> +include $(ROOT)/build/common.mk
> +
> +NAME  := vpmu
> +CATEGORY  := functional

I have added an in-development category for uses in cases like this. 
You will pick it up if you rebase (as well as picking up your first
patch, which I've committed).

> +TEST-ENVS := hvm64
> +
> +obj-perenv += main.o
> +
> +include $(ROOT)/build/gen.mk
> diff --git a/tests/vpmu/main.c b/tests/vpmu/main.c

Thinking more about the eventual usecases here, I think this test would
better as vpmu-intel rather than just vpmu.  Were an AMD variant to
eventually appear, it probably wouldn’t share any code, and thus the
test would want to be vpmu-amd instead.

I am less sure about the PV side of things.  I know the interface is
hypercall / shared memory based rather than MSR based, but the
underlying mechanism and values are still the same, so I optimistically
hope they can share the same primary codebase as their HVM counterparts.

> new file mode 100644
> index 000..c2f6dec
> --- /dev/null
> +++ b/tests/vpmu/main.c
> @@ -0,0 +1,442 @@
> 
> +static void test_valid_msr_write(uint32_t idx, uint64_t wval, uint64_t erval)
> +{
> +uint64_t rval = 0;

What are wval, erval or rval?  (I'm trying to make a point, but) you
have a large number of very short, almost identical variable names which
don't convey obvious meanings.

(see below for a suggestion in a context with more explanation)

> +
> +if( wrmsr_safe(idx, wval) )
> +xtf_failure("Fail: wrmsr(0x%08x, 0x%016"PRIx64") got unexpected 
> fault"
> +"\n", idx, wval);

For the sake of line length, I wouldn't bother splitting this string
like this.  However, (again from context), a block of 8 and 16
characters in a wrmsr() expression are obviously hex, so the 0x prefix
doesn't provide any extra useful information.

I'd recommend simply

"Fail: wrmsr(%08x, %016"PRIx64") got unexpected fault\n"

in this case.

> +
> +/* check to see if the values were written correctly */

/* Check to see if the values were written correctly. */ please.

> +if ( rdmsr_safe(idx, ) )
> +xtf_failure("Fail: rdmsr(0x%08x, 0x016%"PRIxPTR") got unexpected 
> fault"
> +"\n", idx, (uintptr_t) );

The pointer to rval is not relevant.  It will be a compile time constant
and has nothing to do with whether the read succeeds or fails.

"Fail: rdmsr(%08x) got unexpected fault\n" is perfectly fine.

> +
> +/* check if read value is equal to expected value */
> +if ( rval != erval )

If the read failed, this check is illogical, as you are not comparing
erval to anything meaningful.  This check needs to be an else clause to
the rdmsr_safe().

In fact, if you had left rval uninitialised, the compiler would have
helped you by pointing out that the comparison used possibly
uninitialised data.

> +xtf_failure("Fail: rdmsr mismatch idx 0x%08x, wval 0x%016"PRIx64
> +", rval 0x%016"PRIx64"\n", idx, wval, rval);

Naming wval and rval in the text might be meaningful to you as the
author of the test, but it isn't meaningful to anyone else looking at
test logs.

This basic naming scheme I have used elsewhere in XTF is based around
expectations, and what you got.  These are mostly context agnostic, but
convey obvious meaning to people reading the code.

Judging by the callers, you appear to be trying to write a specific
value, then confirm that a (possibly different) value gets read back. 
If so, I'd suggest using 'val', 'exp_read' and 'got' as your variables,
and this as the text:

"Fail: rdmsr(%08x) expected %016"PRIx64", got %016"PRIx64"\n"

Finally, doing so should highlight that you aren't printing out the
useful information in the case that the read mismatches with the
expectation.

> +}
> +
> +static void test_invalid_msr_write(uint32_t idx, uint64_t wval)
> +{
> +/* wrmsr_safe must return false after faulting */
> +if( !wrmsr_safe(idx, wval) )
> +xtf_failure("Fail: wrmsr(0x%08x, 0x%016"PRIx64") did not fault.\n", 

The trailing punctuation isn't useful here.

> +idx, wval);
> +}
> +
> +static void 

Re: [Xen-devel] [PATCH v1 07/10] iommu/arm: Add alloc_page_table platform callback

[Oleksandr Tyshchenko]

On Thu, May 11, 2017 at 9:06 PM, Julien Grall  wrote:
> Hi Oleksandr,
Hi Julien

>
>
> On 11/05/17 15:00, Oleksandr Tyshchenko wrote:
>>
>> On Thu, May 11, 2017 at 2:38 PM, Julien Grall 
>> wrote:
>>>
>>> Hi Oleksandr,
>>
>> Hi, Julien
>>
>>>
>>> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:


 From: Oleksandr Tyshchenko 

 The alloc_page_table callback is a mandatory thing
 for the IOMMUs that don't share page table with the CPU on ARM.
 The non-shared IOMMUs have to perform all required actions here
 to be ready to handle IOMMU mapping updates right after completing it.

 The arch_iommu_populate_page_table() seems an appropriate place
 to call newly created callback.
 Since we will only be here for the non-shared IOMMUs always
 return error if the callback wasn't implemented.
>>>
>>>
>>>
>>> Why do you need a specific callback and not doing it directly in
>>> iommu_domain_init?
>>>
>>> My take here is in the unshare case, we may want to have multiple set of
>>> page tables (e.g one per device). So this should be left at the
>>> discretion
>>> of the IOMMU itself.
>>>
>>> Am I missing something?
>>
>> I was thinking about extra need_iommu argument for init platform
>> callback as I had done for iommu_domain_init API.
>> But I had doubts regarding hw_domain. During iommu_domain_init
>> execution we haven't known yet is the IOMMU expected for domain 0
>> or not.
>>
>> Taking into account that I needed to:
>> - populate page table followed by setting need_iommu flag.
>> - implement arch_iommu_populate_page_table() on ARM because of
>> !iommu_use_hap_pt(d).
>> - find a solution for hw_domain.
>>
>> I decided to use iommu_construct() and implement alloc_page_table
>> callback to be called for populating page table.
>> I thought that it would allow us to keep all required actions in a
>> single place rather than spreading.
>
>
> Looking at your patch #8, you always allocate the page table for hardware
> domain, so this is very similar to set iommu_enable in
> xen_arch_domain_config (see config. in start_xen).
Indeed.

I allocate page table for hw_domain only if need_iommu flag is set.
The need_iommu flag depends on iommu_dom0_strict.
We force iommu_dom0_strict to true.
This all means that we always use iommu for hw_domain)

So, you proposed to avoid new callback and allocate page table
directly in "init" callback?
This also means we have to add extra need_iommu argument to "init" callback.

>
> So this does not hold to me. Maybe Jan (IOMMU maintainer) has a different
> view on it.
>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

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

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

[Volodymyr Babchuk]

Stefano,

>> We, here at EPAM, viewed EL0 apps primarily as a way to extend
>> hypervisor. Because when it comes to embedded and automotive, there
>> arise some ugly things, that are needed at hypervisor level:
>> TEE mediators (OP-TEE is a good TEE, but for example there is TI's
>> MSHIELD with deeply proprietary license), device drivers for vcopros,
>> device drivers for cpufreq, and so on.
>> Some of this things can't be included in hypervisor due to legal
>> issues, some - because of code size or complexity. And we can't run
>> them in stubdoms, because stubdoms are slow for certain use-cases, in
>> some cases they are insecure, in some cases they just don't fit at
>> all.
> I can see that stubdoms can be slow if you require very low latencies.
> Scheduler optimizations (giving stubdoms an higher priority) might be
> able to improve on those.
Yeah, when I wrote "slow" I actually meant "have high latency". Thank
you for correction. Yep, they can be improved to a certain limit.

> But they are not insecure. Also, in what cases they don't fit at all?
About security... I had in mind that case, that we discussed on
community call: secure boot. Say, we put OP-TEE mediator into stubdom.
But as it is sensitive thing, we need to a) check it's signature, b)
create this stubdom before dom0 construction. From other points it as
secure as any other domain.

Regarding "don't fit at all": the virtual coprocessors use-case. I
don't see how we can put vGPU driver into a stubdomain.


>> On other hand you consider EL0 apps as ideal host for emulators only.
>
> Yes, EL0 apps are ideal for emulators, but not just emulators, anything
> that runs deterministically after a guest trap or a timer event could be
> a decent fit for an EL0 app. The issue is the interface between EL0 app
> and Xen, but that can be discussed and designed in a way to satisfy all
> parties.
Okay, we need to discuss it, but looks like this definition covers all
our use-cases.

> But we need to start from somewhere. I suggest you write a simple design
> document to explain the use-case for EL0 apps and their interfaces to
> the rest of the system. We can take the discussion from there. We might
> be able to reach a consensus on a design that works for everybody.
>
> We need a concrete proposal to start from though.
Yes, I agree. Now, when we have discussed this in ML, I have better
vision on this topic. I'll try to present some design document in the
next week.

>> I can see your point, because XEN was always viewed as hypervisor for
>> servers.
>>
>> But servers have different requirements in comparison to embedded
>> applications. Traditional servers does not use hardware accelerated
>> video decoders, they don't need to disable cpu's or scale frequencies
>> to preserve energy (okay, they need to, but it is not as pressing, as
>> on battery-powered device), there almost no proprietary code (or even
>> proprietary blobs, argh!).
>> Looks like virtualization on embedded is the next big thing. Linux
>> kernel was able to satisfy both parties. I hope that XEN can do the
>> same.
> I think that this has not much to do with embedded vs server; it's more
> about the need of supporting new, more complex, hardware and firmware
> interfaces.
Yep, this is more precise.

>
>> So, going back to EL0 apps. Honestly, I'd prefer not to use them as
>> extension mechanism. Yes, they provide isolation, but interfacing with
>> them will be painful. Probably we can leave them to emulators only
>> (but as I can see, PL011 emulator is going to be merged right into
>> hypervisor. Will be there need for other emulators?).
>> What I really want to ask: what do you thing about old good modules
>> like ones in linux kernel? There will be no isolation, this is bad.
>> But:
>>  - you can load proprietary modules if you want to
>>  - they are fast
>>  - you can interface with them in a nativest way possible: just call a
>> function
>
> Proprietary modules are a legal minefield. They are best avoided even in
> Linux. Fortunately, both EL0 apps and stubdoms could be proprietary.
> Thus, especially if you have a requirement for running proprietary
> code, it is key to do EL0 apps and/or stubdoms in Xen on ARM.
As you can see, we already discussed this :) Under "proprietary" I
have meant something like "open source, but not compatible with GPL",
and not it-is-so-secret-that-you-need-to-sign-100-NDAs. Anyways, this
is a hard topic and we need to consider it carefully.


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

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

Re: [Xen-devel] [PATCH v9 01/28] ARM: GICv3: setup number of LPI bits for a GICv3 guest

[Julien Grall]

Hi Andre,

On 11/05/17 18:53, Andre Przywara wrote:

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index bd974fb..033dcee 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -400,6 +400,10 @@ typedef uint64_t xen_callback_t;
 #define GUEST_GICV3_GICD_BASE  xen_mk_ullong(0x03001000)
 #define GUEST_GICV3_GICD_SIZE  xen_mk_ullong(0x0001)

+/* TODO: Should this number be a tool stack decision? */
+/* The number of interrupt ID bits a guest (not Dom0) sees. */
+#define GUEST_GICV3_GICD_INTID_BITS 16
+


You don't use this value in this series nor fully support DomU today. 
Please don't include unnecessary things and drop this.



 #define GUEST_GICV3_RDIST_STRIDE   xen_mk_ullong(0x0002)
 #define GUEST_GICV3_RDIST_REGIONS  1


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v9 00/28] arm64: Dom0 ITS emulation

[Julien Grall]

Hi,

On 11/05/17 18:53, Andre Przywara wrote:

The code can also be found on the its/v9 branch here:
git://linux-arm.org/xen-ap.git
http://www.linux-arm.org/git?p=xen-ap.git;a=shortlog;h=refs/heads/its/v9


This branch does not exist :/

Cheers,

--
Julien Grall

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

[Xen-devel] arm64: incorrect pa setup cause dom0 boot failure

[Feng Kan]

Ian:

Just a quick question regarding the table below in xen/arch/arm/p2m.c
@@ -1479,7 +1487,7 @@ void __init setup_virt_paging(void)
[0] = { 32,  32/*32*/,  0,  1 },
[1] = { 36,  28/*28*/,  0,  1 },
[2] = { 40,  24/*24*/,  1,  1 },
-[3] = { 42,  24/*22*/,  1,  1 },
+[3] = { 42,  22/*22*/,  1,  1 },
^^^ Is this just a typo, or its there for a reason, as I see you made
a comment regarding this later.
We do have a system that PA is 42 bits, so I think that would make the
statement below invalid?
[4] = { 44,  20/*20*/,  0,  2 },
[5] = { 48,  16/*16*/,  0,  2 },
[6] = { 0 }, /* Invalid */


@@ -220,9 +222,11 @@ static lpae_t *p2m_get_root_pointer(struct p2m_domain *p2m,
root_table = gfn_x(gfn) >> (level_orders[P2M_ROOT_LEVEL - 1]);
root_table &= LPAE_ENTRY_MASK;

-if ( root_table >= P2M_ROOT_PAGES )
-return NULL;
+//if ( root_table >= P2M_ROOT_PAGES )
+//return NULL;
^^^ at least for 42 bit case?

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

[Xen-devel] xl list command hangs

[Praveen Kumar]

Hi All,

I am working with latest xen code base ( Unstable branch ). Tried with
no changes / commit from my end, and was facing the hang issue while
running xl list command. I tried doing make world and installing the
packages, but still the problem persists. There we not any specific
logs in xl dmesg when I ran the command.

Has anyone observed this issue ? Please provide pointer how I can
resolve this issue. Thanks in advance.

Below are the snapshot / machine details :


praveen@praveen-Aspire-E5-573G:~$ sudo xl list
NameID   Mem VCPUs  State
Time(s)


praveen@praveen-Aspire-E5-573G:~$ ps -ef | grep xl
root  2316  2065  0 23:40 pts/800:00:00 sudo xl list
root  2317  2316  0 23:40 pts/800:00:00 xl list
praveen   2494  2379  0 23:42 pts/900:00:00 grep --color=auto xl

praveen@praveen-Aspire-E5-573G:~$ sudo cat /proc/2317/stack
[] xenbus_dev_request_and_reply+0x26/0x90
[] xenbus_file_write+0x29b/0x590
[] __vfs_write+0x18/0x40
[] vfs_write+0xa9/0x1a0
[] SyS_write+0x55/0xc0
[] entry_SYSCALL_64_fastpath+0x16/0x71
[] 0x

praveen@praveen-Aspire-E5-573G:~/xen$ sudo xl info
host   : praveen-Aspire-E5-573G
release: 4.4.0-75-generic
version: #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017
machine: x86_64
nr_cpus: 4
max_cpu_id : 7
nr_nodes   : 1
cores_per_socket   : 2
threads_per_core   : 2
cpu_mhz: 2394
hw_caps:
bfebfbff:77faf3bf:2c100800:0121:0001:001c27ab::0100
virt_caps  : hvm hvm_directio
total_memory   : 8111
free_memory: 128
sharing_freed_memory   : 0
sharing_used_memory: 0
outstanding_claims : 0
free_cpus  : 0
xen_major  : 4
xen_minor  : 9
xen_extra  : -rc
xen_version: 4.9-rc
xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler  : credit2
xen_pagesize   : 4096
platform_params: virt_start=0x8000
xen_changeset  : Fri May 5 17:09:49 2017 +0200 git:8839be5
xen_commandline: placeholder sched=credit2
credit2_runqueue=core
cc_compiler: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0
20160609
cc_compile_by  : root
cc_compile_domain  : 
cc_compile_date: Thu May 11 23:35:54 IST 2017
build_id   : 37f8c3a2577cc5321e907ff5be1c9066ecd615b2
xend_config_format : 4

Regards,

~Praveen.

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

Re: [Xen-devel] [PATCH v1 05/10] iommu/arm: Re-define iommu_use_hap_pt(d) as iommu_hap_pt_share

[Oleksandr Tyshchenko]

On Thu, May 11, 2017 at 8:58 PM, Julien Grall  wrote:
>
>
> On 11/05/17 15:38, Oleksandr Tyshchenko wrote:
>>
>> On Thu, May 11, 2017 at 2:28 PM, Julien Grall 
>> wrote:
>>>
>>> Hi Oleksandr,
>>
>> Hi Julien
>
>
> Hi Oleksandr,
>
>
>>>
>>> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:


 From: Oleksandr Tyshchenko 

 Not every integrated into ARM SoCs IOMMU can share page tables
 with the CPU and as result the iommu_use_hap_pt(d) is not always true.
 Reuse x86's iommu_hap_pt_share flag to indicate whether the IOMMU
 page table is shared or not.

 Now all IOMMU drivers on ARM are able to change this flag
 according to their possibilities like x86-variants do.
 Therefore set iommu_hap_pt_share flag for SMMU because it always shares
 page table with the CPU.

 Signed-off-by: Oleksandr Tyshchenko 
 ---
  xen/drivers/passthrough/arm/smmu.c | 3 +++
  xen/include/asm-arm/iommu.h| 7 +--
  2 files changed, 8 insertions(+), 2 deletions(-)

 diff --git a/xen/drivers/passthrough/arm/smmu.c
 b/xen/drivers/passthrough/arm/smmu.c
 index 527a592..86ee12a 100644
 --- a/xen/drivers/passthrough/arm/smmu.c
 +++ b/xen/drivers/passthrough/arm/smmu.c
 @@ -2870,6 +2870,9 @@ static __init int arm_smmu_dt_init(struct
 dt_device_node *dev,

 platform_features &= smmu->features;

 +   /* Always share P2M table between the CPU and the SMMU */
 +   iommu_hap_pt_share = true;
 +
>>>
>>>
>>>
>>> I would prefer to bail-out if someone try to unshare the page-table
>>> rather
>>> than overriding. This would help us to know if someone are try to do
>>> that.
>>>
>>> So I would do:
>>>
>>> if ( !iommu_hap_pt_share )
>>> {
>>> printk()
>>> return -EINVAL;
>>> }
>>
>> I got it for SMMU.
>>
>> But, for IPMMU we will override since iommu_hap_pt_share is true by
>> default. Right?
>>
>> /*
>> * The IPMMU can't reuse P2M table since it only supports
>> * stage-1 page tables.
>> */
>> iommu_hap_pt_share = false;
>
>
> Good point. Looking at the other driver, they print a message to notify the
> override. (See drivers/passthrough/amd/iommu_init.c for instance).
I will print a message too.

>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

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

Re: [Xen-devel] [PATCH v1 10/10] xen/arm: domain_build: Don't expose the "iommus" property to the guest

[Julien Grall]

On 11/05/17 19:19, Oleksandr Tyshchenko wrote:

On Thu, May 11, 2017 at 9:07 PM, Julien Grall  wrote:

This property is used to translate an RID into a Master ID (see the
documentation in bindings/pci/pci-iommu.txt).

So, these two should be skipped too:
- iommu-map
- iommu-map-mask

Right?


Yep.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v1 10/10] xen/arm: domain_build: Don't expose the "iommus" property to the guest

[Oleksandr Tyshchenko]

On Thu, May 11, 2017 at 9:07 PM, Julien Grall  wrote:
>
>
> On 11/05/17 15:15, Oleksandr Tyshchenko wrote:
>>
>> On Thu, May 11, 2017 at 2:58 PM, Julien Grall 
>> wrote:
>>>
>>> Hi Oleksandr,
>>
>> Hi Julien
>
>
> Hi,
>
>
>>>
>>> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:


 From: Oleksandr Tyshchenko 

 We don't passthrough IOMMU device to DOM0 even if it is not used by
 Xen. Therefore exposing the property that describes the IOMMU
 master interfaces of the device does not make any sense.

 Signed-off-by: Oleksandr Tyshchenko 
 ---
  xen/arch/arm/domain_build.c | 4 
  1 file changed, 4 insertions(+)

 diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
 index 3abacc0..2defb60 100644
 --- a/xen/arch/arm/domain_build.c
 +++ b/xen/arch/arm/domain_build.c
 @@ -432,6 +432,10 @@ static int write_properties(struct domain *d,
 struct
 kernel_info *kinfo,
  continue;
  }

 +/* Don't expose the property "iommus" to the guest */
 +if ( dt_property_name_is_equal(prop, "iommus") )
 +continue;
>>>
>>>
>>>
>>> It would be useful to have a link to the bindings associated
>>> (Documentation/devicetree/bindings/iommu/iommu.txt).
>>
>> Agree. I will mention it in commit description.
>>
>>>
>>> Also, whilst you are at it, you likely want to remove all the other iommu
>>> properties such as iommu-map.
>>
>> Excuse me, I have never heard about it. Is it a required property?
>
>
> This property is used to translate an RID into a Master ID (see the
> documentation in bindings/pci/pci-iommu.txt).
So, these two should be skipped too:
- iommu-map
- iommu-map-mask

Right?

>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 71289

Regressions which are regarded as allowable (not blocking):
 build-amd64-libvirt   5 libvirt-buildfail   like 71289
 build-i386-libvirt5 libvirt-buildfail   like 71289

version targeted for testing:
 ovmf f4ac4354652b2bcf4f138b5ebd79b2f07710d4ef
baseline version:
 ovmf 29dc8aa861fac78c6d62391dff312db934b755e3

Last test of basis71289  2017-05-11 13:46:38 Z0 days
Testing same since71291  2017-05-11 16:46:42 Z0 days1 attempts


People who touched revisions under test:
  Jeff Westfahl 
  Ruiyu Ni 

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



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

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

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


Push not applicable.


commit f4ac4354652b2bcf4f138b5ebd79b2f07710d4ef
Author: Jeff Westfahl 
Date:   Fri May 5 05:53:04 2017 +0800

ShellPkg/HandleParsingLib: Show LoadedImageProtocol file name

This patch adds support for showing the file name associated with a
LoadedImageProtocol file path. This is a behavior that was present in
the old shell but has been lost in the new shell.

For example, using 'dh -v' in the old shell:

Handle D3 (3A552218)
Image (3A54C918)   File:MicrocodeUpdate
ParentHandle..: 3A666398

vs. the new shell:

D3: 3A552218
LoadedImage
Revision..: 0x1000
ParentHandle..: 3A666398

Here's what the output of 'dh -v' looks like after this patch:

D3: 3A552218
LoadedImage
Name..: MicrocodeUpdate
Revision..: 0x1000
ParentHandle..: 3A666398

This seems like useful information for the shell to display.

Cc: Ruiyu Ni 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Westfahl 
Signed-off-by: Ruiyu Ni 
Reviewed-by: Ruiyu Ni 
Reviewed-by: Jaben Carsey 

commit bbb212afa0f8e33e0b686a1b6ffd85d353eed83d
Author: Jeff Westfahl 
Date:   Fri May 5 05:53:03 2017 +0800

ShellPkg/HandleParsingLib: Open LoadedImageProtocol first

This patch changes the order of operations to make sure we can open the
LoadedImageProtocol before getting the format string. This should not
affect functionality, and makes the next patch easier to review.

Cc: Ruiyu Ni 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Westfahl 
Reviewed-by: Ruiyu Ni 
Reviewed-by: Jaben Carsey 

commit c15323ae2e79ee9b0779b030605d5d4c204d624a
Author: Jeff Westfahl 
Date:   Fri May 5 05:53:02 2017 +0800

ShellPkg/HandleParsingLib: Show LoadedImageProtocol file path as text

This patch adds support for displaying a text representation of the file
path associated with a LoadedImageProtocol. This is a behavior that was
present in the old shell but has been lost in the new shell.

For example, using 'dh -v' in the old shell:

FilePath..: FvFile(F3331DE6-4A55-44E4-B767-7453F7A1A021)
FilePath..: \EFI\BOOT\BOOTX64.EFI

vs. the new shell:

FilePath..: 3A539018

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

[Volodymyr Babchuk]

George,

On 11 May 2017 at 20:14, George Dunlap  wrote:
>>> We, here at EPAM, viewed EL0 apps primarily as a way to extend
>>> hypervisor. Because when it comes to embedded and automotive, there
>>> arise some ugly things, that are needed at hypervisor level:
>>> TEE mediators (OP-TEE is a good TEE, but for example there is TI's
>>> MSHIELD with deeply proprietary license),
>
> If you're going to use a deeply proprietary TEE mediator, then you need
> to find yourself a deeply proprietary hypervisor to go along with it --
> either one you pay a license fee for or one you develop yourself.  It
> would almost certainly be cheaper to improve the open-source one than to
> do either of those.
> Or you can try mixing the two and see what happens; but that doesn't
> seem like a very sound legal strategy to me.
Okay, point taken.

>>> ...some [things can't be included in hypervisor] because of code
>>> size or complexity.
>
> Sorry, just to be clear: below you mentioned modules as a solution, and
> given the context this would be included.  So can you expand on what you
> mean that there are things that 1) can't be included in the hypervisor
> because of code size or complexity, but for which 2) loadable modules
> would be a suitable solution?
Well... Device drives? Emulators? For example, if I will write bunch
of good and neat GPL drivers for some SoC and I'll promise to maintain
them, will you include them into upstream?
Or I will write emulator for some arcane device, will it be merged
into upstream?
Real case: I will write OP-TEE mediator for one client and Google
Trusty mediator for other client. Every will have, say, 2,000 lines of
code. Are there changes, that they both will be merged into
hypervisor?

>>> And we can't run
>>> them in stubdoms, because stubdoms are slow for certain use-cases, in
>>> some cases they are insecure, in some cases they just don't fit at
>>> all.
>>> On other hand you consider EL0 apps as ideal host for emulators only.
>>> I can see your point, because XEN was always viewed as hypervisor for
>>> servers.
>>> But servers have different requirements in comparison to embedded
>>> applications. Traditional servers does not use hardware accelerated
>>> video decoders, they don't need to disable cpu's or scale frequencies
>>> to preserve energy (okay, they need to, but it is not as pressing, as
>>> on battery-powered device), there almost no proprietary code (or even
>>> proprietary blobs, argh!).
>>> Looks like virtualization on embedded is the next big thing. Linux
>>> kernel was able to satisfy both parties. I hope that XEN can do the
>>> same.

> For many of these, there are probably technical solutions that we could
> come up with that would allow proprietary content (such as video
> decoders ) that would have suitable performance without needing access
> to the Xen address space.
Yes, we probably can. But any such solution will require some changes
in hypervisor to accommodate it. So, what we are currently doing? We
are discussing such solutions.

> Maybe I'm just not familiar with things, but it's hard for me to imagine
> why you'd need proprietary blobs to disable cpus or scale frequency.
> Are these really such complex activities that it's worth investing
> thousands of hours of developer work into developing proprietary
> solutions that you license?
Okay, I don't know no platform where you need proprietary blob to
scale frequency. And I hope, I never will encounter one.
But I can imagine it: some firmware binary that needs to be uploaded
into PMIC. Can we store this firmware in the hypervisor? I don't know.
I'm not a lawyer.

> Loading proprietary modules into Linux is as illegal as it would be in
> Xen.  Many people obviously do it anyway, but you are really putting
> yourself at a risk of meeting a guy like Patrick McHardy[1], a private
> individual with copyright on the Linux kernel who by some estimates has
> made almost EUR 2m in the last few years suing companies for GPL violations.
Okay, I didn't know that it is illegal to load non-gpl modules into
Linux kernel. Thank you for sharing this knowledge. But now I'm
curios, why there are EXPORT_SYMBOL_GPL() and plain EXPORT_SYMBOL()? I
though it was intended to separate GPL and non-GPL code.
BTW, "non-GPL code" does not mean "closed-source code". It can be
LGPL, MIT, BSD, or Copyleft license. I can imagine proprietary license
which is compatible with BSD, but is incompatible with GPLv2.

Anyways, I have taken your point. No proprietary code in modules. What
about other parts of discussion? Are you against loadable modules in
any fashion? What about native apps?

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

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

Re: [Xen-devel] [PATCH v1 10/10] xen/arm: domain_build: Don't expose the "iommus" property to the guest

[Julien Grall]

On 11/05/17 15:15, Oleksandr Tyshchenko wrote:

On Thu, May 11, 2017 at 2:58 PM, Julien Grall  wrote:

Hi Oleksandr,

Hi Julien


Hi,



On 10/05/17 15:03, Oleksandr Tyshchenko wrote:


From: Oleksandr Tyshchenko 

We don't passthrough IOMMU device to DOM0 even if it is not used by
Xen. Therefore exposing the property that describes the IOMMU
master interfaces of the device does not make any sense.

Signed-off-by: Oleksandr Tyshchenko 
---
 xen/arch/arm/domain_build.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 3abacc0..2defb60 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -432,6 +432,10 @@ static int write_properties(struct domain *d, struct
kernel_info *kinfo,
 continue;
 }

+/* Don't expose the property "iommus" to the guest */
+if ( dt_property_name_is_equal(prop, "iommus") )
+continue;



It would be useful to have a link to the bindings associated
(Documentation/devicetree/bindings/iommu/iommu.txt).

Agree. I will mention it in commit description.



Also, whilst you are at it, you likely want to remove all the other iommu
properties such as iommu-map.

Excuse me, I have never heard about it. Is it a required property?


This property is used to translate an RID into a Master ID (see the 
documentation in bindings/pci/pci-iommu.txt).


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v1 07/10] iommu/arm: Add alloc_page_table platform callback

[Julien Grall]

Hi Oleksandr,

On 11/05/17 15:00, Oleksandr Tyshchenko wrote:

On Thu, May 11, 2017 at 2:38 PM, Julien Grall  wrote:

Hi Oleksandr,

Hi, Julien



On 10/05/17 15:03, Oleksandr Tyshchenko wrote:


From: Oleksandr Tyshchenko 

The alloc_page_table callback is a mandatory thing
for the IOMMUs that don't share page table with the CPU on ARM.
The non-shared IOMMUs have to perform all required actions here
to be ready to handle IOMMU mapping updates right after completing it.

The arch_iommu_populate_page_table() seems an appropriate place
to call newly created callback.
Since we will only be here for the non-shared IOMMUs always
return error if the callback wasn't implemented.



Why do you need a specific callback and not doing it directly in
iommu_domain_init?

My take here is in the unshare case, we may want to have multiple set of
page tables (e.g one per device). So this should be left at the discretion
of the IOMMU itself.

Am I missing something?

I was thinking about extra need_iommu argument for init platform
callback as I had done for iommu_domain_init API.
But I had doubts regarding hw_domain. During iommu_domain_init
execution we haven't known yet is the IOMMU expected for domain 0
or not.

Taking into account that I needed to:
- populate page table followed by setting need_iommu flag.
- implement arch_iommu_populate_page_table() on ARM because of
!iommu_use_hap_pt(d).
- find a solution for hw_domain.

I decided to use iommu_construct() and implement alloc_page_table
callback to be called for populating page table.
I thought that it would allow us to keep all required actions in a
single place rather than spreading.


Looking at your patch #8, you always allocate the page table for 
hardware domain, so this is very similar to set iommu_enable in 
xen_arch_domain_config (see config. in start_xen).


So this does not hold to me. Maybe Jan (IOMMU maintainer) has a 
different view on it.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

[Stefano Stabellini]

On 11/05/17 16:19, Volodymyr Babchuk wrote:
> Hi Stefano,
> 
> On 10 May 2017 at 21:24, Stefano Stabellini  wrote:
> > I just want to point out that the comparision with tasklets is not
> > helpful. Tasklets involve the idle vcpu, which we are trying to step away
> > from because it increases irq latency. Tasklets don't provide any
> > isolation. The context switch model for the idle vcpu and for EL0 apps
> > is different, thus it has a different cost.
> > 
> > I think we shouldn't mention tasklets in this thread any longer.
> Yep, you are right. Let's forget about tasklets and focus on EL0 apps.
> 
> I want summarize political (opposed to technical) part of the discussion.
> 
> We, here at EPAM, viewed EL0 apps primarily as a way to extend
> hypervisor. Because when it comes to embedded and automotive, there
> arise some ugly things, that are needed at hypervisor level:
> TEE mediators (OP-TEE is a good TEE, but for example there is TI's
> MSHIELD with deeply proprietary license), device drivers for vcopros,
> device drivers for cpufreq, and so on.
> Some of this things can't be included in hypervisor due to legal
> issues, some - because of code size or complexity. And we can't run
> them in stubdoms, because stubdoms are slow for certain use-cases, in
> some cases they are insecure, in some cases they just don't fit at
> all.

I can see that stubdoms can be slow if you require very low latencies.
Scheduler optimizations (giving stubdoms an higher priority) might be
able to improve on those.

But they are not insecure. Also, in what cases they don't fit at all?


> On other hand you consider EL0 apps as ideal host for emulators only.

Yes, EL0 apps are ideal for emulators, but not just emulators, anything
that runs deterministically after a guest trap or a timer event could be
a decent fit for an EL0 app. The issue is the interface between EL0 app
and Xen, but that can be discussed and designed in a way to satisfy all
parties.

But we need to start from somewhere. I suggest you write a simple design
document to explain the use-case for EL0 apps and their interfaces to
the rest of the system. We can take the discussion from there. We might
be able to reach a consensus on a design that works for everybody.

We need a concrete proposal to start from though.


> I can see your point, because XEN was always viewed as hypervisor for
> servers.
>
> But servers have different requirements in comparison to embedded
> applications. Traditional servers does not use hardware accelerated
> video decoders, they don't need to disable cpu's or scale frequencies
> to preserve energy (okay, they need to, but it is not as pressing, as
> on battery-powered device), there almost no proprietary code (or even
> proprietary blobs, argh!).
> Looks like virtualization on embedded is the next big thing. Linux
> kernel was able to satisfy both parties. I hope that XEN can do the
> same.

I think that this has not much to do with embedded vs server; it's more
about the need of supporting new, more complex, hardware and firmware
interfaces.


> So, going back to EL0 apps. Honestly, I'd prefer not to use them as
> extension mechanism. Yes, they provide isolation, but interfacing with
> them will be painful. Probably we can leave them to emulators only
> (but as I can see, PL011 emulator is going to be merged right into
> hypervisor. Will be there need for other emulators?).
> What I really want to ask: what do you thing about old good modules
> like ones in linux kernel? There will be no isolation, this is bad.
> But:
>  - you can load proprietary modules if you want to
>  - they are fast
>  - you can interface with them in a nativest way possible: just call a
> function

Proprietary modules are a legal minefield. They are best avoided even in
Linux. Fortunately, both EL0 apps and stubdoms could be proprietary.
Thus, especially if you have a requirement for running proprietary
code, it is key to do EL0 apps and/or stubdoms in Xen on ARM.

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

Re: [Xen-devel] [PATCH v1 05/10] iommu/arm: Re-define iommu_use_hap_pt(d) as iommu_hap_pt_share

[Julien Grall]

On 11/05/17 15:38, Oleksandr Tyshchenko wrote:

On Thu, May 11, 2017 at 2:28 PM, Julien Grall  wrote:

Hi Oleksandr,

Hi Julien


Hi Oleksandr,



On 10/05/17 15:03, Oleksandr Tyshchenko wrote:


From: Oleksandr Tyshchenko 

Not every integrated into ARM SoCs IOMMU can share page tables
with the CPU and as result the iommu_use_hap_pt(d) is not always true.
Reuse x86's iommu_hap_pt_share flag to indicate whether the IOMMU
page table is shared or not.

Now all IOMMU drivers on ARM are able to change this flag
according to their possibilities like x86-variants do.
Therefore set iommu_hap_pt_share flag for SMMU because it always shares
page table with the CPU.

Signed-off-by: Oleksandr Tyshchenko 
---
 xen/drivers/passthrough/arm/smmu.c | 3 +++
 xen/include/asm-arm/iommu.h| 7 +--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c
b/xen/drivers/passthrough/arm/smmu.c
index 527a592..86ee12a 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2870,6 +2870,9 @@ static __init int arm_smmu_dt_init(struct
dt_device_node *dev,

platform_features &= smmu->features;

+   /* Always share P2M table between the CPU and the SMMU */
+   iommu_hap_pt_share = true;
+



I would prefer to bail-out if someone try to unshare the page-table rather
than overriding. This would help us to know if someone are try to do that.

So I would do:

if ( !iommu_hap_pt_share )
{
printk()
return -EINVAL;
}

I got it for SMMU.

But, for IPMMU we will override since iommu_hap_pt_share is true by
default. Right?

/*
* The IPMMU can't reuse P2M table since it only supports
* stage-1 page tables.
*/
iommu_hap_pt_share = false;


Good point. Looking at the other driver, they print a message to notify 
the override. (See drivers/passthrough/amd/iommu_init.c for instance).


Cheers,

--
Julien Grall

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

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

[Lars Kurth]

> On 11 May 2017, at 18:20, George Dunlap  wrote:
> 
> On Thu, May 11, 2017 at 6:14 PM, Volodymyr Babchuk
>  wrote:
>> Hi George,
>> 
>> On 11 May 2017 at 19:35, George Dunlap  wrote:
>>> Even better would be to skip the module-loading step entirely, and just
>>> compile proprietary code directly into your Xen binary.
>>> 
>>> Both solutions, unfortunately, are illegal.*
>> Look, I don't saying we want to produce closed-source modules or apps.
>> We want to write open source code. Just imagine, that certain header
>> files have some proprietary license (e.g. some device interface
>> definition and this interface is IP of company which developed it).
>> AFAIK, it can't be included into Xen distribution. I thought, that it
>> can be included in some module with different (but still open source)
>> license.  But if you say that it can't... Then I don't know. It is out
>> of my competence. I'm not lawyer also.
> 
> I see.  That's good to know, but it doesn't change the legal aspect of
> things. :-0

The legal issues would be similar to those with Linux Kernel Modules. For more 
information, see 
http://www.ifross.org/en/artikel/license-incompatibility-and-linux-kernel-modules-reloaded

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

Re: [Xen-devel] [PATCH v8 05/27] ARM: GICv3: forward pending LPIs to guests

[Andre Przywara]

Hi Julien,

On 10/05/17 18:17, Julien Grall wrote:
> 
> 
> On 05/10/2017 06:14 PM, Andre Przywara wrote:
>> Hi,
>>
>> On 10/05/17 12:07, Julien Grall wrote:
>>>
>>>
>>> On 05/10/2017 11:47 AM, Andre Przywara wrote:
 Hi,
>>>
>>> Hi Andre,
>>>
 On 12/04/17 11:44, Julien Grall wrote:
> On 12/04/17 01:44, Andre Przywara wrote:
>> +/* Retrieve the priority of an LPI from its struct pending_irq. */
>> +static int vgic_v3_lpi_get_priority(struct domain *d, uint32_t vlpi)
>> +{
>> +struct pending_irq *p = vgic_v3_lpi_to_pending(d, vlpi);
>> +
>> +if ( !p )
>> +return GIC_PRI_IRQ;
>
> Why the check here? And why returning GIC_PRI_IRQ?

 Because you surely want to avoid dereferencing NULL?
 I changed the return value to 0xff, which is the lowest priority.
 Frankly I think we could just return anything, as we will stop handling
 this LPI anyway a bit later in the code if p is NULL here.
>>>
>>> I agree that you want to prevent NULL. But we also want to avoid return
>>> fake value because there was a caller that didn't bother to check
>>> whether the interrupt is valid at first hand.
>>
>> Well, I changed the sequence in vgic_vcpu_inject_irq() back to be:
>>
>> priority = vgic_get_virq_priority(v, virq);
>>
>> spin_lock_irqsave(>arch.vgic.lock, flags);
>> n = irq_to_pending(v, virq);
>>
>> mostly to prevent the locking order (rank vs. VCPU lock) issue you
>> mentioned. We read the latest priority value upfront, but only use it
>> later if the pending_irq is valid. I don't see how this should create
>> problems. Eventually this will be solved properly by the pending_irq
>> lock.
>>
>>> If you ever have NULL here then there is a latent BUG in your code
>>> somewhere else.
>>
>> Not in this case.
> 
> Because of the locking issue? I know there are locking issue, but it
> does not mean we should introduce bad code just for workaround them for
> the time being...

No, because we now (as before) call vgic_get_virq_priority() without any
locks, so anything could happen. And in the spirit of checking *every*
irq_to_pending() call I'd rather protect this case properly (without
trading NULL pointer exceptions for ASSERTs).

Please look at the new code and tell me if you still don't like it.

Cheers,
Andre.

>>
>>> Ignoring the NULL and return a fake value is likely not
>>> the right solution for development.
>>>
>>> I can see two solutions for this:
>>> - ASSERT(p)
>>> - if ( !p )
>>>   {
>>>  ASSERT_UNREACHABLE();
>>>  return 0xff;
>>>   }
>>>
>>> The later would still return a dumb value but at least we would catch
>>> programming mistake during development.
>>
>> I think this solution asks for the ASSERT to trigger in corner cases: If
>> the LPI fired on the host, but got unmapped shortly afterwards. In this
>> case vgic_vcpu_inject_irq() can be reached with an invalid LPI number,
>> and we handle this properly when irq_to_pending() returns NULL.
>> But in this case get_priority() will be called with the same invalid
>> LPI, so should be able to cope with that as well.
>> Again this will eventually be solved properly with the per-IRQ lock.
> 
> See above. I still prefer to see the ASSERT firing time to time than bad
> code going in staging.
> 
> Cheers,
> 

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

[Xen-devel] [PATCH v9 10/28] ARM: GIC: export and extend vgic_init_pending_irq()

[Andre Przywara]

For LPIs we later want to dynamically allocate struct pending_irqs.
So beside needing to initialize the struct from there we also need
to clean it up and re-initialize it later on.
Export vgic_init_pending_irq() and extend it to be reusable.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic.c| 4 +++-
 xen/include/asm-arm/vgic.h | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 66adeb4..27d6b51 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -61,11 +61,13 @@ struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, 
unsigned int irq)
 return vgic_get_rank(v, rank);
 }
 
-static void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
+void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
 {
 INIT_LIST_HEAD(>inflight);
 INIT_LIST_HEAD(>lr_queue);
 p->irq = virq;
+p->status = 0;
+p->lr = GIC_INVALID_LR;
 }
 
 static void vgic_rank_init(struct vgic_irq_rank *rank, uint8_t index,
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 6b17802..e2111a5 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -302,6 +302,7 @@ extern struct vcpu *vgic_get_target_vcpu(struct vcpu *v, 
unsigned int virq);
 extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq);
 extern void vgic_vcpu_inject_spi(struct domain *d, unsigned int virq);
 extern void vgic_clear_pending_irqs(struct vcpu *v);
+extern void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 extern struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq);
 extern struct vgic_irq_rank *vgic_rank_offset(struct vcpu *v, int b, int n, 
int s);
-- 
2.9.0


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

[Xen-devel] [PATCH v9 17/28] ARM: vITS: handle MAPC command

[Andre Przywara]

The MAPC command associates a given collection ID with a given
redistributor, thus mapping collections to VCPUs.
We just store the vcpu_id in the collection table for that.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 47 ++
 1 file changed, 47 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index f9379c9..8f1c217 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -118,6 +118,27 @@ static paddr_t get_baser_phys_addr(uint64_t reg)
  */
 
 /* Must be called with the ITS lock held. */
+static int its_set_collection(struct virt_its *its, uint16_t collid,
+  coll_table_entry_t vcpu_id)
+{
+paddr_t addr;
+
+/* The collection table entry must be able to store a VCPU ID. */
+BUILD_BUG_ON(BIT(sizeof(coll_table_entry_t) * 8) < MAX_VIRT_CPUS);
+
+addr = get_baser_phys_addr(its->baser_coll);
+
+ASSERT(spin_is_locked(>its_lock));
+
+if ( collid >= its->max_collections )
+return -ENOENT;
+
+return vgic_access_guest_memory(its->d,
+addr + collid * sizeof(coll_table_entry_t),
+_id, sizeof(vcpu_id), true);
+}
+
+/* Must be called with the ITS lock held. */
 static struct vcpu *get_vcpu_from_collection(struct virt_its *its,
  uint16_t collid)
 {
@@ -318,6 +339,29 @@ static int its_handle_int(struct virt_its *its, uint64_t 
*cmdptr)
 return 0;
 }
 
+static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t collid = its_cmd_get_collection(cmdptr);
+uint64_t rdbase = its_cmd_mask_field(cmdptr, 2, 16, 44);
+
+if ( collid >= its->max_collections )
+return -1;
+
+if ( rdbase >= its->d->max_vcpus )
+return -1;
+
+spin_lock(>its_lock);
+
+if ( its_cmd_get_validbit(cmdptr) )
+its_set_collection(its, collid, rdbase);
+else
+its_set_collection(its, collid, UNMAPPED_COLLECTION);
+
+spin_unlock(>its_lock);
+
+return 0;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg) ((reg) & GENMASK(19, 5))
 
@@ -350,6 +394,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its)
 case GITS_CMD_INT:
 ret = its_handle_int(its, command);
 break;
+case GITS_CMD_MAPC:
+ret = its_handle_mapc(its, command);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
 break;
-- 
2.9.0


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

[Xen-devel] [PATCH v9 23/28] ARM: vITS: handle DISCARD command

[Andre Przywara]

The DISCARD command drops the connection between a DeviceID/EventID
and an LPI/collection pair.
We mark the respective structure entries as not allocated and make
sure that any queued IRQs are removed.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index ef7c78f..f7a8d77 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -723,6 +723,27 @@ out_unlock:
 return ret;
 }
 
+static int its_handle_discard(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+int ret;
+
+spin_lock(>its_lock);
+
+/* Remove from the radix tree and remove the host entry. */
+ret = its_discard_event(its, devid, eventid);
+
+/* Remove from the guest's ITTE. */
+if ( ret || write_itte_locked(its, devid, eventid,
+  UNMAPPED_COLLECTION, INVALID_LPI, NULL) )
+ret = -1;
+
+spin_unlock(>its_lock);
+
+return ret;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg) ((reg) & GENMASK(19, 5))
 
@@ -755,6 +776,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its)
 case GITS_CMD_CLEAR:
 ret = its_handle_clear(its, command);
 break;
+case GITS_CMD_DISCARD:
+ret = its_handle_discard(its, command);
+break;
 case GITS_CMD_INT:
 ret = its_handle_int(its, command);
 break;
-- 
2.9.0


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

[Xen-devel] [PATCH v9 07/28] ARM: vGICv3: handle virtual LPI pending and property tables

[Andre Przywara]

Allow a guest to provide the address and size for the memory regions
it has reserved for the GICv3 pending and property tables.
We sanitise the various fields of the respective redistributor
registers.
The MMIO read and write accesses are protected by locks, to avoid any
changing of the property or pending table address while a redistributor
is live and also to protect the non-atomic vgic_reg64_extract() function
on the MMIO read side.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/vgic-v3.c   | 164 +++
 xen/include/asm-arm/domain.h |   5 ++
 2 files changed, 157 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 87f58f6..5166f9c 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -233,12 +233,29 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 goto read_reserved;
 
 case VREG64(GICR_PROPBASER):
-/* LPI's not implemented */
-goto read_as_zero_64;
+if ( !v->domain->arch.vgic.has_its )
+goto read_as_zero_64;
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+
+vgic_lock(v);
+*r = vgic_reg64_extract(v->domain->arch.vgic.rdist_propbase, info);
+vgic_unlock(v);
+return 1;
 
 case VREG64(GICR_PENDBASER):
-/* LPI's not implemented */
-goto read_as_zero_64;
+{
+unsigned long flags;
+
+if ( !v->domain->arch.vgic.has_its )
+goto read_as_zero_64;
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+
+spin_lock_irqsave(>arch.vgic.lock, flags);
+*r = vgic_reg64_extract(v->arch.vgic.rdist_pendbase, info);
+*r &= ~GICR_PENDBASER_PTZ;   /* WO, reads as 0 */
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+return 1;
+}
 
 case 0x0080:
 goto read_reserved;
@@ -335,11 +352,95 @@ read_unknown:
 return 1;
 }
 
+static uint64_t vgic_sanitise_field(uint64_t reg, uint64_t field_mask,
+int field_shift,
+uint64_t (*sanitise_fn)(uint64_t))
+{
+uint64_t field = (reg & field_mask) >> field_shift;
+
+field = sanitise_fn(field) << field_shift;
+
+return (reg & ~field_mask) | field;
+}
+
+/* We want to avoid outer shareable. */
+static uint64_t vgic_sanitise_shareability(uint64_t field)
+{
+switch ( field )
+{
+case GIC_BASER_OuterShareable:
+return GIC_BASER_InnerShareable;
+default:
+return field;
+}
+}
+
+/* Avoid any inner non-cacheable mapping. */
+static uint64_t vgic_sanitise_inner_cacheability(uint64_t field)
+{
+switch ( field )
+{
+case GIC_BASER_CACHE_nCnB:
+case GIC_BASER_CACHE_nC:
+return GIC_BASER_CACHE_RaWb;
+default:
+return field;
+}
+}
+
+/* Non-cacheable or same-as-inner are OK. */
+static uint64_t vgic_sanitise_outer_cacheability(uint64_t field)
+{
+switch ( field )
+{
+case GIC_BASER_CACHE_SameAsInner:
+case GIC_BASER_CACHE_nC:
+return field;
+default:
+return GIC_BASER_CACHE_nC;
+}
+}
+
+static uint64_t sanitize_propbaser(uint64_t reg)
+{
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_SHAREABILITY_MASK,
+  GICR_PROPBASER_SHAREABILITY_SHIFT,
+  vgic_sanitise_shareability);
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_INNER_CACHEABILITY_MASK,
+  GICR_PROPBASER_INNER_CACHEABILITY_SHIFT,
+  vgic_sanitise_inner_cacheability);
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_OUTER_CACHEABILITY_MASK,
+  GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT,
+  vgic_sanitise_outer_cacheability);
+
+reg &= ~GICR_PROPBASER_RES0_MASK;
+
+return reg;
+}
+
+static uint64_t sanitize_pendbaser(uint64_t reg)
+{
+reg = vgic_sanitise_field(reg, GICR_PENDBASER_SHAREABILITY_MASK,
+  GICR_PENDBASER_SHAREABILITY_SHIFT,
+  vgic_sanitise_shareability);
+reg = vgic_sanitise_field(reg, GICR_PENDBASER_INNER_CACHEABILITY_MASK,
+  GICR_PENDBASER_INNER_CACHEABILITY_SHIFT,
+  vgic_sanitise_inner_cacheability);
+reg = vgic_sanitise_field(reg, GICR_PENDBASER_OUTER_CACHEABILITY_MASK,
+  GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT,
+  vgic_sanitise_outer_cacheability);
+
+reg &= ~GICR_PENDBASER_RES0_MASK;
+
+return reg;
+}
+
 static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
   uint32_t gicr_reg,
   register_t r)
 {
 struct hsr_dabt dabt = info->dabt;
+uint64_t 

Re: [Xen-devel] [PATCH v8 07/27] ARM: vGICv3: handle virtual LPI pending and property tables

[Andre Przywara]

Hi,

On 12/04/17 14:13, Julien Grall wrote:
> 
> 
> On 12/04/17 14:12, Andre Przywara wrote:
>> Hi,
> 
> Hi,
> 
>>
>> On 12/04/17 11:55, Julien Grall wrote:
>>> Hi Andre,
>>>
>>> On 12/04/17 01:44, Andre Przywara wrote:
 Allow a guest to provide the address and size for the memory regions
 it has reserved for the GICv3 pending and property tables.
 We sanitise the various fields of the respective redistributor
 registers.
 The MMIO read and write accesses are protected by locks, to avoid any
 changing of the property or pending table address while a redistributor
 is live and also to protect the non-atomic vgic_reg64_extract()
 function
 on the MMIO read side.

 Signed-off-by: Andre Przywara 
 Reviewed-by: Julien Grall 
>>>
>>> Whilst I gave my reviewed-by it is very rude to ignore a comment.
>>
>> Yeah, sorry about that! I was unsure about that as well, so thought
>> about it and eventually forgot to answer.
>>
>>> It would have been nicer to answer even if it is just saying "I can add
>>> a TODO and address it in a follow-up patch".
>>>
>>> Please get use to mention all the changes (e.g the spin_*lock ->
>>> spin_*lock_irq* change) you made in a patch. Mainly if you keep a
>>> reviewed-by.
>>
>> I was really unsure about keeping or dropping it, but since you
>> complained about me dropping it last time I tried it the other way this
>> time ;-)
>>
 diff --git a/xen/include/asm-arm/domain.h
 b/xen/include/asm-arm/domain.h
 index ebaea35..b2d98bb 100644
 --- a/xen/include/asm-arm/domain.h
 +++ b/xen/include/asm-arm/domain.h
 @@ -109,11 +109,15 @@ struct arch_domain
  } *rdist_regions;
  int nr_regions; /* Number of rdist
 regions */
  uint32_t rdist_stride;  /* Re-Distributor
 stride */
 +unsigned long int nr_lpis;
 +uint64_t rdist_propbase;
  struct rb_root its_devices; /* Devices mapped to an
 ITS */
  spinlock_t its_devices_lock;/* Protects the
 its_devices tree */
  struct radix_tree_root pend_lpi_tree; /* Stores struct
 pending_irq's */
  rwlock_t pend_lpi_tree_lock;/* Protects the
 pend_lpi_tree */
  unsigned int intid_bits;
 +bool rdists_enabled;/* Is any redistributor
 enabled? */
 +bool has_its;
>>>
>>> The comment you ignore was the one about consolidating rdists_enabled
>>> and has_its in a single field and use flags.
>>
>> Yes, I had the idea myself before, but decided against it as IMHO it
>> looks much nicer this way (compared to using a flags variable. which I
>> guess is what you mean).
>>
>> Are you OK with that?
> 
> Why is it nicer?

Because I think it's more readable to have: "if ( has_its )" than
"if ( flags & HAS_ITS )".

> You only need 1 bit to represent rdist_enabled and
> another for has_its. This would save a bit a space in a resource limited
> structure.

But because of the padding it wouldn't, so I'd keep it as it is.

Cheers,
Andre.

> I would be OK with a TODO so we know we can save space here
> in the future...
> 
> Although, my main point was you not ignore comment and say no if you
> disagree.
> 
> Cheers,
> 

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

[Xen-devel] [PATCH v9 00/28] arm64: Dom0 ITS emulation

[Andre Przywara]

Hi,

this is a reworked version, addressing comments on v8.
After some discussions we came to the conclusion that for properly addressing
all the issues we found we need some more serious rework of the VGIC:
* Protecting a struct pending_irq with the VGIC VCPU lock will not be
sufficient, instead we need a per-IRQ lock.
* The proper answer to avoid a struct pending_irq reference for an LPI to
be freed while it is in use is reference counting.
However it has been decided that these changes (which haven been partially
drafted in an RFC series[1] already) are quite intrusive and need more
time to get in a proper shape. To not loose the effort already spent on the
ITS review, this series is *not* building on these changes, but instead
tries to address all other issues mentioned in the last review round.
It is expected that the VGIC rework is then piled on top of this series.

Beside some smaller changes likes adding ASSERTs or comments there is a new
patch 15/28 to allow access to a struct pending_irq directly from a device
(instead of going via the LPI number). Patch 20/28 got reworked to cover a
corner case where must avoid putting the same LPI number twice into different
LRs. Those two changes required a slight reordering of some of the later
patches (mostly the ITS command emulation).

For a detailed changelog see below.

Cheers,
Andre

--
This series adds support for emulation of an ARM GICv3 ITS interrupt
controller. For hardware which relies on the ITS to provide interrupts for
its peripherals this code is needed to get a machine booted into Dom0 at
all. ITS emulation for DomUs is only really useful with PCI passthrough,
which is not yet available for ARM. It is expected that this feature
will be co-developed with the ITS DomU code. However this code drop here
considered DomU emulation already, to keep later architectural changes
to a minimum.

This is technical preview version to allow early testing of the feature.
Things not (properly) addressed in this release:
- There is only support for Dom0 at the moment. DomU support is only really
useful with PCI passthrough, which is not there yet for ARM.
- The MOVALL command is not emulated. In our case there is really nothing
to do here. We might need to revisit this in the future for DomU support.
- The INVALL command might need some rework to be more efficient. Currently
we iterate over all mapped LPIs, which might take a bit longer.
- Indirect tables are not supported. This affects both the host and the
virtual side.
- The ITS tables inside (Dom0) guest memory cannot easily be protected
at the moment (without restricting access to Xen as well). So for now
we trust Dom0 not to touch this memory (which the spec forbids as well).
- With malicious guests (DomUs) there is a possibility of an interrupt
storm triggered by a device. We would need to investigate what that means
for Xen and if there is a nice way to prevent this. Disabling the LPI on
the host side would require command queuing, which has its downsides to
be issued during runtime.
- Dom0 should make sure that the ITS resources (number of LPIs, devices,
events) later handed to a DomU are really limited, as a large number of
them could mean much time spend in Xen to initialize, free or handle those.
It is expected that the toolstack sets up a tailored ITS with just enough
resources to accommodate the needs of the actual passthrough-ed device(s).
- The command queue locking is currently suboptimal and should be made more
fine-grained in the future, if possible.
- Provide support for running with an IOMMU, to map the doorbell page
to all devices.


Some generic design principles:

* The current GIC code statically allocates structures for each supported
IRQ (both for the host and the guest), which due to the potentially
millions of LPI interrupts is not feasible to copy for the ITS.
So we refrain from introducing the ITS as a first class Xen interrupt
controller, also we don't hold struct irq_desc's or struct pending_irq's
for each possible LPI.
Fortunately LPIs are only interesting to guests, so we get away with
storing only the virtual IRQ number and the guest VCPU for each allocated
host LPI, which can be stashed into one uint64_t. This data is stored in
a two-level table, which is both memory efficient and quick to access.
We hook into the existing IRQ handling and VGIC code to avoid accessing
the normal structures, providing alternative methods for getting the
needed information (priority, is enabled?) for LPIs.
Whenever a guest maps a device, we allocate the maximum required number
of struct pending_irq's, so that any triggering LPI can find its data
structure. Upon the guest actually mapping the LPI, this pointer to the
corresponding pending_irq gets entered into a radix tree, so that it can
be quickly looked up.

* On the guest side we (later will) have to deal with malicious guests
trying to hog Xen with mapping requests for a lot of LPIs, for instance.
As the 

[Xen-devel] [PATCH v9 19/28] ARM: vITS: handle MAPD command

[Andre Przywara]

The MAPD command maps a device by associating a memory region for
storing ITEs with a certain device ID. Since it features a valid bit,
MAPD also covers the "unmap" functionality, which we also cover here.
We store the given guest physical address in the device table, and, if
this command comes from Dom0, tell the host ITS driver about this new
mapping, so it can issue the corresponding host MAPD command and create
the required tables. We take care of rolling back actions should one
step fail.
Upon unmapping a device we make sure we clean up all associated
resources and release the memory again.
We use our existing guest memory access function to find the right ITT
entry and store the mapping there (in guest memory).

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c|  18 +
 xen/arch/arm/gic-v3-lpi.c|  18 +
 xen/arch/arm/vgic-v3-its.c   | 145 +++
 xen/include/asm-arm/gic_v3_its.h |   5 ++
 4 files changed, 186 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index fd6a394..be4c3e0 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -869,6 +869,24 @@ struct pending_irq *gicv3_its_get_event_pending_irq(struct 
domain *d,
 return get_event_pending_irq(d, vdoorbell_address, vdevid, veventid, NULL);
 }
 
+int gicv3_remove_guest_event(struct domain *d, paddr_t vdoorbell_address,
+ uint32_t vdevid, uint32_t veventid)
+{
+uint32_t host_lpi = INVALID_LPI;
+
+if ( !get_event_pending_irq(d, vdoorbell_address, vdevid, veventid,
+_lpi) )
+return -EINVAL;
+
+if ( host_lpi == INVALID_LPI )
+return -EINVAL;
+
+gicv3_lpi_update_host_entry(host_lpi, d->domain_id,
+INVALID_VCPU_ID, INVALID_LPI);
+
+return 0;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 44f6315..d427539 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -207,6 +207,24 @@ out:
 irq_exit();
 }
 
+void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id,
+ unsigned int vcpu_id, uint32_t virt_lpi)
+{
+union host_lpi *hlpip, hlpi;
+
+ASSERT(host_lpi >= LPI_OFFSET);
+
+host_lpi -= LPI_OFFSET;
+
+hlpip = _data.host_lpis[host_lpi / HOST_LPIS_PER_PAGE][host_lpi % 
HOST_LPIS_PER_PAGE];
+
+hlpi.virt_lpi = virt_lpi;
+hlpi.dom_id = domain_id;
+hlpi.vcpu_id = vcpu_id;
+
+write_u64_atomic(>data, hlpi.data);
+}
+
 static int gicv3_lpi_allocate_pendtable(uint64_t *reg)
 {
 uint64_t val;
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 8a200e9..731fe0c 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -175,6 +175,21 @@ static struct vcpu *get_vcpu_from_collection(struct 
virt_its *its,
 #define DEV_TABLE_ENTRY(addr, bits) \
 (((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(4, 0)))
 
+/* Set the address of an ITT for a given device ID. */
+static int its_set_itt_address(struct virt_its *its, uint32_t devid,
+   paddr_t itt_address, uint32_t nr_bits)
+{
+paddr_t addr = get_baser_phys_addr(its->baser_dev);
+dev_table_entry_t itt_entry = DEV_TABLE_ENTRY(itt_address, nr_bits);
+
+if ( devid >= its->max_devices )
+return -ENOENT;
+
+return vgic_access_guest_memory(its->d,
+addr + devid * sizeof(dev_table_entry_t),
+_entry, sizeof(itt_entry), true);
+}
+
 /*
  * Lookup the address of the Interrupt Translation Table associated with
  * that device ID.
@@ -414,6 +429,133 @@ out_unlock:
 return ret;
 }
 
+/* Must be called with the ITS lock held. */
+static int its_discard_event(struct virt_its *its,
+ uint32_t vdevid, uint32_t vevid)
+{
+struct pending_irq *p;
+unsigned long flags;
+struct vcpu *vcpu;
+uint32_t vlpi;
+
+ASSERT(spin_is_locked(>its_lock));
+
+if ( !read_itte_locked(its, vdevid, vevid, , ) )
+return -ENOENT;
+
+if ( vlpi == INVALID_LPI )
+return -ENOENT;
+
+/* Lock this VCPU's VGIC to make sure nobody is using the pending_irq. */
+spin_lock_irqsave(>arch.vgic.lock, flags);
+
+/* Remove the pending_irq from the tree. */
+write_lock(>d->arch.vgic.pend_lpi_tree_lock);
+p = radix_tree_delete(>d->arch.vgic.pend_lpi_tree, vlpi);
+write_unlock(>d->arch.vgic.pend_lpi_tree_lock);
+
+if ( !p )
+{
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+
+return -ENOENT;
+}
+
+/* Cleanup the pending_irq and disconnect it from the LPI. */
+list_del_init(>inflight);
+list_del_init(>lr_queue);
+ 

[Xen-devel] [PATCH v9 03/28] ARM: GIC: Add checks for NULL pointer pending_irq's

[Andre Przywara]

For LPIs the struct pending_irq's are dynamically allocated and the
pointers will be stored in a radix tree. Since an LPI can be "unmapped"
at any time, teach the VGIC how to deal with irq_to_pending() returning
a NULL pointer.
We just do nothing in this case or clean up the LR if the virtual LPI
number was still in an LR.

Those are all call sites for irq_to_pending(), as per:
"git grep irq_to_pending", and their evaluations:
(PROTECTED means: added NULL check and bailing out)

xen/arch/arm/gic.c:
gic_route_irq_to_guest(): only called for SPIs, added ASSERT()
gic_remove_irq_from_guest(): only called for SPIs, added ASSERT()
gic_remove_from_queues(): PROTECTED, called within VCPU VGIC lock
gic_raise_inflight_irq(): PROTECTED, called under VCPU VGIC lock
gic_raise_guest_irq(): PROTECTED, called under VCPU VGIC lock
gic_update_one_lr(): PROTECTED, called under VCPU VGIC lock

xen/arch/arm/vgic.c:
vgic_migrate_irq(): not called for LPIs (virtual IRQs), added ASSERT()
arch_move_irqs(): not iterating over LPIs, added ASSERT()
vgic_disable_irqs(): not called for LPIs, added ASSERT()
vgic_enable_irqs(): not called for LPIs, added ASSERT()
vgic_vcpu_inject_irq(): PROTECTED, moved under VCPU VGIC lock

xen/include/asm-arm/event.h:
local_events_need_delivery_nomask(): only called for a PPI, added ASSERT()

xen/include/asm-arm/vgic.h:
(prototype)

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic.c  | 34 ++
 xen/arch/arm/vgic.c | 24 
 xen/include/asm-arm/event.h |  3 +++
 3 files changed, 57 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index dcb1783..46bb306 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -148,6 +148,7 @@ int gic_route_irq_to_guest(struct domain *d, unsigned int 
virq,
 /* Caller has already checked that the IRQ is an SPI */
 ASSERT(virq >= 32);
 ASSERT(virq < vgic_num_irqs(d));
+ASSERT(!is_lpi(virq));
 
 vgic_lock_rank(v_target, rank, flags);
 
@@ -184,6 +185,7 @@ int gic_remove_irq_from_guest(struct domain *d, unsigned 
int virq,
 ASSERT(spin_is_locked(>lock));
 ASSERT(test_bit(_IRQ_GUEST, >status));
 ASSERT(p->desc == desc);
+ASSERT(!is_lpi(virq));
 
 vgic_lock_rank(v_target, rank, flags);
 
@@ -408,9 +410,13 @@ void gic_remove_from_queues(struct vcpu *v, unsigned int 
virtual_irq)
 spin_lock_irqsave(>arch.vgic.lock, flags);
 
 p = irq_to_pending(v, virtual_irq);
-
-if ( !list_empty(>lr_queue) )
+/*
+ * If an LPIs has been removed meanwhile, it has been cleaned up
+ * already, so nothing to remove here.
+ */
+if ( likely(p) && !list_empty(>lr_queue) )
 list_del_init(>lr_queue);
+
 spin_unlock_irqrestore(>arch.vgic.lock, flags);
 }
 
@@ -418,6 +424,10 @@ void gic_raise_inflight_irq(struct vcpu *v, unsigned int 
virtual_irq)
 {
 struct pending_irq *n = irq_to_pending(v, virtual_irq);
 
+/* If an LPI has been removed meanwhile, there is nothing left to raise. */
+if ( unlikely(!n) )
+return;
+
 ASSERT(spin_is_locked(>arch.vgic.lock));
 
 if ( list_empty(>lr_queue) )
@@ -437,20 +447,25 @@ void gic_raise_guest_irq(struct vcpu *v, unsigned int 
virtual_irq,
 {
 int i;
 unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
+struct pending_irq *p = irq_to_pending(v, virtual_irq);
 
 ASSERT(spin_is_locked(>arch.vgic.lock));
 
+if ( unlikely(!p) )
+/* An unmapped LPI does not need to be raised. */
+return;
+
 if ( v == current && list_empty(>arch.vgic.lr_pending) )
 {
 i = find_first_zero_bit(_cpu(lr_mask), nr_lrs);
 if (i < nr_lrs) {
 set_bit(i, _cpu(lr_mask));
-gic_set_lr(i, irq_to_pending(v, virtual_irq), GICH_LR_PENDING);
+gic_set_lr(i, p, GICH_LR_PENDING);
 return;
 }
 }
 
-gic_add_to_lr_pending(v, irq_to_pending(v, virtual_irq));
+gic_add_to_lr_pending(v, p);
 }
 
 static void gic_update_one_lr(struct vcpu *v, int i)
@@ -465,6 +480,17 @@ static void gic_update_one_lr(struct vcpu *v, int i)
 gic_hw_ops->read_lr(i, _val);
 irq = lr_val.virq;
 p = irq_to_pending(v, irq);
+/* An LPI might have been unmapped, in which case we just clean up here. */
+if ( unlikely(!p) )
+{
+ASSERT(is_lpi(irq));
+
+gic_hw_ops->clear_lr(i);
+clear_bit(i, _cpu(lr_mask));
+
+return;
+}
+
 if ( lr_val.state & GICH_LR_ACTIVE )
 {
 set_bit(GIC_IRQ_GUEST_ACTIVE, >status);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index d30f324..8a5d93b 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -242,6 +242,9 @@ bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, 
unsigned int irq)
 unsigned long flags;
 struct pending_irq *p = irq_to_pending(old, irq);
 
+/* This will never be called for an LPI, as we don't migrate them. */
+

[Xen-devel] [PATCH v9 02/28] ARM: VGIC: move irq_to_pending() calls under the VGIC VCPU lock

[Andre Przywara]

So far irq_to_pending() is just a convenience function to lookup
statically allocated arrays. This will change with LPIs, which are
more dynamic.
The proper answer to the issue of preventing stale pointers is
ref-counting, which requires more rework and will be introduced with
a later rework.
For now move the irq_to_pending() calls that are used with LPIs under the
VGIC VCPU lock, and only use the returned pointer while holding the lock.
This prevents the memory from being freed while we use it.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic.c  | 5 -
 xen/arch/arm/vgic.c | 4 +++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index da19130..dcb1783 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -402,10 +402,13 @@ static inline void gic_add_to_lr_pending(struct vcpu *v, 
struct pending_irq *n)
 
 void gic_remove_from_queues(struct vcpu *v, unsigned int virtual_irq)
 {
-struct pending_irq *p = irq_to_pending(v, virtual_irq);
+struct pending_irq *p;
 unsigned long flags;
 
 spin_lock_irqsave(>arch.vgic.lock, flags);
+
+p = irq_to_pending(v, virtual_irq);
+
 if ( !list_empty(>lr_queue) )
 list_del_init(>lr_queue);
 spin_unlock_irqrestore(>arch.vgic.lock, flags);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 83569b0..d30f324 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -466,7 +466,7 @@ void vgic_clear_pending_irqs(struct vcpu *v)
 void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
 {
 uint8_t priority;
-struct pending_irq *iter, *n = irq_to_pending(v, virq);
+struct pending_irq *iter, *n;
 unsigned long flags;
 bool running;
 
@@ -474,6 +474,8 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
 
 spin_lock_irqsave(>arch.vgic.lock, flags);
 
+n = irq_to_pending(v, virq);
+
 /* vcpu offline */
 if ( test_bit(_VPF_down, >pause_flags) )
 {
-- 
2.9.0


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

[Xen-devel] [PATCH v9 11/28] ARM: VGIC: add vcpu_id to struct pending_irq

[Andre Przywara]

The target CPU for an LPI is encoded in the interrupt translation table
entry, so can't be easily derived from just an LPI number (short of
walking *all* tables and find the matching LPI).
To avoid this in case we need to know the VCPU (for the INVALL command,
for instance), put the VCPU ID in the struct pending_irq, so that it is
easily accessible.
We use the remaining 8 bits of padding space for that to avoid enlarging
the size of struct pending_irq. The number of VCPUs is limited to 127
at the moment anyway, which we also confirm with a BUILD_BUG_ON.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic.c| 3 +++
 xen/include/asm-arm/vgic.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 27d6b51..97a2cf2 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -63,6 +63,9 @@ struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned 
int irq)
 
 void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
 {
+/* The lpi_vcpu_id field must be big enough to hold a VCPU ID. */
+BUILD_BUG_ON(BIT(sizeof(p->lpi_vcpu_id) * 8) < MAX_VIRT_CPUS);
+
 INIT_LIST_HEAD(>inflight);
 INIT_LIST_HEAD(>lr_queue);
 p->irq = virq;
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index e2111a5..02732db 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -73,6 +73,7 @@ struct pending_irq
 uint8_t lr;
 uint8_t priority;
 uint8_t lpi_priority;   /* Caches the priority if this is an LPI. */
+uint8_t lpi_vcpu_id;/* The VCPU for an LPI. */
 /* inflight is used to append instances of pending_irq to
  * vgic.inflight_irqs */
 struct list_head inflight;
-- 
2.9.0


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

[Xen-devel] [PATCH v9 27/28] ARM: vITS: create and initialize virtual ITSes for Dom0

[Andre Przywara]

For each hardware ITS create and initialize a virtual ITS for Dom0.
We use the same memory mapped address to keep the doorbell working.
This introduces a function to initialize a virtual ITS.
We maintain a list of virtual ITSes, at the moment for the only
purpose of later being able to free them again.
We configure the virtual ITSes to match the hardware ones, that is we
keep the number of device ID bits and event ID bits the same as the host
ITS.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c   | 75 
 xen/arch/arm/vgic-v3.c   |  4 +++
 xen/include/asm-arm/domain.h |  1 +
 xen/include/asm-arm/gic_v3_its.h |  4 +++
 4 files changed, 84 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 8f6ff11..ca35aca 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -52,6 +52,7 @@
  */
 struct virt_its {
 struct domain *d;
+struct list_head vits_list;
 paddr_t doorbell_address;
 unsigned int devid_bits;
 unsigned int evid_bits;
@@ -103,14 +104,49 @@ unsigned int vgic_v3_its_count(const struct domain *d)
 
 int vgic_v3_its_init_domain(struct domain *d)
 {
+int ret;
+
+INIT_LIST_HEAD(>arch.vgic.vits_list);
 spin_lock_init(>arch.vgic.its_devices_lock);
 d->arch.vgic.its_devices = RB_ROOT;
 
+if ( is_hardware_domain(d) )
+{
+struct host_its *hw_its;
+
+list_for_each_entry(hw_its, _its_list, entry)
+{
+/*
+ * For each host ITS create a virtual ITS using the same
+ * base and thus doorbell address.
+ * Use the same number of device ID and event ID bits as the host.
+ */
+ret = vgic_v3_its_init_virtual(d, hw_its->addr,
+   hw_its->devid_bits,
+   hw_its->evid_bits);
+if ( ret )
+{
+vgic_v3_its_free_domain(d);
+return ret;
+}
+else
+d->arch.vgic.has_its = true;
+}
+}
+
 return 0;
 }
 
 void vgic_v3_its_free_domain(struct domain *d)
 {
+struct virt_its *pos, *temp;
+
+list_for_each_entry_safe( pos, temp, >arch.vgic.vits_list, vits_list )
+{
+list_del(>vits_list);
+xfree(pos);
+}
+
 ASSERT(RB_EMPTY_ROOT(>arch.vgic.its_devices));
 }
 
@@ -1407,6 +1443,45 @@ static const struct mmio_handler_ops 
vgic_its_mmio_handler = {
 .write = vgic_v3_its_mmio_write,
 };
 
+int vgic_v3_its_init_virtual(struct domain *d, paddr_t guest_addr,
+ unsigned int devid_bits, unsigned int evid_bits)
+{
+struct virt_its *its;
+uint64_t base_attr;
+
+its = xzalloc(struct virt_its);
+if ( !its )
+return -ENOMEM;
+
+base_attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+base_attr |= GIC_BASER_CACHE_SameAsInner << 
GITS_BASER_OUTER_CACHEABILITY_SHIFT;
+base_attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
+
+its->cbaser  = base_attr;
+base_attr |= 0ULL << GITS_BASER_PAGE_SIZE_SHIFT;/* 4K pages */
+its->baser_dev = GITS_BASER_TYPE_DEVICE << GITS_BASER_TYPE_SHIFT;
+its->baser_dev |= (sizeof(dev_table_entry_t) - 1) <<
+  GITS_BASER_ENTRY_SIZE_SHIFT;
+its->baser_dev |= base_attr;
+its->baser_coll  = GITS_BASER_TYPE_COLLECTION << GITS_BASER_TYPE_SHIFT;
+its->baser_coll |= (sizeof(coll_table_entry_t) - 1) <<
+   GITS_BASER_ENTRY_SIZE_SHIFT;
+its->baser_coll |= base_attr;
+its->d = d;
+its->doorbell_address = guest_addr + ITS_DOORBELL_OFFSET;
+its->devid_bits = devid_bits;
+its->evid_bits = evid_bits;
+spin_lock_init(>vcmd_lock);
+spin_lock_init(>its_lock);
+
+register_mmio_handler(d, _its_mmio_handler, guest_addr, SZ_64K, its);
+
+/* Register the virtual ITSes to be able to clean them up later. */
+list_add_tail(>vits_list, >arch.vgic.vits_list);
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 41cda78..fd4b5f4 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1700,6 +1700,10 @@ static int vgic_v3_domain_init(struct domain *d)
 d->arch.vgic.intid_bits = GUEST_GICV3_GICD_INTID_BITS;
 }
 
+/*
+ * For a hardware domain, this will iterate over the host ITSes
+ * and maps  one virtual ITS per host ITS at the same address.
+ */
 ret = vgic_v3_its_init_domain(d);
 if ( ret )
 return ret;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index b2d98bb..92f4ce5 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -115,6 +115,7 @@ struct arch_domain
 spinlock_t its_devices_lock;/* Protects the its_devices tree */
 struct 

[Xen-devel] [PATCH v9 16/28] ARM: vITS: handle INT command

[Andre Przywara]

The INT command sets a given LPI identified by a DeviceID/EventID pair
as pending and thus triggers it to be injected.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 12ec5f1..f9379c9 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -300,6 +300,24 @@ static uint64_t its_cmd_mask_field(uint64_t *its_cmd, 
unsigned int word,
 #define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2, 63,  1)
 #define its_cmd_get_ittaddr(cmd)(its_cmd_mask_field(cmd, 2, 8, 44) << 
8)
 
+static int its_handle_int(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+struct vcpu *vcpu;
+uint32_t vlpi;
+
+if ( !read_itte(its, devid, eventid, , ) )
+return -1;
+
+if ( vlpi == INVALID_LPI )
+return -1;
+
+vgic_vcpu_inject_irq(vcpu, vlpi);
+
+return 0;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg) ((reg) & GENMASK(19, 5))
 
@@ -329,6 +347,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its)
 
 switch ( its_cmd_get_command(command) )
 {
+case GITS_CMD_INT:
+ret = its_handle_int(its, command);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
 break;
-- 
2.9.0


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

[Xen-devel] [PATCH v9 24/28] ARM: vITS: handle INV command

[Andre Przywara]

The INV command instructs the ITS to update the configuration data for
a given LPI by re-reading its entry from the property table.
We don't need to care so much about the priority value, but enabling
or disabling an LPI has some effect: We remove or push virtual LPIs
to their VCPUs, also check the virtual pending bit if an LPI gets enabled.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 70 ++
 1 file changed, 70 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index f7a8d77..6cfb560 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -456,6 +456,73 @@ static int update_lpi_property(struct domain *d, struct 
pending_irq *p)
 return 0;
 }
 
+/*
+ * Checks whether an LPI that got enabled or disabled needs to change
+ * something in the VGIC (added or removed from the LR or queues).
+ * Must be called with the VCPU VGIC lock held.
+ */
+static void update_lpi_vgic_status(struct vcpu *v, struct pending_irq *p)
+{
+ASSERT(spin_is_locked(>arch.vgic.lock));
+
+if ( test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
+{
+if ( !list_empty(>inflight) &&
+ !test_bit(GIC_IRQ_GUEST_VISIBLE, >status) )
+gic_raise_guest_irq(v, p->irq, p->lpi_priority);
+}
+else
+{
+clear_bit(GIC_IRQ_GUEST_ENABLED, >status);
+list_del_init(>lr_queue);
+}
+}
+
+static int its_handle_inv(struct virt_its *its, uint64_t *cmdptr)
+{
+struct domain *d = its->d;
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+struct pending_irq *p;
+unsigned long flags;
+struct vcpu *vcpu;
+uint32_t vlpi;
+int ret = -1;
+
+spin_lock(>its_lock);
+
+/* Translate the event into a vCPU/vLPI pair. */
+if ( !read_itte_locked(its, devid, eventid, , ) )
+goto out_unlock_its;
+
+if ( vlpi == INVALID_LPI )
+goto out_unlock_its;
+
+p = gicv3_its_get_event_pending_irq(d, its->doorbell_address,
+devid, eventid);
+if ( unlikely(!p) )
+goto out_unlock_its;
+
+spin_lock_irqsave(>arch.vgic.lock, flags);
+
+/* Read the property table and update our cached status. */
+if ( update_lpi_property(d, p) )
+goto out_unlock;
+
+/* Check whether the LPI needs to go on a VCPU. */
+update_lpi_vgic_status(vcpu, p);
+
+ret = 0;
+
+out_unlock:
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+
+out_unlock_its:
+spin_unlock(>its_lock);
+
+return ret;
+}
+
 /* Must be called with the ITS lock held. */
 static int its_discard_event(struct virt_its *its,
  uint32_t vdevid, uint32_t vevid)
@@ -782,6 +849,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its)
 case GITS_CMD_INT:
 ret = its_handle_int(its, command);
 break;
+case GITS_CMD_INV:
+ret = its_handle_inv(its, command);
+break;
 case GITS_CMD_MAPC:
 ret = its_handle_mapc(its, command);
 break;
-- 
2.9.0


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

[Xen-devel] [PATCH v9 21/28] ARM: vITS: handle MAPTI command

[Andre Przywara]

The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
pair and actually instantiates LPI interrupts.
We connect the already allocated host LPI to this virtual LPI, so that
any triggering LPI on the host can be quickly forwarded to a guest.
Beside entering the VCPU and the virtual LPI number in the respective
host LPI entry, we also initialize and add the already allocated
struct pending_irq to our radix tree, so that we can now easily find it
by its virtual LPI number.
We also read the property table to update the enabled bit and the
priority for our new LPI, as we might have missed this during an earlier
INVALL call (which only checks mapped LPIs).
Since write_itte_locked() now sees its first usage, we change the
declaration to static.
---
 xen/arch/arm/gic-v3-its.c|  28 +
 xen/arch/arm/vgic-v3-its.c   | 124 ++-
 xen/include/asm-arm/gic_v3_its.h |   3 +
 3 files changed, 152 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index be4c3e0..8a50f7d 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -887,6 +887,34 @@ int gicv3_remove_guest_event(struct domain *d, paddr_t 
vdoorbell_address,
 return 0;
 }
 
+/*
+ * Connects the event ID for an already assigned device to the given VCPU/vLPI
+ * pair. The corresponding physical LPI is already mapped on the host side
+ * (when assigning the physical device to the guest), so we just connect the
+ * target VCPU/vLPI pair to that interrupt to inject it properly if it fires.
+ * Returns a pointer to the already allocated struct pending_irq that is
+ * meant to be used by that event.
+ */
+struct pending_irq *gicv3_assign_guest_event(struct domain *d,
+ paddr_t vdoorbell_address,
+ uint32_t vdevid, uint32_t 
veventid,
+ struct vcpu *v, uint32_t virt_lpi)
+{
+struct pending_irq *pirq;
+uint32_t host_lpi = 0;
+
+pirq = get_event_pending_irq(d, vdoorbell_address, vdevid, veventid,
+ _lpi);
+
+if ( !pirq || !host_lpi )
+return NULL;
+
+gicv3_lpi_update_host_entry(host_lpi, d->domain_id,
+v ? v->vcpu_id : INVALID_VCPU_ID, virt_lpi);
+
+return pirq;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 731fe0c..c5c0e5e 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -286,9 +286,9 @@ static bool read_itte(struct virt_its *its, uint32_t devid, 
uint32_t evid,
  * If vcpu_ptr is provided, returns the VCPU belonging to that collection.
  * Must be called with the ITS lock held.
  */
-bool write_itte_locked(struct virt_its *its, uint32_t devid,
-   uint32_t evid, uint32_t collid, uint32_t vlpi,
-   struct vcpu **vcpu_ptr)
+static bool write_itte_locked(struct virt_its *its, uint32_t devid,
+  uint32_t evid, uint32_t collid, uint32_t vlpi,
+  struct vcpu **vcpu_ptr)
 {
 paddr_t addr;
 struct vits_itte itte;
@@ -429,6 +429,33 @@ out_unlock:
 return ret;
 }
 
+/*
+ * For a given virtual LPI read the enabled bit and priority from the virtual
+ * property table and update the virtual IRQ's state in the given pending_irq.
+ * Must be called with the respective VGIC VCPU lock held.
+ */
+static int update_lpi_property(struct domain *d, struct pending_irq *p)
+{
+paddr_t addr;
+uint8_t property;
+int ret;
+
+addr = d->arch.vgic.rdist_propbase & GENMASK(51, 12);
+
+ret = vgic_access_guest_memory(d, addr + p->irq - LPI_OFFSET,
+   , sizeof(property), false);
+if ( ret )
+return ret;
+
+p->lpi_priority = property & LPI_PROP_PRIO_MASK;
+if ( property & LPI_PROP_ENABLED )
+set_bit(GIC_IRQ_GUEST_ENABLED, >status);
+else
+clear_bit(GIC_IRQ_GUEST_ENABLED, >status);
+
+return 0;
+}
+
 /* Must be called with the ITS lock held. */
 static int its_discard_event(struct virt_its *its,
  uint32_t vdevid, uint32_t vevid)
@@ -556,6 +583,93 @@ static int its_handle_mapd(struct virt_its *its, uint64_t 
*cmdptr)
 return ret;
 }
 
+static int its_handle_mapti(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+uint32_t intid = its_cmd_get_physical_id(cmdptr), _intid;
+uint16_t collid = its_cmd_get_collection(cmdptr);
+struct pending_irq *pirq;
+struct vcpu *vcpu = NULL;
+int ret = -1;
+
+if ( its_cmd_get_command(cmdptr) == GITS_CMD_MAPI )
+intid = eventid;
+
+spin_lock(>its_lock);
+/*

[Xen-devel] [PATCH v9 06/28] ARM: GICv3: enable ITS and LPIs on the host

[Andre Przywara]

Now that the host part of the ITS code is in place, we can enable the
ITS and also LPIs on each redistributor to get the show rolling.
At this point there would be no LPIs mapped, as guests don't know about
the ITS yet.

Signed-off-by: Andre Przywara 
Acked-by: Stefano Stabellini 
---
 xen/arch/arm/gic-v3-its.c |  4 
 xen/arch/arm/gic-v3.c | 18 ++
 2 files changed, 22 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 07280b3..aebc257 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -505,6 +505,10 @@ static int gicv3_its_init_single_its(struct host_its 
*hw_its)
 return -ENOMEM;
 writeq_relaxed(0, hw_its->its_base + GITS_CWRITER);
 
+/* Now enable interrupt translation and command processing on that ITS. */
+reg = readl_relaxed(hw_its->its_base + GITS_CTLR);
+writel_relaxed(reg | GITS_CTLR_ENABLE, hw_its->its_base + GITS_CTLR);
+
 return 0;
 }
 
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 8140c5f..d539d6c 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -620,6 +620,21 @@ static int gicv3_enable_redist(void)
 return 0;
 }
 
+/* Enable LPIs on this redistributor (only useful when the host has an ITS). */
+static bool gicv3_enable_lpis(void)
+{
+uint32_t val;
+
+val = readl_relaxed(GICD_RDIST_BASE + GICR_TYPER);
+if ( !(val & GICR_TYPER_PLPIS) )
+return false;
+
+val = readl_relaxed(GICD_RDIST_BASE + GICR_CTLR);
+writel_relaxed(val | GICR_CTLR_ENABLE_LPIS, GICD_RDIST_BASE + GICR_CTLR);
+
+return true;
+}
+
 static int __init gicv3_populate_rdist(void)
 {
 int i;
@@ -731,11 +746,14 @@ static int gicv3_cpu_init(void)
 if ( gicv3_enable_redist() )
 return -ENODEV;
 
+/* If the host has any ITSes, enable LPIs now. */
 if ( gicv3_its_host_has_its() )
 {
 ret = gicv3_its_setup_collection(smp_processor_id());
 if ( ret )
 return ret;
+if ( !gicv3_enable_lpis() )
+return -EBUSY;
 }
 
 /* Set priority on PPI and SGI interrupts */
-- 
2.9.0


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

[Xen-devel] [PATCH v9 26/28] ARM: vITS: increase mmio_count for each ITS

[Andre Przywara]

Increase the count of MMIO regions needed by one for each ITS Dom0 has
to emulate. We emulate the ITSes 1:1 from the hardware, so the number
is the number of host ITSes.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c   | 15 +++
 xen/arch/arm/vgic-v3.c   |  3 +++
 xen/include/asm-arm/gic_v3_its.h |  7 +++
 3 files changed, 25 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 36faa16..8f6ff11 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -86,6 +86,21 @@ typedef uint64_t dev_table_entry_t;
 #define GITS_BASER_RO_MASK   (GITS_BASER_TYPE_MASK | \
   (31UL << GITS_BASER_ENTRY_SIZE_SHIFT))
 
+unsigned int vgic_v3_its_count(const struct domain *d)
+{
+struct host_its *hw_its;
+unsigned int ret = 0;
+
+/* Only Dom0 can use emulated ITSes so far. */
+if ( !is_hardware_domain(d) )
+return 0;
+
+list_for_each_entry(hw_its, _its_list, entry)
+ret++;
+
+return ret;
+}
+
 int vgic_v3_its_init_domain(struct domain *d)
 {
 spin_lock_init(>arch.vgic.its_devices_lock);
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 6dbdb2e..41cda78 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1802,6 +1802,9 @@ int vgic_v3_init(struct domain *d, int *mmio_count)
 /* GICD region + number of Redistributors */
 *mmio_count = vgic_v3_rdist_count(d) + 1;
 
+/* one region per ITS */
+*mmio_count += vgic_v3_its_count(d);
+
 register_vgic_ops(d, _ops);
 
 return 0;
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index 82d788c..927568f 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -137,6 +137,8 @@ void gicv3_its_dt_init(const struct dt_device_node *node);
 
 bool gicv3_its_host_has_its(void);
 
+unsigned int vgic_v3_its_count(const struct domain *d);
+
 void gicv3_do_LPI(unsigned int lpi);
 
 int gicv3_lpi_init_rdist(void __iomem * rdist_base);
@@ -196,6 +198,11 @@ static inline bool gicv3_its_host_has_its(void)
 return false;
 }
 
+static inline unsigned int vgic_v3_its_count(const struct domain *d)
+{
+return 0;
+}
+
 static inline void gicv3_do_LPI(unsigned int lpi)
 {
 /* We don't enable LPIs without an ITS. */
-- 
2.9.0


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

[Xen-devel] [PATCH v9 20/28] ARM: GICv3: handle unmapped LPIs

[Andre Przywara]

When LPIs get unmapped by a guest, they might still be in some LR of
some VCPU. Nevertheless we remove the corresponding pending_irq
(possibly freeing it), and detect this case (irq_to_pending() returns
NULL) when the LR gets cleaned up later.
However a *new* LPI may get mapped with the same number while the old
LPI is *still* in some LR. To avoid getting the wrong state, we mark
every newly mapped LPI as PRISTINE, which means: has never been in an
LR before. If we detect the LPI in an LR anyway, it must have been an
older one, which we can simply retire.
Before inserting such a PRISTINE LPI into an LR, we must make sure that
it's not already in another LR, as the architecture forbids two
interrupts with the same virtual IRQ number on one CPU.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic.c | 55 +-
 xen/include/asm-arm/vgic.h |  6 +
 2 files changed, 56 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index fd3fa05..8bf0578 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -375,6 +375,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
 {
 ASSERT(!local_irq_is_enabled());
 
+clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, >status);
+
 gic_hw_ops->update_lr(lr, p, state);
 
 set_bit(GIC_IRQ_GUEST_VISIBLE, >status);
@@ -442,12 +444,41 @@ void gic_raise_inflight_irq(struct vcpu *v, unsigned int 
virtual_irq)
 #endif
 }
 
+/*
+ * Find an unused LR to insert an IRQ into. If this new interrupt is a
+ * PRISTINE LPI, scan the other LRs to avoid inserting the same IRQ twice.
+ */
+static int gic_find_unused_lr(struct vcpu *v, struct pending_irq *p, int lr)
+{
+unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
+unsigned long *lr_mask = (unsigned long *) _cpu(lr_mask);
+struct gic_lr lr_val;
+
+ASSERT(spin_is_locked(>arch.vgic.lock));
+
+if ( test_bit(GIC_IRQ_GUEST_PRISTINE_LPI, >status) )
+{
+int used_lr = 0;
+
+while ( (used_lr = find_next_bit(lr_mask, nr_lrs, used_lr)) < nr_lrs )
+{
+gic_hw_ops->read_lr(used_lr, _val);
+if ( lr_val.virq == p->irq )
+return used_lr;
+}
+}
+
+lr = find_next_zero_bit(lr_mask, nr_lrs, lr);
+
+return lr;
+}
+
 void gic_raise_guest_irq(struct vcpu *v, unsigned int virtual_irq,
 unsigned int priority)
 {
-int i;
-unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
 struct pending_irq *p = irq_to_pending(v, virtual_irq);
+unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
+int i = nr_lrs;
 
 ASSERT(spin_is_locked(>arch.vgic.lock));
 
@@ -457,7 +488,8 @@ void gic_raise_guest_irq(struct vcpu *v, unsigned int 
virtual_irq,
 
 if ( v == current && list_empty(>arch.vgic.lr_pending) )
 {
-i = find_first_zero_bit(_cpu(lr_mask), nr_lrs);
+i = gic_find_unused_lr(v, p, 0);
+
 if (i < nr_lrs) {
 set_bit(i, _cpu(lr_mask));
 gic_set_lr(i, p, GICH_LR_PENDING);
@@ -509,7 +541,17 @@ static void gic_update_one_lr(struct vcpu *v, int i)
 }
 else if ( lr_val.state & GICH_LR_PENDING )
 {
-int q __attribute__ ((unused)) = 
test_and_clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
+int q __attribute__ ((unused));
+
+if ( test_and_clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, >status) )
+{
+gic_hw_ops->clear_lr(i);
+clear_bit(i, _cpu(lr_mask));
+
+return;
+}
+
+q = test_and_clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
 #ifdef GIC_DEBUG
 if ( q )
 gdprintk(XENLOG_DEBUG, "trying to inject irq=%d into d%dv%d, when 
it is already pending in LR%d\n",
@@ -521,6 +563,9 @@ static void gic_update_one_lr(struct vcpu *v, int i)
 gic_hw_ops->clear_lr(i);
 clear_bit(i, _cpu(lr_mask));
 
+if ( test_and_clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, >status) )
+return;
+
 if ( p->desc != NULL )
 clear_bit(_IRQ_INPROGRESS, >desc->status);
 clear_bit(GIC_IRQ_GUEST_VISIBLE, >status);
@@ -591,7 +636,7 @@ static void gic_restore_pending_irqs(struct vcpu *v)
 inflight_r = >arch.vgic.inflight_irqs;
 list_for_each_entry_safe ( p, t, >arch.vgic.lr_pending, lr_queue )
 {
-lr = find_next_zero_bit(_cpu(lr_mask), nr_lrs, lr);
+lr = gic_find_unused_lr(v, p, lr);
 if ( lr >= nr_lrs )
 {
 /* No more free LRs: find a lower priority irq to evict */
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 02732db..3fc4ceb 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -60,12 +60,18 @@ struct pending_irq
  * vcpu while it is still inflight and on an GICH_LR register on the
  * old vcpu.
  *
+ * GIC_IRQ_GUEST_PRISTINE_LPI: the IRQ is a newly mapped LPI, which
+ * has never been in an LR before. This means that any trace of an
+ * LPI 

[Xen-devel] [PATCH v9 04/28] ARM: GICv3: introduce separate pending_irq structs for LPIs

[Andre Przywara]

For the same reason that allocating a struct irq_desc for each
possible LPI is not an option, having a struct pending_irq for each LPI
is also not feasible. We only care about mapped LPIs, so we can get away
with having struct pending_irq's only for them.
Maintain a radix tree per domain where we drop the pointer to the
respective pending_irq. The index used is the virtual LPI number.
The memory for the actual structures has been allocated already per
device at device mapping time.
Teach the existing VGIC functions to find the right pointer when being
given a virtual LPI number.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v2.c   |  8 
 xen/arch/arm/vgic-v3.c   | 30 ++
 xen/arch/arm/vgic.c  |  2 ++
 xen/include/asm-arm/domain.h |  2 ++
 xen/include/asm-arm/vgic.h   |  2 ++
 5 files changed, 44 insertions(+)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index dc9f95b..0587569 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -702,10 +702,18 @@ static void vgic_v2_domain_free(struct domain *d)
 /* Nothing to be cleanup for this driver */
 }
 
+static struct pending_irq *vgic_v2_lpi_to_pending(struct domain *d,
+  unsigned int vlpi)
+{
+/* Dummy function, no LPIs on a VGICv2. */
+BUG();
+}
+
 static const struct vgic_ops vgic_v2_ops = {
 .vcpu_init   = vgic_v2_vcpu_init,
 .domain_init = vgic_v2_domain_init,
 .domain_free = vgic_v2_domain_free,
+.lpi_to_pending = vgic_v2_lpi_to_pending,
 .max_vcpus = 8,
 };
 
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 25e16dc..44d2b50 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1454,6 +1454,9 @@ static int vgic_v3_domain_init(struct domain *d)
 d->arch.vgic.nr_regions = rdist_count;
 d->arch.vgic.rdist_regions = rdist_regions;
 
+rwlock_init(>arch.vgic.pend_lpi_tree_lock);
+radix_tree_init(>arch.vgic.pend_lpi_tree);
+
 /*
  * Domain 0 gets the hardware address.
  * Guests get the virtual platform layout.
@@ -1535,14 +1538,41 @@ static int vgic_v3_domain_init(struct domain *d)
 static void vgic_v3_domain_free(struct domain *d)
 {
 vgic_v3_its_free_domain(d);
+/*
+ * It is expected that at this point all actual ITS devices have been
+ * cleaned up already. The struct pending_irq's, for which the pointers
+ * have been stored in the radix tree, are allocated and freed by device.
+ * On device unmapping all the entries are removed from the tree and
+ * the backing memory is freed.
+ */
+radix_tree_destroy(>arch.vgic.pend_lpi_tree, NULL);
 xfree(d->arch.vgic.rdist_regions);
 }
 
+/*
+ * Looks up a virtual LPI number in our tree of mapped LPIs. This will return
+ * the corresponding struct pending_irq, which we also use to store the
+ * enabled and pending bit plus the priority.
+ * Returns NULL if an LPI cannot be found (or no LPIs are supported).
+ */
+static struct pending_irq *vgic_v3_lpi_to_pending(struct domain *d,
+  unsigned int lpi)
+{
+struct pending_irq *pirq;
+
+read_lock(>arch.vgic.pend_lpi_tree_lock);
+pirq = radix_tree_lookup(>arch.vgic.pend_lpi_tree, lpi);
+read_unlock(>arch.vgic.pend_lpi_tree_lock);
+
+return pirq;
+}
+
 static const struct vgic_ops v3_ops = {
 .vcpu_init   = vgic_v3_vcpu_init,
 .domain_init = vgic_v3_domain_init,
 .domain_free = vgic_v3_domain_free,
 .emulate_reg  = vgic_v3_emulate_reg,
+.lpi_to_pending = vgic_v3_lpi_to_pending,
 /*
  * We use both AFF1 and AFF0 in (v)MPIDR. Thus, the max number of CPU
  * that can be supported is up to 4096(==256*16) in theory.
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 8a5d93b..bf6fb60 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -457,6 +457,8 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned 
int irq)
  * are used for SPIs; the rests are used for per cpu irqs */
 if ( irq < 32 )
 n = >arch.vgic.pending_irqs[irq];
+else if ( is_lpi(irq) )
+n = v->domain->arch.vgic.handler->lpi_to_pending(v->domain, irq);
 else
 n = >domain->arch.vgic.pending_irqs[irq - 32];
 return n;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 7c3829d..3d8e84c 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -111,6 +111,8 @@ struct arch_domain
 uint32_t rdist_stride;  /* Re-Distributor stride */
 struct rb_root its_devices; /* Devices mapped to an ITS */
 spinlock_t its_devices_lock;/* Protects the its_devices tree */
+struct radix_tree_root pend_lpi_tree; /* Stores struct pending_irq's */
+rwlock_t pend_lpi_tree_lock;/* Protects the pend_lpi_tree */
 unsigned int intid_bits;
 #endif
 } vgic;

[Xen-devel] [PATCH v9 15/28] ARM: vITS: provide access to struct pending_irq

[Andre Przywara]

For each device we allocate one struct pending_irq for each virtual
event (MSI).
Provide a helper function which returns the pointer to the appropriate
struct, to be able to find the right struct when given a virtual
deviceID/eventID pair.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c| 69 
 xen/include/asm-arm/gic_v3_its.h |  4 +++
 2 files changed, 73 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index aebc257..fd6a394 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -800,6 +800,75 @@ out:
 return ret;
 }
 
+/* Must be called with the its_device_lock held. */
+static struct its_device *get_its_device(struct domain *d, paddr_t vdoorbell,
+ uint32_t vdevid)
+{
+struct rb_node *node = d->arch.vgic.its_devices.rb_node;
+struct its_device *dev;
+
+ASSERT(spin_is_locked(>arch.vgic.its_devices_lock));
+
+while (node)
+{
+int cmp;
+
+dev = rb_entry(node, struct its_device, rbnode);
+cmp = compare_its_guest_devices(dev, vdoorbell, vdevid);
+
+if ( !cmp )
+return dev;
+
+if ( cmp > 0 )
+node = node->rb_left;
+else
+node = node->rb_right;
+}
+
+return NULL;
+}
+
+static uint32_t get_host_lpi(struct its_device *dev, uint32_t eventid)
+{
+uint32_t host_lpi = INVALID_LPI;
+
+if ( dev && (eventid < dev->eventids) )
+host_lpi = dev->host_lpi_blocks[eventid / LPI_BLOCK] +
+   (eventid % LPI_BLOCK);
+
+return host_lpi;
+}
+
+static struct pending_irq *get_event_pending_irq(struct domain *d,
+ paddr_t vdoorbell_address,
+ uint32_t vdevid,
+ uint32_t veventid,
+ uint32_t *host_lpi)
+{
+struct its_device *dev;
+struct pending_irq *pirq = NULL;
+
+spin_lock(>arch.vgic.its_devices_lock);
+dev = get_its_device(d, vdoorbell_address, vdevid);
+if ( dev && veventid <= dev->eventids )
+{
+pirq = >pend_irqs[veventid];
+if ( host_lpi )
+*host_lpi = get_host_lpi(dev, veventid);
+}
+spin_unlock(>arch.vgic.its_devices_lock);
+
+return pirq;
+}
+
+struct pending_irq *gicv3_its_get_event_pending_irq(struct domain *d,
+paddr_t vdoorbell_address,
+uint32_t vdevid,
+uint32_t veventid)
+{
+return get_event_pending_irq(d, vdoorbell_address, vdevid, veventid, NULL);
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index 40f4ef5..d162e89 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -169,6 +169,10 @@ int gicv3_its_map_guest_device(struct domain *d,
 int gicv3_allocate_host_lpi_block(struct domain *d, uint32_t *first_lpi);
 void gicv3_free_host_lpi_block(uint32_t first_lpi);
 
+struct pending_irq *gicv3_its_get_event_pending_irq(struct domain *d,
+paddr_t vdoorbell_address,
+uint32_t vdevid,
+uint32_t veventid);
 #else
 
 static inline void gicv3_its_dt_init(const struct dt_device_node *node)
-- 
2.9.0


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

[Xen-devel] [PATCH v9 14/28] ARM: vITS: introduce translation table walks

[Andre Przywara]

The ITS stores the target (v)CPU and the (virtual) LPI number in tables.
Introduce functions to walk those tables and translate an device ID -
event ID pair into a pair of virtual LPI and vCPU.
We map those tables on demand - which is cheap on arm64 - and copy the
respective entries before using them, to avoid the guest tampering with
them meanwhile.

To allow compiling without warnings, we declare two functions as
non-static for the moment, which two later patches will fix.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 183 +
 1 file changed, 183 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index e3bd1f6..12ec5f1 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -81,6 +81,7 @@ struct vits_itte
 typedef uint16_t coll_table_entry_t;
 typedef uint64_t dev_table_entry_t;
 
+#define UNMAPPED_COLLECTION  ((coll_table_entry_t)~0)
 #define GITS_BASER_RO_MASK   (GITS_BASER_TYPE_MASK | \
   (31UL << GITS_BASER_ENTRY_SIZE_SHIFT))
 
@@ -97,6 +98,188 @@ void vgic_v3_its_free_domain(struct domain *d)
 ASSERT(RB_EMPTY_ROOT(>arch.vgic.its_devices));
 }
 
+/*
+ * The physical address is encoded slightly differently depending on
+ * the used page size: the highest four bits are stored in the lowest
+ * four bits of the field for 64K pages.
+ */
+static paddr_t get_baser_phys_addr(uint64_t reg)
+{
+if ( reg & BIT(9) )
+return (reg & GENMASK(47, 16)) |
+((reg & GENMASK(15, 12)) << 36);
+else
+return reg & GENMASK(47, 12);
+}
+
+/*
+ * Our collection table encoding:
+ * Just contains the 16-bit VCPU ID of the respective vCPU.
+ */
+
+/* Must be called with the ITS lock held. */
+static struct vcpu *get_vcpu_from_collection(struct virt_its *its,
+ uint16_t collid)
+{
+paddr_t addr = get_baser_phys_addr(its->baser_coll);
+coll_table_entry_t vcpu_id;
+int ret;
+
+ASSERT(spin_is_locked(>its_lock));
+
+if ( collid >= its->max_collections )
+return NULL;
+
+ret = vgic_access_guest_memory(its->d,
+   addr + collid * sizeof(coll_table_entry_t),
+   _id, sizeof(vcpu_id), false);
+if ( ret )
+return NULL;
+
+if ( vcpu_id == UNMAPPED_COLLECTION || vcpu_id >= its->d->max_vcpus )
+return NULL;
+
+return its->d->vcpu[vcpu_id];
+}
+
+/*
+ * Our device table encodings:
+ * Contains the guest physical address of the Interrupt Translation Table in
+ * bits [51:8], and the size of it is encoded as the number of bits minus one
+ * in the lowest 5 bits of the word.
+ */
+#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK(51, 8))
+#define DEV_TABLE_ITT_SIZE(x) (BIT(((x) & GENMASK(4, 0)) + 1))
+#define DEV_TABLE_ENTRY(addr, bits) \
+(((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(4, 0)))
+
+/*
+ * Lookup the address of the Interrupt Translation Table associated with
+ * that device ID.
+ * TODO: add support for walking indirect tables.
+ */
+static int its_get_itt(struct virt_its *its, uint32_t devid,
+   dev_table_entry_t *itt)
+{
+paddr_t addr = get_baser_phys_addr(its->baser_dev);
+
+if ( devid >= its->max_devices )
+return -EINVAL;
+
+return vgic_access_guest_memory(its->d,
+addr + devid * sizeof(dev_table_entry_t),
+itt, sizeof(*itt), false);
+}
+
+/*
+ * Lookup the address of the Interrupt Translation Table associated with
+ * a device ID and return the address of the ITTE belonging to the event ID
+ * (which is an index into that table).
+ */
+static paddr_t its_get_itte_address(struct virt_its *its,
+uint32_t devid, uint32_t evid)
+{
+dev_table_entry_t itt;
+int ret;
+
+ret = its_get_itt(its, devid, );
+if ( ret )
+return INVALID_PADDR;
+
+if ( evid >= DEV_TABLE_ITT_SIZE(itt) ||
+ DEV_TABLE_ITT_ADDR(itt) == INVALID_PADDR )
+return INVALID_PADDR;
+
+return DEV_TABLE_ITT_ADDR(itt) + evid * sizeof(struct vits_itte);
+}
+
+/*
+ * Queries the collection and device tables to get the vCPU and virtual
+ * LPI number for a given guest event. This first accesses the guest memory
+ * to resolve the address of the ITTE, then reads the ITTE entry at this
+ * address and puts the result in vcpu_ptr and vlpi_ptr.
+ * Must be called with the ITS lock held.
+ */
+static bool read_itte_locked(struct virt_its *its, uint32_t devid,
+ uint32_t evid, struct vcpu **vcpu_ptr,
+ uint32_t *vlpi_ptr)
+{
+paddr_t addr;
+struct vits_itte itte;
+struct vcpu *vcpu;
+
+ASSERT(spin_is_locked(>its_lock));
+
+addr = its_get_itte_address(its, devid, evid);
+if ( addr == 

[Xen-devel] [PATCH v9 25/28] ARM: vITS: handle INVALL command

[Andre Przywara]

The INVALL command instructs an ITS to invalidate the configuration
data for all LPIs associated with a given redistributor (read: VCPU).
This is nasty to emulate exactly with our architecture, so we just
iterate over all mapped LPIs and filter for those from that particular
VCPU.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 66 ++
 1 file changed, 66 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 6cfb560..36faa16 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -523,6 +523,69 @@ out_unlock_its:
 return ret;
 }
 
+/*
+ * INVALL updates the per-LPI configuration status for every LPI mapped to
+ * a particular redistributor.
+ * We iterate over all mapped LPIs in our radix tree and update those.
+ */
+static int its_handle_invall(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t collid = its_cmd_get_collection(cmdptr);
+struct vcpu *vcpu;
+struct pending_irq *pirqs[16];
+uint64_t vlpi = 0;  /* 64-bit to catch overflows */
+unsigned int nr_lpis, i;
+unsigned long flags;
+int ret = 0;
+
+/*
+ * As this implementation walks over all mapped LPIs, it might take
+ * too long for a real guest, so we might want to revisit this
+ * implementation for DomUs.
+ * However this command is very rare, also we don't expect many
+ * LPIs to be actually mapped, so it's fine for Dom0 to use.
+ */
+ASSERT(is_hardware_domain(its->d));
+
+spin_lock(>its_lock);
+vcpu = get_vcpu_from_collection(its, collid);
+spin_unlock(>its_lock);
+
+spin_lock_irqsave(>arch.vgic.lock, flags);
+read_lock(>d->arch.vgic.pend_lpi_tree_lock);
+
+do
+{
+nr_lpis = radix_tree_gang_lookup(>d->arch.vgic.pend_lpi_tree,
+ (void **)pirqs, vlpi,
+ ARRAY_SIZE(pirqs));
+
+for ( i = 0; i < nr_lpis; i++ )
+{
+/* We only care about LPIs on our VCPU. */
+if ( pirqs[i]->lpi_vcpu_id != vcpu->vcpu_id )
+continue;
+
+vlpi = pirqs[i]->irq;
+/* If that fails for a single LPI, carry on to handle the rest. */
+ret = update_lpi_property(its->d, pirqs[i]);
+if ( !ret )
+update_lpi_vgic_status(vcpu, pirqs[i]);
+}
+/*
+ * Loop over the next gang of pending_irqs until we reached the end of
+ * a (fully populated) tree or the lookup function returns less LPIs than
+ * it has been asked for.
+ */
+} while ( (++vlpi < its->d->arch.vgic.nr_lpis) &&
+  (nr_lpis == ARRAY_SIZE(pirqs)) );
+
+read_unlock(>d->arch.vgic.pend_lpi_tree_lock);
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+
+return ret;
+}
+
 /* Must be called with the ITS lock held. */
 static int its_discard_event(struct virt_its *its,
  uint32_t vdevid, uint32_t vevid)
@@ -852,6 +915,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its)
 case GITS_CMD_INV:
 ret = its_handle_inv(its, command);
 break;
+case GITS_CMD_INVALL:
+ret = its_handle_invall(its, command);
+break;
 case GITS_CMD_MAPC:
 ret = its_handle_mapc(its, command);
 break;
-- 
2.9.0


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

[Xen-devel] [PATCH v9 28/28] ARM: vITS: create ITS subnodes for Dom0 DT

[Andre Przywara]

Dom0 expects all ITSes in the system to be propagated to be able to
use MSIs.
Create Dom0 DT nodes for each hardware ITS, keeping the register frame
address the same, as the doorbell address that the Dom0 drivers program
into the BARs has to match the hardware.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c| 73 
 xen/arch/arm/gic-v3.c|  4 ++-
 xen/include/asm-arm/gic_v3_its.h | 12 +++
 3 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index f00597e..339ecce 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -20,6 +20,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -945,6 +946,78 @@ int gicv3_lpi_change_vcpu(struct domain *d, paddr_t 
vdoorbell,
 return 0;
 }
 
+/*
+ * Create the respective guest DT nodes from a list of host ITSes.
+ * This copies the reg property, so the guest sees the ITS at the same address
+ * as the host.
+ */
+int gicv3_its_make_hwdom_dt_nodes(const struct domain *d,
+  const struct dt_device_node *gic,
+  void *fdt)
+{
+uint32_t len;
+int res;
+const void *prop = NULL;
+const struct dt_device_node *its = NULL;
+const struct host_its *its_data;
+
+if ( list_empty(_its_list) )
+return 0;
+
+/* The sub-nodes require the ranges property */
+prop = dt_get_property(gic, "ranges", );
+if ( !prop )
+{
+printk(XENLOG_ERR "Can't find ranges property for the gic node\n");
+return -FDT_ERR_XEN(ENOENT);
+}
+
+res = fdt_property(fdt, "ranges", prop, len);
+if ( res )
+return res;
+
+list_for_each_entry(its_data, _its_list, entry)
+{
+its = its_data->dt_node;
+
+res = fdt_begin_node(fdt, its->name);
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,gic-v3-its");
+if ( res )
+return res;
+
+res = fdt_property(fdt, "msi-controller", NULL, 0);
+if ( res )
+return res;
+
+if ( its->phandle )
+{
+res = fdt_property_cell(fdt, "phandle", its->phandle);
+if ( res )
+return res;
+}
+
+/* Use the same reg regions as the ITS node in host DTB. */
+prop = dt_get_property(its, "reg", );
+if ( !prop )
+{
+printk(XENLOG_ERR "GICv3: Can't find ITS reg property.\n");
+res = -FDT_ERR_XEN(ENOENT);
+return res;
+}
+
+res = fdt_property(fdt, "reg", prop, len);
+if ( res )
+return res;
+
+fdt_end_node(fdt);
+}
+
+return res;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index d539d6c..c927306 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1172,8 +1172,10 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
 
 res = fdt_property(fdt, "reg", new_cells, len);
 xfree(new_cells);
+if ( res )
+return res;
 
-return res;
+return gicv3_its_make_hwdom_dt_nodes(d, gic, fdt);
 }
 
 static const hw_irq_controller gicv3_host_irq_type = {
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index e41f8fd..94c577a 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -162,6 +162,11 @@ void vgic_v3_its_free_domain(struct domain *d);
 int vgic_v3_its_init_virtual(struct domain *d, paddr_t guest_addr,
 unsigned int devid_bits, unsigned int evid_bits);
 
+/* Create the appropriate DT nodes for a hardware domain. */
+int gicv3_its_make_hwdom_dt_nodes(const struct domain *d,
+  const struct dt_device_node *gic,
+  void *fdt);
+
 /*
  * Map a device on the host by allocating an ITT on the host (ITS).
  * "nr_event" specifies how many events (interrupts) this device will need.
@@ -248,6 +253,13 @@ static inline void vgic_v3_its_free_domain(struct domain 
*d)
 {
 }
 
+static inline int gicv3_its_make_hwdom_dt_nodes(const struct domain *d,
+const struct dt_device_node 
*gic,
+void *fdt)
+{
+return 0;
+}
+
 #endif /* CONFIG_HAS_ITS */
 
 #endif
-- 
2.9.0


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

[Xen-devel] [PATCH v9 22/28] ARM: vITS: handle MOVI command

[Andre Przywara]

The MOVI command moves the interrupt affinity from one redistributor
(read: VCPU) to another.
For now migration of "live" LPIs is not yet implemented, but we store
the changed affinity in the host LPI structure and in our virtual ITTE.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c| 30 
 xen/arch/arm/gic-v3-lpi.c| 15 ++
 xen/arch/arm/vgic-v3-its.c   | 59 
 xen/include/asm-arm/gic_v3_its.h |  4 +++
 4 files changed, 108 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 8a50f7d..f00597e 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -915,6 +915,36 @@ struct pending_irq *gicv3_assign_guest_event(struct domain 
*d,
 return pirq;
 }
 
+/* Changes the target VCPU for a given host LPI assigned to a domain. */
+int gicv3_lpi_change_vcpu(struct domain *d, paddr_t vdoorbell,
+  uint32_t vdevid, uint32_t veventid,
+  unsigned int vcpu_id)
+{
+uint32_t host_lpi;
+struct its_device *dev;
+
+spin_lock(>arch.vgic.its_devices_lock);
+dev = get_its_device(d, vdoorbell, vdevid);
+if ( dev )
+host_lpi = get_host_lpi(dev, veventid);
+else
+host_lpi = 0;
+spin_unlock(>arch.vgic.its_devices_lock);
+
+if ( !host_lpi )
+return -ENOENT;
+
+/*
+ * TODO: This just changes the virtual affinity, the physical LPI
+ * still stays on the same physical CPU.
+ * Consider to move the physical affinity to the pCPU running the new
+ * vCPU. However this requires scheduling a host ITS command.
+ */
+gicv3_lpi_update_host_vcpuid(host_lpi, vcpu_id);
+
+return 0;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index d427539..6af5ad9 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -225,6 +225,21 @@ void gicv3_lpi_update_host_entry(uint32_t host_lpi, int 
domain_id,
 write_u64_atomic(>data, hlpi.data);
 }
 
+int gicv3_lpi_update_host_vcpuid(uint32_t host_lpi, unsigned int vcpu_id)
+{
+union host_lpi *hlpip;
+
+ASSERT(host_lpi >= LPI_OFFSET);
+
+host_lpi -= LPI_OFFSET;
+
+hlpip = _data.host_lpis[host_lpi / HOST_LPIS_PER_PAGE][host_lpi % 
HOST_LPIS_PER_PAGE];
+
+write_u16_atomic(>vcpu_id, vcpu_id);
+
+return 0;
+}
+
 static int gicv3_lpi_allocate_pendtable(uint64_t *reg)
 {
 uint64_t val;
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index c5c0e5e..ef7c78f 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -670,6 +670,59 @@ out_remove_mapping:
 return ret;
 }
 
+static int its_handle_movi(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+uint16_t collid = its_cmd_get_collection(cmdptr);
+unsigned long flags;
+struct pending_irq *p;
+struct vcpu *ovcpu, *nvcpu;
+uint32_t vlpi;
+int ret = -1;
+
+spin_lock(>its_lock);
+/* Check for a mapped LPI and get the LPI number. */
+if ( !read_itte_locked(its, devid, eventid, , ) )
+goto out_unlock;
+
+if ( vlpi == INVALID_LPI )
+goto out_unlock;
+
+/* Check the new collection ID and get the new VCPU pointer */
+nvcpu = get_vcpu_from_collection(its, collid);
+if ( !nvcpu )
+goto out_unlock;
+
+p = gicv3_its_get_event_pending_irq(its->d, its->doorbell_address,
+devid, eventid);
+if ( unlikely(!p) )
+goto out_unlock;
+
+spin_lock_irqsave(>arch.vgic.lock, flags);
+
+/* Update our cached vcpu_id in the pending_irq. */
+p->lpi_vcpu_id = nvcpu->vcpu_id;
+
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+
+/* Now store the new collection in the translation table. */
+if ( !write_itte_locked(its, devid, eventid, collid, vlpi, ) )
+goto out_unlock;
+
+spin_unlock(>its_lock);
+
+/* TODO: lookup currently-in-guest virtual IRQs and migrate them? */
+
+return gicv3_lpi_change_vcpu(its->d, its->doorbell_address,
+ devid, eventid, nvcpu->vcpu_id);
+
+out_unlock:
+spin_unlock(>its_lock);
+
+return ret;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg) ((reg) & GENMASK(19, 5))
 
@@ -715,6 +768,12 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its)
 case GITS_CMD_MAPTI:
 ret = its_handle_mapti(its, command);
 break;
+case GITS_CMD_MOVALL:
+gdprintk(XENLOG_G_INFO, "vGITS: ignoring MOVALL command\n");
+break;
+case GITS_CMD_MOVI:
+ret = its_handle_movi(its, 

[Xen-devel] [PATCH v9 18/28] ARM: vITS: handle CLEAR command

[Andre Przywara]

This introduces the ITS command handler for the CLEAR command, which
clears the pending state of an LPI.
This removes a not-yet injected, but already queued IRQ from a VCPU.
As read_itte() is now eventually used, we add the static keyword.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 59 --
 1 file changed, 57 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 8f1c217..8a200e9 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -52,6 +52,7 @@
  */
 struct virt_its {
 struct domain *d;
+paddr_t doorbell_address;
 unsigned int devid_bits;
 unsigned int evid_bits;
 spinlock_t vcmd_lock;   /* Protects the virtual command buffer, which 
*/
@@ -251,8 +252,8 @@ static bool read_itte_locked(struct virt_its *its, uint32_t 
devid,
  * This function takes care of the locking by taking the its_lock itself, so
  * a caller shall not hold this. Before returning, the lock is dropped again.
  */
-bool read_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
-   struct vcpu **vcpu_ptr, uint32_t *vlpi_ptr)
+static bool read_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
+  struct vcpu **vcpu_ptr, uint32_t *vlpi_ptr)
 {
 bool ret;
 
@@ -362,6 +363,57 @@ static int its_handle_mapc(struct virt_its *its, uint64_t 
*cmdptr)
 return 0;
 }
 
+/*
+ * CLEAR removes the pending state from an LPI. */
+static int its_handle_clear(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+struct pending_irq *p;
+struct vcpu *vcpu;
+uint32_t vlpi;
+unsigned long flags;
+int ret = -1;
+
+spin_lock(>its_lock);
+
+/* Translate the DevID/EvID pair into a vCPU/vLPI pair. */
+if ( !read_itte_locked(its, devid, eventid, , ) )
+goto out_unlock;
+
+p = gicv3_its_get_event_pending_irq(its->d, its->doorbell_address,
+devid, eventid);
+/* Protect against an invalid LPI number. */
+if ( unlikely(!p) )
+goto out_unlock;
+
+spin_lock_irqsave(>arch.vgic.lock, flags);
+
+/*
+ * If the LPI is already visible on the guest, it is too late to
+ * clear the pending state. However this is a benign race that can
+ * happen on real hardware, too: If the LPI has already been forwarded
+ * to a CPU interface, a CLEAR request reaching the redistributor has
+ * no effect on that LPI anymore. Since LPIs are edge triggered and
+ * have no active state, we don't need to care about this here.
+ */
+if ( !test_bit(GIC_IRQ_GUEST_VISIBLE, >status) )
+{
+/* Remove a pending, but not yet injected guest IRQ. */
+clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
+list_del_init(>inflight);
+list_del_init(>lr_queue);
+}
+
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+ret = 0;
+
+out_unlock:
+spin_unlock(>its_lock);
+
+return ret;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg) ((reg) & GENMASK(19, 5))
 
@@ -391,6 +443,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its)
 
 switch ( its_cmd_get_command(command) )
 {
+case GITS_CMD_CLEAR:
+ret = its_handle_clear(its, command);
+break;
 case GITS_CMD_INT:
 ret = its_handle_int(its, command);
 break;
-- 
2.9.0


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

[Xen-devel] [PATCH v9 13/28] ARM: vITS: add command handling stub and MMIO emulation

[Andre Przywara]

Emulate the memory mapped ITS registers and provide a stub to introduce
the ITS command handling framework (but without actually emulating any
commands at this time).
This fixes a misnomer in our virtual ITS structure, where the spec is
confusingly using ID_bits in GITS_TYPER to denote the number of event IDs
(in contrast to GICD_TYPER, where it means number of LPIs).

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c   | 526 ++-
 xen/include/asm-arm/gic_v3_its.h |   3 +
 2 files changed, 528 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 065ffe2..e3bd1f6 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -19,6 +19,16 @@
  * along with this program; If not, see .
  */
 
+/*
+ * Locking order:
+ *
+ * its->vcmd_lock(protects the command queue)
+ * its->its_lock (protects the translation tables)
+ * d->its_devices_lock   (protects the device RB tree)
+ * v->vgic.lock  (protects the struct pending_irq)
+ * d->pend_lpi_tree_lock (protects the radix tree)
+ */
+
 #include 
 #include 
 #include 
@@ -43,7 +53,7 @@
 struct virt_its {
 struct domain *d;
 unsigned int devid_bits;
-unsigned int intid_bits;
+unsigned int evid_bits;
 spinlock_t vcmd_lock;   /* Protects the virtual command buffer, which 
*/
 uint64_t cwriter;   /* consists of CWRITER and CREADR and those   
*/
 uint64_t creadr;/* shadow variables cwriter and creadr. */
@@ -53,6 +63,7 @@ struct virt_its {
 uint64_t baser_dev, baser_coll; /* BASER0 and BASER1 for the guest */
 unsigned int max_collections;
 unsigned int max_devices;
+/* changing "enabled" requires to hold *both* the vcmd_lock and its_lock */
 bool enabled;
 };
 
@@ -67,6 +78,12 @@ struct vits_itte
 uint16_t pad;
 };
 
+typedef uint16_t coll_table_entry_t;
+typedef uint64_t dev_table_entry_t;
+
+#define GITS_BASER_RO_MASK   (GITS_BASER_TYPE_MASK | \
+  (31UL << GITS_BASER_ENTRY_SIZE_SHIFT))
+
 int vgic_v3_its_init_domain(struct domain *d)
 {
 spin_lock_init(>arch.vgic.its_devices_lock);
@@ -80,6 +97,513 @@ void vgic_v3_its_free_domain(struct domain *d)
 ASSERT(RB_EMPTY_ROOT(>arch.vgic.its_devices));
 }
 
+/**
+ * Functions that handle ITS commands *
+ **/
+
+static uint64_t its_cmd_mask_field(uint64_t *its_cmd, unsigned int word,
+   unsigned int shift, unsigned int size)
+{
+return (le64_to_cpu(its_cmd[word]) >> shift) & (BIT(size) - 1);
+}
+
+#define its_cmd_get_command(cmd)its_cmd_mask_field(cmd, 0,  0,  8)
+#define its_cmd_get_deviceid(cmd)   its_cmd_mask_field(cmd, 0, 32, 32)
+#define its_cmd_get_size(cmd)   its_cmd_mask_field(cmd, 1,  0,  5)
+#define its_cmd_get_id(cmd) its_cmd_mask_field(cmd, 1,  0, 32)
+#define its_cmd_get_physical_id(cmd)its_cmd_mask_field(cmd, 1, 32, 32)
+#define its_cmd_get_collection(cmd) its_cmd_mask_field(cmd, 2,  0, 16)
+#define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2, 16, 32)
+#define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2, 63,  1)
+#define its_cmd_get_ittaddr(cmd)(its_cmd_mask_field(cmd, 2, 8, 44) << 
8)
+
+#define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
+#define ITS_CMD_OFFSET(reg) ((reg) & GENMASK(19, 5))
+
+/*
+ * Must be called with the vcmd_lock held.
+ * TODO: Investigate whether we can be smarter here and don't need to hold
+ * the lock all of the time.
+ */
+static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
+{
+paddr_t addr = its->cbaser & GENMASK(51, 12);
+uint64_t command[4];
+
+ASSERT(spin_is_locked(>vcmd_lock));
+
+if ( its->cwriter >= ITS_CMD_BUFFER_SIZE(its->cbaser) )
+return -1;
+
+while ( its->creadr != its->cwriter )
+{
+int ret;
+
+ret = vgic_access_guest_memory(d, addr + its->creadr,
+   command, sizeof(command), false);
+if ( ret )
+return ret;
+
+switch ( its_cmd_get_command(command) )
+{
+case GITS_CMD_SYNC:
+/* We handle ITS commands synchronously, so we ignore SYNC. */
+break;
+default:
+gdprintk(XENLOG_WARNING, "vGITS: unhandled ITS command %lu\n",
+ its_cmd_get_command(command));
+break;
+}
+
+write_u64_atomic(>creadr, (its->creadr + ITS_CMD_SIZE) %
+ ITS_CMD_BUFFER_SIZE(its->cbaser));
+
+if ( ret )
+gdprintk(XENLOG_WARNING,
+ "vGITS: ITS command error %d while handling command 
%lu\n",
+ 

[Xen-devel] [PATCH v9 08/28] ARM: introduce vgic_access_guest_memory()

[Andre Przywara]

From: Vijaya Kumar K 

This function allows to copy a chunk of data from and to guest physical
memory. It looks up the associated page from the guest's p2m tree
and maps this page temporarily for the time of the access.
This function was originally written by Vijaya as part of an earlier series:
https://patchwork.kernel.org/patch/8177251

Signed-off-by: Vijaya Kumar K 
Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic.c| 50 ++
 xen/include/asm-arm/vgic.h |  3 +++
 2 files changed, 53 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index c29ad5e..66adeb4 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -620,6 +621,55 @@ void vgic_free_virq(struct domain *d, unsigned int virq)
 }
 
 /*
+ * Temporarily map one physical guest page and copy data to or from it.
+ * The data to be copied cannot cross a page boundary.
+ */
+int vgic_access_guest_memory(struct domain *d, paddr_t gpa, void *buf,
+ uint32_t size, bool_t is_write)
+{
+struct page_info *page;
+uint64_t offset = gpa & ~PAGE_MASK;  /* Offset within the mapped page */
+p2m_type_t p2mt;
+void *p;
+
+/* Do not cross a page boundary. */
+if ( size > (PAGE_SIZE - offset) )
+{
+printk(XENLOG_G_ERR "d%d: vITS: memory access would cross page 
boundary\n",
+   d->domain_id);
+return -EINVAL;
+}
+
+page = get_page_from_gfn(d, paddr_to_pfn(gpa), , P2M_ALLOC);
+if ( !page )
+{
+printk(XENLOG_G_ERR "d%d: vITS: Failed to get table entry\n",
+   d->domain_id);
+return -EINVAL;
+}
+
+if ( !p2m_is_ram(p2mt) )
+{
+put_page(page);
+printk(XENLOG_G_ERR "d%d: vITS: memory used by the ITS should be RAM.",
+   d->domain_id);
+return -EINVAL;
+}
+
+p = __map_domain_page(page);
+
+if ( is_write )
+memcpy(p + offset, buf, size);
+else
+memcpy(buf, p + offset, size);
+
+unmap_domain_page(p);
+put_page(page);
+
+return 0;
+}
+
+/*
  * Local variables:
  * mode: C
  * c-file-style: "BSD"
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 7efa164..6b17802 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -313,6 +313,9 @@ extern void register_vgic_ops(struct domain *d, const 
struct vgic_ops *ops);
 int vgic_v2_init(struct domain *d, int *mmio_count);
 int vgic_v3_init(struct domain *d, int *mmio_count);
 
+int vgic_access_guest_memory(struct domain *d, paddr_t gpa, void *buf,
+ uint32_t size, bool_t is_write);
+
 extern int domain_vgic_register(struct domain *d, int *mmio_count);
 extern int vcpu_vgic_free(struct vcpu *v);
 extern bool vgic_to_sgi(struct vcpu *v, register_t sgir,
-- 
2.9.0


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

[Xen-devel] [PATCH v9 12/28] ARM: vGIC: advertise LPI support

[Andre Przywara]

To let a guest know about the availability of virtual LPIs, set the
respective bits in the virtual GIC registers and let a guest control
the LPI enable bit.
Only report the LPI capability if the host has initialized at least
one ITS.
This removes a "TBD" comment, as we now populate the processor number
in the GICR_TYPE register.
Advertise 24 bits worth of LPIs to the guest.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3.c | 70 ++
 1 file changed, 65 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 38c123c..6dbdb2e 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -170,8 +170,19 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 switch ( gicr_reg )
 {
 case VREG32(GICR_CTLR):
-/* We have not implemented LPI's, read zero */
-goto read_as_zero_32;
+{
+unsigned long flags;
+
+if ( !v->domain->arch.vgic.has_its )
+goto read_as_zero_32;
+if ( dabt.size != DABT_WORD ) goto bad_width;
+
+spin_lock_irqsave(>arch.vgic.lock, flags);
+*r = vgic_reg32_extract(!!(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED),
+info);
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+return 1;
+}
 
 case VREG32(GICR_IIDR):
 if ( dabt.size != DABT_WORD ) goto bad_width;
@@ -183,16 +194,20 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 uint64_t typer, aff;
 
 if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
-/* TBD: Update processor id in [23:8] when ITS support is added */
 aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
 typer = aff;
+/* We use the VCPU ID as the redistributor ID in bits[23:8] */
+typer |= (v->vcpu_id & 0x) << 8;
 
 if ( v->arch.vgic.flags & VGIC_V3_RDIST_LAST )
 typer |= GICR_TYPER_LAST;
 
+if ( v->domain->arch.vgic.has_its )
+typer |= GICR_TYPER_PLPIS;
+
 *r = vgic_reg64_extract(typer, info);
 
 return 1;
@@ -426,6 +441,28 @@ static uint64_t sanitize_pendbaser(uint64_t reg)
 return reg;
 }
 
+static void vgic_vcpu_enable_lpis(struct vcpu *v)
+{
+uint64_t reg = v->domain->arch.vgic.rdist_propbase;
+unsigned int nr_lpis = BIT((reg & 0x1f) + 1);
+
+/* rdists_enabled is protected by the domain lock. */
+ASSERT(spin_is_locked(>domain->arch.vgic.lock));
+
+if ( nr_lpis < LPI_OFFSET )
+nr_lpis = 0;
+else
+nr_lpis -= LPI_OFFSET;
+
+if ( !v->domain->arch.vgic.rdists_enabled )
+{
+v->domain->arch.vgic.nr_lpis = nr_lpis;
+v->domain->arch.vgic.rdists_enabled = true;
+}
+
+v->arch.vgic.flags |= VGIC_V3_LPIS_ENABLED;
+}
+
 static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
   uint32_t gicr_reg,
   register_t r)
@@ -436,8 +473,26 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, 
mmio_info_t *info,
 switch ( gicr_reg )
 {
 case VREG32(GICR_CTLR):
-/* LPI's not implemented */
-goto write_ignore_32;
+{
+unsigned long flags;
+
+if ( !v->domain->arch.vgic.has_its )
+goto write_ignore_32;
+if ( dabt.size != DABT_WORD ) goto bad_width;
+
+vgic_lock(v);   /* protects rdists_enabled */
+spin_lock_irqsave(>arch.vgic.lock, flags);
+
+/* LPIs can only be enabled once, but never disabled again. */
+if ( (r & GICR_CTLR_ENABLE_LPIS) &&
+ !(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED) )
+vgic_vcpu_enable_lpis(v);
+
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+vgic_unlock(v);
+
+return 1;
+}
 
 case VREG32(GICR_IIDR):
 /* RO */
@@ -1058,6 +1113,11 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 typer = ((ncpus - 1) << GICD_TYPE_CPUS_SHIFT |
  DIV_ROUND_UP(v->domain->arch.vgic.nr_spis, 32));
 
+if ( v->domain->arch.vgic.has_its )
+{
+typer |= GICD_TYPE_LPIS;
+irq_bits = v->domain->arch.vgic.intid_bits;
+}
 typer |= (irq_bits - 1) << GICD_TYPE_ID_BITS_SHIFT;
 
 *r = vgic_reg32_extract(typer, info);
-- 
2.9.0


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

Re: [Xen-devel] [PATCH for-4.9] xl: don't ignore return value from libxl_device_events_handler

[Julien Grall]

Hi Wei,

On 11/05/17 13:57, Wei Liu wrote:

That function can return a whole slew of error codes. Translate them
to EXIT_FAILURE.

Signed-off-by: Wei Liu 


Release-acked-by: Julien Grall 

Cheers,


---
Cc: Ian Jackson 
Cc: Julien Grall 
Cc: Roger Pau Monné 
---
 tools/xl/xl_misc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/xl/xl_misc.c b/tools/xl/xl_misc.c
index 9037e2b2f0..9c6227af23 100644
--- a/tools/xl/xl_misc.c
+++ b/tools/xl/xl_misc.c
@@ -182,7 +182,7 @@ int main_devd(int argc, char **argv)
 }
 }

-libxl_device_events_handler(ctx, 0);
+ret = libxl_device_events_handler(ctx, 0) ? EXIT_FAILURE : EXIT_SUCCESS;

 out:
 return ret;



--
Julien Grall

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

[Xen-devel] [PATCH v9 05/28] ARM: GICv3: forward pending LPIs to guests

[Andre Przywara]

Upon receiving an LPI on the host, we need to find the right VCPU and
virtual IRQ number to get this IRQ injected.
Iterate our two-level LPI table to find this information quickly when
the host takes an LPI. Call the existing injection function to let the
GIC emulation deal with this interrupt.
Also we enhance struct pending_irq to cache the pending bit and the
priority information for LPIs. Reading the information from there is
faster than accessing the property table from guest memory. Also it
use some padding area, so does not require more memory.
This introduces a do_LPI() as a hardware gic_ops and a function to
retrieve the (cached) priority value of an LPI and a vgic_ops.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v2.c|  7 
 xen/arch/arm/gic-v3-lpi.c| 71 
 xen/arch/arm/gic-v3.c|  1 +
 xen/arch/arm/gic.c   |  8 -
 xen/arch/arm/vgic-v2.c   |  7 
 xen/arch/arm/vgic-v3.c   | 18 ++
 xen/arch/arm/vgic.c  |  7 +++-
 xen/include/asm-arm/domain.h |  3 +-
 xen/include/asm-arm/gic.h|  2 ++
 xen/include/asm-arm/gic_v3_its.h |  8 +
 xen/include/asm-arm/vgic.h   |  2 ++
 11 files changed, 131 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 270a136..ffbe47c 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -1217,6 +1217,12 @@ static int __init gicv2_init(void)
 return 0;
 }
 
+static void gicv2_do_LPI(unsigned int lpi)
+{
+/* No LPIs in a GICv2 */
+BUG();
+}
+
 const static struct gic_hw_operations gicv2_ops = {
 .info= _info,
 .init= gicv2_init,
@@ -1244,6 +1250,7 @@ const static struct gic_hw_operations gicv2_ops = {
 .make_hwdom_madt = gicv2_make_hwdom_madt,
 .map_hwdom_extra_mappings = gicv2_map_hwdown_extra_mappings,
 .iomem_deny_access   = gicv2_iomem_deny_access,
+.do_LPI  = gicv2_do_LPI,
 };
 
 /* Set up the GIC */
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 292f2d0..44f6315 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -136,6 +136,77 @@ uint64_t gicv3_get_redist_address(unsigned int cpu, bool 
use_pta)
 return per_cpu(lpi_redist, cpu).redist_id << 16;
 }
 
+/*
+ * Handle incoming LPIs, which are a bit special, because they are potentially
+ * numerous and also only get injected into guests. Treat them specially here,
+ * by just looking up their target vCPU and virtual LPI number and hand it
+ * over to the injection function.
+ * Please note that LPIs are edge-triggered only, also have no active state,
+ * so spurious interrupts on the host side are no issue (we can just ignore
+ * them).
+ * Also a guest cannot expect that firing interrupts that haven't been
+ * fully configured yet will reach the CPU, so we don't need to care about
+ * this special case.
+ */
+void gicv3_do_LPI(unsigned int lpi)
+{
+struct domain *d;
+union host_lpi *hlpip, hlpi;
+struct vcpu *vcpu;
+
+irq_enter();
+
+/* EOI the LPI already. */
+WRITE_SYSREG32(lpi, ICC_EOIR1_EL1);
+
+/* Find out if a guest mapped something to this physical LPI. */
+hlpip = gic_get_host_lpi(lpi);
+if ( !hlpip )
+goto out;
+
+hlpi.data = read_u64_atomic(>data);
+
+/*
+ * Unmapped events are marked with an invalid LPI ID. We can safely
+ * ignore them, as they have no further state and no-one can expect
+ * to see them if they have not been mapped.
+ */
+if ( hlpi.virt_lpi == INVALID_LPI )
+goto out;
+
+d = rcu_lock_domain_by_id(hlpi.dom_id);
+if ( !d )
+goto out;
+
+/* Make sure we don't step beyond the vcpu array. */
+if ( hlpi.vcpu_id >= d->max_vcpus )
+{
+rcu_unlock_domain(d);
+goto out;
+}
+
+vcpu = d->vcpu[hlpi.vcpu_id];
+
+/* Check if the VCPU is ready to receive LPIs. */
+if ( vcpu->arch.vgic.flags & VGIC_V3_LPIS_ENABLED )
+/*
+ * TODO: Investigate what to do here for potential interrupt storms.
+ * As we keep all host LPIs enabled, for disabling LPIs we would need
+ * to queue a ITS host command, which we avoid so far during a guest's
+ * runtime. Also re-enabling would trigger a host command upon the
+ * guest sending a command, which could be an attack vector for
+ * hogging the host command queue.
+ * See the thread around here for some background:
+ * https://lists.xen.org/archives/html/xen-devel/2016-12/msg3.html
+ */
+vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
+
+rcu_unlock_domain(d);
+
+out:
+irq_exit();
+}
+
 static int gicv3_lpi_allocate_pendtable(uint64_t *reg)
 {
 uint64_t val;
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 29c8964..8140c5f 100644
--- a/xen/arch/arm/gic-v3.c
+++ 

[Xen-devel] [PATCH v9 01/28] ARM: GICv3: setup number of LPI bits for a GICv3 guest

[Andre Przywara]

The host supports a certain number of LPI identifiers, as stored in
the GICD_TYPER register.
Store this number from the hardware register in vgic_v3_hw to allow
injecting the very same number into a guest (Dom0).
DomUs get a fixed limited number for now. We may want to revisit this
when we get proper DomU ITS support.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3.c | 6 +-
 xen/arch/arm/vgic-v3.c| 9 -
 xen/include/asm-arm/domain.h  | 1 +
 xen/include/asm-arm/vgic.h| 3 ++-
 xen/include/public/arch-arm.h | 4 
 5 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a559e5e..29c8964 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1579,6 +1579,7 @@ static int __init gicv3_init(void)
 {
 int res, i;
 uint32_t reg;
+unsigned int intid_bits;
 
 if ( !cpu_has_gicv3 )
 {
@@ -1622,8 +1623,11 @@ static int __init gicv3_init(void)
i, r->base, r->base + r->size);
 }
 
+reg = readl_relaxed(GICD + GICD_TYPER);
+intid_bits = GICD_TYPE_ID_BITS(reg);
+
 vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
- gicv3.rdist_stride);
+ gicv3.rdist_stride, intid_bits);
 gicv3_init_v2();
 
 spin_lock_init();
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index d10757a..25e16dc 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -57,18 +57,21 @@ static struct {
 unsigned int nr_rdist_regions;
 const struct rdist_region *regions;
 uint32_t rdist_stride; /* Re-distributor stride */
+unsigned int intid_bits;  /* Number of interrupt ID bits */
 } vgic_v3_hw;
 
 void vgic_v3_setup_hw(paddr_t dbase,
   unsigned int nr_rdist_regions,
   const struct rdist_region *regions,
-  uint32_t rdist_stride)
+  uint32_t rdist_stride,
+  unsigned int intid_bits)
 {
 vgic_v3_hw.enabled = 1;
 vgic_v3_hw.dbase = dbase;
 vgic_v3_hw.nr_rdist_regions = nr_rdist_regions;
 vgic_v3_hw.regions = regions;
 vgic_v3_hw.rdist_stride = rdist_stride;
+vgic_v3_hw.intid_bits = intid_bits;
 }
 
 static struct vcpu *vgic_v3_irouter_to_vcpu(struct domain *d, uint64_t irouter)
@@ -1482,6 +1485,8 @@ static int vgic_v3_domain_init(struct domain *d)
 
 first_cpu += size / d->arch.vgic.rdist_stride;
 }
+
+d->arch.vgic.intid_bits = vgic_v3_hw.intid_bits;
 }
 else
 {
@@ -1497,6 +1502,8 @@ static int vgic_v3_domain_init(struct domain *d)
 d->arch.vgic.rdist_regions[0].base = GUEST_GICV3_GICR0_BASE;
 d->arch.vgic.rdist_regions[0].size = GUEST_GICV3_GICR0_SIZE;
 d->arch.vgic.rdist_regions[0].first_cpu = 0;
+
+d->arch.vgic.intid_bits = GUEST_GICV3_GICD_INTID_BITS;
 }
 
 ret = vgic_v3_its_init_domain(d);
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 6de8082..7c3829d 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -111,6 +111,7 @@ struct arch_domain
 uint32_t rdist_stride;  /* Re-Distributor stride */
 struct rb_root its_devices; /* Devices mapped to an ITS */
 spinlock_t its_devices_lock;/* Protects the its_devices tree */
+unsigned int intid_bits;
 #endif
 } vgic;
 
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 544867a..df75064 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -346,7 +346,8 @@ struct rdist_region;
 void vgic_v3_setup_hw(paddr_t dbase,
   unsigned int nr_rdist_regions,
   const struct rdist_region *regions,
-  uint32_t rdist_stride);
+  uint32_t rdist_stride,
+  unsigned int intid_bits);
 #endif
 
 #endif /* __ASM_ARM_VGIC_H__ */
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index bd974fb..033dcee 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -400,6 +400,10 @@ typedef uint64_t xen_callback_t;
 #define GUEST_GICV3_GICD_BASE  xen_mk_ullong(0x03001000)
 #define GUEST_GICV3_GICD_SIZE  xen_mk_ullong(0x0001)
 
+/* TODO: Should this number be a tool stack decision? */
+/* The number of interrupt ID bits a guest (not Dom0) sees. */
+#define GUEST_GICV3_GICD_INTID_BITS 16
+
 #define GUEST_GICV3_RDIST_STRIDE   xen_mk_ullong(0x0002)
 #define GUEST_GICV3_RDIST_REGIONS  1
 
-- 
2.9.0


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

[Xen-devel] [PATCH v9 09/28] ARM: vGICv3: re-use vgic_reg64_check_access

[Andre Przywara]

vgic_reg64_check_access() checks for a valid access width of a 64-bit
MMIO register, which is useful beyond the current GICv3 emulation only.
Move this function to the vgic-emul.h to be easily reusable.

Signed-off-by: Andre Przywara 
Acked-by: Julien Grall 
---
 xen/arch/arm/vgic-v3.c  | 9 -
 xen/include/asm-arm/vgic-emul.h | 9 +
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 5166f9c..38c123c 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -161,15 +161,6 @@ static void vgic_store_irouter(struct domain *d, struct 
vgic_irq_rank *rank,
 }
 }
 
-static inline bool vgic_reg64_check_access(struct hsr_dabt dabt)
-{
-/*
- * 64 bits registers can be accessible using 32-bit and 64-bit unless
- * stated otherwise (See 8.1.3 ARM IHI 0069A).
- */
-return ( dabt.size == DABT_DOUBLE_WORD || dabt.size == DABT_WORD );
-}
-
 static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, mmio_info_t *info,
  uint32_t gicr_reg,
  register_t *r)
diff --git a/xen/include/asm-arm/vgic-emul.h b/xen/include/asm-arm/vgic-emul.h
index 184a1f0..e52fbaa 100644
--- a/xen/include/asm-arm/vgic-emul.h
+++ b/xen/include/asm-arm/vgic-emul.h
@@ -12,6 +12,15 @@
 #define VRANGE32(start, end) start ... end + 3
 #define VRANGE64(start, end) start ... end + 7
 
+/*
+ * 64 bits registers can be accessible using 32-bit and 64-bit unless
+ * stated otherwise (See 8.1.3 ARM IHI 0069A).
+ */
+static inline bool vgic_reg64_check_access(struct hsr_dabt dabt)
+{
+return ( dabt.size == DABT_DOUBLE_WORD || dabt.size == DABT_WORD );
+}
+
 #endif /* __ASM_ARM_VGIC_EMUL_H__ */
 
 /*
-- 
2.9.0


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

Re: [Xen-devel] [Patch] Fix broken package config file xenlight.pc.in

[Julien Grall]

Hi Wei,

On 11/05/17 17:30, Wei Liu wrote:

On Thu, May 11, 2017 at 10:29:42AM -0600, Charles Arnold wrote:

The Requires line in this config file uses the wrong names for two dependencies.

The package config file for xenctrl is called 'xencontrol' and for blktapctl is
called 'xenblktapctl'. Running a command like 'pkg-config --exists xenlight' 
will
fail without this fix.

Signed-off-by: Charles Arnold 


Acked-by: Wei Liu 

Julien this should be in 4.9.


Release-acked-by: Julien Grall 

Cheers,





diff --git a/tools/libxl/xenlight.pc.in b/tools/libxl/xenlight.pc.in
index 71d093a0ae..86c38a5634 100644
--- a/tools/libxl/xenlight.pc.in
+++ b/tools/libxl/xenlight.pc.in
@@ -9,4 +9,4 @@ Description: The Xenlight library for Xen hypervisor
 Version: @@version@@
 Cflags: -I${includedir}
 Libs: @@libsflag@@${libdir} -lxenlight
-Requires.private: xentoollog,xenevtchn,xenctrl,xenguest,xenstore,blktapctl
+Requires.private: 
xentoollog,xenevtchn,xencontrol,xenguest,xenstore,xenblktapctl




--
Julien Grall

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

Re: [Xen-devel] [PATCH V4] x86/ioreq_server: Make p2m_finish_type_change actually work

[Julien Grall]

Hi,

On 11/05/17 12:12, Jan Beulich wrote:

On 12.05.17 at 04:42,  wrote:

Commit 6d774a951696 ("x86/ioreq server: synchronously reset outstanding
p2m_ioreq_server entries when an ioreq server unmaps") introduced
p2m_finish_type_change(), which was meant to synchronously finish a
previously initiated type change over a gpfn range.  It did this by
calling get_entry(), checking if it was the appropriate type, and then
calling set_entry().

Unfortunately, a previous commit (1679e0df3df6 "x86/ioreq server:
asynchronously reset outstanding p2m_ioreq_server entries") modified
get_entry() to always return the new type after the type change, meaning
that p2m_finish_type_change() never changed any entries.  Which means
when an ioreq server was detached and then re-attached (as happens in
XenGT on reboot) the re-attach failed.

Fix this by using the existing p2m-specific recalculation logic instead
of doing a read-check-write loop.

Fix: 'commit 6d774a951696 ("x86/ioreq server: synchronously reset
  outstanding p2m_ioreq_server entries when an ioreq server unmaps")'

Signed-off-by: Xiong Zhang 
Signed-off-by: Yu Zhang 
Reviewed-by: George Dunlap 


Reviewed-by: Jan Beulich 
albeit I'm not overly happy with ...


+int p2m_finish_type_change(struct domain *d,
+   gfn_t first_gfn, unsigned long max_nr)
 {
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
-p2m_type_t t;
 unsigned long gfn = gfn_x(first_gfn);
 unsigned long last_gfn = gfn + max_nr - 1;
-
-ASSERT(ot != nt);
-ASSERT(p2m_is_changeable(ot) && p2m_is_changeable(nt));
+int rc = 0;

 p2m_lock(p2m);

 last_gfn = min(last_gfn, p2m->max_mapped_pfn);
 while ( gfn <= last_gfn )
 {
-get_gfn_query_unlocked(d, gfn, );
-
-if ( t == ot )
-p2m_change_type_one(d, gfn, t, nt);
+rc = p2m->recalc(p2m, gfn);
+/*
+ * ept->recalc could return 0/1/-ENOMEM. pt->recalc could return
+ * 0/-ENOMEM/-ENOENT, -ENOENT isn't an error as we are looping
+ * gfn here.
+ */
+if ( rc == -ENOENT)


NIT: space missing before )


+rc = 0;
+else if ( rc < 0 )
+{
+gdprintk(XENLOG_ERR, "p2m->recalc failed! Dom%d gfn=%lx\n",
+ d->domain_id, gfn);


... a message being logged here.

Also I'm sure it was pointed out before that if this is meant for
4.9 (which I assume it is) you should have Cc-ed Julien (now
added).


Xiong Zhang, can you confirm this is meant for Xen 4.9?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] Hypercall Inquiries

[Andrew Cooper]

On 11/05/17 15:22, Rapidash wrote:
> Greetings,
>  My co-worker and I are looking into Xen Hypervisor. By any chance, do
> you or any of your colleagues have technical material/ papers/
> presentations detailing how the hypercall interacts with the hypervisor?

xen/include/public/arch-x86/xen-x86_{32,64}.h document the ABI.

There are some books on Xen, but there isn't a written technical
specification (as far as I am aware).

>
>  Thank you in advance for any assistance,
>   - Rapidash
>
>
> Some specific questions:
> - If the memory of the VM is stored on non-congruent sections of the
> host's machine memory, how does the hypercall handler check whether a
> passed in pointer parameter falls within these VM claimed sections of
> memory?

You look like you are considering PV guests?

If so, realise that PV guests running under Xen are just like userspace
processes running under an native kernel.  There is a shared virtual
address space, and the system call interface uses plain pointers.

> - Since the hypercalls are limited in number compared to syscalls, is
> there ever an instance where the domain will require a syscall that
> the hypercall does not cover?

I don't understand the what you mean.  "hypercalls" are just system
calls from the guest kernel to Xen.  They are entirely orthogonal to the
guests userspace issuing system calls to its kernel.

>  
> Also, we have been looking at the Xen hypercall source code to try and
> figure out the mechanics there. In file "hypercall-x86_64.h" there is
> the following code segment we are attempting to decipher (from it, we
> can figure out the preceding functions):
>
> #define _hypercall5(type, name, a1, a2, a3, a4, a5)  \
> ({\
>  long __res, __ign1, __ign2, __ign3;   \
>  asm volatile (  \
>   "movq %7,%%r10; movq %8,%%r8; "   \
>   "call hypercall_page + ("STR(__HYPERVISOR_##name)" * 32)"\
>   : "=a" (__res), "=D" (__ign1), "=S" (__ign2), \
>   "=d" (__ign3) \
>   : "1" ((long)(a1)), "2" ((long)(a2)),  \
>   "3" ((long)(a3)), "g" ((long)(a4)),  \
>   "g" ((long)(a5))\
>   : "memory", "r10", "r8" );   \
>  (type)__res;  \
> })

This is a rather poor piece of code, but I am afraid that my best advice
here is to read the GCC documentation on how the asm() statement.  None
of these questions are xen-specific, but the chances are good that you
wont understand my answers if you don't understand how extended assembly
works.

>
> - The first line within the asm volatile section, are the contents of
> registers being saved to memory? If so, where?

No.  AT syntax reads left to right, so the destination operands are on
the right hand side.  In this case, the %r10 and %r8 registers.

> - In the third and fourth lines within the same section, are values
> from __res being placed into the "a" register, or are the values
> within the "a" register being stored in the variable __res for use later?

"=a" is an output, meaning that %rax gets stored into __res.

> - Does the "1", "2", "3", "g", "g" correspond to the ebx, ecx, edx,
> esi, and edi registers? Or are they a different set?

The numbers match up to the output operands, so are %rdi, %rsi, %rdx in
that order.

The g constraint means any general purpose register.

~Andrew

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

[Xen-devel] [resend PATCH] xen: common: rbtree: ported updates from linux tree

[Praveen Kumar]

The patch contains the updated version of rbtree implementation from linux
kernel tree containing the fixes so far handled.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c| 748 +
 xen/include/xen/compiler.h |  60 +++
 xen/include/xen/rbtree.h   | 120 --
 xen/include/xen/rbtree_augmented.h | 283 ++
 4 files changed, 931 insertions(+), 280 deletions(-)
 create mode 100644 xen/include/xen/rbtree_augmented.h

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index 3328960d56..ae152c5bf2 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -2,7 +2,8 @@
   Red Black Trees
   (C) 1999  Andrea Arcangeli 
   (C) 2002  David Woodhouse 
-  
+  (C) 2012  Michel Lespinasse 
+
   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
@@ -14,286 +15,479 @@
   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 .
+  along with this program; if not, write to the Free Software
+  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 
   linux/lib/rbtree.c
 */
 
+#include 
 #include 
-#include 
-
-static void __rb_rotate_left(struct rb_node *node, struct rb_root *root)
-{
-struct rb_node *right = node->rb_right;
-struct rb_node *parent = rb_parent(node);
 
-if ((node->rb_right = right->rb_left))
-rb_set_parent(right->rb_left, node);
-right->rb_left = node;
+/*
+ * red-black trees properties:  http://en.wikipedia.org/wiki/Rbtree
+ *
+ *  1) A node is either red or black
+ *  2) The root is black
+ *  3) All leaves (NULL) are black
+ *  4) Both children of every red node are black
+ *  5) Every simple path from root to leaves contains the same number
+ * of black nodes.
+ *
+ *  4 and 5 give the O(log n) guarantee, since 4 implies you cannot have two
+ *  consecutive red nodes in a path and every red node is therefore followed by
+ *  a black. So if B is the number of black nodes on every simple path (as per
+ *  5), then the longest possible path due to 4 is 2B.
+ *
+ *  We shall indicate color with case, where black nodes are uppercase and red
+ *  nodes will be lowercase. Unknown color nodes shall be drawn as red within
+ *  parentheses and have some accompanying text comment.
+ */
 
-rb_set_parent(right, parent);
+/*
+ * Notes on lockless lookups:
+ *
+ * All stores to the tree structure (rb_left and rb_right) must be done using
+ * WRITE_ONCE(). And we must not inadvertently cause (temporary) loops in the
+ * tree structure as seen in program order.
+ *
+ * These two requirements will allow lockless iteration of the tree -- not
+ * correct iteration mind you, tree rotations are not atomic so a lookup might
+ * miss entire subtrees.
+ *
+ * But they do guarantee that any such traversal will only see valid elements
+ * and that it will indeed complete -- does not get stuck in a loop.
+ *
+ * It also guarantees that if the lookup returns an element it is the 'correct'
+ * one. But not returning an element does _NOT_ mean it's not present.
+ *
+ * NOTE:
+ *
+ * Stores to __rb_parent_color are not important for simple lookups so those
+ * are left undone as of now. Nor did I check for loops involving parent
+ * pointers.
+ */
 
-if (parent)
-{
-if (node == parent->rb_left)
-parent->rb_left = right;
-else
-parent->rb_right = right;
-}
-else
-root->rb_node = right;
-rb_set_parent(node, right);
+static inline void rb_set_black(struct rb_node *rb)
+{
+rb->__rb_parent_color |= RB_BLACK;
 }
 
-static void __rb_rotate_right(struct rb_node *node, struct rb_root *root)
+static inline struct rb_node *rb_red_parent(struct rb_node *red)
 {
-struct rb_node *left = node->rb_left;
-struct rb_node *parent = rb_parent(node);
-
-if ((node->rb_left = left->rb_right))
-rb_set_parent(left->rb_right, node);
-left->rb_right = node;
-
-rb_set_parent(left, parent);
+return (struct rb_node *)red->__rb_parent_color;
+}
 
-if (parent)
-{
-if (node == parent->rb_right)
-parent->rb_right = left;
-else
-parent->rb_left = left;
-}
-else
-root->rb_node = left;
-rb_set_parent(node, left);
+/*
+ * Helper function for rotations:
+ * - old's parent and color get assigned to new
+ * - old gets assigned new as a parent and 'color' as a color.
+ */
+static inline void
+__rb_rotate_set_parents(struct rb_node *old, struct rb_node *new,
+struct rb_root *root, int color)
+{
+struct rb_node *parent = rb_parent(old);
+new->__rb_parent_color = 

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

[George Dunlap]

On Thu, May 11, 2017 at 6:14 PM, Volodymyr Babchuk
 wrote:
> Hi George,
>
> On 11 May 2017 at 19:35, George Dunlap  wrote:
>> Even better would be to skip the module-loading step entirely, and just
>> compile proprietary code directly into your Xen binary.
>>
>> Both solutions, unfortunately, are illegal.*
> Look, I don't saying we want to produce closed-source modules or apps.
> We want to write open source code. Just imagine, that certain header
> files have some proprietary license (e.g. some device interface
> definition and this interface is IP of company which developed it).
> AFAIK, it can't be included into Xen distribution. I thought, that it
> can be included in some module with different (but still open source)
> license.  But if you say that it can't... Then I don't know. It is out
> of my competence. I'm not lawyer also.

I see.  That's good to know, but it doesn't change the legal aspect of
things. :-0

It used to be held that the information contained in headers --
constants, interface definitions, and so on -- weren't copyrightable;
in which case you could just include the header (or a modified version
of it) without any problems.  Unfortunately Oracle v Google may have
changed that.  But you'd have to ask a lawyer about that...

 -George

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

[Xen-devel] Added 5 additional Design sessions to Developer Summit Schedule

[Lars Kurth]

Hi everyone,

I added the following sessions to the Design Part of the Summit: you can see 
them via 
https://xendeveloperanddesignsummit2017.sched.com/overview/type/Interactive+Design+%26+Problem+Solving+Session
 (just showing Design sessions)

Please also make use of the "Add to my Sched(ule)" feature in 
https://xendeveloperanddesignsummit2017.sched.com: this will help me identify 
scheduling conflicts *before* the event and will make the event smoother: in 
other words we can make scheduling decisions using real data, before the event.

Added Sessions:

July 12
===
Design Discussion: Intel New QoS (RDT) Features - Yi Sun, Intel 

Design Discussion: SGX virtualization - Kai Huang, Intel

Design Discussion: Support for 5-level paging (including support for PV-guests) 
- Yi Liu, Intel & Jürgen Groß, SUSE 
Note: We merged a proposal from Yi and Jürgen. If we need more time, we can add 
another session on the 13th

July 13
===
Design Discussion: Shared Virtual Memory Virtualization Implementation on Xen - 
Yi Liu, Intel

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

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

[George Dunlap]

On Thu, May 11, 2017 at 6:14 PM, George Dunlap  wrote:
> yourself at a risk of meeting a guy like Patrick McHardy[1], a private
> individual with copyright on the Linux kernel

This should be "copyright on *code in the* Linux Kernel".  Obviously
he doesn't own a copyright on the whole thing, just a decent chunk of
it.

 -George

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

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

[Volodymyr Babchuk]

Hi George,

On 11 May 2017 at 19:35, George Dunlap  wrote:
> Even better would be to skip the module-loading step entirely, and just
> compile proprietary code directly into your Xen binary.
>
> Both solutions, unfortunately, are illegal.*
Look, I don't saying we want to produce closed-source modules or apps.
We want to write open source code. Just imagine, that certain header
files have some proprietary license (e.g. some device interface
definition and this interface is IP of company which developed it).
AFAIK, it can't be included into Xen distribution. I thought, that it
can be included in some module with different (but still open source)
license.  But if you say that it can't... Then I don't know. It is out
of my competence. I'm not lawyer also.

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

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

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

[George Dunlap]

On 11/05/17 16:35, Julien Grall wrote:
> Renaming the subject + adding more people in the conversation as this is
> not related to only ARM anymore.
> 
> On 11/05/17 16:19, Volodymyr Babchuk wrote:
>> Hi Stefano,
>>
>> On 10 May 2017 at 21:24, Stefano Stabellini 
>> wrote:
>>> I just want to point out that the comparision with tasklets is not
>>> helpful. Tasklets involve the idle vcpu, which we are trying to step
>>> away
>>> from because it increases irq latency. Tasklets don't provide any
>>> isolation. The context switch model for the idle vcpu and for EL0 apps
>>> is different, thus it has a different cost.
>>>
>>> I think we shouldn't mention tasklets in this thread any longer.
>> Yep, you are right. Let's forget about tasklets and focus on EL0 apps.
>>
>> I want summarize political (opposed to technical) part of the discussion.
>>
>> We, here at EPAM, viewed EL0 apps primarily as a way to extend
>> hypervisor. Because when it comes to embedded and automotive, there
>> arise some ugly things, that are needed at hypervisor level:
>> TEE mediators (OP-TEE is a good TEE, but for example there is TI's
>> MSHIELD with deeply proprietary license),

If you're going to use a deeply proprietary TEE mediator, then you need
to find yourself a deeply proprietary hypervisor to go along with it --
either one you pay a license fee for or one you develop yourself.  It
would almost certainly be cheaper to improve the open-source one than to
do either of those.

Or you can try mixing the two and see what happens; but that doesn't
seem like a very sound legal strategy to me.

>> ...some [things can't be included in hypervisor] because of code
>> size or complexity.

Sorry, just to be clear: below you mentioned modules as a solution, and
given the context this would be included.  So can you expand on what you
mean that there are things that 1) can't be included in the hypervisor
because of code size or complexity, but for which 2) loadable modules
would be a suitable solution?

>> And we can't run
>> them in stubdoms, because stubdoms are slow for certain use-cases, in
>> some cases they are insecure, in some cases they just don't fit at
>> all.
>> On other hand you consider EL0 apps as ideal host for emulators only.
>> I can see your point, because XEN was always viewed as hypervisor for
>> servers.
>> But servers have different requirements in comparison to embedded
>> applications. Traditional servers does not use hardware accelerated
>> video decoders, they don't need to disable cpu's or scale frequencies
>> to preserve energy (okay, they need to, but it is not as pressing, as
>> on battery-powered device), there almost no proprietary code (or even
>> proprietary blobs, argh!).
>> Looks like virtualization on embedded is the next big thing. Linux
>> kernel was able to satisfy both parties. I hope that XEN can do the
>> same.

For many of these, there are probably technical solutions that we could
come up with that would allow proprietary content (such as video
decoders ) that would have suitable performance without needing access
to the Xen address space.

Maybe I'm just not familiar with things, but it's hard for me to imagine
why you'd need proprietary blobs to disable cpus or scale frequency.
Are these really such complex activities that it's worth investing
thousands of hours of developer work into developing proprietary
solutions that you license?

Loading proprietary modules into Linux is as illegal as it would be in
Xen.  Many people obviously do it anyway, but you are really putting
yourself at a risk of meeting a guy like Patrick McHardy[1], a private
individual with copyright on the Linux kernel who by some estimates has
made almost EUR 2m in the last few years suing companies for GPL violations.

 -George

[1] https://lwn.net/Articles/721458/

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

[Xen-devel] [PATCH for-4.9] x86/mm: Mark pages as dirty after (rather than before) writing to them

[Andrew Cooper]

Otherwise a logdirty client can race with observing the page becoming dirty,
and copy the frame before the write is complete and end up with a stale
version.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Julien Grall 
---
 xen/arch/x86/mm.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 77b0af1..97c3cb8 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3556,11 +3556,10 @@ long do_mmuext_op(
 break;
 }
 
-/* A page is dirtied when it's being cleared. */
-paging_mark_dirty(pg_owner, _mfn(page_to_mfn(page)));
-
 clear_domain_page(_mfn(page_to_mfn(page)));
 
+paging_mark_dirty(pg_owner, _mfn(page_to_mfn(page)));
+
 put_page_and_type(page);
 break;
 }
@@ -3594,12 +3593,11 @@ long do_mmuext_op(
 break;
 }
 
-/* A page is dirtied when it's being copied to. */
-paging_mark_dirty(pg_owner, _mfn(page_to_mfn(dst_page)));
-
 copy_domain_page(_mfn(page_to_mfn(dst_page)),
  _mfn(page_to_mfn(src_page)));
 
+paging_mark_dirty(pg_owner, _mfn(page_to_mfn(dst_page)));
+
 put_page_and_type(dst_page);
 put_page(src_page);
 break;
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v3 4/9] mm: Scrub memory from idle loop

[Boris Ostrovsky]

On 05/11/2017 11:48 AM, Dario Faggioli wrote:
> On Thu, 2017-05-11 at 10:19 -0400, Boris Ostrovsky wrote:
 diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
 index 90e2b1f..a5f62b5 100644
 --- a/xen/arch/x86/domain.c
 +++ b/xen/arch/x86/domain.c
 @@ -118,7 +118,8 @@ static void idle_loop(void)
  {
  if ( cpu_is_offline(smp_processor_id()) )
  play_dead();
 -(*pm_idle)();
 +if ( !scrub_free_pages() )
 +(*pm_idle)();
  do_tasklet();

>>> This means that, if we got here to run a tasklet (as in, if the
>>> idle
>>> vCPU has been forced into execution, because there were a vCPU
>>> context
>>> tasklet wanting to run), we will (potentially) do some scrubbing
>>> first.
>>>
>> We can move do_tasklet() above scrub_free_pages(). And new tasklet
>> after
>> that would result in a softirq being set so we'd do an early exit
>> from
>> scrub_free_pages().
>>
> How early?
>
> In fact, right now, if there is one tasklet queued, this is what
> happens:
>
>  tasklet_schedule(t)
>tasklet_enqueue(t)
>  test_and_set_bit(_TASKLET_enqueued, tasklet_work_to_do);
>  raise_softirq(SCHEDULE_SOFTIRQ);
>  schedule()
>set_bit(_TASKLET_scheduled, tasklet_work_to_do)
>tasklet_work_scheduled = 1;
>do_schedule(tasklet_work_scheduled)
>  csched_schedule(tasklet_work_to_do)
>snext = CSCHED_VCPU(idle_vcpu[cpu]);
>  idle_loop()
>(*pm_idle)()
>  if ( !cpu_is_haltable() ) return;
>do_tasklet() /* runs tasklet t */
>  clear_bit(_TASKLET_enqueued, work_to_do); /* list_empty(list) == true */
>  raise_softirq(SCHEDULE_SOFTIRQ);
>do_softirq()
>  schedule()
>clear_bit(_TASKLET_scheduled, tasklet_work);
>tasklet_work_scheduled = 0;
>do_schedule(tasklet_work_scheduled)
>  csched_schedule(tasklet_work_to_do)
>snext = CSCHED_VCPU(idle_vcpu[cpu]);
>  idle_loop()
>(*pm_idle)()
>  if ( !cpu_is_haltable() )
>  ...
>
> If we move do_tasklet up, as you suggest, this is what happens:
>
>  tasklet_schedule(t)
>tasklet_enqueue(t)
>  test_and_set_bit(_TASKLET_enqueued, tasklet_work_to_do);
>  raise_softirq(SCHEDULE_SOFTIRQ);
>  schedule()
>set_bit(_TASKLET_scheduled, tasklet_work_to_do)
>tasklet_work_scheduled = 1;
>do_schedule(tasklet_work_scheduled)
>  csched_schedule(tasklet_work_to_do)
>snext = CSCHED_VCPU(idle_vcpu[cpu]);
>  idle_loop()
>do_tasklet() /* runs tasklet t */
>  clear_bit(_TASKLET_enqueued, work_to_do); /* list_empty(list) == true */
>  raise_softirq(SCHEDULE_SOFTIRQ);
>if ( !scrub_free_pages() )
>  //do some scrubbing, but softirq_pending() is true, so return 1
>do_softirq()
>  schedule()
>clear_bit(_TASKLET_scheduled, tasklet_work);
>tasklet_work_scheduled = 0;
>do_schedule(tasklet_work_scheduled)
>  csched_schedule(tasklet_work_to_do)
>snext = CSCHED_VCPU(idle_vcpu[cpu]);
>  idle_loop()
>if ( !scrub_free_pages() )
>  //do the scrubbing, returns 0, so we enter the if
>  (*pm_idle)()
>if ( !cpu_is_haltable() )
>  ...
>
> IOW (provided I'm understanding your code right, of course), I still
> see it happening that we switched to idle *not* because the system was
> idle, but for running a tasklet, and yet we end up doing at least some
> scrubbing (like if the system were idle).
>
> Which still feels wrong to me.
>
> If there's more than one tasklet queued (or another one, or more,
> is/are queued before the one t is processed), it's even worse, because
> we go through the whole schedule()->idle_loop()->do_tasklet() again and
> again, and at each step we do a bit of scrubbing, before going back to
> schedule().
>
> It probably would be at least a bit better, if scrub_free_pages() would
> check for softirqs() _before_ starting any scrubbing (which I don't
> think it does, right now, am I right?).

Right.

I didn't realize that do_tasklet() also schedules softirq. So you are
suggesting something along the lines of

do_tasklet();

if ( !softirq_pending(smp_processor_id() && !scrub_free_pages() )
(*pm_idle)();

do_softirq();


>
>> OTOH since, as you say, we only get to idle loop() if no tasklet is
>> pending (cpu_is_haltable() test) then would even that be needed?
>>
> Err... sorry, not getting. It's the other way round. One of the reasons
> why we end up executing idle_loop(), is that there is at least a
> tasklet pending.

Nevermind that. I was thinking we enter idle_loop() based on
cpu_is_haltable().

-boris

>
> Where we only get to if there's nothing pending is to calling
> (*pm_idle)().
>
> Regards,
> Dario




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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f4ac4354652b2bcf4f138b5ebd79b2f07710d4ef
baseline version:
 ovmf 29dc8aa861fac78c6d62391dff312db934b755e3

Last test of basis   109312  2017-05-11 10:45:18 Z0 days
Testing same since   109316  2017-05-11 13:46:34 Z0 days1 attempts


People who touched revisions under test:
  Jeff Westfahl 
  Ruiyu Ni 

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=f4ac4354652b2bcf4f138b5ebd79b2f07710d4ef
+ . ./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 
f4ac4354652b2bcf4f138b5ebd79b2f07710d4ef
+ branch=ovmf
+ revision=f4ac4354652b2bcf4f138b5ebd79b2f07710d4ef
+ . ./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.8-testing
+ '[' xf4ac4354652b2bcf4f138b5ebd79b2f07710d4ef = 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] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

[George Dunlap]

On 11/05/17 16:35, Julien Grall wrote:
> On 11/05/17 16:19, Volodymyr Babchuk wrote:
>> Hi Stefano,
>>
>> On 10 May 2017 at 21:24, Stefano Stabellini 
>> wrote:
>>> I just want to point out that the comparision with tasklets is not
>>> helpful. Tasklets involve the idle vcpu, which we are trying to step
>>> away
>>> from because it increases irq latency. Tasklets don't provide any
>>> isolation. The context switch model for the idle vcpu and for EL0 apps
>>> is different, thus it has a different cost.
>>>
>>> I think we shouldn't mention tasklets in this thread any longer.
>> Yep, you are right. Let's forget about tasklets and focus on EL0 apps.
>>
>> I want summarize political (opposed to technical) part of the discussion.
>>
>> We, here at EPAM, viewed EL0 apps primarily as a way to extend
>> hypervisor. Because when it comes to embedded and automotive, there
>> arise some ugly things, that are needed at hypervisor level:
>> TEE mediators (OP-TEE is a good TEE, but for example there is TI's
>> MSHIELD with deeply proprietary license), device drivers for vcopros,
>> device drivers for cpufreq, and so on.
>> Some of this things can't be included in hypervisor due to legal
>> issues, some - because of code size or complexity. And we can't run
>> them in stubdoms, because stubdoms are slow for certain use-cases, in
>> some cases they are insecure, in some cases they just don't fit at
>> all.
>>
>> On other hand you consider EL0 apps as ideal host for emulators only.
>> I can see your point, because XEN was always viewed as hypervisor for
>> servers.
>> But servers have different requirements in comparison to embedded
>> applications. Traditional servers does not use hardware accelerated
>> video decoders, they don't need to disable cpu's or scale frequencies
>> to preserve energy (okay, they need to, but it is not as pressing, as
>> on battery-powered device), there almost no proprietary code (or even
>> proprietary blobs, argh!).
>> Looks like virtualization on embedded is the next big thing. Linux
>> kernel was able to satisfy both parties. I hope that XEN can do the
>> same.
>>
>> So, going back to EL0 apps. Honestly, I'd prefer not to use them as
>> extension mechanism. Yes, they provide isolation, but interfacing with
>> them will be painful. Probably we can leave them to emulators only
>> (but as I can see, PL011 emulator is going to be merged right into
>> hypervisor. Will be there need for other emulators?).
>> What I really want to ask: what do you thing about old good modules
>> like ones in linux kernel? There will be no isolation, this is bad.
>> But:
>>  - you can load proprietary modules if you want to
>>  - they are fast
>>  - you can interface with them in a nativest way possible: just call a
>> function

Even better would be to skip the module-loading step entirely, and just
compile proprietary code directly into your Xen binary.

Both solutions, unfortunately, are illegal.*

 -George

* I am not a lawyer, and this is not legal advice; but see this
presentation for a bit more information:
http://www.kroah.com/log/linux/ols_2006_keynote.html


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

Re: [Xen-devel] [Patch] Fix broken package config file xenlight.pc.in

[Wei Liu]

On Thu, May 11, 2017 at 10:29:42AM -0600, Charles Arnold wrote:
> The Requires line in this config file uses the wrong names for two 
> dependencies.
> 
> The package config file for xenctrl is called 'xencontrol' and for blktapctl 
> is
> called 'xenblktapctl'. Running a command like 'pkg-config --exists xenlight' 
> will
> fail without this fix.
> 
> Signed-off-by: Charles Arnold 

Acked-by: Wei Liu 

Julien this should be in 4.9.

> 
> diff --git a/tools/libxl/xenlight.pc.in b/tools/libxl/xenlight.pc.in
> index 71d093a0ae..86c38a5634 100644
> --- a/tools/libxl/xenlight.pc.in
> +++ b/tools/libxl/xenlight.pc.in
> @@ -9,4 +9,4 @@ Description: The Xenlight library for Xen hypervisor
>  Version: @@version@@
>  Cflags: -I${includedir}
>  Libs: @@libsflag@@${libdir} -lxenlight
> -Requires.private: xentoollog,xenevtchn,xenctrl,xenguest,xenstore,blktapctl
> +Requires.private: 
> xentoollog,xenevtchn,xencontrol,xenguest,xenstore,xenblktapctl
> 
> 

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

[Xen-devel] [Patch] Fix broken package config file xenlight.pc.in

[Charles Arnold]

The Requires line in this config file uses the wrong names for two dependencies.

The package config file for xenctrl is called 'xencontrol' and for blktapctl is
called 'xenblktapctl'. Running a command like 'pkg-config --exists xenlight' 
will
fail without this fix.

Signed-off-by: Charles Arnold 

diff --git a/tools/libxl/xenlight.pc.in b/tools/libxl/xenlight.pc.in
index 71d093a0ae..86c38a5634 100644
--- a/tools/libxl/xenlight.pc.in
+++ b/tools/libxl/xenlight.pc.in
@@ -9,4 +9,4 @@ Description: The Xenlight library for Xen hypervisor
 Version: @@version@@
 Cflags: -I${includedir}
 Libs: @@libsflag@@${libdir} -lxenlight
-Requires.private: xentoollog,xenevtchn,xenctrl,xenguest,xenstore,blktapctl
+Requires.private: 
xentoollog,xenevtchn,xencontrol,xenguest,xenstore,xenblktapctl



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

Re: [Xen-devel] [PATCH for-4.9] xl: don't ignore return value from libxl_device_events_handler

[Ian Jackson]

Wei Liu writes ("[PATCH for-4.9] xl: don't ignore return value from 
libxl_device_events_handler"):
> That function can return a whole slew of error codes. Translate them
> to EXIT_FAILURE.

Acked-by: Ian Jackson 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   5 xen-buildfail REGR. vs. 107636
 build-arm64   5 xen-buildfail REGR. vs. 107636
 build-i3865 xen-buildfail REGR. vs. 107636
 build-amd64-xsm   5 xen-buildfail REGR. vs. 107636
 build-amd64   5 xen-buildfail REGR. vs. 107636
 build-armhf   5 xen-buildfail REGR. vs. 107636
 build-armhf-xsm   5 xen-buildfail REGR. vs. 107636
 build-i386-xsm5 xen-buildfail REGR. vs. 107636

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 

Re: [Xen-devel] [PATCH v3 4/9] mm: Scrub memory from idle loop

[Dario Faggioli]

On Thu, 2017-05-11 at 10:19 -0400, Boris Ostrovsky wrote:
> > > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > > index 90e2b1f..a5f62b5 100644
> > > --- a/xen/arch/x86/domain.c
> > > +++ b/xen/arch/x86/domain.c
> > > @@ -118,7 +118,8 @@ static void idle_loop(void)
> > >  {
> > >  if ( cpu_is_offline(smp_processor_id()) )
> > >  play_dead();
> > > -(*pm_idle)();
> > > +if ( !scrub_free_pages() )
> > > +(*pm_idle)();
> > >  do_tasklet();
> > > 
> > 
> > This means that, if we got here to run a tasklet (as in, if the
> > idle
> > vCPU has been forced into execution, because there were a vCPU
> > context
> > tasklet wanting to run), we will (potentially) do some scrubbing
> > first.
> > 
> We can move do_tasklet() above scrub_free_pages(). And new tasklet
> after
> that would result in a softirq being set so we'd do an early exit
> from
> scrub_free_pages().
> 
How early?

In fact, right now, if there is one tasklet queued, this is what
happens:

 tasklet_schedule(t)
   tasklet_enqueue(t)
 test_and_set_bit(_TASKLET_enqueued, tasklet_work_to_do);
 raise_softirq(SCHEDULE_SOFTIRQ);
 schedule()
   set_bit(_TASKLET_scheduled, tasklet_work_to_do)
   tasklet_work_scheduled = 1;
   do_schedule(tasklet_work_scheduled)
 csched_schedule(tasklet_work_to_do)
   snext = CSCHED_VCPU(idle_vcpu[cpu]);
 idle_loop()
   (*pm_idle)()
 if ( !cpu_is_haltable() ) return;
   do_tasklet() /* runs tasklet t */
 clear_bit(_TASKLET_enqueued, work_to_do); /* list_empty(list) == true */
 raise_softirq(SCHEDULE_SOFTIRQ);
   do_softirq()
 schedule()
   clear_bit(_TASKLET_scheduled, tasklet_work);
   tasklet_work_scheduled = 0;
   do_schedule(tasklet_work_scheduled)
 csched_schedule(tasklet_work_to_do)
   snext = CSCHED_VCPU(idle_vcpu[cpu]);
 idle_loop()
   (*pm_idle)()
 if ( !cpu_is_haltable() )
 ...

If we move do_tasklet up, as you suggest, this is what happens:

 tasklet_schedule(t)
   tasklet_enqueue(t)
 test_and_set_bit(_TASKLET_enqueued, tasklet_work_to_do);
 raise_softirq(SCHEDULE_SOFTIRQ);
 schedule()
   set_bit(_TASKLET_scheduled, tasklet_work_to_do)
   tasklet_work_scheduled = 1;
   do_schedule(tasklet_work_scheduled)
 csched_schedule(tasklet_work_to_do)
   snext = CSCHED_VCPU(idle_vcpu[cpu]);
 idle_loop()
   do_tasklet() /* runs tasklet t */
 clear_bit(_TASKLET_enqueued, work_to_do); /* list_empty(list) == true */
 raise_softirq(SCHEDULE_SOFTIRQ);
   if ( !scrub_free_pages() )
 //do some scrubbing, but softirq_pending() is true, so return 1
   do_softirq()
 schedule()
   clear_bit(_TASKLET_scheduled, tasklet_work);
   tasklet_work_scheduled = 0;
   do_schedule(tasklet_work_scheduled)
 csched_schedule(tasklet_work_to_do)
   snext = CSCHED_VCPU(idle_vcpu[cpu]);
 idle_loop()
   if ( !scrub_free_pages() )
 //do the scrubbing, returns 0, so we enter the if
     (*pm_idle)()
       if ( !cpu_is_haltable() )
 ...

IOW (provided I'm understanding your code right, of course), I still
see it happening that we switched to idle *not* because the system was
idle, but for running a tasklet, and yet we end up doing at least some
scrubbing (like if the system were idle).

Which still feels wrong to me.

If there's more than one tasklet queued (or another one, or more,
is/are queued before the one t is processed), it's even worse, because
we go through the whole schedule()->idle_loop()->do_tasklet() again and
again, and at each step we do a bit of scrubbing, before going back to
schedule().

It probably would be at least a bit better, if scrub_free_pages() would
check for softirqs() _before_ starting any scrubbing (which I don't
think it does, right now, am I right?).

> OTOH since, as you say, we only get to idle loop() if no tasklet is
> pending (cpu_is_haltable() test) then would even that be needed?
> 
Err... sorry, not getting. It's the other way round. One of the reasons
why we end up executing idle_loop(), is that there is at least a
tasklet pending.

Where we only get to if there's nothing pending is to calling
(*pm_idle)().

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [ovmf baseline-only test] 71289: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-libvirt   5 libvirt-buildfail   like 71288
 build-i386-libvirt5 libvirt-buildfail   like 71288

version targeted for testing:
 ovmf 29dc8aa861fac78c6d62391dff312db934b755e3
baseline version:
 ovmf a6c31c6d6349a51041d8b77df375c340043e36bd

Last test of basis71288  2017-05-11 10:48:55 Z0 days
Testing same since71289  2017-05-11 13:46:38 Z0 days1 attempts


People who touched revisions under test:
  Chao Zhang 
  Jeff Fan 
  Zhang, Chao B 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-i386-libvirt   fail
 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 29dc8aa861fac78c6d62391dff312db934b755e3
Author: Jeff Fan 
Date:   Thu May 11 15:01:39 2017 +0800

UefiCpuPkg/PiSmmCpuDxeSmm: Fix logic check error

Cc: Jiewen Yao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
Reviewed-by: Jiewen Yao 

commit b7025df8f9102a1698879aa451bf5af592c37bc1
Author: Jeff Fan 
Date:   Wed May 10 16:32:25 2017 +0800

UefiCpuPkg/PiSmmCpuDxeSmm: Check ProcessorId == INVALID_APIC_ID

If PcdCpuHotPlugSupport is TRUE, gSmst->NumberOfCpus will be the
PcdCpuMaxLogicalProcessorNumber. If gSmst->SmmStartupThisAp() is invoked for
those un-existed processors, ASSERT() happened in 
ConfigSmmCodeAccessCheck().

This fix is to check if ProcessorId is valid before invoke
gSmst->SmmStartupThisAp() in ConfigSmmCodeAccessCheck() and to check if
ProcessorId is valid in InternalSmmStartupThisAp() to avoid unexpected DEBUG
error message displayed.

Cc: Jiewen Yao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
Reviewed-by: Eric Dong 

commit 5d0933f9bab2781bf5df078d12c22d50df165617
Author: Jeff Fan 
Date:   Wed May 10 14:47:03 2017 +0800

UefiCpuPkg/SmmCpuFeaturesLib: Correct print level

Cc: Jiewen Yao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
Reviewed-by: Eric Dong 

commit 6afc643ce0eded9ccbd015a5cd6d2ba0e264b01d
Author: Jeff Fan 
Date:   Wed May 10 14:42:41 2017 +0800

UefiCpuPkg/SmmCpuFeaturesLib: Fix Ia32/SmiEntry.asm build issue

Cc: Jiewen Yao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
Reviewed-by: Eric Dong 

commit 6d92ae11d14abe39f2587a360bc5d6c370325cad
Author: Zhang, Chao B 
Date:   Thu May 11 13:08:30 2017 +0800

SecurityPkg: Add TCG Spec info to TCG related modules

Add TCG Spec compliance info to TCG related module INFs.

Cc: Qin Long 
Cc: Yao Jiewen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
Reviewed-by: Qin Long 
Reviewed-by: Yao Jiewen 

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

[Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

[Julien Grall]

Renaming the subject + adding more people in the conversation as this is 
not related to only ARM anymore.


On 11/05/17 16:19, Volodymyr Babchuk wrote:

Hi Stefano,

On 10 May 2017 at 21:24, Stefano Stabellini  wrote:

I just want to point out that the comparision with tasklets is not
helpful. Tasklets involve the idle vcpu, which we are trying to step away
from because it increases irq latency. Tasklets don't provide any
isolation. The context switch model for the idle vcpu and for EL0 apps
is different, thus it has a different cost.

I think we shouldn't mention tasklets in this thread any longer.

Yep, you are right. Let's forget about tasklets and focus on EL0 apps.

I want summarize political (opposed to technical) part of the discussion.

We, here at EPAM, viewed EL0 apps primarily as a way to extend
hypervisor. Because when it comes to embedded and automotive, there
arise some ugly things, that are needed at hypervisor level:
TEE mediators (OP-TEE is a good TEE, but for example there is TI's
MSHIELD with deeply proprietary license), device drivers for vcopros,
device drivers for cpufreq, and so on.
Some of this things can't be included in hypervisor due to legal
issues, some - because of code size or complexity. And we can't run
them in stubdoms, because stubdoms are slow for certain use-cases, in
some cases they are insecure, in some cases they just don't fit at
all.

On other hand you consider EL0 apps as ideal host for emulators only.
I can see your point, because XEN was always viewed as hypervisor for
servers.
But servers have different requirements in comparison to embedded
applications. Traditional servers does not use hardware accelerated
video decoders, they don't need to disable cpu's or scale frequencies
to preserve energy (okay, they need to, but it is not as pressing, as
on battery-powered device), there almost no proprietary code (or even
proprietary blobs, argh!).
Looks like virtualization on embedded is the next big thing. Linux
kernel was able to satisfy both parties. I hope that XEN can do the
same.

So, going back to EL0 apps. Honestly, I'd prefer not to use them as
extension mechanism. Yes, they provide isolation, but interfacing with
them will be painful. Probably we can leave them to emulators only
(but as I can see, PL011 emulator is going to be merged right into
hypervisor. Will be there need for other emulators?).
What I really want to ask: what do you thing about old good modules
like ones in linux kernel? There will be no isolation, this is bad.
But:
 - you can load proprietary modules if you want to
 - they are fast
 - you can interface with them in a nativest way possible: just call a function

Artem, could you please comment from your side?



--
Julien Grall

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

[Xen-devel] [PATCH] block: xen-blkback: add null check to avoid null pointer dereference

[Gustavo A. R. Silva]

Add null check before calling xen_blkif_put() to avoid potential
null pointer dereference.

Addresses-Coverity-ID: 1350942
Cc: Juergen Gross 
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/block/xen-blkback/xenbus.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 8fe61b5..1f3dfaa 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -504,11 +504,13 @@ static int xen_blkbk_remove(struct xenbus_device *dev)
 
dev_set_drvdata(>dev, NULL);
 
-   if (be->blkif)
+   if (be->blkif) {
xen_blkif_disconnect(be->blkif);
 
-   /* Put the reference we set in xen_blkif_alloc(). */
-   xen_blkif_put(be->blkif);
+   /* Put the reference we set in xen_blkif_alloc(). */
+   xen_blkif_put(be->blkif);
+   }
+
kfree(be->mode);
kfree(be);
return 0;
-- 
2.5.0


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

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

[Volodymyr Babchuk]

Hi Stefano,

On 10 May 2017 at 21:24, Stefano Stabellini  wrote:
> I just want to point out that the comparision with tasklets is not
> helpful. Tasklets involve the idle vcpu, which we are trying to step away
> from because it increases irq latency. Tasklets don't provide any
> isolation. The context switch model for the idle vcpu and for EL0 apps
> is different, thus it has a different cost.
>
> I think we shouldn't mention tasklets in this thread any longer.
Yep, you are right. Let's forget about tasklets and focus on EL0 apps.

I want summarize political (opposed to technical) part of the discussion.

We, here at EPAM, viewed EL0 apps primarily as a way to extend
hypervisor. Because when it comes to embedded and automotive, there
arise some ugly things, that are needed at hypervisor level:
TEE mediators (OP-TEE is a good TEE, but for example there is TI's
MSHIELD with deeply proprietary license), device drivers for vcopros,
device drivers for cpufreq, and so on.
Some of this things can't be included in hypervisor due to legal
issues, some - because of code size or complexity. And we can't run
them in stubdoms, because stubdoms are slow for certain use-cases, in
some cases they are insecure, in some cases they just don't fit at
all.

On other hand you consider EL0 apps as ideal host for emulators only.
I can see your point, because XEN was always viewed as hypervisor for
servers.
But servers have different requirements in comparison to embedded
applications. Traditional servers does not use hardware accelerated
video decoders, they don't need to disable cpu's or scale frequencies
to preserve energy (okay, they need to, but it is not as pressing, as
on battery-powered device), there almost no proprietary code (or even
proprietary blobs, argh!).
Looks like virtualization on embedded is the next big thing. Linux
kernel was able to satisfy both parties. I hope that XEN can do the
same.

So, going back to EL0 apps. Honestly, I'd prefer not to use them as
extension mechanism. Yes, they provide isolation, but interfacing with
them will be painful. Probably we can leave them to emulators only
(but as I can see, PL011 emulator is going to be merged right into
hypervisor. Will be there need for other emulators?).
What I really want to ask: what do you thing about old good modules
like ones in linux kernel? There will be no isolation, this is bad.
But:
 - you can load proprietary modules if you want to
 - they are fast
 - you can interface with them in a nativest way possible: just call a function

Artem, could you please comment from your side?

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

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

Re: [Xen-devel] [block-xen-blkback] question about pontential null pointer dereference

[Gustavo A. R. Silva]

Hi Juergen,

Quoting Juergen Gross :


On 10/05/17 18:49, Gustavo A. R. Silva wrote:


Hello everybody,

While looking into Coverity ID 1350942 I ran into the following piece of
code at drivers/block/xen-blkback/xenbus.c:490:

490static int xen_blkbk_remove(struct xenbus_device *dev)
491{
492struct backend_info *be = dev_get_drvdata(>dev);
493
494pr_debug("%s %p %d\n", __func__, dev, dev->otherend_id);
495
496if (be->major || be->minor)
497xenvbd_sysfs_delif(dev);
498
499if (be->backend_watch.node) {
500unregister_xenbus_watch(>backend_watch);
501kfree(be->backend_watch.node);
502be->backend_watch.node = NULL;
503}
504
505dev_set_drvdata(>dev, NULL);
506
507if (be->blkif)
508xen_blkif_disconnect(be->blkif);
509
510/* Put the reference we set in xen_blkif_alloc(). */
511xen_blkif_put(be->blkif);
512kfree(be->mode);
513kfree(be);
514return 0;
515}

The issue here is that line 507 implies that be->blkif might be NULL. If
this is the case, there is a NULL pointer dereference when executing
line 511 once macro xen_blkif_put() dereference be->blkif

Is there any chance for be->blkif to be NULL at line 511?


Yes. xen_blkbk_probe() will call xen_blkbk_remove() with be->blkif being
NULL in the failure path.

The call to xen_blkif_put() should be guarded by the "if (be->blkif)" of
line 507, too.



Thanks for clarifying. I'll send a patch to fix this shortly.

--
Gustavo A. R. Silva







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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  bf123952303abd3b715e6c05c5d147bda11a4996
baseline version:
 libvirt  1d07a5bf3c03309642068d20698a1f55739dafa2

Last test of basis   109246  2017-05-10 04:20:43 Z1 days
Testing same since   109301  2017-05-11 04:21:19 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Jiri Denemark 
  Peter Krempa 
  Wim ten Have 

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



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

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

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

Test harness 

Re: [Xen-devel] Proposal to drop Windows XP tests from Xen Project CI

[Ian Jackson]

Ian Jackson writes ("Proposal to drop Windows XP tests from Xen Project CI"):
> Recently, the tests of Windows XP SP3 that are run by osstest, as part
> of the Xen Project's test suite, have started failing a lot more.
> 
> It is not clear what has caused this.  The failures are causing
> blockages: several of our `staging' branches are not gettting pushed
> to the corresponding `stable' or `master' branches.  Older Xen
> releases, as well as current master (4.9-rc) are affected.  This is a
> problem for Xen development.
> 
> In my capacity as osstest administrator, I have tried to find someone
> to help debug these.  (I don't have the knowledge to do so myself.)
> 
> I haven't had a good response.  My colleagues at Citrix tell me that
> their internal XenRT system, used for XenServer, will be dropping its
> own tests of Windows XP.  It's been suggested to me to simply drop the
> Xen Project tests of Windows XP.
> 
> If you thinks that XP should continue to work well, and therefore to
> be tested, I'm afraid I need your help.  Please contact me at the
> address above, and I can provide more details, help, etc.

I have just pushed to osstest pretest the change to drop testing of
Windows XP.  We are replacing it with tests of Windows Server 2016 and
Windows 10 (but of course as those are new tests, they will not count
for blocking regressions until they have passed).

Jan Beulich writes ("Re: [OSSTEST PATCH 3/3] make-flight: Drop Windows XP 
tests"):
> On 04.05.17 at 14:20,  wrote:
> > We drop the tests only on the branches:
...
> >   xen-4.7-testing
> >   xen-4.8-testing
> >   xen-unstable
> > 
> > The other branches are mostly out-of-support Xen branches.  These are
> > either old ones we are still doing security support for (and would
> > like to know about regressions on, even for old guests), or very old
> > ones which we don't expect to change ever.
> 
> 4.6, while having passed the 1.5 year general support limit, had
> its most recent stable release go out before that time span was
> over, so I think we owe the community another stable release
> there. Hence I'm wondering whether it should be grouped with
> 4.7 and 4.8 above.

Done.  (Ie, I am dropping the tests on Xen 4.6 too.)

Ian.

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

Re: [Xen-devel] [PATCH v1 05/10] iommu/arm: Re-define iommu_use_hap_pt(d) as iommu_hap_pt_share

[Oleksandr Tyshchenko]

On Thu, May 11, 2017 at 2:28 PM, Julien Grall  wrote:
> Hi Oleksandr,
Hi Julien

>
> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko 
>>
>> Not every integrated into ARM SoCs IOMMU can share page tables
>> with the CPU and as result the iommu_use_hap_pt(d) is not always true.
>> Reuse x86's iommu_hap_pt_share flag to indicate whether the IOMMU
>> page table is shared or not.
>>
>> Now all IOMMU drivers on ARM are able to change this flag
>> according to their possibilities like x86-variants do.
>> Therefore set iommu_hap_pt_share flag for SMMU because it always shares
>> page table with the CPU.
>>
>> Signed-off-by: Oleksandr Tyshchenko 
>> ---
>>  xen/drivers/passthrough/arm/smmu.c | 3 +++
>>  xen/include/asm-arm/iommu.h| 7 +--
>>  2 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/drivers/passthrough/arm/smmu.c
>> b/xen/drivers/passthrough/arm/smmu.c
>> index 527a592..86ee12a 100644
>> --- a/xen/drivers/passthrough/arm/smmu.c
>> +++ b/xen/drivers/passthrough/arm/smmu.c
>> @@ -2870,6 +2870,9 @@ static __init int arm_smmu_dt_init(struct
>> dt_device_node *dev,
>>
>> platform_features &= smmu->features;
>>
>> +   /* Always share P2M table between the CPU and the SMMU */
>> +   iommu_hap_pt_share = true;
>> +
>
>
> I would prefer to bail-out if someone try to unshare the page-table rather
> than overriding. This would help us to know if someone are try to do that.
>
> So I would do:
>
> if ( !iommu_hap_pt_share )
> {
> printk()
> return -EINVAL;
> }
I got it for SMMU.

But, for IPMMU we will override since iommu_hap_pt_share is true by
default. Right?

/*
* The IPMMU can't reuse P2M table since it only supports
* stage-1 page tables.
*/
iommu_hap_pt_share = false;

>
>> return 0;
>>  }
>>
>> diff --git a/xen/include/asm-arm/iommu.h b/xen/include/asm-arm/iommu.h
>> index 57d9b1e..10a6f23 100644
>> --- a/xen/include/asm-arm/iommu.h
>> +++ b/xen/include/asm-arm/iommu.h
>> @@ -20,8 +20,11 @@ struct arch_iommu
>>  void *priv;
>>  };
>>
>> -/* Always share P2M Table between the CPU and the IOMMU */
>> -#define iommu_use_hap_pt(d) (1)
>> +/*
>> + * The ARM domain always has a P2M table, but not every integrated into
>> + * ARM SoCs IOMMU can use it as page table.
>
>
> The first part: "ARM domain has a P2M table" is pretty obvious. I would
> instead say: "Not every ARM SoCs IOMMU use the same page-table format as the
> processor.".
Agree.

>
>> + */
>> +#define iommu_use_hap_pt(d) (iommu_hap_pt_share)
>>
>>  const struct iommu_ops *iommu_get_ops(void);
>>  void __init iommu_set_ops(const struct iommu_ops *ops);
>>
>
> Cheers,
>
> --
> Julien Grall


-- 
Regards,

Oleksandr Tyshchenko

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

[Xen-devel] Hypercall Inquiries

[Rapidash]

Greetings,

My co-worker and I are looking into Xen Hypervisor. By any chance, do you or 
any of your colleagues have technical material/ papers/ presentations detailing 
how the hypercall interacts with the hypervisor?

Thank you in advance for any assistance,
- Rapidash

Some specific questions:
- If the memory of the VM is stored on non-congruent sections of the host's 
machine memory, how does the hypercall handler check whether a passed in 
pointer parameter falls within these VM claimed sections of memory?
- Since the hypercalls are limited in number compared to syscalls, is there 
ever an instance where the domain will require a syscall that the hypercall 
does not cover?

Also, we have been looking at the Xen hypercall source code to try and figure 
out the mechanics there. In file "hypercall-x86_64.h" there is the following 
code segment we are attempting to decipher (from it, we can figure out the 
preceding functions):

#define _hypercall5(type, name, a1, a2, a3, a4, a5) \
({ \
long __res, __ign1, __ign2, __ign3; \
asm volatile ( \
"movq %7,%%r10; movq %8,%%r8; " \
"call hypercall_page + ("STR(__HYPERVISOR_##name)" * 32)"\
: "=a" (__res), "=D" (__ign1), "=S" (__ign2), \
"=d" (__ign3) \
: "1" ((long)(a1)), "2" ((long)(a2)), \
"3" ((long)(a3)), "g" ((long)(a4)), \
"g" ((long)(a5)) \
: "memory", "r10", "r8" ); \
(type)__res; \
})

- The first line within the asm volatile section, are the contents of registers 
being saved to memory? If so, where?
- In the third and fourth lines within the same section, are values from __res 
being placed into the "a" register, or are the values within the "a" register 
being stored in the variable __res for use later?
- Does the "1", "2", "3", "g", "g" correspond to the ebx, ecx, edx, esi, and 
edi registers? Or are they a different set?

Sent with [ProtonMail](https://protonmail.com) Secure Email.___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 2/3] * util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64

[Fu Wei]

Hi Vladimir,

On 11 May 2017 at 06:01, Vladimir 'phcoder' Serbinenko
 wrote:
>
>
> On Tue, May 9, 2017, 11:02 Fu Wei  wrote:
>>
>> Hi Vladimir
>>
>> On 9 May 2017 at 14:59, Vladimir 'phcoder' Serbinenko 
>> wrote:
>> >
>> >
>> > Le Tue, May 2, 2017 à 9:06 AM,  a écrit :
>> >>
>> >> From: Fu Wei 
>> >>
>> >> This patch adds the support of xen_boot command for aarch64:
>> >> xen_hypervisor
>> >> xen_module
>> >> These two commands are only for aarch64, since it has its own protocol
>> >> and
>> >> commands to boot xen hypervisor and Dom0, but not multiboot.
>> >>
>> >> For other architectures, they are still using multiboot and module
>> >> commands.
>> >>
>> >> Signed-off-by: Fu Wei 
>> >> ---
>> >>  util/grub.d/20_linux_xen.in | 13 ++---
>> >>  1 file changed, 10 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
>> >> index c48af94..919 100644
>> >> --- a/util/grub.d/20_linux_xen.in
>> >> +++ b/util/grub.d/20_linux_xen.in
>> >> @@ -122,16 +122,16 @@ linux_entry ()
>> >>  else
>> >>  xen_rm_opts="no-real-mode edd=off"
>> >>  fi
>> >> -   multiboot   ${rel_xen_dirname}/${xen_basename} placeholder
>> >> ${xen_args} \${xen_rm_opts}
>> >> +   ${xen_loader}   ${rel_xen_dirname}/${xen_basename} placeholder
>> >> ${xen_args} \${xen_rm_opts}
>> >> echo'$(echo "$lmessage" | grub_quote)'
>> >> -   module  ${rel_dirname}/${basename} placeholder
>> >> root=${linux_root_device_thisversion} ro ${args}
>> >> +   ${module_loader}${rel_dirname}/${basename} placeholder
>> >> root=${linux_root_device_thisversion} ro ${args}
>> >>  EOF
>> >>if test -n "${initrd}" ; then
>> >>  # TRANSLATORS: ramdisk isn't identifier. Should be translated.
>> >>  message="$(gettext_printf "Loading initial ramdisk ...")"
>> >>  sed "s/^/$submenu_indentation/" << EOF
>> >> echo'$(echo "$message" | grub_quote)'
>> >> -   module  --nounzip   ${rel_dirname}/${initrd}
>> >> +   ${module_loader}--nounzip   ${rel_dirname}/${initrd}
>> >>  EOF
>> >>fi
>> >>sed "s/^/$submenu_indentation/" << EOF
>> >> @@ -206,6 +206,13 @@ while [ "x${xen_list}" != "x" ] ; do
>> >>  if [ "x$is_top_level" != xtrue ]; then
>> >> echo "  submenu '$(gettext_printf "Xen hypervisor, version %s"
>> >> "${xen_version}" | grub_quote)' \$menuentry_id_option
>> >> 'xen-hypervisor-$xen_version-$boot_device_id' {"
>> >>  fi
>> >> +if [ "x$machine" != xaarch64 ]; then
>> >
>> > Machine of grub-mkconfig doesn't necessarily match the kernel. Think of
>> > chroot or of having 32-bit userspace with 64-bit kernel. Better to do
>> > this
>> > on runtime. I know, it's not very nice but the whole grub-mkconfig is
>> > trouble that needs redesign that I'm working on.
>>
>> So if we need to do this at run time(in grub shell), can I use
>> "grub_cpu" variable instead?
>
> Yes, you can. Another possibility, probably better, is to check actual file
> type, see grub-file

Very good idea, will do in my v8 patchset, will send v8 in a day.

>>
>>
>> Thanks!
>>
>> >>
>> >> +   xen_loader="multiboot"
>> >> +   module_loader="module"
>> >> +else
>> >> +   xen_loader="xen_hypervisor"
>> >> +   module_loader="xen_module"
>> >> +fi
>> >>  while [ "x$list" != "x" ] ; do
>> >> linux=`version_find_latest $list`
>> >> gettext_printf "Found linux image: %s\n" "$linux" >&2
>> >> --
>> >> 2.9.3
>> >>
>> >
>>
>>
>>
>> --
>> Best regards,
>>
>> Fu Wei
>> Software Engineer
>> Red Hat



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

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

[Xen-devel] [PATCH 4.9 099/103] xen: Revert commits da72ff5bfcb0 and 72a9b186292d

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Boris Ostrovsky 

commit 84d582d236dc1f9085e741affc72e9ba061a67c2 upstream.

Recent discussion (http://marc.info/?l=xen-devel=149192184523741)
established that commit 72a9b186292d ("xen: Remove event channel
notification through Xen PCI platform device") (and thus commit
da72ff5bfcb0 ("partially revert "xen: Remove event channel
notification through Xen PCI platform device"")) are unnecessary and,
in fact, prevent HVM guests from booting on Xen releases prior to 4.0

Therefore we revert both of those commits.

The summary of that discussion is below:

  Here is the brief summary of the current situation:

  Before the offending commit (72a9b186292):

  1) INTx does not work because of the reset_watches path.
  2) The reset_watches path is only taken if you have Xen > 4.0
  3) The Linux Kernel by default will use vector inject if the hypervisor
 support. So even INTx does not work no body running the kernel with
 Xen > 4.0 would notice. Unless he explicitly disabled this feature
 either in the kernel or in Xen (and this can only be disabled by
 modifying the code, not user-supported way to do it).

  After the offending commit (+ partial revert):

  1) INTx is no longer support for HVM (only for PV guests).
  2) Any HVM guest The kernel will not boot on Xen < 4.0 which does
 not have vector injection support. Since the only other mode
 supported is INTx which.

  So based on this summary, I think before commit (72a9b186292) we were
  in much better position from a user point of view.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Juergen Gross 
Cc: Boris Ostrovsky 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Konrad Rzeszutek Wilk 
Cc: Bjorn Helgaas 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Vitaly Kuznetsov 
Cc: Paul Gortmaker 
Cc: Ross Lagerwall 
Cc: xen-de...@lists.xenproject.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Anthony Liguori 
Cc: KarimAllah Ahmed 
Signed-off-by: Juergen Gross 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/xen/events.h |   11 ++
 arch/x86/pci/xen.c|2 -
 arch/x86/xen/enlighten.c  |   21 
 arch/x86/xen/smp.c|2 +
 arch/x86/xen/time.c   |5 ++
 drivers/xen/events/events_base.c  |   26 ++-
 drivers/xen/platform-pci.c|   64 ++
 include/xen/xen.h |3 +
 8 files changed, 117 insertions(+), 17 deletions(-)

--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -20,4 +20,15 @@ static inline int xen_irqs_disabled(stru
 /* No need for a barrier -- XCHG is a barrier on x86. */
 #define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
 
+extern int xen_have_vector_callback;
+
+/*
+ * Events delivered via platform PCI interrupts are always
+ * routed to vcpu 0 and hence cannot be rebound.
+ */
+static inline bool xen_support_evtchn_rebind(void)
+{
+   return (!xen_hvm_domain() || xen_have_vector_callback);
+}
+
 #endif /* _ASM_X86_XEN_EVENTS_H */
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -447,7 +447,7 @@ void __init xen_msi_init(void)
 
 int __init pci_xen_hvm_init(void)
 {
-   if (!xen_feature(XENFEAT_hvm_pirqs))
+   if (!xen_have_vector_callback || !xen_feature(XENFEAT_hvm_pirqs))
return 0;
 
 #ifdef CONFIG_ACPI
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -137,6 +137,8 @@ struct shared_info xen_dummy_shared_info
 void *xen_initial_gdt;
 
 RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
+__read_mostly int xen_have_vector_callback;
+EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
 static int xen_cpu_up_prepare(unsigned int cpu);
 static int xen_cpu_up_online(unsigned int cpu);
@@ -1521,7 +1523,10 @@ static void __init xen_pvh_early_guest_i
if (!xen_feature(XENFEAT_auto_translated_physmap))
return;
 
-   BUG_ON(!xen_feature(XENFEAT_hvm_callback_vector));
+   if (!xen_feature(XENFEAT_hvm_callback_vector))
+   return;
+
+   xen_have_vector_callback = 1;
 
xen_pvh_early_cpu_init(0, false);
xen_pvh_set_cr_flags(0);
@@ -1860,7 +1865,9 @@ static int xen_cpu_up_prepare(unsigned i
xen_vcpu_setup(cpu);
}
 
-   if (xen_pv_domain() || xen_feature(XENFEAT_hvm_safe_pvclock))
+   if (xen_pv_domain() ||
+   (xen_have_vector_callback &&
+

Re: [Xen-devel] [PATCH v3 4/9] mm: Scrub memory from idle loop

[Boris Ostrovsky]

>> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
>> index 90e2b1f..a5f62b5 100644
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -118,7 +118,8 @@ static void idle_loop(void)
>>  {
>>  if ( cpu_is_offline(smp_processor_id()) )
>>  play_dead();
>> -(*pm_idle)();
>> +if ( !scrub_free_pages() )
>> +(*pm_idle)();
>>  do_tasklet();
>>
> This means that, if we got here to run a tasklet (as in, if the idle
> vCPU has been forced into execution, because there were a vCPU context
> tasklet wanting to run), we will (potentially) do some scrubbing first.
>
> Is this on purpose, and, in any case, ideal? vCPU context tasklets are
> not terribly common, but I still don't think it is (ideal).
>
> Not sure how to address this, though. What (the variants of) pm_idle()
> uses for deciding whether or not to actually go to sleep is
> cpu_is_haltable(), which checks per_cpu(tasklet_work_to_do, cpu):
>
> /*
>  * Used by idle loop to decide whether there is work to do:
>  *  (1) Run softirqs; or (2) Play dead; or (3) Run tasklets.
>  */
> #define cpu_is_haltable(cpu)\
> (!softirq_pending(cpu) &&   \
>  cpu_online(cpu) && \
>  !per_cpu(tasklet_work_to_do, cpu))
>
> Pulling it out/adding a call to it (cpu_is_haltable()) is ugly, and
> probably not what we want (e.g., it's always called with IRQs disabled,
> while they're on here).
>
> Maybe we can test tasklet_work_to_do, before calling scrub_free_pages()
> (also ugly, IMO).
> Or, if scrub_free_pages() is, and always will be, called only from
> here, within the idle loop, test tasklet_work_to_do inside, similarly
> to what it does already for pending softirqs...

We can move do_tasklet() above scrub_free_pages(). And new tasklet after
that would result in a softirq being set so we'd do an early exit from
scrub_free_pages().

OTOH since, as you say, we only get to idle loop() if no tasklet is
pending (cpu_is_haltable() test) then would even that be needed?


-boris




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

Re: [Xen-devel] [PATCH v1 04/10] xen/arm: p2m: Update IOMMU mapping whenever possible if page table is not shared

[Oleksandr Tyshchenko]

On Thu, May 11, 2017 at 2:24 PM, Julien Grall  wrote:
> Hi Oleksandr,
Hi Julien

>
> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko 
>>
>> Update IOMMU mapping if the IOMMU doesn't share page table with the CPU.
>> The best place to do so on ARM is __p2m_set_entry(). Use mfn as an
>> indicator
>> of the required action. If mfn is valid call iommu_map_pages(),
>> otherwise - iommu_unmap_pages().
>>
>> Signed-off-by: Oleksandr Tyshchenko 
>> CC: Julien Grall 
>
>
> Acked-by: Julien Grall 
Great. Thank you.

>
>
>>
>> ---
>>Changes in v1:
>>   - Update IOMMU mapping in __p2m_set_entry() instead of
>> p2m_set_entry().
>>   - Pass order argument to IOMMU APIs instead of page_count.
>> ---
>>  xen/arch/arm/p2m.c | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>> index 34d5776..9ca491b 100644
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -984,7 +984,15 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
>>  p2m_free_entry(p2m, orig_pte, level);
>>
>>  if ( need_iommu(p2m->domain) && (p2m_valid(orig_pte) ||
>> p2m_valid(*entry)) )
>> -rc = iommu_iotlb_flush(p2m->domain, gfn_x(sgfn), 1UL <<
>> page_order);
>> +{
>> +if ( iommu_use_hap_pt(p2m->domain) )
>> +rc = iommu_iotlb_flush(p2m->domain, gfn_x(sgfn), 1UL <<
>> page_order);
>> +else if ( !mfn_eq(smfn, INVALID_MFN) )
>> +rc = iommu_map_pages(p2m->domain, gfn_x(sgfn), mfn_x(smfn),
>> + page_order, p2m_get_iommu_flags(t));
>> +else
>> +rc = iommu_unmap_pages(p2m->domain, gfn_x(sgfn), page_order);
>> +}
>>  else
>>  rc = 0;
>>
>>
>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

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

[Xen-devel] [PATCH 4.10 125/129] xen: Revert commits da72ff5bfcb0 and 72a9b186292d

[Greg Kroah-Hartman]

4.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Boris Ostrovsky 

commit 84d582d236dc1f9085e741affc72e9ba061a67c2 upstream.

Recent discussion (http://marc.info/?l=xen-devel=149192184523741)
established that commit 72a9b186292d ("xen: Remove event channel
notification through Xen PCI platform device") (and thus commit
da72ff5bfcb0 ("partially revert "xen: Remove event channel
notification through Xen PCI platform device"")) are unnecessary and,
in fact, prevent HVM guests from booting on Xen releases prior to 4.0

Therefore we revert both of those commits.

The summary of that discussion is below:

  Here is the brief summary of the current situation:

  Before the offending commit (72a9b186292):

  1) INTx does not work because of the reset_watches path.
  2) The reset_watches path is only taken if you have Xen > 4.0
  3) The Linux Kernel by default will use vector inject if the hypervisor
 support. So even INTx does not work no body running the kernel with
 Xen > 4.0 would notice. Unless he explicitly disabled this feature
 either in the kernel or in Xen (and this can only be disabled by
 modifying the code, not user-supported way to do it).

  After the offending commit (+ partial revert):

  1) INTx is no longer support for HVM (only for PV guests).
  2) Any HVM guest The kernel will not boot on Xen < 4.0 which does
 not have vector injection support. Since the only other mode
 supported is INTx which.

  So based on this summary, I think before commit (72a9b186292) we were
  in much better position from a user point of view.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Juergen Gross 
Cc: Boris Ostrovsky 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Konrad Rzeszutek Wilk 
Cc: Bjorn Helgaas 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Vitaly Kuznetsov 
Cc: Paul Gortmaker 
Cc: Ross Lagerwall 
Cc: xen-de...@lists.xenproject.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Anthony Liguori 
Cc: KarimAllah Ahmed 
Signed-off-by: Juergen Gross 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/xen/events.h |   11 +++
 arch/x86/pci/xen.c|2 +-
 arch/x86/xen/enlighten.c  |   21 +++--
 arch/x86/xen/smp.c|2 ++
 arch/x86/xen/time.c   |5 +
 drivers/xen/events/events_base.c  |   26 +-
 drivers/xen/platform-pci.c|   13 +++--
 include/xen/xen.h |3 ++-
 8 files changed, 56 insertions(+), 27 deletions(-)

--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -20,4 +20,15 @@ static inline int xen_irqs_disabled(stru
 /* No need for a barrier -- XCHG is a barrier on x86. */
 #define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
 
+extern int xen_have_vector_callback;
+
+/*
+ * Events delivered via platform PCI interrupts are always
+ * routed to vcpu 0 and hence cannot be rebound.
+ */
+static inline bool xen_support_evtchn_rebind(void)
+{
+   return (!xen_hvm_domain() || xen_have_vector_callback);
+}
+
 #endif /* _ASM_X86_XEN_EVENTS_H */
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -447,7 +447,7 @@ void __init xen_msi_init(void)
 
 int __init pci_xen_hvm_init(void)
 {
-   if (!xen_feature(XENFEAT_hvm_pirqs))
+   if (!xen_have_vector_callback || !xen_feature(XENFEAT_hvm_pirqs))
return 0;
 
 #ifdef CONFIG_ACPI
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -137,6 +137,8 @@ struct shared_info xen_dummy_shared_info
 void *xen_initial_gdt;
 
 RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
+__read_mostly int xen_have_vector_callback;
+EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
 static int xen_cpu_up_prepare(unsigned int cpu);
 static int xen_cpu_up_online(unsigned int cpu);
@@ -1508,7 +1510,10 @@ static void __init xen_pvh_early_guest_i
if (!xen_feature(XENFEAT_auto_translated_physmap))
return;
 
-   BUG_ON(!xen_feature(XENFEAT_hvm_callback_vector));
+   if (!xen_feature(XENFEAT_hvm_callback_vector))
+   return;
+
+   xen_have_vector_callback = 1;
 
xen_pvh_early_cpu_init(0, false);
xen_pvh_set_cr_flags(0);
@@ -1847,7 +1852,9 @@ static int xen_cpu_up_prepare(unsigned i
xen_vcpu_setup(cpu);
}
 
-   if (xen_pv_domain() || xen_feature(XENFEAT_hvm_safe_pvclock))
+   if (xen_pv_domain() ||
+   (xen_have_vector_callback &&
+

Re: [Xen-devel] [PATCH v1 10/10] xen/arm: domain_build: Don't expose the "iommus" property to the guest

[Oleksandr Tyshchenko]

On Thu, May 11, 2017 at 2:58 PM, Julien Grall  wrote:
> Hi Oleksandr,
Hi Julien

>
> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko 
>>
>> We don't passthrough IOMMU device to DOM0 even if it is not used by
>> Xen. Therefore exposing the property that describes the IOMMU
>> master interfaces of the device does not make any sense.
>>
>> Signed-off-by: Oleksandr Tyshchenko 
>> ---
>>  xen/arch/arm/domain_build.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 3abacc0..2defb60 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -432,6 +432,10 @@ static int write_properties(struct domain *d, struct
>> kernel_info *kinfo,
>>  continue;
>>  }
>>
>> +/* Don't expose the property "iommus" to the guest */
>> +if ( dt_property_name_is_equal(prop, "iommus") )
>> +continue;
>
>
> It would be useful to have a link to the bindings associated
> (Documentation/devicetree/bindings/iommu/iommu.txt).
Agree. I will mention it in commit description.

>
> Also, whilst you are at it, you likely want to remove all the other iommu
> properties such as iommu-map.
Excuse me, I have never heard about it. Is it a required property?

>
>> +
>>  res = fdt_property(kinfo->fdt, prop->name, prop_data, prop_len);
>>
>>  if ( res )
>>
>
> Cheers,
>
> --
> Julien Grall


-- 
Regards,

Oleksandr Tyshchenko

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

Re: [Xen-devel] [PATCH for-4.9] xl: don't ignore return value from libxl_device_events_handler

[Roger Pau Monné]

On Thu, May 11, 2017 at 01:57:19PM +0100, Wei Liu wrote:
> That function can return a whole slew of error codes. Translate them
> to EXIT_FAILURE.
> 
> Signed-off-by: Wei Liu 

Acked-by: Roger Pau Monné 


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

[Xen-devel] [PATCH 4.11 27/28] xen: Revert commits da72ff5bfcb0 and 72a9b186292d

[Greg Kroah-Hartman]

4.11-stable review patch.  If anyone has any objections, please let me know.

--

From: Boris Ostrovsky 

commit 84d582d236dc1f9085e741affc72e9ba061a67c2 upstream.

Recent discussion (http://marc.info/?l=xen-devel=149192184523741)
established that commit 72a9b186292d ("xen: Remove event channel
notification through Xen PCI platform device") (and thus commit
da72ff5bfcb0 ("partially revert "xen: Remove event channel
notification through Xen PCI platform device"")) are unnecessary and,
in fact, prevent HVM guests from booting on Xen releases prior to 4.0

Therefore we revert both of those commits.

The summary of that discussion is below:

  Here is the brief summary of the current situation:

  Before the offending commit (72a9b186292):

  1) INTx does not work because of the reset_watches path.
  2) The reset_watches path is only taken if you have Xen > 4.0
  3) The Linux Kernel by default will use vector inject if the hypervisor
 support. So even INTx does not work no body running the kernel with
 Xen > 4.0 would notice. Unless he explicitly disabled this feature
 either in the kernel or in Xen (and this can only be disabled by
 modifying the code, not user-supported way to do it).

  After the offending commit (+ partial revert):

  1) INTx is no longer support for HVM (only for PV guests).
  2) Any HVM guest The kernel will not boot on Xen < 4.0 which does
 not have vector injection support. Since the only other mode
 supported is INTx which.

  So based on this summary, I think before commit (72a9b186292) we were
  in much better position from a user point of view.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Juergen Gross 
Cc: Boris Ostrovsky 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Konrad Rzeszutek Wilk 
Cc: Bjorn Helgaas 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Vitaly Kuznetsov 
Cc: Paul Gortmaker 
Cc: Ross Lagerwall 
Cc: xen-de...@lists.xenproject.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Anthony Liguori 
Cc: KarimAllah Ahmed 
Signed-off-by: Juergen Gross 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/xen/events.h |   11 +++
 arch/x86/pci/xen.c|2 +-
 arch/x86/xen/enlighten.c  |   16 +++-
 arch/x86/xen/smp.c|2 ++
 arch/x86/xen/time.c   |5 +
 drivers/xen/events/events_base.c  |   26 +-
 drivers/xen/platform-pci.c|   13 +++--
 7 files changed, 50 insertions(+), 25 deletions(-)

--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -20,4 +20,15 @@ static inline int xen_irqs_disabled(stru
 /* No need for a barrier -- XCHG is a barrier on x86. */
 #define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
 
+extern int xen_have_vector_callback;
+
+/*
+ * Events delivered via platform PCI interrupts are always
+ * routed to vcpu 0 and hence cannot be rebound.
+ */
+static inline bool xen_support_evtchn_rebind(void)
+{
+   return (!xen_hvm_domain() || xen_have_vector_callback);
+}
+
 #endif /* _ASM_X86_XEN_EVENTS_H */
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -447,7 +447,7 @@ void __init xen_msi_init(void)
 
 int __init pci_xen_hvm_init(void)
 {
-   if (!xen_feature(XENFEAT_hvm_pirqs))
+   if (!xen_have_vector_callback || !xen_feature(XENFEAT_hvm_pirqs))
return 0;
 
 #ifdef CONFIG_ACPI
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -138,6 +138,8 @@ struct shared_info xen_dummy_shared_info
 void *xen_initial_gdt;
 
 RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
+__read_mostly int xen_have_vector_callback;
+EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
 static int xen_cpu_up_prepare(unsigned int cpu);
 static int xen_cpu_up_online(unsigned int cpu);
@@ -1861,7 +1863,9 @@ static int xen_cpu_up_prepare(unsigned i
xen_vcpu_setup(cpu);
}
 
-   if (xen_pv_domain() || xen_feature(XENFEAT_hvm_safe_pvclock))
+   if (xen_pv_domain() ||
+   (xen_have_vector_callback &&
+xen_feature(XENFEAT_hvm_safe_pvclock)))
xen_setup_timer(cpu);
 
rc = xen_smp_intr_init(cpu);
@@ -1877,7 +1881,9 @@ static int xen_cpu_dead(unsigned int cpu
 {
xen_smp_intr_free(cpu);
 
-   if (xen_pv_domain() || xen_feature(XENFEAT_hvm_safe_pvclock))
+   if (xen_pv_domain() ||
+   (xen_have_vector_callback &&
+xen_feature(XENFEAT_hvm_safe_pvclock)))
xen_teardown_timer(cpu);
 

Re: [Xen-devel] [PATCH v1 09/10] xen/arm: Add use_iommu flag to xen_arch_domainconfig

[Oleksandr Tyshchenko]

On Thu, May 11, 2017 at 2:42 PM, Julien Grall  wrote:
> Hi Oleksandr,
Hi Julien

>
>
> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko 
>>
>> This flag is intended to let Xen know that the guest has devices
>> which will most likely be used for passthrough and as the result
>> the use of IOMMU is expected for this domain.
>> The primary aim of this knowledge is to help the IOMMUs that don't
>> share page tables with the CPU on ARM be ready before P2M code starts
>> updating IOMMU mapping.
>> So, if this flag is set the non-shared IOMMUs will populate
>> their page tables at the domain creation time and thereby will be able
>> to handle IOMMU mapping updates from *the very beginning*.
>>
>> In order to retain the current behavior for x86 still call
>> iommu_domain_init() with use_iommu flag being forced to false.
>>
>> Signed-off-by: Oleksandr Tyshchenko 
>> CC: Jan Beulich 
>> CC: Julien Grall 
>> CC: Ian Jackson 
>> CC: Wei Liu 
>>
>> ---
>>Changes in V1:
>>   - Treat use_iommu flag as the ARM decision only. Don't use
>> common domain creation flag for it, use ARM config instead.
>>   - Clarify patch subject/description.
>> ---
>>  tools/libxl/libxl_arm.c   | 10 ++
>>  xen/arch/arm/domain.c |  2 +-
>>  xen/include/public/arch-arm.h |  5 +
>>  3 files changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>> index d842d88..9c4705e 100644
>> --- a/tools/libxl/libxl_arm.c
>> +++ b/tools/libxl/libxl_arm.c
>> @@ -78,6 +78,16 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>>  return ERROR_FAIL;
>>  }
>>
>> +/* TODO Are these assumptions enough to make decision about using
>> IOMMU? */
>> +if ((d_config->num_dtdevs && d_config->dtdevs) ||
>> +(d_config->num_pcidevs && d_config->pcidevs))
>
>
> Checking num_dtdevs and num_pcidevs is enough. It would be a bug if dtdevs
> and pcidevs are not null.
ok

>
>> +xc_config->use_iommu = 1;
>> +else
>> +xc_config->use_iommu = 0;
>> +
>> +LOG(DEBUG, "The use of IOMMU %s expected for this domain",
>> +xc_config->use_iommu ? "is" : "isn't");
>> +
>>  return 0;
>>  }
>>
>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>> index ec19310..81c4b90 100644
>> --- a/xen/arch/arm/domain.c
>> +++ b/xen/arch/arm/domain.c
>> @@ -569,7 +569,7 @@ int arch_domain_create(struct domain *d, unsigned int
>> domcr_flags,
>>  ASSERT(config != NULL);
>>
>>  /* p2m_init relies on some value initialized by the IOMMU subsystem
>> */
>> -if ( (rc = iommu_domain_init(d, false)) != 0 )
>> +if ( (rc = iommu_domain_init(d, config->use_iommu ? true : false)) !=
>> 0 )
>
>
> !!config->use_iommu is enough.
ok

>
>>  goto fail;
>>
>>  if ( (rc = p2m_init(d)) != 0 )
>> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
>> index bd974fb..cb33f75 100644
>> --- a/xen/include/public/arch-arm.h
>> +++ b/xen/include/public/arch-arm.h
>> @@ -322,6 +322,11 @@ struct xen_arch_domainconfig {
>>   *
>>   */
>>  uint32_t clock_frequency;
>> +/*
>> + * IN
>> + * Inform the hypervisor that the use of IOMMU is expected for this
>> domain.
>
>
> I would simplify to : "IOMMU is expected to be used for this domain".
ok

>
>> + */
>> +uint8_t use_iommu;
>>  };
>>  #endif /* __XEN__ || __XEN_TOOLS__ */
>>
>>
>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

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

[Xen-devel] [linux-4.9 test] 109296: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2   6 xen-boot fail REGR. vs. 107358

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 109240 pass in 
109260
 test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-stop fail in 109240 pass in 109296
 test-amd64-i386-xl-qemuu-winxpsp3 16 guest-stop  fail in 109240 pass in 109296
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 109260 
pass in 109296
 test-armhf-armhf-libvirt-xsm  5 xen-install  fail in 109260 pass in 109296
 test-amd64-amd64-xl-qemuu-winxpsp3 17 guest-start/win.repeat fail in 109260 
pass in 109296
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail pass in 
109240
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
109260
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail pass in 
109260

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 107358
 test-amd64-amd64-xl-rtds  9 debian-install   fail REGR. vs. 107358

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop  fail in 109240 like 107358
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stopfail in 109240 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-start/win.repeat fail in 109260 
like 107358
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail like 107358
 test-armhf-armhf-libvirt-raw  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-rtds  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-xsm   6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-vhd   6 xen-boot fail  like 107358
 test-armhf-armhf-xl   6 xen-boot fail  like 107358
 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-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   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-arndale   6 xen-boot fail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass

version targeted for testing:
 linux89f3b8d5f264d5dab9818c6667c71e3cc55b13f5
baseline version:
 linux37feaf8095d352014555b82adb4a04609ca17d3f

Last test of basis   107358  2017-04-10 19:42:52 Z   30 days
Failing since107396  2017-04-12 11:15:19 Z   29 days   49 attempts
Testing same since   109171  2017-05-08 09:58:59 Z3 days6 attempts


334 people touched 

Re: [Xen-devel] [PATCH v1 07/10] iommu/arm: Add alloc_page_table platform callback

[Oleksandr Tyshchenko]

On Thu, May 11, 2017 at 2:38 PM, Julien Grall  wrote:
> Hi Oleksandr,
Hi, Julien

>
> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko 
>>
>> The alloc_page_table callback is a mandatory thing
>> for the IOMMUs that don't share page table with the CPU on ARM.
>> The non-shared IOMMUs have to perform all required actions here
>> to be ready to handle IOMMU mapping updates right after completing it.
>>
>> The arch_iommu_populate_page_table() seems an appropriate place
>> to call newly created callback.
>> Since we will only be here for the non-shared IOMMUs always
>> return error if the callback wasn't implemented.
>
>
> Why do you need a specific callback and not doing it directly in
> iommu_domain_init?
>
> My take here is in the unshare case, we may want to have multiple set of
> page tables (e.g one per device). So this should be left at the discretion
> of the IOMMU itself.
>
> Am I missing something?
I was thinking about extra need_iommu argument for init platform
callback as I had done for iommu_domain_init API.
But I had doubts regarding hw_domain. During iommu_domain_init
execution we haven't known yet is the IOMMU expected for domain 0
or not.

Taking into account that I needed to:
- populate page table followed by setting need_iommu flag.
- implement arch_iommu_populate_page_table() on ARM because of
!iommu_use_hap_pt(d).
- find a solution for hw_domain.

I decided to use iommu_construct() and implement alloc_page_table
callback to be called for populating page table.
I thought that it would allow us to keep all required actions in a
single place rather than spreading.

>
>
>>
>> Signed-off-by: Oleksandr Tyshchenko 
>> CC: Jan Beulich 
>>
>> ---
>>Changes in V1:
>>   - Wrap callback in #ifdef CONFIG_ARM.
>> ---
>>  xen/drivers/passthrough/arm/iommu.c | 5 +++--
>>  xen/include/xen/iommu.h | 3 +++
>>  2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/drivers/passthrough/arm/iommu.c
>> b/xen/drivers/passthrough/arm/iommu.c
>> index 95b1abb..f132032 100644
>> --- a/xen/drivers/passthrough/arm/iommu.c
>> +++ b/xen/drivers/passthrough/arm/iommu.c
>> @@ -70,6 +70,7 @@ void arch_iommu_domain_destroy(struct domain *d)
>>
>>  int arch_iommu_populate_page_table(struct domain *d)
>>  {
>> -/* The IOMMU shares the p2m with the CPU */
>> -return -ENOSYS;
>> +const struct iommu_ops *ops = iommu_get_ops();
>> +
>> +return ops->alloc_page_table ? ops->alloc_page_table(d) : -ENOSYS;
>>  }
>> diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
>> index 3afbc3b..f5914db 100644
>> --- a/xen/include/xen/iommu.h
>> +++ b/xen/include/xen/iommu.h
>> @@ -175,6 +175,9 @@ struct iommu_ops {
>>unsigned int flags);
>>  int __must_check (*unmap_pages)(struct domain *d, unsigned long gfn,
>>  unsigned int order);
>> +#ifdef CONFIG_ARM
>> +int (*alloc_page_table)(struct domain *d);
>> +#endif /* CONFIG_ARM */
>>  void (*free_page_table)(struct page_info *);
>>  #ifdef CONFIG_X86
>>  void (*update_ire_from_apic)(unsigned int apic, unsigned int reg,
>> unsigned int value);
>>
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 29dc8aa861fac78c6d62391dff312db934b755e3
baseline version:
 ovmf a6c31c6d6349a51041d8b77df375c340043e36bd

Last test of basis   109308  2017-05-11 07:57:17 Z0 days
Testing same since   109312  2017-05-11 10:45:18 Z0 days1 attempts


People who touched revisions under test:
  Chao Zhang 
  Jeff Fan 
  Zhang, Chao B 

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=29dc8aa861fac78c6d62391dff312db934b755e3
+ . ./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 
29dc8aa861fac78c6d62391dff312db934b755e3
+ branch=ovmf
+ revision=29dc8aa861fac78c6d62391dff312db934b755e3
+ . ./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.8-testing
+ '[' x29dc8aa861fac78c6d62391dff312db934b755e3 = 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] public/elfnote: document non-alignment of relocated init-P2M

[Andrew Cooper]

On 09/05/17 16:23, Jan Beulich wrote:
 On 09.05.17 at 17:10,  wrote:
>> On 09/05/17 15:23, Jan Beulich wrote:
>>> Since PV kernels can't use large pages anywa, when the init-P2M support
>> anyway
> Already fixed after Alan pointed this out. Do I need to send v2
> because of this typo?

No.  Acked-by: Andrew Cooper 

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